If you want to store and organize a large quantity of information for multiple users, like the components of a draft policy guide, a great low-cost way is to set up a wiki. You’ve already used one if you’ve ever accessed Wikipedia.
People will tell you that you can download free open source software and have a wonderful collaborative tool ready to use in no time. That’s all true, except the part about time.
We became enthusiastic about wikis after Leslie O’Flahavan gave a presentation about them (PPT) to the Capital PC Users Group (CPCUG).
Since then, we’ve put up three wikis for client projects. Each uses progressively more of the wiki’s capabilities, which are impressive. In the process, we encountered a few road blocks that all novice wiki developers likely face. We expect that the process will get smoother as the technology evolves, but in the meantime, here are a few things to keep in mind:
- Documentation resides in various places. As is often the case with open source software, documentation is spotty. We use TikiWiki, and the “wiki help” function, once you’re in editing mode, offers the basics—how to rename the homepage and how to center text, for example—but beware, wikis have elements of a black hole. Entire pages seem to disappear temporarily, only to pop up again hours later. You can also go to tikiwiki.org, but the explanations there aren’t always clear. We wish we had bought Wikis for Dummies sooner.
- A little more knowledge can be a dangerous thing. One rule to live by: the more you know about wikis, the greater your risk may be of misplacing information.
- Many hands don’t always make lighter work. A wiki allows information to be modified and augmented by a variety of users. Unless you have a high tolerance for chaos, you’re probably better off designating one or two moderators with access to the editing password.
- Passwords are initially an obstacle. So that everybody in the world can’t snoop around your project wiki, create a screening password. But be sure those working on your project know what it is (!) Then, to edit files, create an additional “admin” password for those administering the pages.
- If you build it, they won’t necessarily come. None of the clients whose projects gave rise to wikis were grateful or even pleased at first. We shouldn’t have been surprised. A wiki isn’t fancy graphically. Adding content can be complicated. Probably most important, using a wiki requires more effort than using e-mail until you get the hang of it. We like our wikis, but we have a powerful incentive to invest in collaborative tools. If we rely solely on e-mail and overlook one, a client’s publication might suffer. Being organized matters a lot to us.
Creating a wiki can be fun. But the most gratifying moment comes when the project that once consisted of enormous files and innumerable e-mails is now all neatly laid out, a click away.


2 Trackbacks
[...] self-reliant self-starters, but as workloads grow, details can get blurry. Create a project wiki and designate a wiki master to capture and update project [...]
[...] free wiki software to store and organize large quantities of information for multiple users on a variety of projects. Our wiki sites have helped simplify management by reducing file transfers, allowing content to be [...]