…which is one of the first tools we built as part of the project. And it’s a lot more complex that most people expect, especially if their main exposure to a content management system is through blogging.
The main reason there’s so much to it is that there’s so much to the organisation it operates in. On a blog, if you write an article then you don’t need to worry about people finding it, because it will appear at the top of your homepage, which is more or less the only page that people will be watching if not the RSS feeds. Furthermore, a blog is really just a single stream of articles. So when you write a blog post you really only need to worry about the headline, the body text, and maybe an extract to entice people in — and you certainly don’t need to worry about the environment that the article appears in.
On a large website such as guardian.co.uk, by contrast, an article generally won’t appear on the homepage, and it has a less than 1% chance of appearing at the top of the homepage. But it will be linked from many other pages. It will also most likely be only one part of a whole mesh of other pieces of content, all touching on different aspects of that and much bigger stories (plural), so it’s important to link all these together. (This is part of what Lloyd Shepherd calls “slow news”.) Therefore the article editor has lots of boxes to fill in which ensure the article fits in properly with the rest of the site’s content. Keywords are central to link to and list it on appropriate subject pages; an alternative headline is essential to allow the article to be linked to from those subject pages and elsewhere (many newspaper headlines only make sense on the printed page with a particular layout and don’t translate to the web); a one- or two-sentence explainer is similarly important to go underneath the alternative headline.
And side from the importance of maximising cross-linking, there are other factors that explain the differences with an article editor for a blog post, but they are still all consequences of working in serious organisation. Rights issues mean the writer has to be identified exactly; design requirements will mean that different parts of the article (most obviously the standfirst) need to be separated so that they can be displayed differently; print publication times mean you’ll need to identify the print publication date and the web publication date separately; marketing decisions may mean you need to give a particular article a specific URL.
A while back, Martin Stabe lamented “Why can’t a newspaper CMS be as user-friendly as a blog?” I’m sure our article editor could be more user-friendly, but I doubt we’ll get it to be quite as user-friendly as many blog editors simply because it does a different and more complex job — a job in an organisation with hundreds of people and very sophisticated media and presentational requirements.
niksilver.com 
I haven’t seen the backend of the new Guardian system, so I don’t know whether the issues I’ve sometimes raised apply to it.
But I don’t think the frustrations journalists (including me) often express about the CMSs they use have much to do with the debate about “lightweight vs. heavyweight” software as you’ve described it in the past. I think the issue is primarily one of poor backend usability and design.
The weakest point of editorial systems usually has nothing to do with the core software and everything to do with basic user interface design: Crucial options that are hidden away in counter-intuitive places, unnecessary navigation elements that require extra clicks for heavily-used or required tasks, menus that that don’t anticipate what you are most likely to achieve, pages that take ions to load, and so on. When you’re trying to break a story online while the next print deadline looms, every extra click and cumbersome procedure is a serious obstacle.
Martin, yes, I’m not trying to pretend the issues of usability and complexity are the same, much less that the considerations I’ve set out here are in any way an explanation or excuse for poor usability — they are not. This was simply an attempt draw a distinction between (for want of better phrasing) a personal CMS and an enterprise CMS.
I picked up on your points about usability because you were (and are) advocating the excellence achieved in personal CMSs to be carried over to enterprise CMS, and I wanted to say that it’s difficult to do because the task in hand is more complex, and they are different beasts. Of course, that doesn’t mean championing usability isn’t worth doing, and I agree that it’s a cause worth championing.
As an aside, I have been preparing these articles simultaneously for this blog and for Guardian’s own “Inside…” blog using the R2 CMS, and there were clearly more clicks needed to get the work done on the R2 CMS. (I didn’t have the luxury of a production staffer to help me). It would have been easy to blame the tools, and possibly the usability of the tools. Of course, I knew I was working for outlets with very different standards, and the result on the Guardian site is a much more sophisticated offering. Still, in the heat of the moment it’s easy to lose sight of that bigger picture.
I’m going to caveat this entire comment with the fact that I have no idea how the R2 system works, but I do have plenty of experience of creating enterprise level CMS. I created the CMS that both the number-10 web site and the Royal web site used to great effect between 2001 and 2007 (i.e. both content heavy sites). So with that in mind …
… I’m with Martin on this one. I also don’t believe that complexity is an inverse function of usability (i.e. the more complex, the less usable). To a large extent, many CMS tasks can be automated on the first draft and refined by an reporter / editor subsequently. Tasks like automating the tagging and properties of articles could be a great help for example.
As a developer, I realise how easy it is to create something that ‘you know how it works’. Its often very easy to lose sight of the end users and this is a big problem. Usually, designers only get involved at the front end of the site and never pay a moments notice to what goes on under the covers. I’ve found that getting the designers involved at the level of interface designer to the CMS is extremely important. Just because it is an internal tool doesn’t mean that it doesn’t warrant a similar level of design as the front end.
So what’s my point? I think that the combination of looking at where tasks can be intelligently automated by the system itself and getting the designers involved at an early stage can dramatically reduce the complexity of systems. Granted, it will increase the amount of budget for the development, but the benefits in the reduction of time and stress on the end users should justify this … hopefully. :)
Odhran, I’d certainly not disagree with you. I also don’t believe more complex = less usable. Although I do believe that more complex = more difficult to make as usable as something less complex. It’s easy to make a two-button tool usable, and more difficult to make a 10-button-and-lots-of-boxes-which-are-optional-depending-what-you-enter tool equally usable. You have to be smarter about it and, as you say, recognise that achieving that requires more budget.
Automation is helpful, and I’d highlight the point you made in passing:
Its often very easy to lose sight of the end users and this is a big problem
That’s about not designers, nor developers, but people who have to work with this stuff day after day, under circumstances most others can’t guess at, and to deadlines that are inconveniently near.