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.
- TALKIN’ WORLD WAR III BLUES
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.
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.
RSS Feed
Follow Me
Well… you didn’t really answer my question. But in a way, that answers my question
What you’ve written is totally valid in your scenarios. I wouldn’t want to go overboard and say it’s always valid (I work hard to analyze very different uses of a CMS), though these are certainly things we try to call out on our blog and in our reports. But, for example, take this blog, where I doubt you care very much about what WordPress forces on you, since it got you started quickly and was what you needed. Anyway, that’s a different discussion.
But what I meant is: one of the reasons CMS implementations start to hurt, is that the website design (and publishing the site to the web), and the technology behind it, are the main focus. If I look at your post, only one line considers the people having to produce and manage content: “It’s all about modelling the content and making the editors’ day job easier”. But that’s not what you wrote about, you wrote about how the CMS shouldn’t get in your way when you try to produce the front-end UX
Many of the systems we cover at CMS Watch wouldn’t get in your way (too much) if you want complete control over how the front-end site looks like. (They all have some quirks, and many will prevent you from publishing perfectly valid and accessible XHTML, but still, a lot of them will let you get pretty close).
So that means that, within the subset of systems that fit your requirements — as you’ve laid down here — there’s a lot of choice. Wouldn’t it be nice to base the choice on how content is actually managed by your clients, and which CMS is best suited to aid in that? If you don’t want to end up with a badly fitting CMS (no matter how shiny and polished it may be), that should be at least equally important (and, in many scenarios that rely on proactive managing of [lots of] content, the *most* important).
This is probably as long as I should go into the subject given that this is just a comment. But to circle it back to your previous post, which got all of this started, the problem here is not the “how not to break the egg” (though I like those slides you’ve posted here). In selecting the CMS, the problem is: which comes first, the chicken… or the egg?
I think my sarcastic one liner didn’t work and I’ve been misunderstood completely
I said:
“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.”
I could have written 50 pages here. There are an enormous number of content management related functions that are incredibly important. I singled out Ease of Use as it the important for the editors and adoption of the system, and logical as it is the most important for the developers. I didn’t want to get into the millions of Content Management features that are crucial in selecting the correct product. You know the list better than me as you guys write the reports: Content Modelling, Repository Services, Authoring Tools, Submission Methods, Taxomony, Tagging, Aggregation, Workflow, Globalisation, Integration, Ease of Use, Deployment, Search, Syndication, Retention, Extensibility, Virtualisation, Performance etc, etc, etc. And that’s without the non-functional stuff. Getting all this correct is half the project. It’s the Option 2 in your question. Of course we do all this, *despite* the fact that the RFPs are too delivery focused.
What I was trying to say is that the many items here are the factors which influence our choice of CMS. What the front end looks like has almost nothing to do with the CMS choice. From the front end point of view, all I want are the items I listed in this post. And most of the good products have all of them.
Which is why I was trying to say we do both. We pick the CMS based entirely on “actual managing of the content”. The visitor facing aspects have very little, if anything, to do with the choice. We often design the visitor facing site without even knowing (or caring) which CMS will sit in the background. The chicken and the egg come together. The chicken needs to do two things – satisfy the real content management lifecycle needs, and not break the egg when it sits on it.
Does this make any sense at all?
I didn’t miss the sarcasm, and all of it makes perfect sense
No debate there.
It’s just that a CMS is about “we, the people actually working with this stuff, want something that doesn’t get in our way but actually *helps* us do our jobs”. The webmasters, content managers, editors and authors of this world demand something that guides them through their process of managing content.
To do that for a blog is quite easy: you know what it needs to do, and how everybody does it, so you look at people working with it and arrange all buttons and menu options accordingly. As does WordPress, which is why so many people like WordPress “as a CMS”. (Unfortunately, take WordPress away from that rather straightforward scenario and it quickly becomes yet another ill-fitting solution).
To do the same for ten, a hundred, or thousands of editors becomes exponentially more problematic. How do these people go about their work? What do they expect? Where should content go to be approved, rejected, monitored, archived, and how? How do people expect to enter the content? How do they get effective feedback on the result? How would all of this be intuitive to them? This is different in every scenario and organization. As long as the CMS users haven’t standardized their ways, you can’t standardize the CMS.
Only then come the features of the CMS in play, and how you enable them, and more importantly, how you disable what gets into the way. That’s when somebody like you implements the CMS to fit like a glove. The “best” CMS is the one that’s the easiest to fit, either because it already was a pretty good match or because it’s easy to tailor.
How many users of a CMS do you know that are actually (really) happy using it? Not too many, if the scenario is anything more complicated than publishing a blog, or a couple dozens of pages, or more than a few people trying to work together.
The implementation and delivery bit are the easy parts. I know, they’re pretty hard to get right, but they’re still the easy bit. (It’s the only part I can even pretend to vaguely understand).
So I did get the sarcasm, and your points are still quite valid. I just think aligning content management to the CMS is neglected too much, so I won’t let you get away with dealing with it in one sentence
Adriaan,
Firstly, apologies for the way WordPress nests these comments. Hard to follow reply chains. Will have to look at that some time. I don’t count WordPress as a CMS yet.
I think we’re in violent agreement about all of this. The delivery side is easier, and is easier to change if you get it wrong. It doesn’t involve changing the day jobs of hundreds of people. Getting happy CMS end users is the challenge.
And, believe or not, I do know quite a few users that are actually (really) happy using their CMS. I’d love to claim this is because we implement the CMS for them in a perfect way but this is, at best, only partially true. The main reason for happiness is normally the fact that the CMS they were using before was an unbelievable pile of poo and their expectations are so low it is scary. In the land of the blind, the one-eyed man is king and all that.
I’d also like to pick on one a point made by James H. One thing that we’re guilty of is not actually using the CMS ourselves after we’ve implemented it. We’ll put in some test content, but the developers won’t hours doing repetitive tasks that the end users do every day. When we do spend time doing this, it’s amazing how quick wins are identified. The end users are often too scared to ask for changes because they don’t know if it is going to cost them fortune. I’ve seen one line of JavaScript which saved about 5 editors about 30 minutes a day. That’s about one-third of a full time employee. And the change was only made after we’d been in production for about 6 months and one of our techies had to do a day of content entry after a database restore didn’t work. After about 2 hours, he just implemented the change to save himself time!
Having spent the best part of 15 years using and training/cajoling people to use content management systems of varying shapes, colours and sizes, this post resonates with me more than any so far.
There was an interesting category in the CMS meme about CMS vendors ‘eating their own dog food’ and I think this could be extended to ‘how many hours have either the CMS developers and/or implementers spent using the system to actually manage content in the way the client organisation does?’
During the time I spent working for a vendor I grew to hate the phrase ‘ease-of-use’ because it is so ambiguous and entirely relative to the business need and publishing scenario it is being applied to. To apply a generic ‘ease-of-use’ description to a system that works a bit like Word (and of course everyone knows how to use Word) is largely irrelevant if the publishing task and business objective is nothing like what you would use Word for.
My current project is the biggest eye-opener so far as I am ‘cajoling’ many cultures, age-groups and business functions to use a globalised content management capability. Once again ‘ease-of-use’ is entirely relative to those three aspects – culture very much influences the publishing process as some cultures (both social and business) are more hierarchical than others – age makes a massive difference in the acceptance of the technology and willingness to use it – and business function determines how demanding users will be in terms of what they want out of the system.
To me this puts an emphasis on how flexible and adaptable the system is. Sometimes this does mean compromising on some of the finer technical details and design aesthetics in order to deliver the content that end users want and demand in as efficient ways as possible.
Nice post Jon, broadly I think I am with you – that the objective is to build something to engage your audience, that marketing and creative folks should lead this and the CMS shouldn’t be a creative constraint.
I do believe however in content author adoption being essential to the success of a web project, in that a great website needs great content – and that comes from lots of people in an organisation, not just the tech savvy folks on the core project that can easily take to new tools. So, I am with James there and I agree ‘ease of use’ is tricky to measure, until real people start to play with it and then they’ll soon let you know!
ÿþ|
A step-by-step information to relieving the symptoms of an alcoholic emergency therapy for
Alcoholic Poisoning.
Simply want to say our article is as astonishing.
The clearness onn your submit is just cool andd that i
could suppose you are knowledgeable on tuis subject. Fine together with your permission let mee
to seize your RSS feed to keep up to date with drawing close
post. Thanks a million and please carry on the enjoyable
work.
Also viswit my page – professional wedding Photographer London
That iss very fascinating, You’re a vsry professional blogger.
I have joined yolur rss feed and look forward tto in the hunt
for extra of your fantastic post. Also, I’ve shared your web site in my social networks
Visitt my web-site; hog roasts worcestershire
A net friendly user is sure to come across this incident many a times
a day when he or she inserts a query into search engine and click the enter button. The
reliability of the company will help you to have an extensive analysis
to your site. You had better be able to use your questions quickly and professionally fashion. Due to the advance in technology, there are many
websites of varied businesses available online.
What’s up to every single one, it’s genuinely a pleasant for me to pay a
quick visit this website, it includes helpful Information.
Fuck me, I held ATVI right up until the end of Wound up setting aside the money for a down payment + Not that it wasn’t a justified move, but seeing that 5y performance graph hurts a Congrats for you man!
Dude, I understand you have a strong opinion about this, but you literally just came into a thread about *suicide* and started shit-talking someone to ‘deal with Wrong place, wrong