Why wikis?

Jon Udell's "The Wiki way" talks about Wikis more generally and JotSpot in particular. In Jon's words:

The users of a Wiki think of the process as organic growth. Enterprise IT planners tend to regard it as unstructured chaos. They're both correct. JotSpot's aim is to harmonize these opposing views by empowering users to create islands of structure in their seas of unstructured data.

I liked JotSpot's demo; adding user-definable forms (structure, or what we'd call content types in Sytadel) to unstructured information is a nice feature. It's also one we often hear requested for CMS deployments. Interestingly, we moved away in Sytadel 4.0 from supporting this kind of facility (preferring to use just XSD and XSL), whereas in Sytadel 3.0 we had a complete Construction E-gineer which allowed users to build their own new content types.

However I disagree with the basic thesis that by allowing users to create structured information you will address those Enterprise IT planners' concerns. Let me explain ...

I've been trying to understand the exact appeal behind wikis for some years, since using one extensively in a previous company in the year 2000.

Wikis are great - they do let you (as in you, the average user in an organisation) rapidly build a web site, with minimal involvement from technical experts once they've installed the underlying software in your web server. This is a strong attractor.

One of the strongest features of wikis is the ability to hyperlink to other content while continuing to write without losing context. This works by using camel cased titles. (Camel casing is words where there are no spaces and all the individual words are capitalised.) This blog entry would be referred to as WhyWikis for example. (An alternative is to use [['s and ]]'s.) It's intriguing that this simple facility alone is noticeably more efficient than highlighting text, clicking a url insert icon, and entering the destination URL. Thus wikis provide a simple form of content management, where the location of the destination content is irrelevant to you, and the addressing of the content is also trivial (provided you know what it's called).

The Wikipedia is a great example of where Wiki technology is superb. The content is basically unstructured, and it's very unlikely that individual content items run into naming clashes. The one example where this may start to occur more frequently is references to individuals.  For instance, while Bill Clinton is currently the only entry for Bill_clinton in the Wikipedia, what happens if a famous business tycoon called Bill Clinton comes to prominence? (I've run into this problem in a minor way at my old university, where the name "Peter Bailey" was shared by a far more distinguished individual, Peter Bailey of human rights and public law renown.)

And wikis allow simple, collaborative, open content creation. As we found with FAQTs in the past, providing simple, collaborative, open content creation systems to people will generally be used (gratefully) and not abused.

There are a number of problems I suspect for Enterprise IT planners with wikis, and it's not the existence of unstructured (vs structured as in form or content type) content.

First, it represents yet another form of content repository that needs to be backed up, archived, and supported for users. Every new repository adds another lot of complexity to their tasks.

Second, many organisations are yet to embrace free-for-all intranet content. This will (hopefully) change, but there is still strong reluctance to unleashing all users within an organisation to publish whatever they like to whoever they like. (This of course is a question of trust, between managers and non-managers.) The smaller the organisation, the more this is likely to be supported on average I suspect. Neverthless, electronic workflow/approval rears its ugly head once again.

Third, not all content (and content creators) successfully self-organise. There remains strong value in pre-organisation of the information (this is essentially the field of information architecture), and strong value in editorialising (content managers) and post-organising (librarians). Pre-organisation is an evolving area of research and best practice (but almost completely content domain specific), and editorialising and post-organising is nearly all human-centric. (Some emerging practices such as content tagging in del.icio.us and Flickr are interesting approaches to this problem.) The upshot of these issues is that the content repository becomes rich with information, but lacking authority or easy navigability. Highly effective search helps the navigability, but managing the authority of information is harder to achieve.

Fourth, its hard to refactor the content. For example, I decide I want to consistently rename various bits of information, and all the links to it. I can do this if I have local access to the file system, and am handy with Perl or some other regular expression tool, but as a general user that's difficult through a wiki's interface.

Despite these problems, the emerging number of people using wikis, and more interestingly, companies building on top of wiki technology concepts, demonstrates that there is strong appeal in their fundamentals.