Matt Schwartz

A good wiki is hard to find, most are full of much more fail than knowledge.  Google around a bit and you will find countless numbers of wikis that started full of potential, but wound up with few contributors and only a smattering of content.  There are many reasons for these blank slates, but a  primary one is misuse or at least a misunderstanding of what wikis on the modern web tend to do well.

When Ward Cunningham built the first wiki the goal was to create a web (Hypercard) application that allowed people to write their content in the same place that it was viewed.  Click a button, type some text, behold your wondrous creation.  These days however, with all of the tools that are available to allow the easy creation of content, a wiki will rarely be the best tool for that job.  That’s why people build CMS’s.

Lets be clear, there are plenty of sites out there that use wiki software to host their content.  A site built by one or a few people that happens to  be built on Mediawiki is not the plate of failure I am talking about.  It is the site that sets out to be an actual distributed collaboration project in the model of Wikipedia and winds up consisting of three pages of editorial about HAM radio.

Successful wikis are construction projects:

• Wikipedia is building an encyclopedia
• Wiki Travel is building an online Frommers
• The MSDN wiki is building a user’s manual

The construction project mentality is not just a turn of phrase or a seminar induced buzz word.  Having a tangible model that contributors and viewers alike can reference when using the site is one of the things that best enables useful collaboration.

The misunderstanding that takes place is that people confuse the wiki software itself with an actual wiki.  Wiki software provides a lightweight way to put words on the screen.  A wiki is a document that is the end result of people writing, editing and molding their common knowledge into an end product.  An encyclopedia, a travel guide, or a user’s manual.  Its not a web site where everyone gets a page, but rather a single collective work where each contribution gets the site one step closer to an end goal.

This is what wikis are good at: document construction.  Harnessing lots of people to work together one single thing.  Not at bringing lots of different people together to chat about a subject.  That chatting might produce lots of interesting information, but it does not produce a useful or functional document.

Contributors are going to provide better content when working within this model.  The blank slate of a fresh edit page gets replaced by meaningful content when users can successfully squeeze the information pent up in their heads into some useful online form. A construction project helps those contributors by providing a template for their knowledge to be placed into. A wiki that is just a series of pages about a topic does not do this.  Instead, it encourages people to simply spill their thoughts out on to your web site.

A construction project mentality is the difference between providing a useful piece of the puzzle and throwing some knowledge at the wall and seeing what sticks. Consider:

HAM Radio Fail Wiki:

• I know a lot about HAM radio and want to share the knowledge.
• What would be a useful contribution?
• Well this guy wrote a page with a diatribe about customized antennas and the time he used a custom antenna and talked to someone that might have been from Connecticut.
• I will tell my story about HAM radio.

This entry does not contribute to collaboration – even if it is well written it is not a contribution to a common document, it can not be readily edited or refined by anyone other than the original author.  It is a stub.

The HAM Radio Encyclopedia Wiki:

• I know a lot about HAM radio and want to share the knowledge.
• What would be a useful contribution?
• There is not a page about custom antennas.
• What should I type?  What should my end product look like?
• OK, this place is an encyclopedia.  I’ll type what I think an entry on that subject should look like. (content, tone, scope, etc)

Even if this contribution is terrible it is one that can be collaborated upon.  Others can supplement, correct, or expand it because it at least fits into the document that is being collectively built. Without the construction model in place the user was provided with no scope, no frame of reference to target his knowledge at.  Instead he only found a blank slate and a stage on which to preform.