A Tale of Three Wikis

If designing is a process of addressing situational imbalances (and I believe it is), then the problem I am writing about here is certainly a design matter.

I love wikis. I think they're one of the great inventions of the Web Age and far more flexible and usable than alternatives like content management systems. Right now I'm struggling to choose a wiki to use in my work. Because I know many others have struggled like me in this matter, I offer my experience for you here as a case study of one person's thoughts.

The Setup

The only way to design something useful is to really understand the problem - or, as I prefer to think of it, really understand the nature of the imbalance. Unfortunately, understanding the imbalance only happens when you've actually addressed it. So designing often proceeds by trial and error, at least on paper, as alternatives are attempted, found lacking, and revised or discarded.

That's a long way of saying I haven't yet found my ideal solution, but I'm working on it.

There are some constraints on my situation that mean whatever solution I come up with is unlikely to satisfy everyone else. As an academic, I need a system that's easy to control, easy to use, runs on relatively weak platforms, and is essentially free of cost. Because I love my Macs, whatever software I choose must be Apple-friendly. And while I am a programming geek, my day job precludes my spending much time messing with code, so administration has to be light. Also, I live in a research environment; this means that while my user community is generally of above-average intelligence, computer literacy is not necessarily a given, and my users are often singularly focused on their own research and have little curiosity to learn new tools. This is one of the reasons that email remains, mistakenly in my opinion, a mainstay of research life.

There are some excellent free wiki services, like the very robust wikispaces, but I'm uncomfortable having research notes and some possibly sensitive information off my employer's secure intranet. I also look at wikis as subjects of research, so having some control over the code itself important. This puts these wiki services out of the running.

There's a great website, wikimatrix.org, that let's users compare existent wiki software; over a hundred of wiki engines are listed there. I've spent quite some time scouring through wikimatrix, but I always come back to three specific implementations: foswiki, mediawiki, and my own wiki engine, called xiki.

Solution 1: Foswiki

I've already written about foswiki. It's a fork of a well-established wiki engine called TWiki and, in my opinion, much better than its progenitor. It's written in perl, a programming language I know quite well, easy to administer, and very flexible. It is not suitable for use by my undergraduate students because some of its syntax is hard to understand. And because I have so many undergraduates in my classes (regularly over 150 in each semester), the required hand-holding would just take away too much time from the subject matter.

Foswiki is suitable for my graduate students, who generally have more experience, interest, and skill at developing good content and working with software they are typically unaccustomed to using.

Foswiki's flexibility also makes it a good vehicle for research activities because new code can be added relatively easily.

Not that I'd have to add that much; foswiki has a rather impressive set (over 200) of extensions.

For instance, one can create tables that implement spreadsheets; the neat part is that one can edit the spreadsheet tables without having to actually edit the whole page. I've used this facility quite successfully in my research. One person, who has a reasonable understanding of the plugin, creates empty spreadsheet tables for the research team. Adding data to the spreadsheet - including adding new rows - is easily done thereafter by any user using a purely visual interface. You can even have multiple spreadsheet tables on one page, all editable simultaneously by different users. Now, that's useful - for researchers anyways.

There are other extensions to implement checklists, workflows, blogs, and RSS news feed aggregators. Of course, being a jack of all trades, foswiki isn't stellar at any one thing - yet. But as an overall solution, it's tough to beat.

Solution 2: Mediawiki

Mediawiki is another contender. It's extremely robust and efficient, being a classic LAMP application (which can run faster than pure perl applications like foswiki). It has been fine-tuned for application to developing bodies of knowledge like Wikipedia, which means it's well suited for use in research and courseware development. It's notion of namespaces is also very interesting (e.g. I can see a namespace for each of my courses, which would allow me to tweak base courseware documents with extra bits specialized to each course). There is a plugin backplate for adding my own extensions too.

But PHP is not something I like; it seems too confusing to me to combine content and code in one source as PHP does. Maybe it's just me, but that sort of thing just rubs me the wrong way. And having to maintain the LAMP substrate for mediawiki is something that requires a non-trivial amount of time on my current server platform. Of course, if you're paying your service provider for mediawiki services, then this isn't a problem at all, but research doesn't depend on those services much; we tend to do it all ourselves.

There's also a rather confusing number of plugins for mediawiki. It seems to me that there are too many variations. Which one is most robust? Which one is more functional? Which one does what I need?

Mediawiki also lacks any attempt at real WYSIWYG editing. Its developers have very good reasons for this, which they have made public, but that doesn't help me that much, especially in light of services like Google Sites. (Whatever else you can say about Google Sites, it does have brilliant editing features.) All the evidence I have indicates that WYSIWYG (imperfect though it is for wikis) is essential for new users, even though seasoned users tend to prefer the "raw" wiki markup editors. So any new users to my installation will have a steeper learning curve with mediawiki than with, say, foswiki.

Solution 3: Xiki

The third contender is my own wiki engine: xiki. I started writing it several years ago because of my dissatisfaction with the alternatives at the time. I was even able to secure a tiny amount of research funding for it. My premise was, and still is, that there's a market for a wiki engine tuned for collaborating researchers, and that the existent wikis just aren't good enough for that.

Xiki is small and fast, largely because I do not want it to have a massive plugin system. To support that kind of run-time flexibility requires much more computation than just "hardwiring" in the functionality that you need. You can see the same effect in other software, like web browsers. Safari, for instance, is blindingly fast compared to Firefox. The reason for this is that Firefox is more of a programming platform than just a browser. Its formidable collection of addons extends it's capacities far beyond those of Safari. But the cost is a truckload of extra computation at run-time needed to manage all those addons securely. And that slows it down.

Speed is very important to users. My graduate students have experimented with other wikis, but they are happy with xiki despite its shortcomings exactly because it is so fast. (Of course, I could fix this by getting a more powerful server, but why should I spend money to "fix" free software?  That just doesn't make sense to me.)

Another thing xiki doesn't do is WYSIWYG editing even though I think it's very important. I just can't spare the time to write the necessary code to make it happen.

Instead of supporting WYSIWYG, I have carefully designed xiki's markup for two purposes.

First, I try to make the raw content as legible as possible. This means carefully limiting the syntax to things that don't look like "code." An example of this is that I parse special combinations of plain English words rather than use distinctive (and weird) syntax. Another example is that I designed the syntax for lists to line up nicely even in the raw content, and that blank lines between list items are acceptable. These kinds of small features improve the legibility of the raw content while editing so that users will be more comfortable when editing.

Second, I try to simplify the syntax of the most obvious and common constructs, even if that makes parsing harder. For instance, some wiki engines use two and three single quotes to denote italics and bold fonts. This means you need ten single quotes, '''''like this''''' to make bold italicized text. To me, this is just silly. In xiki, bold is done *like this*, italics is done /like this/, and bold italics is done */like this/* because it just makes sense. This notation does introduce some interesting special cases - like a URL that ends in / within italicized text. That one took me a couple of hours to sort out, but I did.

The point is that xiki is tuned to work for my user community, and there's a lot more I want to do with it.

There are two big problems with xiki. First, searching my site appears very slow because xiki's parser does all the HTML generation first, and then ships it out to your browser in a single burst of output. My original idea was that searching a wiki shouldn't be very important because a well constructed wiki page will have embedded links to every other relevant page. The problem is that not all of my pages are well constructed.

Second, and much more importantly, xiki has exactly one developer - me. And my time is so scarce that I can't imagine how I'll ever continue to develop it. (Yes, I've tried to find programmers interested in helping me develop it as an open source project, but I've had no luck there either.)

Painted Into a Corner

I'd like to keep developing xiki, mostly because my graduate students (my primary users) see it's usefulness and potential. But none of them are programmers; and even if they were, working on xiki is neither what they signed up for, nor typical research in engineering design.

Circumstances are pushing me away from xiki, even though the geek in me would love to keep developing it. And I hate the notion of trying to convert all my content (over 3,000 pages) to another wiki format. The problem is that I can't see how I can win because the other contenders have weaknesses that annoy me so much.

So what's the answer? I don't know yet. At the moment, I'm experimenting with foswiki, to see how close I can come to something suitable for my purposes. But every day I spend on foswiki is one less day I can spend on xiki, which is really only making matters worse.

What do you think? Which wiki should I use? Feel free to submit a comment and tell me. Who knows? You may just have the answer that I can't find.