Over the past year or so I have started to take a deep dive into understanding the use cases and value of wikis on an Intranet. My sense was, and still is, that the wiki model is incredibly powerful but also very different from existing models of collaboration. It is a real mind-bender because the wiki model changes assumptions about what is a "document" and what is a web page. I am also finding that many enterprise IT people have a difficult time positioning wikis within their set of tools. In fact, I think many analysts and columnists still have a hard time understanding wikis too.

To illustrate my point, how many times have you heard blogs and wikis discussed in the same sentence? Search the Internet for "Blogs and Wikis" and you will see what I mean. Dozens of conference sessions and whitepapers address them together.

In doing my research for this blog post I found something Tim Bray wrote a year and a half ago. Tim says:

Granted that they’re both about people placing content on the Web for other people, but in their essential nature, it seems like they couldn’t be more different…At a deep level, I don’t think blogs are really a new thing in the world; but wikis are.

And that is as far as I will go to describe wikis in terms of blogs (a common approach by many writers). The key point from Tim is the last one; wikis "are really a new thing in the world".

So, what is a wiki? In short, I view wikis as books. They are books that can contain as many pages as necessary, can be filled with any type of content and can easily be ordered (or re-ordered). A wiki can represent any type of book; fiction, non-fiction, a textbook, a how-to manual, anything. Plus, a wiki does not ever have to be finished. It can be updated as things change such as market conditions, corporate policies, etc. Today, on most Intranets, knowledge workers often produce "documents" but these are just a different form of what I call book (or are pages in a book). Wikis start challenging our assumptions about of what form a document takes.

Wikis just happen to exist on the web and this is where it gets confusing. Since they are web pages then wikis must be about producing websites, right? Yes and no. Yes, wikis can be used for building websites but this model is way too limiting. There are better analogies to describe wikis (like a book that never is completed).

Wikis are represented as a collection of webpages. Each page of the wiki can be edited by simply clicking "Edit this page" and it is relatively easy to link to other wiki pages. All of this takes place within the web browser. No other programs are required to view or edit a wiki page. But, when you are done (if you are ever done, some wikis are never quite finished) you often have a collection of pages that can best be described as an online book with each wiki page representing a page of the book.

A wiki page is never represented as a "file" that is copied, moved, or edited. Although wiki pages can be referred to as documents they do not require a program (other than a browser) to edit them, unlike a Microsoft Word document. Wiki pages sit on a server but are not downloaded any longer than it takes a browser to render them for the reader. For all intents and purposes, wiki pages are documents but take on few characteristics of documents we deal with today. This is a totally new paradigm for documents that enterprise IT is just starting to understand.

The Google vs. Microsoft battle may be a good way to highlight this fundamentally new approach in working together. Google products like Writely and Spreadsheet work with entities (documents) that only exist on the web. Granted they can import and export Word and Excel files, but fundamentally the "document" the user is editing or reading exists within Writely or Spreadsheet and are only accessible using a browser.

Microsoft Word and Excel produce files that are edited on the desktop computer. Only others with a compatible application can read these files. Finding and indexing the many documents that make up a whole book (or collection documents) can be troublesome. Even though the notion of linked Office files has existed for some time, most people do not use this feature.

It is interesting to note that Microsoft Office SharePoint Server 2007 blurs the lines between these two models (web-based documents versus file-based documents) by providing Excel Services (to read more about this intriguing new capability checkout David Gainer's Microsoft Excel 2007 blog). Excel Services running within a SharePoint 2007 site provide a way to create web interfaces into spreadsheets. However, the fundamental storage unit of the spreadsheet is still a file. If someone did not upload an Excel file to the SharePoint site there would be no spreadsheet to represent in a web browser.

SharePoint 2007 also adds a template for wikis. These are true wikis; only requiring a browser to read and edit. I wonder how long (if it has not happened already) it will be until Microsoft is asked to export a wiki page to a word-formatted file (or vice-versa, importing .doc files into SharePoint wikis). So future users of SharePoint 2007 will be presented with a question: when do we use a wiki and when do we share a Word document?

When looking for opportunities to apply wikis on an Intranet I think the important thing to remember is that the basic document collaboration metaphor changes. Do not look to wikis to change how a departmental website is produced. Rather, look for those scenarios where multiple people are co-authoring documents or where documents can be improved by allowing many others to contribute to them.

Instead of just looking at existing websites for wiki opportunities look at departmental applications based on shared network drives or workspaces that share documents for the best opportunities to apply wiki technologies.