Feature

posted 28 Nov 2006 in Volume 3 Issue 5

Workshop: Social networking

Understanding enterprise wikis

Wikis are all the rage, with many companies implementing wiki software to help staff better share their knowledge and information. However, like all implementations, there is a right way – and a wrong way – to go about it.

By Mark Choate

Wiki software has been around in one form or another since 1995, but a rather recent variant is something called ‘enterprise wiki software’. Heightened interest in this proposition comes in response to the increasing number of big-name organisations, including Disney, Nokia and Yahoo, which are turning to wikis as a way to improve internal communications. But if we look at wikis in an enterprise context, we have to answer two important questions:

What’s the difference between a wiki and a content management system (CMS)? Couldn’t we just press our existing CMS into service as a wiki?
Are wiki tools enterprise-ready?

That is to say, would they pass muster before the CIO? In this workshop, I will endeavour to provide direct answers to both questions.

Wikis and content management

A wiki is a collaborative website where users can create and edit pages. Wikis fall conceptually under the broad concept of content management and you could certainly use your existing CMS to create a ‘wiki-like’ site. However, wikis have unique characteristics that differentiate them from run-of-the-mill content-management systems. Wikis emphasise ease of content creation. This simplicity comes from many sources:

A wiki mark-up language that provides a short-hand way of formatting text and linking documents;
The ability of users to create and edit pages directly and independently;
A bottom-up approach to site structure and navigation;
Very simple templating;
A conscious decision to eschew workflow or even simple approval steps.

Let’s look at each issue in turn.

Content creation and editing

Wiki software empowers users to create and edit their own pages, but content management systems also provide tools for creating and editing content, too.

The difference is in approach. When wikis first came out (in 1995), there were not a lot of options for ‘what you see is what you get’ (WYSIWYG) editing from within a browser. As a result, the wiki mark-up language (sometimes called ‘wikitext’) provided a particularly valuable short-hand for formatting text that was much easier to learn than pure HTML.

A good CMS today will offer a WYSIWYG interface that makes writing content for the web a lot like using a word processor. These days, more wikis have WYSIWYG editing features as well, so the wiki mark-up language has become a less interesting feature in terms of formatting, although it does provide the benefit of being supported by all browsers on all platforms (something that is typically not the case with rich-text editors). Many wikis support both wikitext and rich-text editors. Figure one shows an example of the editor from Wikipedia, which supports both forms of content formatting.

However, there is one area where wikitext still retains its power and where wiki software is different from a CMS: linking. Wiki software still provides a much easier way to link pages within the wiki to each other. Links are made based on the title of a page, so the author does not need to use, remember, or type long URLs in order to link one page to another. Site structure and navigation Because contributors can readily create new pages and can easily link one page to another, wikis take a unique approach to site structure and navigation.

A CMS usually takes a more formal approach to site structure and navigation, with the site organised into a hierarchy by an information architect. User-created pages in a wiki mean that the hierarchy and structure of the site is created in an ad hoc way. Navigation tends to be simple and the hierarchies are flat.

For example, the online encyclopaedia Wikipedia has hundreds of thousands of articles on a broad range of topics, but these topics are not arranged in any conceptual hierarchy. The entry for ‘dogs’, for instance, serves as a good illustration. The URL for the article about dogs is: http://en.wikipedia.org/wiki/Dog.

A pug is a kind of dog, and the URL for the pug entry is this: http://en.wikipedia.org/wiki/Pug.

Since a pug is a kind of dog, you might expect to see the following URL for pugs: http://en.wikipedia.org/wiki/Dog/Pug

But it’s not there. Some wiki packages do support more complex categorisation of content, but many are totally flat, just like Wikipedia. Even if the software does support sub-pages, contributors are still allowed to create sub-pages in an ad hoc fashion and there is no systematic approach to the site’s information architecture.

Content repository and APIs

Any experienced system administrator or architect will ask of any content technology, ‘what does the repository look like?’. And for good reason. They have to care about compatibility, performance, back-up and a raft of similar issues.

Wikis, historically, have taken a very simple approach to data storage. The first wikis stored content in plain-text files that were written using the wiki mark-up language. When a user requested a page, the page was rendered. This was not speedy, but it worked. These days, wiki packages employ one of several different backends, with many housing their content in databases.

One important consideration is whether the system supports automatic back-ups (commercial wiki applications often do). Another factor to consider is what this means in terms of integrating wiki content with content managed by other systems. For example, will the enterprise-search system be able to index wiki content? Will the content indexed be raw wikitext or rendered HTML pages?

This brings us to the issue of application programming interfaces (APIs). Unfortunately, most wiki software doesn’t have one. Want to access a wiki through your portal or integrate with an intranet CMS collaboration system? Today, you typically need to purchase these functions from a vendor. In the future, I expect more wikis to open up their systems for integration with other enterprise packages.

Templates

When a page of wikitext is requested, it gets rendered into HTML in a two-part process. First, the wiki mark-up is converted to HTML and links are created between pages. Then, this content is wrapped by a template that provides a consistent look and feel to all the pages in the wiki.

Compared to a CMS, most wikis have simple templating systems, often only enabling one template for the entire site. Wiki templates – and page rendering in general – are often not cached, so the page is rendered with each request. From an enterprise perspective, a lack of caching can obviously limit the scalability of the system. On the other hand, there’s no finicky caching mechanism to deal with.

Workflow

Wikis turn the idea of workflow on its head. They are decentralised and typically lack the controlling mechanism of a workflow system with a formal approval process.

The fact that wikis are decentralised and lack sophisticated workflow and approval processes is considered a positive feature of wikis and not a fault. This is contrary to the basic philosophy of many content management systems, which emphasise control over empowerment.

Despite wikis’ decentralised approach, there is one important thing to remember: the anyone-can-edit policy is just that – a policy – and not an inherent feature of the software. At the same time, wikis do not handle content control in the same way that a content management system does, so you will need to take a different approach with wikis.

Control versus flexibility

In CMS software, as in life, there is a classic trade-off between control and flexibility. With a traditional CMS, decision-making is often centralised by an editor of some sort that reads and approves content prior to publishing. With a wiki, the writer writes, then publishes without editorial oversight or approval. This direct channel to publication is what makes wikis so wonderful in scenarios that emphasise speed and flexibility.

But what if the enterprise does want to exercise at least some control? In the absence of traditional workflow controls, content creation in a wiki is managed through change monitoring, automated spam prevention and user access control. Let’s look at each one in turn.

Change monitoring

As one might expect, one layer of defence is simply to monitor changes that have been made to the wiki. This makes the most sense for wikis that reside exclusively within the firewall.

In addition to monitoring changes, you will no doubt want to be able to do something about fixing unwanted changes, like rolling them back to a previous version. In short, the ‘change monitoring’ approach requires two basic features – the ability to monitor recent changes, plus some kind of version control.

Recent changes can be monitored as follows:

Most Wikis 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;
E-mail notification of changes is just an e-mail version of the ‘recent changes’ page, but with the convenience of notification;
A variant of e-mail notification is support for really simply syndication (RSS), enabling you to monitor a wiki for recent changes using your preferred RSS reader;
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 ability to track whether a recently changed page has been checked yet, reducing the chances of duplicated work.

I once encountered a philosophical debate about whether wikis should have version control. The idealist in the conversation argued that version control was against the ‘wiki way’ and somehow lacked philosophical purity. The realist argued that people make mistakes and sometimes deliberately do bad things, so the ability to roll back changes was, indeed, a good thing. The realist won the argument in the broader marketplace of ideas and many (if not most) versions of wiki software have version control. Features to look for include capabilities similar to what you would find in a CMS, including:

The ability to roll-back changes to the previous version;
The ability to compare different versions side-by-side;
The use of ‘diffs’ between versions, a function highlighting specific differences between versions.

Spam prevention

Another approach is to monitor the content of changes programmatically. This is sometimes referred to as spam prevention. This differs from user access control in the sense that it monitors wiki edits based on the content itself or patterns of user behaviour. Some systems can block access to internet protocol (IP) addresses and URLs, or they can block the posting of individual changes based on the following criteria:

Restricting the use of certain words or phrases, using word lists or regular expressions;
Blocking access based on excessive activity.

User-access control

When a wiki software package bills itself as an ‘enterprise wiki’, it usually means that it has user-access control.

Most wikis can differentiate between registered and non-registered users and will let you keep non-registered users from making changes. An increasing number of wiki software projects are now offering more sophisticated user-access control through the use of 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.

But there is a lot of variance among wiki packages in terms of how those rights are applied to the site. Some wikis enable 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.

The most sophisticated enterprise wikis work with single sign-on security systems such as SiteMinder, or offer network and directory integration (supporting Microsoft Active Directory and LDAP-standard directory software) for user authentication and authorisation.

Conclusion

Contrary to their reputation, wikis are content management systems that can be managed. They simply take a different approach to content management by choosing to emphasise speed and flexibility rather than imposing strict controls. In order to successfully implement a wiki software package, you will need to look at workflow from a different perspective and be sure to select wiki software that provides the right level of content monitoring and access control for your organisation.

Mark Choate is an award-winning internet publisher, e-business consultant and educator. His particular area of expertise lies in cross-media content-management tools, blogs and wikis. He currently helps organisations make innovative use of these new technologies to improve the quality and efficiency of their work. He originally wrote this article for analyst company CMS Watch. Mark can be contacted at mark@choate.info.

What is a wiki?

“The simplest online database that could possibly work. Wiki is a piece of server software that enables users to freely create and edit web page content using any web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and cross-links between internal pages on the fly.

Wiki is unusual among group communication mechanisms in that it allows the organisation of contributions to be edited in addition to the content itself.

Like many simple concepts, ‘open editing’ has some profound and subtle effects on Wiki usage. Allowing everyday users to create and edit any page in a website is exciting in that it encourages democratic use of the web and promotes content composition by non-technical users.”

Source: http://wiki.org