By Strategic Use and Capacity Building Programme PRAGUE, Czech Republic,
Published onPage last updated on
APC staff started playing with wikis internally four years ago, and started using this online tool seriously about a year later. Collaborative work can normally be documented with the help of a drawing board or some tape recorder in the corner of a room. At the Association for Progressive Communications, people’s collective space is not a room. Instead they work from home, some in small offices, others in affiliated organisations, all over the world.
The visible side of APC staff’s work is found online, in documents, blog entries and documents, Voice over Internet Protocol conference call notes and lately… wikis. From experimentation, wikis have progressively become core to APC’s work habits.
But what is a wiki anyway? How does it differ from other online tools APC uses? How can it support the way we work at APC? This first out of two pieces looks at these questions by rooting the answers in APC’s global working dynamics.
Wiki?
Wiki is an online database-driven website for simple, quick and versatile online publishing. The graphic layout of published content is a lot simpler than what we can achieve with most “real” content management systems (such as APC-developed ActionApps). It is easy to use and extremely flexible in terms of structuring content – all this without needing strong administrative or web design skills, as opposed to mentioned content management system (CMS).
The good, the wiki and the beauty
Back in 2002, many at APC were using Hyper Text Markup Language (HTML) to format website entries and present their output online. CMS and blogs were slowly singing a new tune out there, a tune in which HTML would take the back seat.
The beauty of wikis, lies in its simplicity. You type your text into an online form and have it published instantly on a chosen page. To make formatting more attractive, wiki formatting standards are applied. At the same time, most wikis support HTML, meaning that text formatted and published elsewhere can be re-published on wiki without loosing its character.
Unless some administrator restricts it, a wiki installation is by default open –it is available for editing by anyone whom we let know about the existence of the wiki. This openness is in some cases fundamental to genuine collaborative work.
You expect several people to work collaboratively on the APCNews monthly bulletin? You probably want a single document available to all, at all times. From experience, there is nothing more frustrating than having to wait until a colleague wakes up in some other time zone on the globe, to request the latest version of documents that got stranded in her/his inbox.
Another beauty is that wiki databases require minimal installation and it should be relatively easy to perform. Yet, you need to possess basic server administrator skills to be able to install a wiki. This, at APC, is not the greatest hurdle though.
Where there is low connectivity, a wiki can be installed on a personal computer and on the spot, on a local network. The simplicity in setting up a wiki makes it worthwhile to make it happen locally, even for a single meeting or workshop.
Documenting APC meetings
APC initiates and moderates countless meetings and workshops in a year. They tackle the question of how to best use information and communication technology (ICT), how to think and craft internet-related policy and how to strengthen APC’s network.
Wikis are a prime resource to record meetings and other events of that nature. It is not only a very simple publishing tool that you can teach any workshop participant to use in half an hour, it is also powerful in letting more than one person express itself. Everybody can publish any type of content in a form and space he/she wants. An active community therefore develops knowledge together, in a much easier way.
This user-friendliness and flexibility can well motivate your workshop participants to actually go online and record notes from meeting sessions, personal observations, agendas, action plans and the like. APC meeting wikis become journals of the event where all collected “knowledge” can be recorded and later used.
Moreover, once events are over, wikis can be used as starting points to further develop on different threads and topics that came out of discussions. Wiki installations have been successfully used in a number of APC meetings and events, such as regional and council meetings, the 2004 ActionApps camp and the series of wireless project encounters.
ActionApps camp
APC used the TikiWiki as a platform for documenting a weeklong intensive ActionApps [1] developers’ meeting. There was a need to allow both meeting participants, as well as anyone from the ActionApps community to follow the meeting conclusions online, and to allow them to add their own contributions.
The wiki was a completely open one – no login was needed to post content.
1 ActionApps is a collaborative web-publishing tool for non-profits initiated by APC. For more information, see http://actionapps.org/
It was primarily used to plan the meeting agenda and to create personal pages for each participant. As the meeting progressed, participants started adding new related pages and sections where issues for discussions were proposed, action plans drafted etc. Since the discussion topics have broken into four major areas, the wiki homepage became a signpost pointing to entirely self contained sub-sections.
A section was created to collect training resources and documentation that had previously been scattered across many APC members’ sites. After the meeting finished, the wiki was used to further tackle some of the main discussion issues. The ActionKit [2] – a separate operating system project whose planning started during the ActionApps camp meeting – has particularly benefited from this space.
2 See ActionApps Camp wiki: http://www.actionapps.org/tikiwiki
Collaborative project development
Another good use of wikis is for collective project proposal development. A geographically dispersed group of people can develop texts directly “on the page”, or upload document files to a wiki repository. The repository then contains downloadable file attachments, with exact upload times recorded, authors’ notes on every version and the like.
Both techniques are usually combined. The “formal” document is often being developed and uploaded as a downloadable text file, while particular half-developed sections, lists of resources are being developed on web-based page. This approach requires someone to then integrate these separately developed sections into the master document. So even though wikis make it easier for many, it doesn’t dispense the bottomliner of the project from being a good synthesizer.
One thing to be careful about here is not to overwrite somebody else’s edits. This happens when two people work on the page simultaneously, without knowing it.
Tricalcar project
A wiki was successfully employed for collaborative exchange leading up to the Tricalcar project proposal, a Latin America and the Caribbean (LAC) version of APC’s wireless project. Over ten collaborators needed to be able to work on the same document. This was made difficult by the fact that they were located across the whole LAC region (and some in Europe).
Circulating the document by email was simply not an option, as there is a high risk of losing track of versions. Some would develop proposal sections and others would add content to them. The collaborators lived and worked in different time zones, which made the need for one central document repository even more acute.
A wiki was created with following settings: Anyone can read, but only logged users can edit content, upload and download attachments.
Specific sections were created where chapters of the proposal were jointly developed. Then, one or two editors incorporated them into the master document. Every time someone added changes to the document, she/he uploaded it with comments linked to the changes made.
See the Tricalcar wiki: http://www.apc.org/tiki-lacwifi/ (you need to log in to see attachments).
Documentation of open source development
It is increasingly common to use some type of wiki as a platform for development of open source project documentation. This is due to the fact that wikis have become much more flexible in terms of layout design. More importantly however, open source projects depend on community involvement in the development, which applies both to the application itself, as well as the documentation.
A wiki makes it easy for anyone to contribute to the development documentation, without heavy access paths.
MediaWiki for instance, was chosen as a platform for the development of ActionApps documentation. The previous documentation version was not particularly easy to contribute to, thereby discouraging community contributions to the project. What was needed was a platform where anyone could easily register and enter their content. MediaWiki was chosen particularly because it is simple to use and it handles the combination of wiki syntax and HTML code with great ease.
See the ActionApps documentation: http://actionapps.org.
When is a wiki the right tool for collaboration?
If one needs to do put together a collaborative document in a hurry, a wiki can be very effective. This especially true when time is short and "managing" the process of circulating a document for people to comment in a particular order, is too labour intensive.
Wikis are useful when working on a single document or a relatively self-contained topic, section or page. They might also be useful in the idea stage of jotting down and adding information.
Yet, wikis are not ideal if you need to see who has made what changes where, or to comment directly on text. Each page shows who saved the last changes, but you cannot track who wrote which parts of the text.
In the final stages of a project proposal, wikis might also be less effective. This is basically due to wikis’ unappropriateness for creating heavily formatted documents.
Part II next month: Next month’s piece offers a glimpse into the experience APC’s Strategic Uses and Capacity Building (SU&CB) programme made with the MediaWiki and TikiWiki. While shedding light on the issues brought about by wikis, part II explores the larger free and open source context in which they fit in.
