Why Content Management is Not the Same As Wikis

In the technical support documentation space I've been recommending wikis as a way to enhance collaboration on support documentation as an alternative model to the traditional approach of having a small cadre of technical writers and experts using a traditional content management tool to publish documents to the way.

While I'm an advocate of opening up the wiki to customer input, there are levels of collaboration that may make it easier for companies to get their feet wet without going so far as to open it up to customer input. The wiki could be used, for example, to allow input from other employees across the company, from R&D engineers to call support agents.

However, whenever I propose this, the established parties usually say "Why don't we just fix the content management process we have?" or "If all we want to do is collaborate inside the company, we can use the content management tools we have for that."

Wikis aren't just another content management tool however. Wikis embody design principles that encourage contributions. When Digg was first implemented, the earliest versions had a two-step process to submit a digg vote. Kevin Rose, founder of Digg, spoke about the impact that moving from a two-step to one-step process had on the site:

There was a huge shift in activity on Digg when we made the move to the one-click digg in November 2005. Once we added Ajax, activity went through the roof on [the number of] diggs. It was just insane. Just the ease of the "one-click and you're done" made all the difference in the world. Once the users grasped that the content is syndicated to friends, friends' activities then went through the roof. These small incremental steps in feature additions drove the growth.

The more direct and lightweight the process is for contributing, the greater the number of contributors. And it's not just pure volume of contributors: a simple contribution at first can then lead a user from passive recipient to enthused contributor. The editors at Wikipedia that devote much of their lives to upholding the quality of Wikipedia all started their involvement with a single, simple contribution at some point in time.

Wikis are perhaps the purest embodiment of the design principles of directness and lightweight processes. Every page has an edit button, so contributions are never more than a click away. The act of adding a few words to a document t is rarely more than clicking edit, inserting those words, and then clicking save.

Contrast that with a typical content management system: As a user who is browsing support documents on the web, and then spots an error in a document, if I've already used the content management system before, I have to then:

1. find/launch the content management system
2. login
3. navigate to the document I was already viewing, usually by an obscure mechanism that isn't the URL of the public document
4. choose to edit the document
5. make the edit
6. save the document
7. probably go through an edit review process relying then on other people to review the edit
8. wait for notification that the edit is published
9. check that the web document reflects the change

If I haven't used the content management system, I would need to:

1. Find out how the content is managed, probably by emailing peers until I get an answer
2. Find out how to apply for a login
3. Justify my need/right to modify the content (usually a lengthy process)
4. Find out how to use the system

The two choices differ so significantly in effort involved, that the result is not just a quantitative difference in the number of contributions, but a qualitative one as well: true collaboration among a large group of contributors is unlikely using a traditional content management tool, because only those whose primary job it is to manage content are likely to invest the effort to use it.

By comparison, wiki makes it clear that editing is possible, puts the edit tool only a click away, and removes the step of having to renavigate to the content to be edited. While these steps may seem small, like we saw with the Digg example, small reductions in effort correspond to large increases in contributions.

Side note: I'm currently reading Designing Web Interfaces: Principles and Patterns for Rich Interactions, which inspired some of these thoughts.