« More Gmail Invites | Main | M-Web chooses IS - just like that! »

Jeffrey Veen hits the nail on it's head regarding CMS

Jeffrey Veen is quite correct that Open source content management software sucks in a piece on his blog titled Making A Better Open Source CMS.

Open source content management software sucks. It sucks really badly. The only things worse is every commercial CMS I've used. But it really doesn't have to be that way.

Even closed source CMS's suck. You have people who have no User Interface experience coming along and telling you to change this do that and the user interface goes from bad to worse. Also the people who are designing the CMS aren't the people at the end of the day who have to use it.

Jeffrey says that various open source CMS have been written by geeks for geeks, which is true.

It was software written by geeks, for geeks. This whole category of software desperately needs to be redesigned with writers, editors, designers, and site owners in mind.

Here are my recommendations to the folks writing open source content management systems.

Make it easy to install. Your tool will see better adoption if you stop to consider the out-of-the-box experience before you ship it. I want to download, unpack, and run an installer in my browser. Ask me a few questions, and then you go set up the database tables and write the conf.php or whatever. Set constraints for yourself as you design this experience: 10 minutes from download to running, never send a user to the command line, never force open a text editor. It will be hard, but you're good at solving hard problems, and this is time very well spent.

I personally prefer an easy to edit config file for just the database details and maybe a couple of settings. Allowing users flexibility of what they can change is an art. Customisability without loosing functionality is key.

Make it easy to get started. Give first-time users a series of quick wins that become increasingly complex. When I first log in, I want to create a Web page. Next, I'd like to add some styles to it. Then, I'd like to make links to some other Web pages. I'll build a navigation system after that, and start to add other features eventually. But I want to feel successful with your system within a few minutes. I don't want to you to present the stunning power at my fingertips until I'm comfortable with my surroundings. Please save the content ranking, on-the-fly PDF creation, community forums, and user polls for later. I may eventually want that stuff, but not the first time I log in.

So do you give users the ability to go from a basic setup with help guidelines enabled to turning off the help/instructions at a later stage? Marketing people say things like our product is feature rich or carrier-grade without understanding the meaning of the words. I suppose that it is a selling point to use certain words in a way to market a product as being something it is not.

Write task-based documentation first. Most systems have installation instructions that are quite good: "First do this, then do this, this, and this." But when it comes to actually using the CMS, they revert to feature-based docs, carefully outlining what each feature does, and typically from a back-end perspective. Remember, I want to get started quickly, so give me the basics in sequential order for doing that. Do I have to create users first? Can I make a template right now?

I have to admit that I felt like a bit of an idiot working out steps for users to follow for a website administration area for one site I was developing on. Does little pop-up windows with help text in help at all? I've seen systems which do this and I prefer this method. Do we have to make it so depending on your ability to work around the system you enable / disable help / instruction steps / etc.?

Separate the administration of the CMS from the editing and managing of content. I am proficient enough with scripting languages and basic computer science concepts. I can write my own templates, and even dip into object oriented Perl and Python if I need to. So why do all open source content management systems baffle me? I know most systems have the notion of administrator and user, I don't want to keep having to switch accounts to make changes. I mean separate them in the interface. Remember: 98 percent of your audience will be using the CMS to manage their Web sites, not manage the system. Yet most systems are optimized for the other 2 percent.

Perhaps one shoul rely more on User Experience experts to be involved earlier on in the design process so that the issues like sites being optimised to manage the system actually is reversed to being optimised for useing the CMS portions.

Users of a public web site should never -- never -- be presented with a way to log into the CMS. Every organization I have ever worked with has kept the content management interface completely separate from their public-facing Web site, yet almost every open source CMS mixes them together. These systems provide a mechanism for anyone to create an account and login to the CMS directly from the site being managed. Yes, I know I can edit the template and take this out. But the only sites that really require this functionality seem to be open source projects; this is an indication that you're badly misinterpreting your audience.

Stop it with the jargon already. I don't know what a portlet is. Or a component, module, block, or snippet. The last system I evaluated had something called "mambots" which, to me, sounded like robotic assistance for breast feeding. Are you making up words to promote your differentiation in the market? Because it is confusing. Please just use simple words to describe the things your system does.

This tends to come in from the marketing people who decide to call for example a profile editor something like modify content. For one project were implemented VCards and ended up with the marketing people calling them the company name online business cards or something to that effect.

Why do you insist Web sites have "columns"? I've used quite a few systems now that have the notion of a 3-column layout. They give me the ability to turn columns off and on, and put "portlets" into "content-slots". Where does this assumption come from? For the last two years, I haven't built a single Web site with columns -- and these are high-traffic commercial sites. All the markup gets spit out linearly, and then styled in whatever column format we want using CSS. Yet so many content management systems bake the 3-column layout so deeply into the code that it takes considerable hacking to get rid of it (I'm looking at you, Plone.). It may be a couple of years before everyone can start using table-free layout, but why not set the precedent with your tools? Think how much easier your CMS will be if I could simply say, "I want these features presented in this order," and then apply a stylesheet that does all of the presentation.

A lot of people who are developing CMS's have never heard of Web Standards. I've worked with designers who point blankly are not interested in using web standards for anything, even when sites who have gone for a web standards complaint coding tell you that the pages which they serve are smaller and takes less bandwidth.

Remember various people suggest using a two or three column layout for design to try and focus on areas of layout.

I realize no CMS will work for every site. But I've lost track of how many times I've heard people tell me things like, "Yeah, we tried PHP-Nuke. But everything came out so Nuke-y looking." That suggests to me that most systems are designed with a particular genre of site in mind. Then, features and functionality are added on top of that basic framework. And the whole package is then shipped as a tangled mess of add-ons and faulty assumptions.

I designed a simple CMS using PHP, MySQL, Smarty Template Engine which is still an ongoing work in progress. The point is that backstage works for me by managing the content on my website, excluding blog entries.

Further Reading