Using Wikis for content management…

So here’s a thought partly inspired by an e-mail from a work colleague and partly by Haughey.com. Creating and editing wiki pages is extremely simple and elegant once you get past the first 30 minute learning curve. And essentially you end up with a page that’s got an incredibly simple template, pretty well marked-up code (or at least could do if you used the right Wiki system) and can be edited incredibly quickly. Now, imagine for a moment that the Wiki page itself is nothing but a content management interface and that the Wiki has a separate templating and publishing engine that grabs what you’ve written on the page, turns it into a nicely designed fully-functioning (uneditable) web-page and publishes it to the world. It could make the creation of small information rich sites enormously quick – particularly if you built in FTP stuff.

Now one of the problems with using Wikis generally is that they don’t lend themselves to the creation of clear sectionalised navigation. Nor do they do naturally find it easy to use graphic design, colour or layout differently on separate pages to communicate either your context or the your location in the site. That’s not to say that Wikis are broken, of course, just that the particularly networked rather than hierarchical model of navigation that they lend themselves towards isn’t suitable for all kinds of public-facing sites (the same could be said of the one-size-fits-all design of the pages). This would clearly be a problem. Wikis sacrifice that kind of functionality on the whole in order to gain advantages in other areas (ie. collaborative site generation and maintainance). Without those advantages, you’d simply be left with an inferior product.

So how to integrate design and architecture into the production of a wiki-CMSed website? Well, it’s not a particularly new question with regard to wikis generally – loads of suggestions about how some kinds of hierarchy could be built in have been made and some of them implemented. On the whole they’ve not been terribly successful as they present a higher level of user-level complexity, and with a lot of potential naive users, publically editable wikis can’t really afford complexity. But that’s not true if only one person or a small group were to be updating the site. The complexity level could increase a bit and the learing curve would have to be just a little steeper initially.

Here’s an example of how you could create hierarchy and utilise different templates at the level of the individual page. First, imagine a templating interface that allowed you to create an outline hierarchy of the various sections of a site (just like you’d produce in the outline view of Word or using something like OmniOutliner). Now, each section of that site-map could have a distinct template attached to it, or inherit a template from the section above. Then all you’d need on the Wiki-page (as content-management interface) would be a drop-down box on the right that allowed you to choose which section the page you’d created would sit under. Given that, you could use the mechanics behind the templating engine automatically generate a variety of different models of hierarchical navigation and breadcrumb trails which you could embed into your templates (you could use a templating mechanism very much like the one used to move content chunks around weblogs using Typepad). And the same part of the Wiki page that you use to decide which section the wiki page should be contained within could also house a .gif thumbnail of the template for that page. And the assigned section of a new page could even default to that of the page from which you created it – forward-link from a page about Troubleshooting (in the section “Help”) to create a page about Error Messages, and Error Messages is automatically created inside the “Help” section initially. And all of this could then be ‘published’, pushing everything out in a lovely stylish elegant and visually rich format to the rest of the world at the push of a button.

Wouldn’t that be cool? Blogger-style management for all kinds of other sites… The only things that don’t seem obvious to me at the moment is how you make the intra-wiki links not look like Wiki links to the general public while preserving the ease of use that they engender for the person creating the pages… Any thoughts?