Designing a Smarter Wiki


As mentioned during the presentation, we're going to have a Vancouver Wiki Wednesday. Go there and sign up for the March 7th meetup. Wikithon during the day, then meet to demo and discuss.

 

Discussion Links

 

 

 

Presentation: A project in planning stages.

 

Why wiki succeeds over more brittle software is that is makes no assumptions about what people will do with it. It is the "simplest thing that could possibly work," and the applications/domains to which it is put are wide open and free ranging. This is also what makes the Internet itself work so well.

 

But wiki is limited in that architecturally, it is a big bag of pages. If it has a full-text search engine, great, you can find stuff, but other than explicit linking, there isn't much to it. This is an advantage and a disadvantage, obviously. It makes the thing incredibly flexible and easy to maintain, but it perhaps makes it harder to tailor to particular workflows.

 

So, with this in mind, 2007's project is to create subclassable wiki pages. Perhaps not literally, but at least figuratively. To be a bit more specific: at the user (or at least administrator) level, any page in the wiki ought to be classifyable as one or more (user-)defined types. And then, based on what categorizations you have, you can drive things like automated navigation systems, blog-like interfaces, smart CSS, smarter RSS, etc.

 

We had a first take at this last year at http://thinkubator.ccsp.sfu.ca -- which is all wiki, but in which each page can be categorized to be 'under' a particular topic; topics then can display their child pages in reverse-chronological order, blog style. It works pretty well, look nice, and allows newcomers to get a better sense of what's in there (as opposed to the big-bag-of-pages approach of most wikis).

 

This year I want to make these page types or classes stronger, though. Consider: pages which are about a particular topic vs. pages which are about a particular user. Pages which are about something "new" or ephemerall vs. pages which are reference material. Pages which are about the wiki itself vs. pages about other things.

 

Seems to me it's simple enough to accomplish; in fact, you could do it all with nothing more than tags, so long as you're prepared to deal with the potential for misfiling, mistyping, and of course abuse. The big gain, though, is to allow things like navigational palettes and CSS stylesheets to be conditional on which page class it is. Then user pages would look and act different than help pages, which would look different than news pages or reference pages. And so on.

 

Anyway, this MOOSECAMP, I'm interested in discussing this plan in more detail as it takes shape. See also http://thinkubator.ccsp.sfu.ca/OOWiki

 

- JMax