And I Hate Every One Of You, Personally

by Phil Hollenback

This essay originally appeared in modified form in the SysAdvent Blog.

Hello, my name is Phil and I hate wikis. I hate them with a passion. I hate them individually. I hate them plurally. I hate every scrap of information that has ever been documented on a wiki. Most of all, I despise CamelCase.

Except, of course, the only thing I hate more than wikis is every single other documentation alternative. Thus I am trapped, as we all are, in the leaky boat of wiki-based documentation. Why do we tolerate living like this?

First, let me present my bona fides. I've been running my site on phpwiki since 2001 (here's the proof). That's a pretty respectable chunk of the web era, right? I'd like to think that I'm thus somewhat of an expert at wikis. In addition to my personal site, I've administered various company intranets running PmWiki, Twiki, etc. I work at a company that surely has one of the largest Twiki installations in the world. I've set up, run, or used a wiki at pretty much every professional career I've ever had. I know these things.

I remember my boundless optimism back in 2001. Wikis are the ultimate content management system! Why jump through the hoops of transferring files to the server with FTP when you can just create pages out of thin air, right in your web browser? Those were magical, mystical times.

But here it is almost 2011 and guess what? Every wiki works pretty much exactly the same as they did back in 2001 (or for that matter back in 1995 when WikiWiki was invented). Why has absolutely no real development happened in the world of wikis? I realize that there may be amazing commercial wikis out there like Microsoft Sharepoint or confluence, but I don't really know anyone who uses them. Instead we all blindly set up our own free wiki installations over and over again, with all the same annoyances and problems. We are all blind worshippers at the altar of the wiki.

Let's get specific: here are the concrete things I passionately hate about wikis, in no particular order of relevance:


This seemed amazing back in 2001, and rightly so. However the really cool thing was the autocreation of web pages, not CamelCasing. Camel Case was just an easy way to tell early wiki syntax parsers to create a link to a new page. Now in 2010 camel case is faintly embarrassing. It's like those pictures from the early 80s where guys all had perms - seemed a good idea at the time. Now every single time you try to explain wikis to someone, you have to apologize for how camel case works.

Markup Languages

Wiki markup languages must be amazing and precious, because we have dozens of them to choose from. Seriously? I have to remember whether to write






based on which wiki I'm using? That's awesome.


If you ask 99% of office workers how to create a table, the answer is fire up Excel. Wikis actually manage to make that worse, because it is so horrible to create wiki tables. The canonical table representation in wikis is vertical bars and spaces, and you better not accidentally add an additional column while you are at it.

    | *this* | *is an* | *awesome table* |
    | there | are | many like it | but this one | is mine |

Does anyone really think this fragile and difficult to read formatting convention is usable? I've written up thousands of wiki tables and I can assure you that it is not.

Attaching Images and Documents

Looking for a standard way to drop images into a document? Good luck with that. If you are lucky you can attach an image to a page, assuming you don't accidentally exceed the web server file upload size. Wait, did you also say you want to flow the text around your image? You just made milk come out of my nose. Next you will be asking for the ability to right-justify your image on the page!

Attaching documents to a wiki is just as bad, because most wiki software uses the same horrible upload mechanism. As a bonus, any excel spreadsheet you attach to a page becomes an inert lump of no-displayable, non-searchable data.

Organizational Structure

We all love really shallow document hierarchies, right? Must be the case because that's how every wiki works. Oh sure we all pretend there is a tree design in wikis but nobody ever uses it. We all end up creating zillions of top-level documents. Which then brings us to the issue of wiki search. Also essentially nonexistent. Most people cheat and use a domain-specific google search instead, but then you surrender your site to the whims of the almighty google. That means your search mechanism doesn't have any domain-specific optimizations.

What Now?

Let me be clear: I am a fan of the idea and the idealism of wikis. Giving ordinary users the ability to create webpages on demand is incredibly empowering. Giving ordinary users the ability to structure webpages as they see fit removes the unnecessary distinction between content creator and website designer.

However, what we have now is not enough. We have been given the taste of freedom and naturally we want more. The silly thing is that all of these issues could be fixed. For example, we could standardize on the generally usable markup language Markdown for all wikis. We could give up on CamelCase entirely (I understand Mediawiki has already moved in that direction). We could come up with better table and organizational structures.

The real question is why, over the 15+ year history of the Wiki, has this not happened? That question continues to baffle me - perhaps we as wiki users have become complacent with our 'not really good enough' wikis? No more, I say! It is time for us to throw off the shackles of mediocrity inherent in existing wikis. It is time to demand more from our tools!

An Update!

I just discovered WikiCreole, a project to unify and standardize all the variants of wiki markup. I've upgraded my phpwiki installation to v1.4.0, which supports most of the WikiCreole markup. So far I'm liking it a lot. Progress is being made!

Our Founder
ToolboxClick to hide/show