I spent a few weeks in December 2005 investigating the universe of wiki software, and confirmed what I already suspected: It’s a very big universe with many wikis! It would be impossible to explore them all, so I first tried to come up with a short list of wiki engines to focus on. Fortunately, there are a number of excellent sites that attempt to provide matrices of wiki software functions and abilities. Here are a few I used and recommend:
- Good reviews of wiki software at onLamp.com, a site devoted to open-source LAMP products.
- This is a very thorough “choice tree†for wikis.
- Splitbrain, which makes Dokuwiki, has a good comparison page on wikis.
- Best of all, don’t miss the new Wiki Matrix website, which evolved from a static HTML table matrix last fall.
After studying these various resources, I was able to narrow the list of wikis down to the following:
MediaWiki was the default choice, since I assumed it was probably the best of the lot, given its starring role in powering Wikipedia and just about every other high-profile wiki you encounter on the web. After a painless default installation of MediaWiki, I had the usual MediaWiki shell and did a few quick walk-throughs of the structure just to make sure all the plumbing was in place. It seemed to be, so I proceeded to install a few of the others from my short list.
In fairly quick succession, I installed Dokuwiki, PMwiki, and Tikiwiki, reviewed their documentation and capabilities, and did some basic configurations. They all seemed to be reasonably good, but none was noticeably superior, at first glance, to my initial configuration of MediaWiki. It seemed to make sense to stick with MediaWiki, given its large market share and equally large mind-share.
So, over a period of about 2 days, I began trying to configure MediaWiki to do some things beyond its default behavior–things I knew would be needed to provide a useful wiki for my target, non-technical clientele.
What a mess! I had spent 2 solid days without accomplishing much of anything toward setting up the desired wiki, which by the way was intended for use by a Federal organization that was interested in testing the use of wikis for developing and maintaining standard operating procedures for its divisions and branches.
Here is a summary of the problems I encountered with MediaWiki:
- Basic help on structured wiki markup was not available from within the software. In fact, no help files were loaded by default. Users are expected to create their own help pages.
- Basic help on structured wiki markup was not available from within the software. In fact, no help files were loaded by default. Users are expected to create their own help pages.
- The software’s documentation is terrible. The main problem is that there are so many sources of information, you get conflicting instructions. Many of the conflicts have to do with the various versions of mediawiki (1.3, 1.4, 1.5, etc).
- Creating simple navigation is quite difficult. One approach to navigation is to use “sub-pages,†but then forming links is tricky, and the page names include their parents by default. In other words, the relationships are discovered strictly by naming. Using piping, it’s possible to make the link text look OK, but the titles on the pages are another issue.
- MediaWiki includes no basic, web-based administration tools at all. In fact, there’s no detection of sysadmin capability at all in the interface. To change the links in the Navigation box, for example, it turns out (after hours of hunting) that you are supposed to change the text in a page called Special:Allmessages. Not exactly intuitive, and it’s set up by default so as to be editable by anyone.
- Another useful navigation feature–breadcrumbs–don’t exist, and they can’t be created without custom coding. (There’s an extension for this, but it only works in an older version of MediaWiki.)
- Skinning is also very difficult compared with the other wiki software I had looked at.
- A basic requirement for this project that I understood was not natively wiki-like was the need for some basic authentication and the ability to write-protect certain parts of the wiki tree for different groups. MediaWiki has a plugin for authentication, but it turns out that anyone who has administrator privileges can edit any part of the tree, and that wasn’t going to be sufficient in my security-conscious Federal agency.
After this experience, I decided to return to the drawing board, and take a second look at the short list packages. I also added a new one: Twiki. It’s written in Perl and uses flat files, but appears to be much more “mature†than some of the others.
In general, my impression after working with these various software packages is that wiki software is not nearly as “mature†as blog software. I was looking for an open-source wiki that would be as powerful as WordPress is in the blog world, while also being as easy to design, configure and administer as WordPress.
Twiki wasn’t much better, and neither was MoinMoin, which I also ended up checking out (even though MoinMoin is written in Python, and I had no Python programmers to call on). Despite much positive press, MoinMoin has the same deficiencies as other wiki software. And what are those?
Basically, wikis were developed for use by programmers as a way of sharing information on software projects. They developed around a culture of highly sophisticated hacker-types who didn’t need a lot of hand-holding when it came to navigation. The main concern was to allow rapid development of pages on a new topic, with automatic links to pages that hadn’t yet been written (but which needed to be written). Wikis were designed to grow organically, as one writer filled in the blanks in another’s page by adding information to it through hyperlinks, or as multiple writers contributed to fleshing out the details on a particular topic. In both cases, the result was to produce a decentralized information resource that relied primarily on search for finding things.
On Wikipedia today, it’s become clear to those “in charge†that strong editorial oversight is needed to keep a wiki useful. For one thing, wikis don’t automatically understand synonymous terms. One person may write a page that has a link to a new page called “WikiSystemsâ€, and another may already have filled in a page called “WikiSoftware.†Unless someone were watching “from above,†you could end up with two pages that covered pretty much the same ground.
Also, notice the terms “WikiSystems†and “WikiSoftware.†In wikis, the default way of linking is to write new pages in what is known as “camel case:†Two words “munged†together, each having an initial cap. Wiki software is designed to recognize camel-cased terms and to automatically hyperlink them. Again, this is useful in its original conception, but it’s not particularly intuitive for a nontechnical user base such as you would find in most business or government organizations.
Another shortcoming that many wikis don’t handle well is authentication. Most wikis are designed to allow content editing by anyone. Most also allow administrators to restrict editing to registered users only. However, the ability to restrict access to certain pages to only certain people is not a native ability in most wiki systems.
Before I get around to describing the software I ultimately selected, I want to include my impressions of a few commercial software packages that have developed in the last year in an attempt to feed the growing market for wikis in corporate Intranets. One of the most well-known is Jotspot, an outsourced wiki system that can be purchased for a monthly fee. Jotspot is probably the most advanced wiki of this type, although since December there have been a fairly large number of newer entrants to the field, and it’s possible that Jotspot has some good competitors by now. Jotspot is actually more of a full-blown Intranet than a wiki. Indeed, it shares this characteristic with Twiki, which branches out way beyond the central wiki functionality. Besides being a wiki, Jotspot (and Twiki) comes with a large number of plug-in applications that can be used for various Intranet functions (e.g., Project Management, Bug Reporting, Company Directory, Knowledge Base, Call Log Management, Blogging, Group Calendaring, Meeting Management, Polls and surveys, Personal to-do lists, etc.) The hosted version has a reasonable price tag, maxing out at $199 a month for unlimited users.
Jotspot also has an enterprise version for companies that want to host the software themselves. I set up a test wiki at Jotspot, and although it definitely has a lot to offer, it also isn’t nearly as configurable as one of the open-source packages. In addition, I felt certain I could find a perfectly good wiki package for my target organization without investing a lot of money.
Another impressive, hosted wiki-like system is Backpack, and I also set up a test there. However, Backpack is designed to work best as a personal wiki, rather than for collaboration. The same company also makes a web application called Basecamp that looks like an ideal solution for project management uses, but is not designed for documentation or knowledge management–the two main uses that this pilot wiki would be put to.
And if anyone was interested in a personal wiki, I don’t think you could do much better than Tiddlywiki, an amazing, rich-web interface “wiki on a stick†that literally packs all of its information into a single portable file. It works an amazing amount of magic that could possibly be useful collaboratively, but that is designed to work best for individuals.
Finally, I looked at Projectforum, a commercial package that the customer was interested in. It turns out that Projectforum is not a wiki system, actually. Rather, it’s a discussion forum package (there are hundreds–possibly thousands–of such packages) that is trying to leverage the buzz around the term “wiki†and RSS.
The critical difference is that a wiki is primarily a content management system, not a system for user discussions. MediaWiki uses the term “collaborative editing,†because wikis typically have built-in discussion forums for each piece of content that gets added to the wiki. For example, if I post a Standard Operating Procedure on designing a website, readers would have the ability to create a discussion about that SOP. Also very important is the ability for users to interlink content into a growing content tree, producing in the end a very useful knowledge-base of information on a given topic.
Projectforum doesn’t have those features, and is missing other standard wiki features as well. As its name implies, Projectforum is actually designed for project management rather than content/document management, and it excels at the collaborative discussion part of project management. In that sense, it is similar to Basecamp.
So after this market review, I had almost concluded that no wiki was really yet up to the challenge I was hoping to put it to, when I decided to try a relatively new, little known package called Wiclear. After reading through the website documentation, I tried to quell my growing excitement, because on paper at least, Wiclear was designed to overcome all of the shortcomings that were so obvious in all the wikis I’d tried.
Developed by a French programmer and modeled after a French blog system called Dotclear, Wiclear shares with nearly all other wikis the virtue of being open-source. Meaning, I can freely download the source code and install it. Wiclear is written using PHP, an increasingly popular web programming language, and the open source database MySQL. Since I happen to have some expertise in both, I felt comfortable with the prospect of possibly having to tweak the system to my requirements.
Indeed, after only 3 hours of work, I was able to configure Wiclear with all the basic requirements:
- Apply a customized style sheet
- Customize the section navigation
- Customize the page elements
- Customize the heading
- Set up test users
- Enter test content
- Set up appropriate help documentation for a wiki-nubi.
Compared with my experience with the other wiki software–in particular, with MediaWiki, Wiclear was very easy to work with. Furthermore, Wiclear had the following required features, some–but not all–of which were available in one or more of the other wiki systems.
- Browser-driven installation
- Web administration interface
- Easy templating
- Hierarchical page structure enforcing parent-child relationships between pages
- Individual page access controls through use of industry-standard ACL’s (access control lists); the system provides an easy web-based interface for setting per-page permissions
- An automatically generated “site plan‖site map–for navigation
- Automatically generated “breadcrumbsâ€
- Automatically generated “sub-page navigation†(showing all child pages to the current one)
- Registered users can add comments about any page, whether they are the author or not. (This feature is configurable and is in fact a standard feature of most wiki systems.)
- Users can attach external files to individual pages (a relatively rare wiki feature, but one that I was sure would be “oohed and aahed†at by my customer base.
- Enables user self-registration, and provides flexible User/group management tools.
- Provides a “Post New Content†feature that’s unique in wiki’s, but extremely useful for adding new content to the tree.
- Usual features that made wikis so popular for collaborative editing in the first place:
- Page history
- Comparisons with and rollback to earlier pages
- Subscriptions by email
- RSS feeds
- List of recently changed pages
- Search
- “What links here†feature
- Simple editing system for easy content entry (with optional HTML entry), as well as an optional preview capability
Further, if my customers were ever to require the ability to support multiple languages, they could turn on one of Wiclear’s most impressive features: built-in multilingual support.
Wiclear has a clear, well documented code base, and with my knowledge of PHP and MySQL–plus HTML, CSS, and JavaScript–I was quickly able to add a few custom features that I thought my customers would appreciate. The first was a simple WYSIWYG HTML editor that would give our writers the comfort of having Word-like editing tools in place. For this, I chose Dojo’s excellent DHTML, rich-text editor, which is one of the few that supports Safari on the Mac as well as all the other usual suspects (Mozilla/Firefox and IE). The Dojo editor is a breeze to set up, and works beautifully. It doesn’t “do tables,†but my pitch to users is to keep the text structure simple, so hopefully nothing more complicated than headings and nested lists will be needed.
The second tweak that might be of interest to readers was a default setting to automatically subscribe an author to the page he/she has written. This ensures that anyone who authors a page gets notified whenever it has been changed. (You cannot opt out of this feature, but you can always unsubscribe.) I hope this will take care of the worry over unauthorized edits, since it will be hard to not know when “your†page has changed, and quite easy to go in and fix any errors.
The author of Wiclear has steadily continued to improve the product. There have been 3 new releases since I installed Wiclear in late November 2005. In fact, the author has incorporated at least one of the features I requested after my initial configuration–namely, the ability to define a “root†page that could be ACL-protected against accidental damage. This was kind of important to give my customers the necessary comfort level to know that their part of the tree wouldn’t be uprooted someday, either advertently or inadvertently. 
I actually hand-coded the hack into Wiclear at the time, but the software’s author had finished integrating that function by January.
So far, I’m very pleased with my choice, and still relieved that I didn’t have to back out of the idea of testing the wiki waters for collaborative editing. Next comes the more difficult part–convincing users that this is a tool that can work for them rather than simply another complication to their working lives. Fortunately, there are several forward-thinking groups in the agency that are anxious to try the wiki out. I was delighted to set up the first group with their own branch of the wiki tree, and look forward to getting their feedback.
In a dumbed-down form appropriate for non-geeks, Wikis have great potential to be a key knowledge-management solution for a lot of content management problems in an organization. I think with Wiclear I’ve set up a foundation that won’t scare people away without even giving it a try, and that, in my organization, would be called a victory!
