Wiki tools are not all the same

After starting in near obscurity nearly 15 years ago, wikis have now become almost ubiquitous on the enterprise landscape. Today, most of the industry discussion about wikis centers on critical issues of improving adoption and maximizing business value.

This prompts some commentators to claim that the type of wiki software or vendor you select doesn’t matter. After all, wiki solutions are not hard to procure. In addition to scores of pure-play wiki vendors, major enterprise software players like Microsoft, IBM, Google, Oracle and SAP now embed some sort of wiki functionality in their portal and collaboration tools.

Actually, the tool you select matters a lot. If you care about adoption and having the right "fit" for your enterprise, the wiki solution you choose will impact your ultimate success. CMS Watch research with users suggests that selecting the right tool isn’t sufficient alone for long-term success, but it is necessary—particularly at a time when wiki functionality from traditional software platform vendors frequently comes up short.

Not all wiki tools work the same way. Here’s a list of some key differentiators:

• rich-text editing environment,
• organizing and refactoring services,
• change monitoring and alerting,
• access control and approvals,
• spam prevention, and
• target use cases.

The way one vendor approaches a particular feature doesn’t make that wiki inherently better or worse—just different, and better suited to some use cases over others. Let’s look at each issue in turn.

Rich-text editing

When wikis first came out, there were not a lot of options for WYSIWYG editing from within a browser. Consequently, the wiki markup language (sometimes called "wikitext") provided a particularly valuable shorthand for formatting text that was much easier to learn than pure HTML.

These days most wikis have rich-text editing features as well, so the wiki markup language becomes a less interesting feature in terms of formatting, although it does provide the benefit of being supported by all browsers on all platforms (which is typically not the case with rich-text editors). Some wiki tools no longer support wikitext, which could be problematic if you have sophisticated users who are expecting to use it, just as they do on Wikipedia.

Organizing and refactoring information

The wiki concept of user-generated pages means that site hierarchy and structure tends to get formed in an ad hoc way. Navigation remains very simple, and hierarchies flat. That has its pros and cons. Wiki enthusiasts consider fluid content development a benefit, and indeed, wikis can escape the strictures of "normal" Web site publishing where everything needs to fit into neat boxes and folders.

But that can also lead to organizational chaos. Wikis have a tendency to get very disorganized in the absence of a "steward" or "gardener" who can "refactor" the content from time to time. Refactoring entails renaming, moving or combining pages or even entire wiki instances. Some wiki tools provide special services to facilitate that, but many do not.

Linking can also get tricky in enterprise environments where you might want to be able to easily link across wiki instances. Only a handful of tools in the market today allow you to do that natively within the system. Finally, some wiki packages support more complex categorization of content, but many simply expose flat lists, just like Wikipedia.

Change monitoring, alerting and approvals

The power of wikis comes in their simple, informal editorial services. But what if the enterprise wants to exercise at least a modicum of oversight? As you might expect, one layer of defense is to simply monitor changes made to the wiki—and roll back unwanted changes where necessary.

Most (but not all) wiki tools have a "Recent Changes" page that lists all the pages that have been changed. If the wiki supports registration, then it also will identify who made the change. That feature can typically be e-mail- and RSS-enabled. More sophisticated systems identify and differentiate "trivial" changes from more substantive ones. For example, you may not want to be notified by e-mail every time someone fixes a spelling error.

If more than one person has been tasked with monitoring changes, some wikis offer the capability to track whether a recently changed page has been checked yet, reducing the chances of duplicated work. In busy environments, you’ll definitely want to be able to compare differences visually, side-by-side, but not all wiki services enable that.

Wikis created for enterprise use may also support simple approval mechanisms. The concept of "workflow" may be anathema to wiki purists, but in some organizations, for certain types of wikis, pre-approval of submitted content or changes can add value—as long as you don’t overdo it. Not all wiki packages support approval mechanisms.

Access control

When a wiki software package bills itself as an "enterprise wiki," it usually means that it has user access control. An increasing number of wiki packages employ access control lists that assign rights at a more granular level. Users and groups can be assigned rights to tasks such as reading a page, writing to it, editing it and rolling it back to a previous version.

There is a lot of variance among wiki packages in terms of how those rights are applied to the site. Some wikis let you restrict access to certain sections of a site, while others let you restrict access to individual pages. A less common but useful feature is the ability to restrict access to parts of pages. For example, you might not allow everyone the ability to post a comment to an article.