Figuring that MediaWiki was probably overkill for this project, I struck out in search of something that would be easier to install and configure for me, and easier for non-technical users to maintain. What I found was DokuWiki, a somewhat minimalistic wiki platform that explicitly aims to fulfill the documentation needs of “developer teams, workgroups, and small companies.” Perfect!

As I soon discovered, one of DokuWiki’s distinguishing features is that it does not make use of a database for storage, as so many other wikis and content management systems do. This makes installation incredibly simple right off the bat: Just drop the files in a directory on your web server and go. All of your pages are stored as plain text files (e.g. another_wiki_page.txt)  in a directory hierarchy that matches the hierarchy of “namespaces” you create on the wiki. In this way, your content remains organized and perfectly readable even when you take the wiki software out of the equation.

For the most part, DokuWiki’s syntax is pleasant and sensical. Instead of MediaWiki’s odd multiple-single-quotes scheme, you have //slashes// for emphasis and **asterisks** for strong emphasis, which feels more intuitive. Instead of MediaWiki’s bizarre syntax differences between internal and external links, DokuWiki treats them all the same: [[link_target|Link Text]]. But then again, there are some strange and arbitrary syntax decisions on DokuWiki’s side, like the fact that the largest headings are surrounded by ======Six Equals Signs======, and the number of equals signs goes down by one for each sub-heading level. Weird, though I suppose it’s in the name of plain-text readability.

Uploading images and other files to DokuWiki is a breeze, thanks to a pop-up media manager that includes a multi-file Flash uploader and can insert wiki-links to your files with a click. Nifty media icons abound in DokuWiki’s output, with PDF files, Word documents, and more each getting their own instantly-recognizable icons. External links and email addresses also get unique icons, making them stand out nicely on the page. The “pretty by default” approach extends to text, which gets automatic curly quotes and various other typographic entities in much the same way that WordPress output does.

Given that I’m using DokuWiki for documentation on a company intranet, I would be remiss if I didn’t mention what an absolute cakewalk it is to integrate your own authentication scheme into it. If you already have a table of users in a database somewhere, as I did, you can set up DokuWiki to authenticate against it in the time it takes you to write a couple of SQL queries. There are other built-in authentication modules you can use, and if none of them meet your needs, writing your own is surprisingly easy (and well-documented) if you have a decent knowledge of PHP. There is also a fairly comprehensive ACL system that becomes much more useful if you set up your authentication scheme to provide “groups” to DokuWiki, or if you’re using the built-in mechanism.

One downside I’ve encountered in terms of usability is DokuWiki’s strict adherence to a particular naming convention for both page names and media file names: Only lowercase letters, periods, dashes, and underscores are permitted. The aesthetics of this decision leave something to be desired, especially since the name of the page you’re on is (at least in the default theme) displayed at the top in very large text, and probably:looks:ugly_as_sin. I’m not sure why capital letters and spaces are disallowed, since they are both quite safe to put in a filename. You can set an option to superficially replace the ugly page names with the contents of the first heading on the page in question, but this just makes the page’s “real name” harder to discover when you have to link to it, and the visual duplication of the page title and the first heading is far from nice-looking.

Thankfully, DokuWiki presents itself very well in all other aspects, and the overall package has so many good things going for it that I can’t help but give it my recommendation. If you want a lightweight, documentation-oriented wiki that feels almost as slick as WordPress but gives off a more techy vibe, DokuWiki can definitely take you there.

Now, to be fair, Drupal and WordPress are in two completely different categories, at least to start out with. WordPress is advertised and works best as a blogging system, and you have to do some hacking to expand its functionality beyond that. Drupal is a sort of uber-extensible CMS framework that does almost nothing useful out of the box, and you have to do some hacking to transform it into a blogging system or an online store or whatever else you want.

Nevertheless, in the few weeks I’ve been using WordPress, I’ve noticed a few things that really impressed me, and made me wish I had the same features in Drupal. This is not to detract from Drupal’s sheer power as a do-anything CMS, but I have often found it lacking in usability (and apparently I’m not alone). At any rate, here are some of those nifty features:

• Fully-integrated WYSIWYG editing out of the box. This is really something that’s important to get right if your content is being edited by “regular people”, and it’s also an area where Drupal falls flat on its face. By default, Drupal just gives you a plaintext input box and expects you to start typing HTML into it. You can download modules that plug in various generic WYSIWYG editors, but installation is awkward and integration is lacking.
• Integrated one-click plugin installation and updating. To install a WordPress plugin, all you have to do is find it with the integrated plugin browser, and click the Install button. The plugin is automagically transferred to your server and unpacked, and it’s just one more click to activate it. Upgrading a plugin to a new version is similarly a one-click process. With Drupal, it’s all manual: Download the module tarball from the Drupal web site, unpack it, FTP into your server, transfer the files over, and activate the module. And you have to do this every time a new version of the module comes out. Gets kind of irritating when you have more than a dozen modules installed, which is probably the minimum number you need to do anything useful in the first place. Sadly, this rigamarole is necessary for WordPress themes as well, but that’s apparently being worked on, and you only really install themes once.
• Built-in editors for everything. Want to tweak your theme’s stylesheet? Don’t waste time SSHing into your server, just hit the Editor link and you’re already there. Anything you could want to change on the server is available through the web interface. Admittedly, fewer things in Drupal actually require you to edit files on the server, but I’m surprised they haven’t done something like this already, since the coding effort required is small.
• Decent image handling out of the box. I say “decent” because the way WordPress does it is far from perfect, but at least you can upload media files to a designated directory on the server, and insert them inline into your content with only minor fiddling, all without installing any plugins. Drupal doesn’t provide anything like this unless you install half a dozen modules, none of which are quite able to cooperate perfectly, and all of which are guaranteed to require several hours of tedious and/or non-intuitive configuration. Which brings me to my final point about WordPress…
• Most things are obvious, intuitive, and painless. It’s hard to explain this one since it’s more of a feeling than anything else, but it pervades the entire WordPress core. When I want to do something with this web site, I log in and “just do it”. The entire interface is so slick and easy-to-use that I never stop for a moment and wonder why I’m doing something the way I’m doing it. It all just makes sense. And it’s all buttery-smooth thanks to the pervasive AJAX effects and excellent use of color and typography on the backend (in fact, I find myself wishing I had a front-end theme that captured the feel of the admin interface!). Of course, part of this comes from the fact that WordPress is laser-focused on providing a great blogging platform, thereby achieving a level of coherence and integrated features that Drupal, which tries to be all things to all people, could never match. Still, it makes Drupal look positively clunky by comparison. To this day, whenever I log into the CSH web site with a task to do, I experience a brief moment of confusion as I wonder whether the module I’m looking for decided to vomit its settings page into ”Content management”, “Site building”, or “Site configuration” (or maybe it’s a secondary tab in a sub-page of one of those categories…).

Well, that’s enough of me ragging on Drupal. As I said before, it’s really an amazingly powerful framework, and for things much more complex than a personal blog, it’s still my CMS of choice. I just think that, in terms of usability, it could do worse than to take a few cues from WordPress. (Incidentally, I’ve discovered a number of WordPress annoyances as well in the past few weeks, but those will have to wait for another day.)