Wiki: "The Simplest Thing That Could Possible Work"

Such a simplest-possible software platform exists and is readily adaptable. Wiki, born in Ward Cunningham's software community in the mid-1990s and grown to stunning proportions with projects like wikipedia, is just such a system. Today, embraced by the "Web-2.0" crowd, wiki platforms are available in a wide variety of colours, are mostly open-source software, and well enough known by a wide audience to be at least an "non-threatening" addition to a software system.

All wiki systems share the same fundamental virtues: simplicity and openness. A wiki is, essentially, a big bag of content objects in a flat namespace. These content objects are usually simple text documents (though not necessarily limited to that). Each content object is easily editable, through the web, by any user. The single piece of organizational logic is provided by a quick and dead simple interlinking facility, based simply on the local names of the content objects, allowing users to quickly assemble collections, navigational paths, and other relationships between content by writing in pointers to other content objects. Additionally, there is usually facility for tracking the change history of any given object.

This rudimentary "content management system" has been used to great advantage, and has proved to scale extremely well. Cunningham's original WikiWikiWeb has been running for over a decade, boasts over 30,000 pages of content. Wikipedia, a more recent project, is far larger, claiming over 1.5 million pages of content in its english-language site. What is significant is that, apart from a full-text search engine providing random-access to content within the wiki, no other organizational structures are required in these sites beyond the dead-simple features outlined above; the simple system of hypertext pointers and wiki names provides the vast majority of the architectural and navigational superstructure on these huge content bases. Interestingly, both site employ a fluid page-categorization system that lurks somewhat behind the overt content linkages in the content, but this categorization system relies on nothing more than the same system of hypertext pointers. If nothing else, wiki presents astounding example of how much functionality can be wrung from so little technological infrastructure.

Furthermore, this system of building large-scale editorial organizations on the thinnest of technological foundations means that the work of organizing and managing the content in the system is an editorial process, rather than a technical administration task. The organization of content, design of site navigation, and the ongoing management of contributions and changes can be—and is—handled by an editorial staff, not a technical one.

Building a Smarter Wiki

Watching these large-scale, successful examples in use day-to-day and year-to-year, we began to dream about the possibilities of using wiki for managing a publication. An early idea we put to practice here was simply to write some simple functions in our wiki (http://thinkubator.ccsp.sfu.ca) that would return a list of content objects in reverse-chronological order. With one stroke, our wiki could present itself as a communal blog. Building on that, we added a little more functionality that paid attention to the categorization of pages, again based on nothing more than interlinkages. Producing a reverse-chronological listing of wiki pages within a given category turned—again, at a single stroke—our wiki into a blogging platform, with as many possible blogs (and RSS feeds) as there are category pages. These ultimately trivial enhancements did nothing to constrain the simplest-possible architecture of the wiki itself, but allowed us to interact with it as something more than a big bag of content.

These early experiments were restricted to categorization and temporal structure, which, in effect, you get for free with a wiki; all that was required to reveal these additional structures was some code to pull them to the surface. But what about going further? What about arranging the wiki on the basis of multiple, overlapping categories? How far could this be taken without introducing so much complexity that it outweighs the productive simplicity of the platform.

A model which is instructive here is the Web-2.0 notion of tagging. A tag is simply an arbitrary keyword, added by a user, to a content object. Tags, in practice, are a sort of simplest-possible metadata scheme. Rather than defining an architecture of cataloguing and organizing structures and controlled vocabularies, as in traditional database architecture, the tagging approach allows an unlimited range of arbitrary keywords to be added to a single field on a content object. The magic of this approach is revealed once a population of users adds tags to a constellation of content objects, and patterns appear. Flickr, the photo-sharing site, provides perhaps the most obvious example of this usage. That "wedding" was to be the most popular tag applied to flickr photos was perhaps predictable, but the fact that "travel" would be more popular than "vacation" was probably not. More importantly, no sane database designer would have attempted to pre-define these categorizations, nor attempt to manage the "long tail" of tags which emerge in actual use. The now commonplace "tag cloud" is a brilliant piece of topsight over the patterns defined by user-generated tags, and one which undoubtedly winds up shaping the tagging decisions subsequent users make, in an interestingly generative feedback loop.

To date, the simple wiki categorization system is rather underpowered in comparison to the full-scale architectural power of tagging, as sites like flickr demonstrate. But ultimately, these are created of the same stuff: they are an arbitrary "system of names" and relationships based on names. We are only beginning to see the design possibilities they offer.

A publication like a cultural magazine is in some respects a vastly smaller problem domain than a project like Wikipedia, but in other respects it is more complex.

A Publication Architecture Built from Tags

Start with a wiki. In this wiki can go textual content, image files, as well as other arbitrary blobs (most wiki platforms offer this much already). Each content object automatically gathers basic metadata like author and contributor ids (assuming a site-login policy), creation and modification dates, and revision tracking. To this add a simple tagging interface, allowing authors and editors to assign multiple arbitrary tags to content objects (whether this is implemented via wiki names or a specialized object attribute is perhaps unimportant). Then create a front-end aggregration interface (or several) to the site, allowing the content to be pulled and filtered according to the accrued metadata on each object: authorship, datestamps, revisions, and, of course, tags.

The result of this scheme in a large-scale, public wiki like Wikipedia or the WikiWikiWeb could easily run to chaos, with no guidelines for contributors about the semantics or implications of particular tags. The result would be a tag cloud like flickr's, which presents a raw statistical picture of user behaviour, and which is probably not more useful than existing wiki catgegorization systems.

But in a small workgroup, composed only of those people contributing to the production of a particular publication, and for whom there is a degree of shared culture and historical awareness of the publication over time, things might be different. Add to this an editorial staff whose very function is to add a top-down sense of logic and organization over the publication, and an arbitrary system of tags might begin to look like a flexible organizational tool. Consider the following set of possible tags:

• canada day 2006
• event
• celebrations
• prime ministers
• july 15 issue
• current events
• copyedited
• approved
• brilliant
• self-congratulatory

These tags are applied to a hypothetical news item on the Prime Minister's comments on the Canada Day celebrations, which has been copyedited and approved for publication by an editor. It has also been deemed both "brilliant" and "self-congratulatory" by various people. The author's name and the mechanical data regarding datestamps and revisions have also been gathered by the system. The first four tags here could be considered as subject descriptors, useful when searching or browsing for material on particular topics. The next four tags could be considered workflow descriptors, adding information about which issue this is slated to appear in, that it should appear in the publication's "current events" section, that it has been through various editorial review and approval stages. The last two tags pass value judgements on the content.

Clearly, we have a mishmash of semantics here that would make any database architect shudder. There is simply no basis for any unambiguous assertion of status or relationship in this collection of descriptors. But—and here is the conceptual leap I ask you to make—within a small workgroup with a shared culture and history—these sorts of informal descriptors are exactly the sort of thing that editorial decisions and actual practice are based on. Their ambiguity is relative. If the context is well-enough established, then these become useful 'tags' on pieces of content. With a small amount of pre-defined agreement at the policy level (that is, agreement between human beings about how the work is done), these descriptors are indeed enough to be useful. But more importantly, the arbitrariness of the tags means that the recategorization or items is basicallly unlimited, the re-conceptualization of the categories themselves is unconstrained (what if they dump their "current events" category altogether?), and the business of managing the tags is entirely an editorial one.

It seems to me that the great thing about the tagging model is precisely that there isn't a pre-defined set of descriptors available. Users can add as many tags as they want, which means that things can be described multiply, along different axes, in multiple dimensions quite practically, without having to do a lot of relational gymnastics. The result is that relationships between different kinds of descriptors can be handled semantically and editorially, rather than formally and technically.

The question naturally arising out of this scenario is one of who gets to define these tags? In the example above, "brilliant" or "self-congratulatory" are understood to be taken with a grain of salt, but "July 15 issue" isn't—in fact, this one carries considerable implications for the editorial integrity of the whole operation. If a senior editor adds this tag, that's fine, but what if the contributing author sets it? We must return to the issue of top-down control, which software has always been so good at.

I am not sure this issue is as big a problem as it might seem at first glance, and I suspect that could be handled fairly easily. One approach would simply add the contributor and datestamp information to the tag, thus lending it the kind of authority it needs: "Approved" as added by the managing editor would be a piece of information that leverages further workflow, but any other combination wouldn't. Or perhaps the system needs two sets of tags: one for privileged users and one for everyone else. The latter is less elegant, to be sure, but I think that the important thing to point out is that this problem and others like it can probably be addressed by adding only one extra layer of information; that is to say this does not lead to infinte regress. In the scheme I am proposing, adding more layers of complexity needs to be avoided wherever possible, but it would appear that adding a little bit of complexity in particular, critical contexts is outweighed by the overall aesthetic of freedom in the overall system.

Handling the Content Itself

A lingering issue with wikis is that widespread use of "wiki markup," a system of embedding (hopefully) innocuous formatting cues in plaintext to make the wiki display formatted text. This strategy is an artifact of wiki history: either you worked in plaintext or in raw HTML. Wiki markup was a compromise that would work in-browser and automatically produce formatted HTML in the browser. There is, today, no need to go this route, as it actually adds an extra layer of complexity.

Through-the-web rich text editors, like FCKEditor? and TinyMCE, provide a much better solution: they allow a semi-WYSIWYG interface that produces XHTML in the wiki. This has two major benefits. The first, and most obvious, is that users work in a familiar word processor-like interface. Second, and more importantly, the textual content of the wiki becomes a structured collection of valid XHTML. Having clean XHTML throughout means that, with some simple aggregation, multiple content objects can be pulled together to create larger XML-based content structures. The XHTML itself is enough for web publication of the content, but being able to pull together larger XML collections makes it possible, for instance, to semi-automatically pull content out for print production in a tool like Adobe InDesign.

I have personally worked with this process on two fronts. In 2005/06 I wrote a PhD dissertation entirely within a wiki environment. The wiki produced XHTML output, so I was able to write some functions to pull the entire content of the wiki together and serialize it all out as XML, which I was able then to bring in to Adobe FrameMaker for typesetting. This particular experiment was a one-off, and so the real ongoing advantages of such a system were not realized. I was, however, able to bring roughly 300 pages of wiki content directly into a desktop-publishing environment ready for printing. The second experiment had to do with structured content in an XML-based database export format. The XML was transformed into a publication-oriented DTD, then imported into Adobe InDesign CS2 with a set of templates designed for the purpose. Wile InDesign had limitations due to its partial XML support, this was successful as a proof-of-concept, and every indication is that subsequent versions of InDesign (and its competitors) will have more robust XML support.

To bring this scenario together, then, an aggregating function in the wiki could pull together all material tagged as approved for a given issue, assemble it all as XML (with XHTML at the detail level, and a custom publication DTD at the superstructural level), and imported wholesale into a print layout tool.

A further consideration is the possibility that, given a rich text editing environment through the web, a publication community could conceivably reduce or even entirely lose its dependence on proprietary authoring software like MS Word.

Driving Interface Design from Tags

Another potential application of tagged content is to drive the look and functionality of the web interface itself. This is trivially accomplished by conditionally tying the content tags to CSS stylesheets and navigational page elements. For example, content tagged as "feature" content might pull a particular CSS stylesheet, while content tagged as "columnists" might pull a differen CSS. The look and feel of the content can thus be dependent on its tagging; and these associations are simple enough to remain in the realm of editorial control (beyond designing the CSS itself, perhaps, though this is a task normally left to specialist designers anyway). Similarly, for various reasons, navigational and other functional interface components (navigational templates, user-comment forms) could be conditionally tied to categorizations, again in a simple enough manner to be part of the editor's purview, and not relying on database architecture or web-designer interventions. The effect of this is, on the surface, no different from the templating systems that all CMS feature, but one which is far simple and more malleable, again, moving the administrative functions from the technical to the editorial realm.