“Live: Someone is dead” - how CMS software can damage the news UX
I posted a screengrab to my Tumblr last night of the headline from The Times website which unfortunately managed to follow the formula “Live: Someone is dead”.
It is easy to just look at this as someone from the Guardian having a go at The Times, but it isn’t. And I’ve every sympathy this morning with the sysadmins at News International struggling to keep their sites up and running - there but for the grace of LulzSec...
I think last night’s headline is the perfect example of something that wouldn’t be allowed to happen in print, but which hits a magic Venn diagram intersection of technology, editorial and information architecture allowing it to happen digitally.
All of the decisions along the way look perfectly reasonable. Of course if a story is being covered “Live”, it makes sense to technically treat the opening “Live” on the headline with a different bit of CSS to make it stand-out. And of course, from a pure IA point of view, it makes sense to denote this content type with a kicker of “Live” automatically applied. And of course, if the “Live” bit is being applied automatically, from an editorial point of view you just write the headline to best convey the story, probably with a little hint of SEO in mind.
And none of those things are wrong as individual judgements, until you look at the overall user experience - where it ends up looking crass.
One of the biggest problems with designing the CMS for a news site is that, rightly, editorial staff want the maximum amount of flexibility within the tools, and to control the way that every bit of text appears. Every option on the front end, however, introduces a new set of switches and buttons on the back-end, inevitably increasing the complexity of the CMS interface and the software underpinning it. Nevertheless, examples like the one above shows why your templates need to allow maximum flexibility - in this case I’d want the ability to switch the “Live” to also be able to say “Breaking” or “Latest” or be dropped altogether.
Another common problem is that with a CMS, editors seldom edit on the page. Instead they put blobs of text into webforms, divorced from the overall context of how they will eventually appear. This is in marked contrast to being able to edit layout “on the page” as a traditional print production process allows, where a composition like the one above would be noticed much sooner.