Scott Blomquist

Selection paralysis

I got to thinking lately about how I wish I had a wiki on my personal web site, because I want to do some quick’n’dirty semi-structured and richly linked writing to share with others so I can get feedback and input. I spent some time catching up on what wiki systems are best at what, and discovered I was completely daunted by how many different choices there were.

I eventually whittled the list of candidates down to just short of 10 different packages, and then got stuck again. What happens if I pick one today and invest considerable time in it only to discover that a different one fits better with what I’m using it for? Is there any way to migrate the data to a different wiki package at or near full-fidelity?

Sadly, there is no good general way to do data interchange between different wiki packages today. This is bad for users like me who get stuck at the step before actually installing a wiki, and it hinders the ability of every wiki package out there to try out new and different ways to display, edit, tag, or transform their content today.

Wikis are complex organisms

Every functioning wiki is an organism consists of 3 parts: Content, Community, and Client Experience. The first and most obvious part is the Content—for example, Wikipedia wouldn’t be an encyclopedia without the articles. The second part of a wiki is the Community—the people who volunteer their time and effort to make sure the wiki improves over time and resists vandalism. An enormous amount of time gets spent on the most respected wikis discussing and tweaking both the Content and the Community.

The third and final component is the Client Experience. Most successful wikis have a difficult time trying out changes, especially particularly radical and innovative ones, while at the same time maintaining continuity of Content and especially Community. A large fraction of Wiki Clones have arisen as forks of communities or at least software packages due to someone wanting to try out a pet interface improvement. This has contributed to the vast number of Wiki Clones out there today, and without data interchange, there is little hope of reconvergence as practices around Wikis mature.

Standardize what exactly?

There are the perennial discussions about standardizing Wiki markup, but I don’t believe that to be a worthwhile effort. It’s sort of like expecting everyone to use the same programming language or text editor. There are benefits and drawbacks to each, and I don’t expect that we’ll converge on one true favorite any time soon (or even that we should).

I believe the best place to begin a standardization effort would be between the storage layer and the UI. If each wiki engine was able to produce a standardized intermediate format for all of its content and metadata, then three key scenarios would be enabled almost with very little additional effort: 1) wiki owners could worry less about wiki lock-in because they could always use the interchange layer to export/import their data into a different package, 2) client-side editors for wiki content could be developed and work across many wiki packages, and 3) interesting federation and synchronization scenarios become possible.

My proposal

I haven’t started work on a specific protocol proposal, but I’ve spent some time looking around to make sure I wouldn’t be contradicting a previously invented wheel. What I’ve found are mostly undeveloped thoughts tossed onto various wiki pages that discuss possible work around standardization. I haven’t yet found any well-developed specifications or any broadly published prototypes. I’m guessing that I’m missing something, and if I am, then please point me at it. I’m definitely not interested in redundantly solving a well-solved problem.

As I reflect back over ever wiki page I’ve written in my entire life, I have primarily used headers, bold, italics, links, bullet lists, numbered lists, images, and, rarely, tables. I can’t help but notice that these are the markup primitives that nearly every blog editor includes. Further, I know that blog editors usually think of the content in terms of XHTML. This makes me think that a very neat prototype would be to modify a wiki such that any old blog editor could open up an article, having mistaken it for a blog post, and then publish back an updated version of the article without requiring any changes to the blog editor!

If a wiki were to change its intermediate representation to a well-documented subset of XHTML, then each wiki would be on the hook to write a transformation in both directions between its specific markup and XHTML (which already exists today for display purposes), and back (which probably doesn’t yet exist, but seems that it wouldn’t be terribly difficult).

One thing that we don’t have today is a way to convey the history information about an article, but a good place to start for that would seem to be FeedSync over Atom.

Obviously, I’m being vague about a lot of the details here. That’s partly because I want feedback on my starting direction before I go too far down this path. It’s also partly because I don’t want this post to get too technical. I’ll follow up later with a more detailed technical description of what I’m thinking.