Now you would not think to look at him
But he was famous long ago
For playing the electric violin
On Desolation Row
- DESOLATION ROW

A few months ago, I was chatting to a very wise man. He said to me: “If three people tell you that you’re drunk, even if you’ve had nothing to drink, you’d best go home and sleep it off”.

When people tell me that I’m drunk these days, I normally am. But there are some other things people keep telling me that I don’t agree with, so they’re probably right. They’re all related to the fact that I’m an old school control freak dog that probably can’t learn new tricks.

So, I give you Five Things I’m Probably Wrong About But Strongly Believe I’m Not. Maybe some long blog posts about any or all of these if people want to have an argument and educate me, but I’ll keep it short for now.

I prefer XML to JSON. Yes, I know they’re not really competing technologies. One is an interop format, and one is an object serialisation. But they sure feel like they compete from where I’m standing. The kids all seem to prefer JSON over XML as an API response format, even when the client of the API isn’t JavaScript. But not me. I’m old school like Dave Winer, even though he’s sometimes a bit of a cock.

I prefer RDFa to Microformats. And I prefer RDF to XHTML for structured data. I’ll take structure and standards over conventions. Microformats are more popular than RDFa, and people are probably right that RDF is complex and hasn’t taken off. But I can’t help it. I just don’t like using CSS classes to imply semantics.

I prefer XSLT to all alternatives. I love forced well formed markup. I love the fact you can’t be lazy and hack. I love the override model and the terminology they use. I love XSLT so much that I don’t really know what the viable alternatives are. Freemarker? mustache? I hate all web templating languages that end in a P. That includes JSP, ASP(.NET), PHP. It’s not easy to make XSLT spaghetti like you see in the P langauges. I know the kids all think XSLT is complicated, verbose and slow, but I just don’t see it.

I prefer strongly typed to weakly typed languages. The theme of control continues. I’ve seen to many non-typed programmers write hundreds of test cases for their code which pretty much replicated a typing system. Compilers are an automated test suite in my book. While we’re here, I hate Perl more than anything else. Especially if the project team size is greater than one. “There’s more than one way to do it.” Sneaky fuckers just want to write code that is impossible to understand so that the weird guy on the second floor can keep his job maintaining it. I’ll have a double helping of consistency with some control sauce on top, please.

I prefer referential integrity to chaos. I like the fact I can’t get horseshit data into my system. While I believe the repository administrator should be able to disable referential integrity (REFINT) constraints for performance reasons in a tested, production environment, I can’t handle the mess my development repositories get in to. Many smart folk are telling me REFINT is a slow waste of time and a layer above the repo should be responsible for it. But I don’t buy that either. Note that I am a big NoSQL fan and prefer a hierarchical repository to a relational one.

So you see, I’m a freak. My developers are all tree-loving hippies that want flexibility. I want impose technologies that restrict the hell out of all of that. And you all thought I was the hippy! If any of you, dear readers, agree with me on any of the above, I’d feel a whole lot better. I’m feeling rather alone out here. I’m like the guy at the back of the crowd:

Brian: Please, please, please listen! I’ve got one or two things to say.
The Crowd: Tell us! Tell us both of them!
Brian: Look, you’ve got it all wrong! You don’t NEED to follow ME, You don’t NEED to follow ANYBODY! You’ve got to think for your selves! You’re ALL individuals!
The Crowd: Yes! We’re all individuals!
Brian: You’re all different!
The Crowd: Yes, we ARE all different!
Man in crowd: I’m not…
The Crowd: Sch!
- Life of Brian (1979)

Ain’t it just like the night to play tricks when you’re tryin’ to be so quiet?
We sit here stranded, though we’re all doin’ our best to deny it
- VISIONS OF JOHANNA

The end of the decade is nigh, and the mystics at CMS Watch have been throwing the bones again. They’ve released their very interesting 2010 Technology Predictions. The first of these caught my eye:

CMS Watch: Enterprise Content Management and Document Management will go their separate ways

I don’t agree with the terminology here. In my world, Document Management is one of the pillars of Enterprise Content Management. Enterprise Content Management is not a technology, it’s a business problem. Documents are one of the types of content the Enterprise needs to manage. So they can’t really go their separate ways. The wise Pie responded quickly to this prediction with an alternative:

Pie: Enterprise Content Management and WCM will go their separate ways.

Now this I agree with more than the CMS Watch version.  Parts of ECM include Document Management, Records Management, Collaboration, Imaging, Workflow and all that good stuff. It is these pillars that allow a business to manage their content. The end game of all of these technologies is content sitting in a repository that can be easily found and consumed. The includes all the fun with versions, security, compliance and anything else you’d want to do with it. But it does not include setting up web based delivery channel that exposes some of this content. WCM should not be considered part of ECM.

Now Pie also acknowledges that his prediction isn’t going to happen, although it should. My prediction is even less lightly to happen, but here it is anyway:

Jon: Enterprise Content Management is well defined. The term WCM is horseshit, unnecessary and should take a long walk off a short pier.

I can already see the news headlines: LONDON, 2009 – SHOCK HORROR! WCM Geek Demands Death of term WCM. But it’s true. I’m of the camp that wished the term WCM would cease to exist.

The W is meant to stand for Web, which makes people think Web Site. But it also includes Mobile, Kiosks, TV and various other HTML based delivery channels. Many vendors are trying to deliver their WCM content to print channels too. I want any product that ends in “CM” to focus on content creation and management. As Pie said, this content should be accessed via an API or repository standard. A Content Management System should be an extensible application that works pretty well out of the box. The kind of standard these systems care about include data/process standards (for example DITA, BPEL, or Dublin Core) and repository access standards (for example JCR or CMIS).

The other half of the coin is the delivery framework. These are called Web Publishing Tools (WPT) in NPR’s COPE and Presentation Management Systems (PMS) by Peter Monks. Things like Struts, Spring Web, ASP.NET MVC, Ruby on Rails and many many more are all delivery frameworks. So are Portals. They let you manage authentication, URLs, site structure, templates, layouts, page composition, personalisation, aggregation and more. They understand standards like JSON, AJAX libraries, Web Services,  SAML, OAuth, OpenID, Open Social, Portlets, Gadgets, WSRP, and so on and so on. They let you call any API to bring in content or functionality from any source.

Of course you can use these technologies to power sites that aren’t “content managed” at all.  They should treat CMS driven content components, SoCo powered UGC components, DAM powered media components and anything else that can sit on a web site as equals. Interestingly, it isn’t uncommon to see “Web Content Management Systems” used to power sites that that aren’t really content managed. Take something like Drupal – it’s often simply used as a delivery framework without any content modules. I’ve launched sites running on .NET “WCM” systems that have never intended to have any content changed post launch. In these examples, the WCM product is being used purely as a good delivery framework.

But sadly, my prediction it isn’t going to happen. I’m just going to have to keep thinking of a WCMS as a tightly coupled hybrid of a content management system and a delivery framework. On the plus side, I’ll continue to make money out of poor customers that think a “WCM migration/replacement” doesn’t involve a complete site rewrite as they’re throwing the delivery baby out with the content bath water. Losers.

Standing next to me in this lonely crowd,
Is a man who swears he’s not to blame.
All day long I hear him shout so loud,
Crying out that he was framed.
- I SHALL BE RELEASED

How many WCM implementations leave customers grinning from ear to ear? The statistics make sad reading. But if so many projects don’t meet expectations, who is to blame? Is it the vendor, either because of a crappy product or dodgy practice? Or the implementer that eats your budget while making a beautiful product smell real bad? Or are the customers naive, unrealistic or worse?

On Wednesday morning, the Web Content Management Track of the Greatest Web Conference in the World kicks off. The opening session, “Inconvenient truths and unsolved industry challenges “, has a rather unambitious aim – to solve the world’s WCM problems. A bit like WCM World Peace. On the panel we’ll have Janus Boye himself representing the customer viewpoint, Jarrod Gingras of CMS Watch representing the analyst massive, and little old me defending the honour of the implementers.

The topics are sure to be varied, and our esteemed moderator will be sourcing questions from the crowd, and from Twitter. We’ll be using the hashtag #fixwcm so be sure to set up your Twitter search now, and get involved in the discussions. Apart from blaming each other for multiple disasters, some other issues we might be covering include:

• Does the term WCM even make sense these days?
• Are there too many vendors out there, and will we see consolidation?
• Can buyers navigate the marketplace themselves?
• Why do so many projects fall on their face?
• Will Open Source vendors dominate in the future?
• Do you need hard requirements to select a CMS, or is it a philosophical decision?
• Are more Web / Content Standards the answer to our prayers?
• Why are the Requests for Proposal always so bad?

You can start shaping the session right now by tweeting your thoughts using our #fixwcm hashtag. We want to hear why you think WCM is broken, and what the biggest challenges are. Or if you just want a 140-character rant about a horrorshow of a project, that’ll be fun too.

Join us live on Twitter on Wednesday 4th November between 10:30 and 12:00 CET to throw in some curveballs. And if, for some reason, you’re attending the conference but choose to attend one of the competing parallel sessions (like the great Kristina Halvorson, Bob Boiko, Jane McConnell or Shawn Shell – it’s a tough pool), you can still participate on Twitter at the same time!

See you in person or in the Twittersphere. It’s going to be cold as hell in Aarhus, but the discussions are sure to get heated.

P.S. If you think the main WCM problem is the design of the content repository, it looks like @pmonks, @justincormack, @micycle and others might have it fixed before our session starts. Hope they’ll share their findings live! The Content Tree is Dead. Long Live the Content Graph.

Never bein’ able to separate the good from the bad,
Ooh, I can’t stand it, I can’t stand it,
It’s makin’ me feel so sad.
- DEAD MAN, DEAD MAN

ACME Corporation have decided to launch a web presence to support their thriving cartoon supply business . They hire you as the brand new big technical cheese to realise their vision. And this vision, as usual, includes everything: Content Management, of course; Search so that you can find the products; a Community to provoke discussion about new product design; Digital Asset Management to store the images and blueprints of the products; Analytics to track down who is interesting in committing nefarious deeds; CRM to improve the way they deal with their prospects; and mapping software to track Road Runners. And something to glue these all together. So, Mr Big Cheese, what are you going to do: buy a single one-stop-shop product that does everything, or assemble together a set of best-of-breed products?

The ACME Corporation Web Site

What do the RFPs say customers want?

The majority of the CMS Vendor Selection RFPs that I see demand feature ticking around search, analytics, SoCo, DAM and all the rest. They ask for it all. These RFPs are geared towards procuring a single product that does everything. Most also all assume that the Content Management System will also be the delivery layer and ask for many delivery layer features. A pure-play decoupled CMS wouldn’t stand a chance. If the scoring was done purely on the features lists, a portal would often beat a CMS. The vendor presentations tend to focus more on the features of the canned demonstration site they all have than on the CMS back end.

What does the research say customers want?

The research doesn’t agree completely with this. The recent eConsultancy CMS Survey showed that more customers want best-of-breed suppliers over a one-stop shop, especially for companies with more than 100 employees.

What is the strategy of the vendors?

Well, they all seem to heading towards the one-stop-shop solution. Sure, they’ll release new features to their core product. But more and more, they seem to be differentiating by moving into other areas. CMS vendors, in particular, are packaging in social/collaboration software, search software, shopping baskets and payment modules, basic DAM and the kitchen sink. Everyone is producing their own Analytics and MVT software. For example, SiteCore recently announced their Online Marketing Suite and EPiServer called with their Marketing Arena . Seeing as most of these features really sit at the delivery layer, not the content management layer, the number of pure decoupled CMS vendors is on the decline. There is a huge amount of M&A activity at the high end of the market as everyone tries to cover all the bases.

So, the strategy of the vendors seems to be on diversification. Gut feeling would imply that finding a niche, or focussing on improving the core CMS would be front of mind. Not so, they’re all playing “RFP feature ticking”. They all bang on about being “open” and supporting open standards, while at the same time singing about their proprietary, tight integration between their newly aquired products. For example, a typical conversation:

Me: So, Mr Vendor X, why do you think we’d use your new Analytics|Search|Community product over the one we currently use?
Vendor: Because our one has a ‘much deeper integration with our product’ and ‘understands our product’  better.

There are problems with this as I see it, some of which include:

• everyone is building monoliths
• as parts of the system become obsolete, and it becomes harder to take advantage of unexpected future goodies
• you really are at the mercy of a single vendor

What does the future hold?

I would have expected the fact that standards are improving to mean that we’d have more focussed best-of-breed vendors that allow you to plug their product in to any CMS – the nice Lego-block style architecture diagram. However, currently it looks like we’re heading the other way, which really depresses me. We might even be buying the Google CMS Appliance before long.

If it continues at this rate, our friends at CMS Watch might need to consolidate all their lovely reports into the “Web In A Box” report quite soon …

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.