PRAGUE, Czech Republic, 07 July 2006
“The word wiki is a shorter form of wiki wiki (weekie, weekie) which is from native Hawaiian, in which it is commonly used as an adjective to denote something ‘quick’ or ‘fast’,” says Wikipedia, the world’s most important collaborative online encyclopaedia.
Fast and quick, they are. But did you know they were free and open?
While shedding light on the larger context of free and open source software (FOSS) developed tools, this second article on wikis looks at the concrete experience APC’s Strategic Uses and Capacity Building (SU&CB) programme made with wikis. It delves into the MediaWiki and the TikiWiki.
Wikis are free
Most wikis are free and open source projects and they are published under GPL (General Public License) on a repository called Sourceforge. Large development communities nourish these projects on a voluntary basis. The fact that wikis are open source gave the way to development of many variations of the tool, thus benefiting from easy wiki publishing when using them for different specific purposes.
APC’s long time focus is on promotion and demystification of free and open source tools. Therefore it was only natural that along with using the ActionApps and other FOSS content publishing tools, APC started to experiment with wikis. Due to its innovativeness and easiness of content structuring, wikis became a major APC tool for collaborative work.
However, not only was APC “infected” by the interest in wikis. Because of their free availability and the media attention caught by Wikipedia, wikis have over the last few years experienced a real boom of usage. Since their release, some scored millions of downloads and many companies and organisations use them as their main collaborative spaces as well as a replacement for intranets.
Wikis for documentation
It is increasingly common to use some type of wiki as a platform for development of FOSS project documentation. First, wikis have become much more flexible in terms of layout design. More importantly, however, open source project depend on community involvement in the development, which applies both to the application itself, as well as the documentation.
Here again, the wiki makes it easy for anyone to contribute, without having to rely on special access to documentation administration. MediaWiki was the choice for the development of the ActionApps content management system (CMS) documentation. Wikis, it is interesting to note, have also been used as a documentation platform for a number of GNU/Linux distributions. Count Ubuntu and Knopix as two important illustrations of this.
Type of wiki
The combination of tools that we get with a wiki depends on the type of wiki. Each wiki can include a number of "wiki features", as well as "non wiki tools which may be part of the package" (eg. online calendar). TikiWiki, for example, is a comprehensive groupware platform which includes wiki tool among other tools. MediaWiki, on the other hand, is a dedicated wiki tool. This distinction is important when looking at the pros and cons of opting for one type of wiki over another.
Are you just looking for a wiki? Then MediaWiki (and some others) may be the best choice. If you are looking for an integrated groupware platform, MediaWiki will not be the thing at all, and you would probably choose TikiWiki.
To give an example from real life, APC’s Strategic Use and Capacity Building Programme uses a number of features on its internal wiki, which are not typical wiki features. These are image galleries, article type publishing features (called “Articles”), a functionality allowing to import and display sheet-type files (TikiSheet), and others. All these functionalities are available in a number of other FOSS publishing tools. However, to have them all in one place, it was chosen to use TikiWiki, a wiki that includes a large number of functionalities, additional to the simple wiki publishing.
The non wiki tools that come with the wiki “package” are usually separate installable plug-ins. For instance, TikiWiki currently offers 60+ plug-ins that further extend its functionalities. [See the Wiki software comparison table for details on the functionalities available through different types of wikis (link at the bottom)].
Following are some basic distinction between two commonly used types of wikis, the TikiWiki and MediaWiki.
TikiWiki is a more “conventional” wiki where most formatting and structuring of every wiki page is done manually. Therefore, the output design mirrors closely what you paste to the online form. This makes TikiWiki maximally simple to use and a superb tool for note taking and online collaborative work. The cost (or possibly benefits) of its simplicity, may be some limits in output.
MediaWiki generally provides you with more sophisticated outcome design than TikiWiki. Some of the features that make it graphically more attractive are (semi) automated, such as the creation of page indexes. By inserting proper syntax into the input forms, the page breaks down into a structure whose sections can not only be edited separately, but they also behave as separate database entries. Such chunks of text will appear as separate chapters that have neatly distinguished graphics at the output.
As already mentioned, media wiki was chosen as a platform for the development of documentation for ActionApps content management system (see http://actionapps.org). The documentation is not being developed centrally, but it is open to community contributions. Thus, the first requirement on the wiki was that the output content “looks good”, without the contributor having to spend too much effort on formatting. Secondly, MediaWiki allows an easy insertion of illustrative images directly into the text, without having to use html code.
One more very nice feature has influenced opting for MediaWiki: ActionApps documentation is being developed in parallel in two languages, English and Spanish. By inserting a small script at the bottom of each page, the pages of different language mutations can be mutually interlinked. That way, if some documentation section is developed in one language only, or it is better developed in one of the languages, by clicking on “English” (or “Spanish”), the reader can jump directly into the same section written in the other language.
MediaWiki is more handy for creating public sites than TikiWiki (it takes far less formatting and editing to create a decently looking wiki-based site).
Other types of wikis
There is no one platform that clearly stands out. As the development of different wikis has been driven by different needs, each wiki is good for some specific purpose. APC currently uses Tikiwiki and MediaWiki. Other commonly used free wikis are Kwiki, Twiki (designed specifically as an enterprise collaboration platform), Docuwiki and others. The list of all existing types of wiki software is long. [See the comprehensive list and comparison table of different wikis at the bottom].
Before installing a wiki, it is advisable to do a good mapping of feature requirements and to read the comparison table as well as projects’ online forums. That way, you have a good chance that you chose the wiki that best matches your needs.
Issues related to using (not only) wikis for online collaboration
In the following section, we point out several issues one should be aware of when planning to use wikis. We also mention some issues related to Tikiwiki specifically, as it is the wiki that APC’s Strategic Use and Capacity Building Programme has most experience with.
Issues related to wikis in general
Automatised spammers look for wikis and try to post unwanted content there (particularly malicious code). As they become more sophisticated it is increasingly easy for these robots to attack an unprotected wiki (a completely open one – where you come, click the edit button and publish…). Forcing wiki users to create an account and logging in before being able to modify wiki content addresses this problem. Creating such an account is a simple half-minute work. This helps, but does not warn the spammers off completely. The MediaWiki used for ActionApps documentation has experienced a number of spammer postings, although a login is required to edit.
Anything as open as a wiki is also vulnerable. If anyone can edit a wiki, which allows the use of html code, anyone can also insert malicious code (not just incorrect content)
The main advantage can become a problem, when uninvited people or machines stick their hands into your work and introduce unwanted changes (issue often discussed in relation to Wikipedia). Wiki has a history log where you can always roll back to the version prior to the undesired changes. However, if this need arises too frequently, this might become a problem in terms of need for having someone to keep an eye on the content constantly (which we usually don’t, when developing a collaborative project online)
If the wiki is installed really badly – with no permissions system in place – any site visitor can behave as super administrator and he/she can delete the whole wiki installation. If that happens and you don’t have a back up, there is no history to roll back to.
Yet another language to learn
If you want to achieve more than basic default wiki formatting, while retaining simplicity of wiki usage, you would use the internal wiki formatting syntax. It is relatively simple (formatting options are limited) so it is manageable to learn and use without any extensive training (you would be fine just using one of online manuals, see examples below). Still, whatever easy it is to learn, wiki syntax is probably unrelated to any website publishing syntax you have used before. Also note that different wikis often use different syntax.
Most wikis can also handle html – another way of achieving more sophisticated formatting.
Setting up a wiki doesn’t guarantee collaboration
One often tends to think that a perfect online collaborative space assures people’s participation and you spend a lot of time with tuning up the wiki, setting up log-ins, etc. However, although a wiki can facilitate online collaboration, unless you combine it with other facilitation techniques, most of the people for whom you created logins are likely to never log in…
When wikis are used for an intranet, or public sites, they tend to grow into an insane tangle where no one can find anything (both to use or to update). Good information architecture and management have to be in place to keep a wiki-built site usable (due to wiki’s default openness and unstructuredness).
Issues related specifically to the TikiWiki
It is not a really huge problem, nor a general wiki drawback. However, understanding the logic of TikiWiki administration is not a question of half an hour. Unless you are a very proficient wiki user, it can take quite a while to do even simple administrative tasks. This observation is based on subjective experience, no CMS administration is really simple.
Documentation can be a major problem, as with many other FOSS tools (and is a big problem with Tiki).
The importance of issues listed above must be weighted in the context of the purpose of each wiki, your technical support context, etc. While the somewhat complicated administration interface of TikiWiki might become an issue when you need to perform some administrative changes without an ambition to become a “real” wiki administrator, it might be no issue at all when you have a technical support person dedicated to administration of all wikis you use…
The discussion on the above listed issues might seem long, but these are not so significant compared to the benefit APC gained so far from using wikis. They proved to be an invaluable tool and can be recommended anywhere when there is a need to work collaboratively on certain issues for an extended period of time. That is particularly true where there is a need to quickly set up a collaborative space, which is easy to use by people with different ICT skills and who should be working together right away, instead of having to learn how to use the tool.
Old APC wiki sites used in the past both for meetings and project development still serve as important resources for APC’s current activities, evaluation, etc. Wikis are great to maintain continuity between what has been planned and what is being worked on.
Developed by SUCB
Wiki formatting – sample guides:
MediaWiki: http://meta.wikimedia.org/wiki/Help:Editor (scroll down to formatting)
List of Wiki software: http://en.wikipedia.org/wiki/List_of_wiki_software
Comparison of wiki software: http://en.wikipedia.org/wiki/Comparison_of_wiki_software
Examples of wikis used as OS project documentation platforms
HTML to wiki online converter: http://diberri.dyndns.org/wikipedia/html2wiki