Categories
Design Personal Publishing Technology

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?

22 replies on “Using Wikis for content management…”

If you use Opera or Mozilla you can use a user stylesheet to display something that the webpage’s stylesheet hides. eg:
On each page:

blah blah blah

In the Style sheet:
p.intrawikilinks
{display:none;}
In your user style sheet:
p.intrawikilinks
{display:inline (or whatever)}
The visitor sees nothing out of the ordinary but you get the extra links. Not all that secure though as a quick view of the page source will show the hidden links.

that blah blah blah should be:
(html paragraph tag id=”intrawikilinks”) Blah blah blah (end html paragraph tag)

There’s a good example of a hierarchical wiki at faq.ozoneasylum.com. Obviously hiding the intra-wiki links isn’t what’s needed there. Something like the solution above, or an admin page separate from the public part of the site.

LOTD is U
I am maintaining my day behind schedule. Maybe one day I will get in sync with Kate. Here we go. U is for unbelievable. — This site is full of unbelievable things. U is for unpunctual. This is a bit disappointing. U is for underworld’s use. U is for u…

What’s the benefit you’re focused on? If it’s the avoidance of markup there are non-wiki approaches like Textile.
While the auto-linking is cool, for a “published” site you want enough flexibility over link labels and linking that you’ll probably end up escaping the wiki’s auto-linking features anyway…
And I’m sure there must be some 3-line Perl hack out there to let an admin edit a page via a browser…
I wonder whether “published” (“polished”?) sites will become less relevant over time to many contexts…
http://webseitz.fluxent.com/wiki/z2004-01-09-CoatesWikiCms

A good way to avoid the CamelCaseLinks issue without requiring the editors jump through hoops writing links like
[link to foo site:LinkToFooSite]
would be to post-process the HTML output using a dictionary of substitutions:
s/(]+>)LinkToFooSite()/$1link to foo site$2/gs
Make the list of from -> to pairs editable through the web, with the “from” list automatically updated from the current wiki pages, and it’s a bit nicer.

This seems like an awfully long way round – ripping out and replacing half of the Wiki functionality to be able to get the simple markup capability within a more normal site structure.
What you’d be better off doing is using a CMS that provides Structured
Text or similar. The Zope App Server has STX as standard, and Plone is a rather nice CMS built on top of it. Editable documents can be edited in any one of HTML, STX or Plain Text.

Tom Coates on Wikis as Content Management Tools
Tom Coates is thinking about the relationship between wikis, CMSs (shudder) and planned navigation:Here’s an example of how you could create heirarchy and utilise different templates at the level of the individual page. First, imagine a templatin…

Echoing Bill Seitz’s and Martin Burns’ comments, I really can’t understand what the point of this is. We have built several simple CMS apps that do exactly what you describe, with WYSIWYG front ends and a choice of templates drawn from an initial hierarchical outline. There must be hundreds of implementations of this idea floating around that allow logged in users to build pages as you describe. Remove the logged in requirement and lo – you have the openness of a Wiki, but without the need for people to engage with or learn the rather counter-intuitive ways of the Wiki.
Why Wiki? Isn’t that putting the cart before the horse, so to speak, in terms of user requirements?

I have to agree with the latter comments, Tom. Isn’t the benefit of a Wiki that the content and structure of the content emerge gradually from from the input of the various wiki users, a very purist bottom-up approach to information architecture? Taking a top-down approach already implies a categorisation attempt that is outside of the sphere of influence of the wiki contributors, which kind of counteracts the point of a wiki.

“using wikis for content management”
Via Many-to-Many: “Using Wikis for content management….” Here, Tom Coates addresses what has been one of my reservations about wikis, the somewhat awkward resulting appearance and navigational elements: “the particularly networked rather than heirarc…

I’m talking about the Wiki as interface rather than Wiki as thing – suggesting no more than that the Wiki interface might be a good way of assembling a site for people who aren’t particularly technically literate (or for those people who’d like to be able to assemble a highly templated site very quickly). As evidence for the basic utility of a wiki structure for the maintainance of a non-weblog site (like a portfolio site for example) I site a.wholelottanothing.org and haughey where Matt Haughey has used a wiki as the foundation of his site, allowing him to edit and adapt it whenever he wants without it appearing to be a wiki to people on the outside.

You might want to check out diamond wiki for an example of how you can let wiki users create hierarchies of wiki pages. Diamond wiki lets each wiki page be in multiple hierarchies simultaneously, so it fits better with the free-for-all approach of wikis, instead of the top-down approach of a single taxonomy.

LOTD is U
I am maintaining my day behind schedule. Maybe one day I will get in sync with Kate. Here we go. U is for unbelievable. — This site is full of unbelievable things. U is for unpunctual. This is a bit…

JotSpot – The Application Wiki, does exactly what you describe (although it does it better). You can create generic data manipulation templates – available via a drop-down menu on the right – and go on to use them to structure data in an heirarchical manner (if you so choose).
Here is a link to Jon Udell’s JotSpot screencast.

Comments are closed.