How We Got Here: Seven Requirements for Five CMSes

If you hit a tree on the web, anywhere from ten to twenty Context Management Systems (CMSes) will fall out of it. Obtaining a few good candidates for remaking the TCP web site then meant weeding out a lot of options. Facing that many candidates puts a lot of pressure on your selection process. It needs to be fair, yet thorough. You don't want to be evaluating for a week and yet you want a small number of quality candidates at the end. Here were my seven requirements:

• Platform independent
• Actively maintained
• Sizable community
• Mature
• Humane learning curve
• Extensible
• Variety of themes

Let's see how they worked out.

#1: Platform Independent

Was the CMS platform independent? In the heart of a web designer, portability is right up there next to standards compliance and the dartboard with IE 6 at the center. Dealing with various web technologies and browser quirks is complicated and stressful enough without painting yourself into a corner as well. to No-one can predict what will happen to any major OS or the company that develops it. Your data is your lifeblood, and you can't afford to let an OS keep your site hostage.

#2: Actively Maintained

Was the CMS updated in the last year? That's as good a test for a heartbeat as any. Abandoned projects are usually abandoned for a good reason; they are in some ways, like a haunted house, with oddities and unfinished business. There might even be a few ghosts on the premises. Abandoned projects also require a lot more involvement due to the lack of community. In addition to being the webmaster on your project, you take on the role of developer and QA for the CMS. Again, this is usually not a good idea due to the finite amount of time in your schedule.

#3 and #4: Sizable Community and Mature

Did the system have a user community large enough to answer questions reasonably quickly? Projects without a significant user community could be cutting-edge or toys, but in both cases, the few people that understand the system become the bottleneck -- if they are even available. Was the system mature? A product that has been around a while has had its rough edges sanded down a bit, which means less hassle using it for your site. Otherwise, you're dealing with growing pains and missing functionality.

#5: Humane Learning Curve

Did the CMS have a humane learning curve? Time is a luxury, and finding a CMS with a low learning curve makes the best use of it. Trying to learn a new system under deadline pressure never turns out well. Yes, there's plenty of time to learn new things and expand your mind in a street-legal way, but developing a new site with deadlines is not usually the best opportunity.

#6 and #7: Extensible and Variety of Themes

All CMSes should be extensible and provide a wide array of themes. Granted that any CMS will not give you the wide-open customization of doing things by hand, but any CMS that forces you do things a very precise, particular way, constrains your freedom. If you're ok with the restrictions a particular CMS imposes, then they're not really restrictions. The number of themes available not only speaks of the size of the community, but also the adaptability of the CMS. But aside from those reasons, spending time developing a theme because there's nothing even close to what you want might be a signal that you're using the wrong tool.

The Application

Applying those seven requirements yielded five CMSes: CMSMadeSimple, Drupal, Textpattern, WordPress, and XOOPS.

• CMSMadeSimple, ironically, proved impossible to install on the staging server.
• XOOPS also flamed out at the same point.
• Textpattern had a small community and a sparse selection of templates, in addition to a steep learning curve.
• WordPress was a last resort measure; WP is time-intensive and was not designed as a CMS.

That left Drupal, which surprisingly, worked out quite well. This I can say honestly, despite the problems setting it up on our server, one of which was an annoying stretch of time where competing mySQL processes were setting the drupal database password to different values. Such things are part of the webmastering experience; they give you bragging rights with geeks, and as a technical writer, they inspire you to write better documentation than the kind you survived during the experience.

~Mike