Chapter 5. First Growth

5.1. Structure or Chaos?

One of the first questions asked when implementing a wiki is how to set up a structure for the information it will contain. There is a common belief that the inherent open nature of a wiki will inevitably lead to chaos. In some senses this isn’t too far off the mark, so perhaps the best question to ask when deciding on a wiki structure is how much chaos can your community tolerate.

Remember, the decisions on usability, navigation, and structure will come from the community. The looser the structure you start with, the more likely it is that an efficient usable structure will evolve. Force fitting a structure, your own or a traditional company model, will limit the effectiveness of the wiki and rob it of much of the value that comes from a collaborative community environment.

Those of us raised on more traditional media (i.e., the printed word) are most comfortable with the book paradigm where information comes in a structured format, like chapters with headings and sub-headings, and where navigation is either a map (a table of contents) or an alphabetical listing of subjects covered (an index).

Naturally, when we started to deliver information electronically we carried that paradigm over. We made a few concessions to the new media, but the underlying print-based model stayed because that’s what we were comfortable with. It’s what we naturally understood, and it matched the way that we handled locating and using written information outside of the work environment. However, this model no longer works for a new generation, which has always known and used the Internet and which has developed a different way of accessing information. This generation has a much looser way of searching for and accessing information that abandons the hierarchical book structure for one based on searching, peer recommendation, tagging, and browsing.

We need to bear these differences in mind when designing the wiki’s structure. What makes a wiki uniquely valuable is that it will develop organically, based on the needs of the community, and will create its own folksonomy rather than adhere to an imposed taxonomy.

A model based on the book paradigm may not be instinctive and can easily lead to confusing navigation paths. Also, the book paradigm can lead you to base the wiki on the existing source document hierarchy and navigation schema, rather than allowing the content structure to develop organically. By applying an existing structure you could be limiting the potential for a community-driven schema without even realizing it.

As I stated earlier, a degree of chaos is inevitable in the early stages of any successful wiki implementation. The question is, how much chaos is the community willing to tolerate?

Whatever level of chaos you decide you can tolerate, you need to develop a management approach that supports it. In the early stages of developing this book I posted the following note on Twitter:

“The first rule of wiki is that there are no rules.”

While many agreed with this sound bite, some objected. The idea of total chaos and freedom of input was contrary to their nature and culture. In such cases you may want to create an initial minimum structure so that you have some guidelines for contributors.

In practice, the majority of groups will prefer at least some basic guidelines and templates to a totally open system. This sort of implicit governance builds trust in both the wiki and the content. Self-governance also encourages good behavior within the community.

Be aware that the structure your community needs may not be the one that you think it needs. Whenever you enforce even a minimal structure make sure to monitor it for emerging patterns and be prepared to adjust accordingly.

In his excellent book, Wikipatterns[Mader07], Stewart Mader discusses and catalogs many of the different types of behavior that wiki contributors develop and use during a wiki implementation. By studying and recognizing these patterns you can quickly make necessary design and structural changes