cms, Enterprise CMS, Enterprise Content Management, Web CMS, Web Content Management

Things We Hate About Content Mgmt

things we hate about cm
 
By The Motley Crew (== Jon Marks, Adriaan Bloem, Irina Guseva, Ian Truscott, Justin Cormack, Andrew Liles, The Spirit of Philippe Parker)

It was a lovely Friday morning/afternoon, and we were Waving. The experiment initiated by McBoof (yes, that one) brought together 6 CMS folks from around the world. The event gathered together analysts, journalists, vendors, system integrators to Wave on a topic that was decided at that very moment. We had one hour (in between conference calls and other job thingys) to pick a topic and Wave it.

A little collab on what exactly to Wave about later, we decided to do “a mindmap of things we find annoying in CMSs.” To up the ante, we also decided to take the original bullet points (deemed “too easy”) and convert the whole thing to prose. Was the tool given really up to the task? Were our minds flexible enough to wrap around this kind of realtime collaboration?

In the beginning – we blame the tool ;) — we were Drowning, not Waving. We (almost) didn’t fight about edits. We almost didn’t step on each other’s toes. All in all, it turned out to be a fun and productive collaborative exercise. Read on to see for yourself.

Cosmetic Issues

There really should be a CMS UI fashion police. As there should be a Magic Quadrant for shoes and handbags. Why? Well, there’s a couple of issues.

For instance, sloppy, non-designed design. You know the kind of thing that has not been thought about and reworked and made to feel right. The sort of thing coders do if you don’t force them. But at the same time, over-designed interfaces can be just as bad: the designers and developers really need to be on speaking terms.

When building a system that works, you can’t have the development team in the basement on a sustenance of Jolt coding away into the night, and the designers in the penthouse in turtleneck sweaters sipping espressos. Too many CMS designs end up being programmer vs. end-user friendly. And this is not the best way to charm away those marketing and web content folks.

Developers and designers need to talk to each other and essentially, both should talk to users - not just eat your own dogfood – but listen to what dogs like to eat. A developer or UI designer are not content editors, marketers or knowledge and information workers.

Some vendors say that the agonizingly and depressingly black UI backgrounds are hip and modern. Well, they are not, really. Who told you that? Especially if you add a Star Trek theme to it and sprinkle in some stars and cosmic swirls, because if Apple does it, it must be cool right? Not pointing any fingers, but I would quit if I were a content manager having to spend my 9-5 staring into the “black hole” of some of the CMS UIs that are out there on the market.

Even pop-ups seem less annoying when compared to dark UIs. Which brings us onto…

Interface Issues

Interfaces need a comfortable lived in feel. Content management is something people work with every day, it is their interface to their job. You meet people who hate the interface, and that makes their work a heap of pain. I have seen people who describe the 44 clicks it takes to insert an image. You have a responsibility to these people, to make them love the content and make the tool disappear.

We all hate it when the interface does something on its own that ruins your context. E.g. a page refresh, or in Wave the jumping around of the scrolled window in some cases ;-) Or the lack of an easy way to bookmark, so you can reference someone to the content. Remember people will be collaborating and need to send links around. Make sure the UI is a proper web application with URLs. And why do tasks that are easy to describe and often repeated in exactly the same way still take more than a few clicks? (Or maybe even dozens of clicks.) With bonus points for forcing users to use dialogs or tabs to enter mandatory information. Remember people do not have all the information in the right order.

Also, we need sane conflict merges. Check in and check out is too extreme for most uses. But people want to edit offline still. Of course Wave doesn’t have an offline: Google thinks this problem is going away, it’s real time so there are never conflicts (that’s defined in the XML protocol; it’s quite interesting if you are that way geeky). Does Google have the right answer here? Well, the Motley Crew is struggling here, and some browsers lost sync during this experiment.

“Power users” (those who use it all day long) of CMSs needed to have a “Desktop” experience. What does Desktop Experience mean? Well, it doesn’t really have to be on the desktop – these days it is perfectly possible to get very close to a hitherto Desktop experience in a browser or similar. these are qualities: very low latency from action to response, no page refreshes, modal and modal-less dialog boxes as appropriate, “push” notification.

Architectural Issues

Architectural issues of the wave overtook any architectural issues of Content Management Systems. The fact that we authored this entire article in a single blip didn’t help, and slowed everything down enormously. McBoof learned the hard way that he really need a new laptop and spent most of the session giving his machine CPR. Next time we’ll do each paragraph in its own blip to stop FireFox going down like a Led Zeppelin.

DeadWave

Monolithic systems. Build it out of pieces that the client can not use all of. Obviously your pieces may work together better, but there should be components. Do not try to reinvent all kinds of wheel. “Best of breed,” though, is just another weasel marketing idea, as if systems are pinnacles not about meeting requirements.

 

Marketeers are adroit at using the term Best Practice to position Their Way as the only way that a particular matter can be solved. (Many of us live in that netherland of having to pedal that point of view, but it is a falsehood that the careful buyer should try to see through.) I think this devalues genuine best practice, vendors should cite references

Most often a marketeer’s Best Practice view is the only one they subscribe to as their product development has paddled up the wrong stream and cannot or won’t reverse their architectural design (probably because of the cost of doing so). This intransigence most often causes a product to doom itself. (Think of IBM and The Mainframe Is The Only Way To Do Serious Business).

Who really still believes that there is a place in this world for Flash or Java Applet based Rich Text Editors? TinyMCE, FCKeditor and others are filling the gap left by Ektron when they bit the hand that feeds and entered the CMS market. Ephox is trying to spread, but I find it difficult to come up with an excuse to use an Applet over HTML with javascript these days. Stick with the standard.

Business Issues

Where you are buying into something that you may very well need to change or integrate with there is strong benefit in considering Open Source. Open Source used to frighten commercial software companies but we have come along way on that road to understand that commercial organisation can operate in an Open Source world and benefit. This does not necessarily mean that their prized system needs to be fully opened up, but taking the spirit of it to mean that you are completely open to people seeing and learning from your code how it operates.

Exactly what you need to see opened up varies. In a CMS there may be a subsystem that stores the content or one that allows a Rich Text Editor. These arguably don’t need to be opened up, but when a CMS ships with modules for, for example, an RSS feed widget, calendaring tool, prebuilt webforms, users who then want a variation on this module can benefit from seeing how the “pros” did it, they can then use it as a starting point for their own different implementation.

We really don’t need vendors that pay lip service to the buzzwords. When they think the new CMS buzzword “engagement” is just a screenshot of Google Analytics. Or when they add an image picker and call it DAM. And a cross-over between WCM and ECM? Don’t think WCM is like ECM and it’s about organizing content, not about effectively communicating with the audience. And don’t think that if you organize the content, you can automatically communicate effectively.

Completely different, but equally frustrating, is procurement (and the procedures that go with it.) Procurement folk don’t recognise the importance of user adoption to the success of the project — of the black background and all the UI issues pointed out previously. If a CMS is procured according to procedure, the selection is a success to them. But those same rules are often a recipe for ignoring what the users really need.

At the same time, budgets that aren’t transparent are an issue - customer and vendor should be able to have a sensible grown up conversation. As a customer, of course you want good value, but how cheap are you? But to vendors: many licensing models don’t make any sense, and force you to do stupid things. People are scared to have that conversation - the best architectural fit first I say, lets figure out an appropriate license around that.

Conclusion

So much hatred rolled up into a tight little ball of anti-CMS rage. Who would have expected it from such a respected bunch of CMS folk. We hate the designs, the interfaces, the architectures and the business. Time for a beer/wine? Wave good bye!

(Note: This is a cut/paste (as is, no edits) from Google Wave)

About these ads
Standard

22 thoughts on “Things We Hate About Content Mgmt

  1. Pingback: Twitter Trackbacks for Things We Hate About Content Management « Irina Guseva: Random Thoughts on CMS, WCM, ECM and Other Acronyms [irinaguseva.wordpress.com] on Topsy.com

  2. hmmmm the power of collaboration!!!! Well done! This is an excellent article – It certainly gains my support from a CMS customer/user/trainer perspective and hopefully it will provide a rallying cry to vendors to really focus on those pain points.

  3. Pingback: ajf7688 Blog - Things We Hate About Content Management « Irina Guseva: Random …

  4. Pingback: Things We Hate About Content Management « Irina Guseva: Random … | CMS Desk

  5. Pingback: Things We Hate About Content Management « Irina Guseva: Random … | www.kotihost.com

  6. Pingback: Persuasive Content | I Predict A (CMS) Riot: 1 hour, 6 People, 1 Wave

  7. Pingback: uberVU - social comments

  8. Pingback: Things We Hate About Content Management « Irina Guseva: Random … Hello CMS - the best cms website

  9. Pingback: Wave experiment: Things We Hate About Content Management – Technology of Content

  10. Speaking of content management systems that work like desktop applications, we’ve been using Infomaxim for some time now. The latest version has a nicely AJAX’ified interface and is extremely responsive. The new report builder is very cool too, with a very nice drag and drop tabular report tool. Infomaxim’s scope of capabilities encompasses a bunch of things we use to have to do across 3 or 4 separate applications – the integration is another thing that makes it feel more like a desktop app. Worth checking out…

  11. Pingback: Things We Hate About Content Management | Digital Asset Management

  12. Pingback: Things We Hate About Content Management – A Collaborative Google Wave Blog Post « Media Management and Licensing

  13. Pingback: The Cheap Computer Geek » Blog Archive » Riding the Google Wave

  14. Pingback: links for 2009-10-28 « News, Software and All you need

  15. Pingback: Contented Management > ‘Bove the contentious waves he kept

  16. Irena

    to sum it up, you want something that looks good, is easy-to-use, doesn’t do stuff you don’t expect, allows you to easily merge edits back in after working offline, has a flexible but standards-compliant architecture (preferably open-source) and communicates its pricing openly.

    I’d say I know the ticket ;-) – although admittedly we haven’t really covered the easy offline editing/merge part.

    Cheers
    - Boris

  17. Pingback: Top 10 CMS Stories in 2009 « Irina Guseva: Random Thoughts on CMS, WCM, ECM and Other Acronyms

  18. Pingback: Nexus One: A Gadget for Google Addicts « Irina Guseva: Random Thoughts on CMS, WCM, ECM and Other Acronyms

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s