Wiki tools are not all the same
By Tony Byrne - Posted Oct 28, 2009

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:

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.

Spam prevention

Another approach is to monitor the content of changes programmatically; typically you do that for spam prevention. Spam prevention is critical on public wikis, especially those that don’t require a login to edit, though almost never an issue on enterprise wikis behind the firewall.

Depending on the service, it could monitor wiki edits based on the content itself (including banned words or disallowed links), or patterns of user behavior, such as excessive activity.

Effectively controlling spam requires the wiki provider to stay up to speed on all the latest anti-spam techniques and algorithms. Few do.

Different scenarios

Enterprises use wikis to accomplish different things, and some tools will "fit" different scenarios better than others.

Some enterprises employ wikis to create an authoritative, "gold-standard" knowledgebase—e.g. for call center use. It is sometimes called a "structured wiki." In this case, you would want to see a richer set of administrative and management services, including potentially the ability to set a controlled vocabulary and easily move pages around. You will also like the ability to output entire sections of a wiki into a print-friendly format like PDF. That is actually a common complaint about certain wiki tools—that they don’t natively generate print-friendly renditions.

Alternatively, you may employ a wiki as a more fluid community of practice. Here, the emphasis becomes less about structure and more about flexibility, ease of contribution and search. Contributors will likely want to attach documents, tag entries and incorporate bookmarks. Surfacing the newest and most active items becomes more important.

Looking at suppliers

CMS Watch divides the wiki supplier community into three broad camps: platform vendors, social software suites and pure-play wiki products (see WIKI sidebar below).

Platform vendors

Those vendors tend to embed wiki services into existing portal or collaboration platforms. It seems they do that as a bit of an afterthought, because customers tell us those wiki services tend to be poorly thought through and not conducive to enterprisewide adoption. Major enterprises commonly plug in a separate wiki service instead.

Social software suitesThose vendors bundle wiki services as part of a broader set of social applications. In theory, that means you can more easily integrate wikis, blogs, tag clouds, profiles and other social computing services. That has real value in a large enterprise. At the same time, most wiki services you’ll find among those tools tend to pale once again in comparison with the best-of-breed offerings we’ll examine next. We get the sense that social software suite vendors include wiki services because they feel compelled to check a box, rather than out of passion for "the wiki way."

Pure-play wiki products

Those are vendors and products that focus intently on providing broad wiki functionality. In most cases, you can find an open-source and/or SaaS version of a particular wiki offering there, although they may be circumscribed in one way or another.

Most of those tools can boast a particular niche. For example, MediaWiki provides a very Wikipedia-like experience, mimicking the platform (for better and worse) from whence it came. Socialtext and Atlassian have ambitions about expanding out to become more full-fledged collaboration offerings, to the delight of some customers and the dismay of others.

Wiki choices and the enterprise

From a platform perspective, many enterprises today do not suffer from owning too few wiki tools, but rather, too many. It’s not unusual in a large organization to see successful (or not) wikis running on as many as five different platforms.

Inevitably, senior leadership comes to see a need for at least some degree of consolidation. But on which one or two platforms do you standardize? That is never a simple answer, especially when you need to address several different scenarios, like software documentation vs. marketing community of practice vs. sales collateral repository.

Some IT leaders try to short-cut the process and simply default to a solution like SharePoint because they already license the platform enterprisewide and assume it will stretch for a variety of different needs. Their colleagues are likely to be sorely disappointed.

If you’re looking to standardize, here’s a better approach. Inventory the business purposes of wikis in your enterprise that have seen success to date—or are likely to thrive in the future—and then assess the strengths and weaknesses of available tools. You’ll want to assess incumbent solutions, but also keep an eye on the broader marketplace, especially if you’re thinking of exposing any wikis beyond the firewall.

Wikis are "old" by social computing standards, but wiki technology continues to evolve. Do your research to make the right long-term choices.

THE WIKI MARKETPLACE

Major platform vendors: Google, IBM, Microsoft, Oracle and SAP.

Social software suites: Awareness, blueKiwi, Jive, Telligent, Traction and many others.

Pure-play wiki products: Atlassian, MediaWiki, MindTouch, Socialtext, TWiki, Wetpaint and many others.

(Source: www.cmswatch.com/Social/Vendors)