Hammer
Article started by pieterh
18 Oct 2009 14:37
The Hammer pattern is a recipe for creating knowledge bases in Wikidot. A knowledge base is a set of articles in some domain, edited and discussed by collaboration between many individuals, and organized in different ways.
The name "Hammer" comes from the effectiveness and wide applicability of this pattern. Many collaborative projects can be easily cracked by hitting them with Hammer and it is a simple technique for regaining control over wiki projects that have lost coherence.
Examples of use:
- The Design section of pieterh's blog.
- The Wikidot FAQ project.
- The Knowledge base sample application.
- This pattern site.
General structure
We can use Hammer as part of a site, or as a whole site. A site can contain one, or many knowledge bases. A knowledge base is one category ('article:'), containing a dozen to many hundreds of articles. A cover page ('article:_start') provides an overview of the knowledge base. Usually the cover page provides the start page for the site. A template ('article:_template') formats each article and adds necessary scaffolding such as per-page comments, rating, and inter-page navigation.
Content model
The content model is based on lists, which all editors can share. Principally, Hammer uses autonumbering for articles, so that pages have names like 'article:1'. This defines a de-facto content model of the knowledge base as a list of articles stretching from oldest to most recent.
Discussion model
Comments are corrections to, proposals, and discussions of individual articles. We do not use a separate forum, although this is typically used for discussions of the knowledge base as a whole. We therefore use the Comments module in the article:_template page to add commentary to each article. We may show the comments in reverse order (newest first) so that errata and ideas move away from the article as they age.
Navigation
Users navigate by looking at lists of articles, and selecting one to work with (to view, edit, delete, retag). The cover page is a navigator: a table of articles that the user can filter and resort in various ways. Hammer relies heavily on the ListPages module to create this navigator. Additionally, the article template adds navigation between pages using a scrollbar that emphasizes the list content model.
Life cycle
Hammer uses the Workflow pattern to push pages through a life cycle, using hidden page tags like _open, _closed, _deleted. Users can then navigate through lists of pages in particular states.
Ownership
Hammer uses the Editor pattern for page ownership.
Hammer encourages the creation of many sites, one per specific problem. Smaller knowledge bases are easier to understand, improve, and manage. So the barrier to entry for new editors is lower. Many sites with the same Hammer organization are collectively easier to understand than either one large site, or many sites each with an ad-hoc organization. So the overall effort for top editors is less. And smaller sites create a stronger sense of ownership than larger ones, so there is healthy competition.
The standard Hammer permissions model is:
- Site access policy is usually "open"
- Registered users can make comments
- Trusted users get rapidly promoted to admin
- Only admins can edit pages.
This is again different from the Wiki pattern where all participants are equal (though some more equal than others), and where all edits are done directly into a page. In Hammer, the more expert users synthesize questions and remarks from less expert users.
Analysis
Hammer and Wiki are both knowledge base patterns but they operate very differently. Wiki encourages the growth of an ad-hoc structure that maps the natural organic navigation paths that users expect. When structure is missing, users create it. When structure is wrong, they change it. In Wiki, structure is implicit in content, and impossible to map explicitly. Hammer imposes a linear, uniform structure that is separate from content, and its explicit mapping is the first thing visitors see. Wiki imposes no specific page structure while Hammer uses live templates to impose structure and navigation.
How do we decide what pattern to use? There is no single answer. Large wikis with many contributors can be very successful. But many wikis die of neglect because they impose a high maintenance cost. Hammer is much more aggressive about separating layers of content, and this can reduce maintenance by an order of magnitude. We are studying whether Hammer can be used to revive wikis.
At the same time, Hammer is obviously inappropriate for some cases. A list-based content model does not scale above several hundred articles, perhaps a thousand. This is mitigated with a life cycle, so that inactive or closed articles can be separated from the active ones. It can also be resolved through hierarchy, which is what the PageTree pattern does. Lists of Lists can work very well. And it can be resolved through abandonment of a formal structure, which is what Wiki does well.
We suggest at this stage that Hammer is suitable for any kind of linear workflow application, for expert groups who serve a larger passive audience, and for workgroup coordination. It is not suitable for forums, for wikis, and for other non-linear applications.
Source code
Cross-site includes to be defined:
- hammer_template
- hammer_start
- hammer_start_head