In a previous post I talked about various types of Web sites, outlining a purpose-based taxonomy.
Today I’d like to talk about wikis, a particular type of software platform for building and displaying Web sites.
The first wiki software was created by Ward Cunningham in 1995, and he originally described it as “the simplest online database that could possibly work.” “Wiki” is a Hawaiian word for “fast,” and he came up with the name after remembering a Honolulu International Airport counter employee telling him to take the “Wiki Wiki Shuttle” bus that runs between the airport’s terminals. According to Cunningham, “I chose wiki-wiki as an alliterative substitute for ‘quick’ and thereby avoided naming this stuff quick-web.”
Almost everyone has heard of wikis these days, thanks to the extraordinary success of Wikipedia, but it still seems the advantages of wikis are often misunderstood and under-appreciated, especially when it comes to corporate usage.
Let’s consider the defining attributes of a wiki.
All of the following statements are typically true of a wiki.
The Wiki software runs on the Web server, not on users’ computers. This means that all the features of a wiki can be made available to any user with access and a Web browser (Internet Explorer, Mozilla Firefox, Apple’s Safari, etc.).
Ordinary Web pages are easy to create and modify. With a wiki, any user of a site can create a new page, and update an existing page.
No special authoring tool is needed. With a wiki, you add/update/format content using nothing more than a modern Web browser.
Lightweight markup is used to create content. A lightweight markup language is one that allows a user to type text in a normal fashion, using a few special conventions, and then automatically converts the text to HTML, the universal language understood by all Web browsers. Markdown and Textile are two examples of such lightweight languages.
Page titles become targets for hyperlinks. With normal web pages, the page title seen by a human user and the file name and directory path used to create a link to that page are two different things. With wiki software, the page title is used to identify the page to both man and machine, making it much easier to create hyperlinks. An offshoot of this is that each page in a wiki must have a unique title.
Renaming a page also modifies all links within the wiki. With ordinary web pages, renaming or moving a page can result in broken links within the site. With wiki software, the links are maintained in a database, allowing the wiki software to automatically change the links to point to the new page title.
Hyperlinks are easy to create. Since a page title is all that is needed to identify the target for a hyperlink, a hyperlink can usually be created in a lightweight markup language just by writing natural English, and then enclosing the page title within brackets, or via some other equally painless convention.
Here’s an example of a sentence with an embedded hyperlink, using the Textile-based syntax of Confluence:
See our List of [Defect Codes] for further information.
And here’s the same example, using HTML and normal web pages.
<p>See our list of <a href="defect-codes.html">Defect Codes</a> for further information.</p>
A link to a page can precede the creation of the targeted page, and clicking on the link will open an editing session capable of creating the missing page. This is another convenience feature that makes it easy to build a site of related pages.
Complete version history is automatically maintained for all pages, and any earlier version of a page can be easily restored by anyone with the appropriate authority. This capability provides a safety net to support the combination of quick and easy updates and a broad group of contributors.
Many people seem to think that the following statements are true of wikis, but at best these are overly broad generalizations.
Wikis are inherently egalitarian, allowing any user to update any page.
While it is true that wikis are good at enabling collaboration, many wiki packages — especially those designed for corporate use, such as Confluence — allow fine-grained access control, so that update privileges can be restricted to as small a group as needed. Read-only privileges can also be restricted independently, so that some defined subset of potential users may be allowed to read a wiki, and some yet smaller subset may be given update privileges.
Wikis can be built entirely with volunteer labor.
While wikis are famous for allowing casual users to also update and contribute content, dedicated resources are often needed to design the structure of a wiki, to provide seed content, to define rules of engagement for contributors, and to monitor and encourage submissions.
Wikis should exist in parallel with other, more tightly controlled websites.
This was the original idea behind Wikipedia — to host a wiki for submissions, and then promote content to the official Nupedia site only after careful review and editing. However, the wiki grew so rapidly that the founders quickly abandoned Nupedia… and the rest, as they say, is history.
Despite this notable precedent, many sponsors seem to persist in the notion that a wiki should be able to peacefully coexist with an official site on the same topic. This strategy does not typically work very well, since it positions the wiki as a sort of “sandbox” in which users are allowed to play, but clearly identifies a second site as the serious and official authority on the same topic. The message is clear: “play all you want over here, but however much time and labor you invest, people will not take your content seriously.” This sort of message does not typically motivate potential contributors to do their best work.
Wikis are an example of social media.
Sites like Facebook, LinkedIn and HuffPost are designed to stimulate and encourage social interaction among their users. A wiki, on the other hand, typically keeps social interaction among contributors hidden from casual readers, so that they can focus on content.
The difference is significant. On a social media site, it is important to preserve each user’s every submission as an independent piece of content, and identify the source, so that you can learn more about the contributors. On a wiki, the opposite is true: individual identities are subordinated to the greater good of a single, shared version of reality that everyone can agree on.
By the way, this mistaken belief often seems to reinforce misperception # 3 above.
The more wikis, the better — let a thousand wikis bloom!
This misperception seems based on the mistaken ideas that wikis are a form of social media and that they are inherently egalitarian. Again, though, as with the structure of individual wikis, the overall structure of a wiki collection — say, within a corporate firewall — is best tended to by a dedicated resource who is willing to do some carful pruning from time to time. Otherwise it is hard for casual users to decide which wiki to consult, with makes it hard for all wikis to attract visitors.
A good definition might be:
Wiki: a website designed to facilitate collaborative content creation in order to encourage convergence on a shared and stable view of reality.
A wiki is a good choice whenever the following are all true:
A number of different contributors will work collaboratively on the site’s content.
The majority of the site’s content will be text-based.
The content is meant to emphasize what the collaborators have in common, rather than their differences.
The site is not intended primarily for marketing purposes (in other words, not a “brochure” site).
March 13, 2011
Next: Types of Metrics