Kabissa recognizes that Wikis are powerful online collaboration tools. We have had an “intranet” wiki as a team/project management tool for over a year, and it has been a very useful addition to our other typical office tools (shared file server, e-mail, etc). With it, a team of people spread across the globe is able to work closely together, and new people can quickly get up to speed with Kabissa's organizational logistics, policies and procedures. This last is very important because we have several intern positions that are regularly being filled by new people.
But as exemplified by the Wikipedia Online Encylopedia1), the revolutionary value of wikis is in using them for collaboratively working on text-based resources. Wikipedia is the prime example of a large scale Wiki encyclopedia project, with its thousands of contributors creating a tremendously valuable shared resource used by millions of people around the world.
To explore this potential on a smaller scale and to address the shared ICT capacity building needs of Kabissa, our training partners, collaborators and 900+ member organizations in African civil society, Kabissa will wikify (create a wiki version) of Kabissa's popular Time To Get Online Internet training manual. Our goal is to produce a wiki version of the guide that is more readily accessible through a web browser and can be contributed to and used in revolutionary new ways.
In 2003, Kabissa launched the Time to Get Online program, which combines self-learning materials with hands-on workshops to empower African organizations to fully integrate the Internet into their work. The program is designed specifically for the needs of African civil society organizations and structured around Kabissa’s Steps to Success methodology. This methodology promotes the idea that organizations must gradually build their Internet skills and use those Internet tools most appropriate for their own priorities, communities, and environment.
Responding to the demands of past Time to Get Online workshop participants, Kabissa incorporated a Training-of-Trainers (TOT) program in 2005. This intensive program is designed to prepare trainers from civil society organizations with the tools needed to conduct their own Time to Get Online workshops. The program covers approaches for training adult learners, specific Time to Get Online content, and the development of sustainability plans. The TOT model creates more learning opportunites for organizations throughout the region and empowers a network of ICT training partners to adapt the curriculum to the needs of their own communities.
Time To Get Online has been very successful and has become an integral part of Kabissa's identity as a capacity building organization in Africa. The manual is a trusted source by all organizations that participate in our workshops and otherwise get their hands on a copy, and our training partners have been very busy spreading the benefits of the program in their communities through their own workshops.
More information about the program is available at http://www.timetogetonline.org
The 150 page core manual is currently produced using Microsoft Word and is published both online as an Adobe Acrobat PDF file and in print form in a sturdy and user-friendly binder. We use an attractive, consistent layout based on tables and large icons separating different kinds of information (e.g. exercises, key points, case studies, etc) for easy reading. Where possible, we use screen shots to illustrate points. The printed binder version has large tabs to make chapters and appendices easy to find, and is accompanied by a CD-ROM containing a useful range of Free and Open Source Software, full websites and further reading materials discussed in the manual.
The manual is updated by Kabissa when we are funded to support or run training workshops. Thus far it has been published and used for workshops in English, French and Arabic. The latest version can be downloaded from the Time To Get Online website.
The current production method has served us very well and enabled us to produce top quality training materials. However, Kabissa now has many training partners wishing to contribute to the manual and adapt it for their local conditions. We also have a growing number of members that are seeking to benefit from the lessons in the manual and do not have access to face to face workshops.
| Microsoft Word | Wiki |
| Single word document for each version that can only be edited by one person at a time under close Kabissa supervision, which slows production | Single online resource that can be edited by many people at the same time and used to produce various versions |
| Cumbersome formatting and layout issues in Word that need to be taken care of on an iterative basis as part of the quality control provided by Kabissa | Wikis separate formatting from content, so it is possible to have people working all the time on improving the content without concern for layout |
| Only able to produce one version at a time, while training needs call for different versions for different communities that can be produced quickly (for example just focussing on a region like West Africa or just focusing on a sector like Youth) | With Wikis there is an opportunity to customize outputs to quickly generate versions that can be customized for different audiences or trainings |
| There is no accessible, structured means for our training partners and other collaborators to discuss and arrive at improvements to specific sections of the manual, or to contribute case studies or related resources for their communities | Wikis include a “discussion” feature to enable discussion about specific sections. |
| “Versioning” is possible in Word through “track changes” but becomes cumbersome as the document grows in size, and is difficult to share work with collaborators and virtually impossible to share benefits between concurrent versions | One of the great features of Wikis is that all versions are kept - going back to the beginning when a Wiki page was created. This makes it easier to share the work (since it is possible to revert changes later) |
| For readers trying to make use of the free PDF download, the document is of limited use because it is so large (150+ pages) and is not designed for online reading. | Wikis are designed to be read online with online search and navigation. |
There are several challenges we will need to keep in mind when moving our manual from Word to Wiki. For one thing, there is a potentially steep learning curve for new people to learn how to contribute to wikis. Wikis use a markup syntax, much like HTML but simpler, to handle formatting of documents, inserting images and links, and automatically generating titles and navigation menus. This syntax can be tricky to learn, particularly for those not familiar already with HTML code and other similar formatting syntax. To make matters worse, the syntax varies somewhat between Wiki tools so if you know how to contribute to, for example, Wikipedia, you may still have to learn some new syntax to contribute to another wiki project. However, the wiki syntax is fairly straightforward and committed collaborators will be able to get up to speed quickly without training. Some wiki tools get around this issue with WYSIWYG editors, online help, keyboard shortcuts (e.g. CTRL-B for bold) and toolbars for commonly needed syntax.
Another related issue for new collaborators is that, to view a wiki page with formatting as it will be seen in its final form, a web server is required. It is possible to install a web server on a PC and web servers come installed on Linux and Mac OSX systems, but still the web server requirement may be a stumbling block for those mainly familiar with typical Microsoft Office software. So while it is possible to work with plain text files offline to develop wiki pages, it is not possible to see the results without access to a web server and wiki tool either on the Internet or on the PC. Initially this will not be an issue since only the Kabissa team and close collaborators with good Internet connectivity will be editing the wiki. Down the road, we may need to address this issue by providing more support to collaborators in Africa with poor or intermittent Internet access.
Wikis require constant “gardening”. While it is beneficial to enable multiple people to edit and contribute to a wiki, the web is full of examples of poorly managed wikis that become unusable. For a team wiki a certain amount of managed disorder is acceptable, with many works in progress, notes, and discussions related to various areas of work, but of course for a larger project intended for wider consumption this is not acceptable. A disciplined workflow is needed with good communication among all collaborators, with a chief editor that is in charge of quality control for the whole document. Wikis have features to facilitate the collaboration process, enabling collaborators to closely monitor all changes made by everyone, and to compare recent changes with past versions. If they are unhappy with a change, they can revert back to an older version if needed, and then start a discussion about the proposed changes with others.
Access Control for contributing to various sections of the document will be a concern once we open up the wiki for use by our training partners and other collaborators, members and the general public. Initially we will want only the Kabissa team editing pages, then once the content has been completely transferred from the word document we will want to open up access gradually to others. As we provide read/write access to others, we will need to train them and provide them with guidance on editorial guidelines for everyone to follow. Ultimately an ideal goal is to provide complete read/write access to our training partners and perhaps write access to the rest of the world for specific sections where we want broad public involvement (e.g. case studies or resources).
Wikis separate content from presentation through the use of customizable templates. By default these typically are designed for relatively simple documents. A challenge will be to customize the templates to suit the unique presentation needs of our manual. In particular, to produce downloadable PDF versions and print versions will require significantly customized templates.
In our implementation plan, we list all of our known requirements and preferences in detail. A strong emphasis is on open source, so that the tool we use and contribute to is available to other African civil society organizations. It also must be user-friendly and relatively easy for us to install, configure and begin using in our existing Joomla CMS enviroment. As we move along, we must also be able to expand the functionality to meet our future needs. The choice we make now is important, however thanks to the consistent syntax used by wikis and conversion tools available it is possible to migrate from one wiki tool to another later if our needs change.
There are many competing wiki tools available, and thankfully there is an excellent website called WikiMatrix.org which provides detailed descriptions of wiki tools available and line by line feature comparisons.
We have firsthand experience with three wiki tools that stand out from the crowd. These are (with links to their WikiMatrix descriptions) as follows:
MediaWiki is the open source wiki tool that drives Wikipedia. It is very powerful, clearly can be used for very large projects, and has sophisticated collaboration features (access permissions, page discussions, user discussions, etc). Because it is the largest wiki project, it has a large community of developers and contributors to the software, and seems most likely to have conversion tools and add-on functionality.
DokuWiki is an open source wiki tool that Kabissa has been using for our team wiki for the last year. It has a straightforward syntax and is very userfriendly and simple to use compared to other wiki tools. DokuWiki has an impressive pluggable technology which means that by default there is a simple feature set but it is easy to add a range of add-on functionality as needed. There is a very active developer community working on all sorts of interesting web 2.0 functionality. Integrations are possible with the WordPress blogging tool, our own Joomla content management system, and more. Dokuwiki uses plain text to store wiki pages so has relatively light server requirements (no database server required).
Confluence Wiki is not open source but available for free for nonprofit use. As a commercial product it is very polished and has very powerful functionality by default (excellent
WYSIWYG editor, sophisticated file management, access controls and more). Unfortunately Confluence has very heavy server requirements so it is not straightforward to host it on our own server.
Based on our research and the very useful feature comparison at wikimatrix.org, we have decided to continue working with DokuWiki for this project.
Contributed by Ryan Cargo, Special Projects Intern at Kabissa, Spring 2006.
Converting the TTGO materials to a wiki format required both a technical and contextual review of the material. The technical side included the addition of wiki syntax, creation of wiki-specific images, layout of templates for ease of use, and organization based on wiki’s content structure. The contextual side included reformatting and rewriting the materials to best suit the change in publishing mediums.
Overall the wiki syntax learning curve is fairly minor, although I did have prior experience with HTML and several programming languages. The wiki syntax is straightforward and Dokuwiki provides an efficient means of previewing your page while editing its code. Icons, example images, and screenshots used in the wiki all required individual attention in a separate imaging application (e.g. Adobe Photoshop). This ranged from resizing to the addition of borders and arrows to call out areas of importance. Laying out the TTGO wiki using templates required attention at the administrative level of the wiki, and thus are not features that will be adjustable by future users.
Organizing the content based on Dokuwiki’s file structure warranted special attention which was ultimately worthwhile. Although technically identical to Window’s file and folder structure, the wiki’s organization by “namespace” and “page” is a bit harder to conceptualize. However, many important functionalities (e.g. automatically generated table of contents) depend on the proper setup of this hierarchy. Keeping with this structure will be important as the TTGO wiki grows, and may warrant special explanation for future contributors.
Much of the review necessary stemmed not from the conversion to a wiki format, but from the TTGO materials being over two years old. Updates included verifying that online references were still available and revising mentions of current internet technologies and software (e.g. Mozilla Firefox’s rising popularity over Netscape Navigator’s). Some content, however, did require changes due to the change in publication medium. References relevant only to a printed version, such as “See Page 37”, were changed to an active link to that page in the wiki. Additionally, care was taken so that no information would be lost should the wiki be printed, for example all links to external websites included the full URL as a footnote.
Some general considerations arose from the possibility that the wiki’s audience may have slightly different interests than those of the printed version. Because the wiki format may be used more as a reference than a cover-to-cover guide, the ability to search, a more detailed sub-chapter table of contents, and easier linking to outside sources was desired. In addition the icons used in the printed version were revised to provide streamlined visual cues for quickly finding information of interest. Despite these considerations, a means to “page through” the materials was still provided for those wanting to read an entire chapter at a time.
Summarizing the time required to convert the TTGO materials into an hours / page value is not only difficult, but would be somewhat misleading based on the lessons learned from the entire process. Converting the raw content from Word format to the wiki was merely an exaggerated exercise of cut-and-paste once coding and formatting standards were settled upon. Editing and inserting the images, while tedious, was also straightforward once a routine system was begun. However, the universal changes to the wiki after its conversion as a whole were painstakingly slow, as described further in the Lessons Learned section.
Deciding on a universal format for the wiki before the entire contents have been wikified seems to be the deciding factor when it comes to efficiently implementing a wiki. Although we conducted a serious internal (and to a certain extent, external) review of the format used for the first test chapter, the standards decided upon based on that review were ultimately changed significantly. Unfortunately, these changes were not made before the rest of the materials were wikified, so extensive work on every page was duplicated. It can not be stressed enough that making universal changes to an extensive, existing wiki is vastly more time consuming than simply doing so in the initial, one-time-only conversion process.
While the wiki has not yet been released for use, it appears that most of the proposed benefits of its format will be fulfilled. After interacting with the wiki during the creation of these online TTGO materials, the only concern I have regards the commitment required by users to learn and understand how the wiki works before editing and contributing to it. In the meantime, slightly more gardening may be required by the administrators. These concerns, however, could easily be alleviated by the addition of material specifically about the wiki to the TTGO materials.
Results of TTGO Screen Casting!
The recorded results of our first three volunteers interacting with the TTGO Wiki are in! Their experiences were recorded in nearly 60 minutes of screen casts which reveal a lot about both the successes of our format and some areas we need to work on. The findings are listed below, I'll try to tackle some of these issues in the coming weeks. Note that some findings are just interesting and may not need any action whatsoever. — Ryan Cargo 2007/05/01 10:47
On a final note, screen casting was the perfect tool to test usability in this situation. Sound enabled the reviewer to hear when a user was trying to click something that wasn't clickable, or sense verbal frustration / excitement at the wiki. It also gave a real sense of the time it took users to complete various functions and navigate the wiki in general.