Wiki Information Patterns

The recent generation of web tools (part the so-called web 2.0) offers new amazing ways to share information on the web. New tools enable new way to shape company processes: software development is the most obvious one, but not the only one. As always, new tools have also a dark side: one might turn out to be a great productivity booster in a given context and total waste of time in an apparently similar one.

The shape of the information
The primary advantage of wikis is that they allow you to provide the desired information to a group of users “on-the-fly”. In an agile scenario, useless information is simply not written because nobody is demanding for it.
Another positive site effect of making publishing as easy as possible, is that different types of information may find their way to be effectively shared as well. Information doesn’t need any more to be “framed” in a complete document and published when the whole document is complete. Or put in a stand-by state before being “officially released” if the information is not fitting the standard document structure. At the end, wikis are just probably the most effective way to lower the information publishing threshold.

This allows smaller bits of meaningful information to be provided to the readers community, but multiplies for a zillion times the question “where should I write this?”.

Wikis provide no fixed structure constraints so that the information grows (bloats) spontaneously, as a pseudo-organic being, looking like a logical structure to somebody and like a completely uncontrolled chaos to somebody else.

The communication model
Publishing useful informations is still a lot different from ensuring that every consumer is reached by the same bit of information. If you want instant, or official, communication to a group of people, then mailing lists are probably the best way. Wiki information are instead meant to be persistent, available to an open community of users, and consumed on demand. They fit the XP paradigm by ensuring collective ownership of the content, so everybody is free (and usually encouraged) to add extra information, or to correct the current content if it’s found to be incorrect.

In this context the reader is probably looking for some information about a given subject and is given different options:

• navigate the wiki structure to go where the information should be,
• search in a google-like fashion the whole wiki for the desired information,
• check the differences, between last time through a “what’s new” service or an RSS feed.

Navigating the wiki is probably the weakest way: the wiki is intended not to have a strong, well defined structure. The wiki growth model resembles the algorithm for storing data in a balanced tree structure: pages get split when they start containing too many different information, so the searched information might not be in the same place it was found before. On the contrary, if the structure is not changing that much, a visitor might think that also the content hasn’t changed that much since last visit, making the wiki a less attractive place to visit.

After you admit that a super imposed structure is not the solution, you have to step back and rely on the search approach, which works whatever the current structure is. The only limit of this approach is that it lets you search for things you know, but tells you nothing about things you don’t know.

To “smell” current trends in your community you’d better switch to the “what’s new” approach, maybe enabling a RSS feed reader (most wikis support RSS feeds). Unfortunately, this typical web 2.0 approach might result unfamiliar yet to somebody, requiring some guidance to become effective. Be careful that, even in an ideal world where everybody has a RSS feed reader linking to your wiki you still can’t compare effectiveness of communication to an old fashioned web 1.0 e-mail.


Tags: Wiki, Project management, Web 2.0