April 2009
« Mar   May »

Oh CMS, Deliver Me

Half of the people can be part right all of the time,
Some of the people can be all right part of the time.
But all of the people can’t be right all of the time.
I think Abraham Lincoln said that.
“I’ll let you be in my dreams if I can be in yours,”
I said that.

Is the tail wagging the dog?

A recent posting caused a rather lively conversation. One question I didn’t get around to answering came from Adriaan Bloem, an analyst at CMS Watch:

But just ask yourself this: 1. Do you design the visitor UX, then use a CMS as a tool to build it? Or 2. Do you consider the process of building and maintaining the lifecycle of a site (the actual *managing of the content*) to be as important as the visitor-facing facia of it? If 1., and not 2., the CMS is going to be thrown out together with the site it produces like a pair of badly hurting shoes as soon as the opportunity arises. And it’ll have caused plenty of hurt by then.

Badly hurting shoes?!? Hey buddy, this is my baby you’re talking about. So, in order to answer this, I’m going to first talk a little about what I want from a content management system.

I want it to manage content, and give me a sensible way to get at that content. And I want this to be easy and logical. That’s all. Done. [UPDATE: My attempt to be sarcastic may have failed. I know it isn't that simple and there are a hundred Content Management Features that influence the decision. But those aren't what this post is about. See this comment]

But content management systems these days do more than this. I’m still an old-school fan of decoupled delivery, although most products now also provide delivery capability and a whole boatload of extras. And the infamous RFP matrices I see focus far too much on delivery side issues that are nothing to do with the CMS. So what do I want from the delivery framework? Not much either, really. In some vague order of importance, these are the biggies.

Every <Tag> is sacred

I want full control over the markup generated by the product. Our interface developers (the front end guys) take their HTML/CSS/JavaScript very seriously, and I want to be able to emit their code byte for byte. I’ll accept some things. A <FORM> tag around a .NET page is expected, with a hidden VIEWSTATE input. Adding extra styles to the front end when doing inline editing is okay too. But when viewing the site as a normal user, I don’t want any of those either. I certainly don’t want their JavaScript and CSS stomping all over my JavaScript and CSS.

The “Egg Analogy” presentation below is a Microsoft one, which I first saw when our friends from Redmond popped into our office to demo their Expressions product suite. The first 9 slides really touch a nerve for me. Don’t bother with the propaganda from slide 1o onwards. The slides mirror our development process pretty well, as does the end result if the delivery framework places constraints on the markup. We don’t like breaking the egg.

If it ain’t broke, don’t break it

So, we’ve got our perfect HTML. Let’s make sure the editors can’t break the egg either. This is more a Content Management than Content Delivery issue but, I beg you, don’t let the editorial team play with the HTML directly without ensuring the markup is valid. It isn’t that hard to do. Don’t publish something that isn’t valid, at the very least. Applying some accessibility guidelines doesn’t hurt either. I also need the editors to have full control over the URLs, including multiple “campaign URLs” for the same entry point. Don’t allow illegal characters in these URLs, please. Oh yeah. Tell your Rich Text Editor not to convert relative URLs into absolute ones that point to my staging environment.

Play properly with the interwebs

HTTP status codes exist for a reason. Please can your “Page Not Found” page actually also return a 404, not a 200. Please use 301 and 302 redirects in the right places. Please use proper caching headers when serving static files. And dynamic files too. Did you know that SharePoint serves an “Exires” header (without the ‘p’)? WTF! Form builders need a good excuse not to use XForms.

Developers should dig it

The product should feel natural to them. No proprietary languages. No stupid development tools. No complex installations. Less quirks than average. It needs a logical API and useful templated controls. It should feel like it is an extension of the dev tools they know and love. The in-memory caching and decaching should be invisible to them. And it should be fast.

I want my configuration in configuration files and template code on the file system so it plays with our release management and continuous integration software. I only want content in the content database, so I can back up and restore databases without screwing up code. I want language files in standard places.

I love the products that do less rather than more. Using .NET as an example, your API should do less with each .NET release. Chuck out propriety authentication methods for .NET Membership. Chuck out your clever workflow engine for Windows Workflow. Stand on the shoulders of giants, and let my developers do the things they know already. Focus on the core use cases of a Content Management System.

Don’t try to sell me snake oil

I don’t want a non-techie sales guy telling me things like “Oh yes, our product does SEO really well”, “It also works as a Portal” or “It does an iPhone version” without knowing what it means. I don’t want the system to bloat itself with tightly coupled modules that need to be uninstalled with a scalpel and a bottle of gin. You can keep your Module X that has clearly been hacked together on a client project, produces crap markup, isn’t cross browser, doesn’t have an accessible fallback, and clearly isn’t ready for production. I don’t really want sub-standard features that have been implemented simply to tick a box on an ill-thought-out RFP. On most of my projects, the CMS isn’t the only third party application in the solution. It needs to talk to the others too. I already have products for my Analytics and MVT, thank you very much. If you also do e-Commerce, SoCo or something else, I might consider those as a loosely coupled optional extra. And I really really really don’t want fancy drag-and-drop site building demoware that is completely useless and downright dangerous on a real project.

Snake Oil

Rant over. So, to answer Adriaan’s question at last

I believe that any delivery framework that meets the above requirements can be used to create any user experience. In fact, I like the idea that our UX, Creative and even Interface Developers can do their thing without knowing which CMS we’re going to use. So, I’m going to say we do both 1. and 2. at the same time. The front end is designed entirely with the users in mind, without caring about the CMS details. The CMS implementation is completely the opposite. It’s all about modelling the content and making the editors’ day job easier.

In a year or three, the customer may need a complete site refresh and the content and processes shouldn’t need to change unnecessarily. Or, alternatively, the Best CMS Product Ever might be released, and the customer might want to use it instead of the CMS we’ve implemented. They should be able to do this without losing the design, UX and HTML, which is a substantial investment. Or, to paraphrase Adriaan. I want to be able to throw out our CMS like a pair of badly fitting shoes, or throw out our website like a hat that is too tight. But I don’t need to throw them out together.

Finally, I reserve the right to violently disagree with any of the ill-thought-out things I’ve said in the above. Get out those hunting rifles – it is open season on Jon.

  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Digg
  • LinkedIn
  • StumbleUpon
  • Technorati

2,476 comments to Oh CMS, Deliver Me