Sort of minor post here. While writing down the follow-up of the last post, I found myself defining a classification of the structures wikis tend to assume when left growing in an uncontrolled fashion. I was tempted to call them patterns, but they’re far from being a proven solution, and often they tend to be part of the problem instead.
Tree-like structure
This is the most common shape, when people are told to use wikis. Information is put on a deeply nested page, on a path that doesn’t have any other content than the link. The overall structure is no different than a deeply nested directory tree, but it’s probably not the way to efficiently use wikis:
- if you are exploring the wiki you have to click quite a few times to find meaningful information;
- the information is always in the leaf and not in the node that addresses it, sometimes the information is only in the attached document;
- a nested directory tree is a personal interpretation of a structure to a set of information that doesn’t yet have one. Put in this way is a sort of arbitrary act: I’ve never seen two person agree on a directory structure “at a glance”, simply because people’s brains are organized differently: it’s easier to agree on a subject than on the way we store it in our personal mind categories.
Blog-like structure
In this case, the author puts the whole information needed in a single page that keeps getting bigger and bigger. Aside from readability, this approach fools feed readers, that keep marking the page as modified, leaving the reader the burden of discovering where the page has actually changed.
This structure might fit sequential information (like a sequence of steps in a how-to document), but tends to be discouraging for the readers. Linking the page, as a memo, also turns out to be less efficient, cause you ‘re linking the whole page and not the section.
Document Aggregators
If you have a lot of external documentation to be made available to the wiki community, aggregator pages in a wiki can really make things a lot easier for the newcomer: they can provide extra information about where to start reading, the context the documentation was written, the intended audience and so on. Adding just a note, when attaching a document could really make the difference.
If the documentation is evolving, then we are probably putting ourselves at risk of duplicating the information. Some wikis are more oriented to software development and allow integration with SCM systems, more often this is a duplicated step so misalignments are always possible.
Hypertext blob structure
This is my personal favourite. The information is divided into several pages, each one focused on a single topic. Pages normally contain a lot of outgoing links, some pointing to a related page, some simply acting as a “to do” marker. In this way the information is structured as a “pure hypertext” containing links to all the related pages.
Unfortunately this structure works fine if you are using it as a help file, but tends to make you loose the grip about where the important information is.
The worst situation happens where you have to linearize the content of the wiki: both the structures described before can be represented as trees with a root acting as a starting point, while the pure hypertext has returning links transforming the structure in a graph, thus making linearization harder. To handle these situations some wikis provide a more constrained tree-like structure that can be enhanced by extra links, which have no impact on the main structure.
With such “fully floating wikis”, a technique I often use to help user navigate in complex information structures is to provide one or more access pages that act as reading keys of the whole hypertext. A hypertext might have many of these indexing pages pointing to safe “starting points”.
Tags: Wiki, Project management, Agile
No comments:
Post a Comment