Decoupled content

In this second part of my talk with Jeff Eaton, we turn our attention to a project Jeff is involved in: a CMS implementation that was design for content management first, and is now reaping the rewards.

Jeff Eaton

Jeff Eaton

Digital Strategist at Lullabot

Twitter: @eaton

Rick: Let’s talk about the difference between the content models we want to use inside the CMS to store data, the models we use to present to our end-users, and the way we manage that.

Jeff: I’m on a client project at the moment; a news network. They’re looking to upgrade the underlying platform, from one version of Drupal to the next. They need an assessment of what we’re going to need to rewrite and what will just be magicked up by the latest system.

One thing about this amazes me: they love their tools. They’ve been building the system over the last three years. When I talk to the authors and editors, they’re saying: “We love this CMS. It’s the best thing we’ve ever used.”

Rick: Shocking!

Jeff: It gets better. If you look at it… it’s ugly as sin.

This demonstrates that that value in author experience isn’t in prettifying the screens…

Rick: Beautification…

Jeff. Yeah. It isn’t about making it aesthetically beautiful. It’s about making it fit to task.

Rick: I talked about that earlier with Eric Reiss – Vitruvius’ description of firmitas (function), utilitas (utility) and vinustas in architecture, and how that maps to service design. The best translation we came up with for vinustas is emotional aesthetics.

Jeff: That aesthetic is the last thing that most of the people who actually use the system are concerned about. But it gets most emphasis in pitches and demos; it’s the only one of the three that the project sponsors and managers understand.

Anyway, back to this client.

Their CMS was intended only to be a web system. But the people brought in to manage the process were old-school Java content repository hacks. They built a fully decoupled CMS.

They didn’t build a web site with forms to edit it. They aren’t storing HTML. The whole thing is built on a very simple XML DOM (Document Object Model) that describes an article body. There are nine things it can contain; a few small building blocks that can be combined in some interesting ways.

And the editor interface has been heavily customised: it’s not a WYSIWYG editor, it’s about the meaning in those nine structures. Everything is optimised to work smoothly.

Associations are a big deal. Yeah, there are references between articles, but they go much further. They don’t assume that order implies priority – they are two separate things. If they have to deliver a short version of something, it might drop the second paragraph but keep the third; a shortened list could drop items from the middle (imagine it were listed alphabetically); an image might be the last element in the article, but so important that it is included when the article is trimmed to a teaser.

They’ve thought through a lot of subtle details. But the technical side is cake. It’s simple.

Rick: Based on a repeating pattern?

Jeff: Exactly. When there’s a new requirement, implementing it is straightforward. Declare the behaviour and you’re done.

Rick: That sounds a lot like the WYSISMUC editor (p. 129) I’m putting together. Does the CMS I wanted all along already exists?

Jeff: Probably. They’ve rolled together a lot of the stuff you describe. And their current thinking is: “We don’t want to be the only ones using this. We’ve gotten it to work the way we want to, but we understand there’s value in other people using the same tools, and developing them, and ironing out the bugs.” So they’re looking at open-sourcing it.

Rick: Are they pushing out mark-up? (Because it’s something I want.)

Jeff: In a couple of instances, I believe so. But it’s irrelevant. Because that’s entirely a question of the templates on the front end. On the back-end, they literally don’t care because they’re focussing on capturing the story in a structured way. Once they have that structure, they transform it based on templates for each audience. It pipes out JSON for their iPhone app, HTML to the web site. From one source.

This means they can do all sorts of crazy stuff. They’re rolling out a responsive design on their front-end web site. And no one touched the back end. They didn’t need to. The content is structured. It already includes everything they need to know – not just the words and pictures, but priorities and emphasis. The authors have been specifying this all along; the new front-end design is just using it in more complex ways.

I mean, it’s amazing.

All the things I’ve been ranting “you oughta do this” about in articles over the last three years, they’ve implemented. And they’ve never read any of my articles!

It’s a great example: putting the structure and governance in place early on really pays off. They’ve been doing it for three years. They have a ton of content in really good shape. So they can re-architect their site with minimal effort; they don’t need to change the content structure, or how it’s managed.

Rick: Because it’s decoupled.

Jeff: Exactly!

Rick: That sounds similar to the New York Times’ Scoop story. It’s the big news organisations – the people who handle serious amounts of content, those who will benefit the most – who are taking the lead and doing it right.

Jeff: They’re facing the greatest pressure to reuse efficiently. The industry is under pressure to perform. Their financial straits are forcing them to think strategically. They don’t have the luxury of throwing a marketing budget at reinventing the wheel every few years.

Rick: I take it this structured authoring and environment decoupling means that authors don’t have any kind of access to the underlying code in the editor.

Jeff: Correct. They’re not going to wrangle the mark-up. They are journalists and editors. They understand story. They aren’t code monkeys. They aren’t domain experts in mark-up. Their job isn’t to handle the deep technical issues of making sure the content delivers out correctly to basic HTML, responsive HTML, XML, JSON…

Rick: And whatever new thing comes along next week.

Jeff: Exactly.

Rick: Right. They need to author their content in a way that makes sense to them, with the interface translating that to a semantic structure behind the scenes.

Jeff: The language of your content is not the same as the language of each of your delivery platforms. It is not the same as the language of your storage platform. Once you accept that that translation has to occur, the world gets so much simpler.

It’s counter-intuitive that adding another step would make it simpler, but it does.

And I’m preaching to the choir…

Rick: So what about that translation layer to delivery? Are they pre-building and caching the content for each channel, or building it on the fly?

Jeff: It’s somewhere between the two. Their DOM is great for storage, but not so efficient for delivery. So they have a proprietary layer that flattens out the CMS’s stored content into two tables: one with all the bits of content, and the other with all the associations. This lets the rendering layer make two fairly straightforward SQL queries and they have everything they need to push into some lightweight templates.

Rick: The best of both worlds between pre-built and on-request from-database page assembly.

I love this. They really have completely decoupled the three layers. They author in a way that makes sense to journalists and editors, store in a way that makes sense to the system, and deliver optimally for all audience channels,

Jeff: One of the things I get fired up about – and you talk about it a lot in the book – is that a sufficiently solid author experience won’t expose the underlying storage mechanism to authors. Otherwise, you’re forever at the mercy of your next platform – you move and have to retrain everyone in whatever goofy interface things bubble up from that.

So often, the stack that a given set of tools was built on shows up to the authors. The implementation team’s assumptions ripple out into five or six predictable pain points. It’s a different five or six things depending on the starting point.

Rick: But it’s so easy to reverse engineer. You can see what the developers were thinking – the assumptions they made about content – from the authoring interface.

Personally, I like the approach you’re describing because it creates light-weight pages. So many of today’s most common CMSes use the same code in author and to serve to the end user. Whenever they need another bit of structure – either to make the editing work, or for the end user – a few more divs get thrown in.

I’m sure the average page could be made a half Mb lighter if all that redundant code were cleaned out.

Jeff: As somebody who mostly lives and works in the Drupal community, I am never going to cast stones about the number of deeply nested divs and spans that something throws out. But I definitely hear you.

Drupal drove past one of those little road-side farms, just selling divs by the bucket, and we said “Yes, we would like some of those.”

Rick: Get ’em in bulk.

Jeff: The prices were so low!

But joking aside… I think that’s a key distinction between the built-to-fit system, and the assemble-from-plugins platforms. The super-heavy Drupal sites take those easy-to-assemble components, snap them together, and skin them. It’s a great way to build something quickly, to put it in front of people. But you’re paying the price of assembling something from Lego rather than carving it from wood.

Rick: I’ve seen some pretty funky Lego art. But not everyone can do that stuff.

Jeff: Yeah. At a certain level of complexity, it takes just as much skill and understanding to get the assembled pieces to play nicely together as to build something proprietary.

To finish up, there’s one more thing we get from decoupling the layers. With so many projects, we find people wrestling viciously with some weird content management problem that boils down to allowing deep conceptual concerns about what they are communicating to bleed into the decorative, stylistic decision.

Rick: I thought it was the other way round…

Jeff: Well, they’re not allowing things to bleed into the front end. They’ve pushed important decision making into that stylistic layer, rather than treating them as fundamentally being about message and communication.

Rick: Which means the stylistic bleeds into the messaging.

Jeff: It’s all kinda fuzzy: who’s bleeding and who’s getting bled on.

Rick: Zombie-fest!