Peter 2006-06-01 < StructuredWikis LLC

NOTE: The founders of StructuredWikis LLC moved on. The content on this site is for archival purposes only. Please contact the following companies:

Twiki, Inc. for wiki support, wiki solutions and services
-- Peter Thoeny

Evolved Media for content creation and publishing services
-- Dan Woods

The Penguin and The Python for Linux consulting and Python programming

What is a Structured Wiki?

Ward Cunningham invented wikis, a type of website that allows users to add, remove, or otherwise edit all content very quickly and easily. Wiki systems:

support organic content: The structure and text content of the site is open to editing and evolution,

have open content: Readers can refactor incomplete or poorly organized content at any time,

are hyper-linked: Many links pointing to related content, and

are built on trust: Open for anyone to edit, with "soft security" and audit trail.

The ease of interaction and operation makes a wiki an effective tool for collaborative writing and to share knowledge. Now, on to a completely different world. Database systems:

contain highly structured data,

offer easy reporting,

support workflow, and

are built on access control.

A structured wiki combines the benefits of - as it seems like - contradicting worlds of wikis and databases. When you do that you get something very powerful: A collaborative database environment where knowledge can be shared freely, and where structure can be added as needed.

I pioneered the structured wiki concept in 1998 with the open source TWiki collaboration platform while I was working for TakeFive as the director of customer support. The company had one relatively complex software product that integrated with other software. I was based in the US, the software factory was in Salzburg, Austria. The product had nice end user documentation, but internal documentation was almost non-existent. Customer support was quite challenging at times, especially because the developers have been 9 hours time difference away. My first priority was to deploy a knowledge base for customer support. Initially I considered to get an off-the-shelf knowledge base software. Then I thought, what about a wiki? A wiki makes it very easy to collaboratively create and maintain knowledge base entries, but it lacked the structure to categorize, publish and control content. My engineering background kicked in, and I started to add features to a wiki so that it can be deployed as a knowledge base for customer support:

Entries are based on a template, with problem/solution pairs.

Files can be attached to entries, for example with a patch that fixes an issue.

E-mail notification is used to keep everybody in the loop. Senior engineers can review content for accuracy, and less senior people can hone their trouble shooting skills by reading the changes.

Each entry has a form to categorize the content.

Query-by-example search forms are used to quickly find a solution to a problem.

Based on the categorization, content was pushed out to the corporate website as FAQs or a public knowledge base entries.

Access control was used to determine who can publish content.

Version control was introduced for accountability and audit trail.

The result was the T5-Wiki, which later became TWiki.

In a structured wiki, structure can be added as needed. The "as needed" part is important. First and foremost, employees are enabled to document processes and to share their daily workflow in the free-form wiki way. Secondly, employees can create structured wiki application with forms, queries and reports to automate their daily workflow.

Knowledge workers follow a pattern when working in a structured wiki environment. People typically start with unstructured wiki content. For example, a call-center might have a simple wiki page with a status board listing who is on call at what time. This could be in the form of a bullet list or a table. Status board in view mode and edit mode

The users discover patterns while maintaining the page: The status board has a fixed list of support engineers and a fixed list of time slots. A user or administrator can now build a simple application to automate the task of changing the status board. Discovering patterns and adding structure is typically done in iterations. The example on the right shows the final iteration of a status board. When you edit the table you get pick lists to select a time and person.

Feedback on this blog? Please send me an e-mail.