Content Creator: The MailOnline CMS

A few months ago, the New York Times wrote about “Scoop”, their new publishing system.

Scoop, they point out, is more than just a means of facilitating their editorial processes. They see it as “…central to our ambitions to innovate on all platforms”. They also point out that the capabilities, ease of use, and competitive edge of content management systems is an increasingly important part of media publishing in the digital age. The fact that Google are throwing their hat into the ring shows they’re also probably right.

This is interesting to me for a number of reasons, not least because of NYT’s emphasis on the user experience of their CMS.  What we currently understand as user experience design has so far been all but entirely absent when it comes to things like this. Anyone who’s had the misfortune to fill out timesheets online, submit expenses or holiday requests, or use anything built with Sharepoint will know what I mean. The experience of such systems is universally similar to sticking pins in your eyes.

I’m therefore glad to see that at long last people are realising that investing in the UX of internal systems design is important. It may even be as important to the long-term health of a digital business as investment in their external-facing systems.

I was also particularly interested to read about Scoop because for several months I’ve been working on the equivalent project at MailOnline. It’s called Content Creator, or Web Publishing System (WPS) 2.0. I thought I’d compare and contrast the two projects, and shed some light on its design process along the way.

(Those of a more technical disposition might like to read Jason Green’s account of how it’s being built.)

It’s About People

Scoop needs to support  a more complex editorial process than exists at MailOnline. In particular, Scoop is designed to deal with the separation of roles in the creation of a typical news story. Interestingly, they mention some doubts about this being the way forward, saying that Scoop doesn’t do a very good job of letting one person create an article completely on their own.

In contrast, MailOnline reporters see their stories through from start to finish in most cases, writing the headline, finding and placing pictures (and often videos) into a story themselves. They rely on very busy picture and video desks to supply them suitable material for this, and of course editors take a hand in shaping things along the way (tweaking headlines or previews as they place them on pages, for example). But for the most part, single ownership and individual accountability is the rule.

This means features like collaborative working, advanced change tracking and (albeit somewhat surprisingly) the incorporation of the print publication process – are all largely absent. It’s also worth noting that while one of our design principles is to accommodate different roles, this doesn’t translate into imposing a structured workflow on the people that use the system. In my experience, doing so usually turns out to be a bad idea. Working practices tend to evolve quite quickly, and technology is often quite slow to respond to that.

However, like NYT, we currently publish about 600-800 stories a day (here’s a recent typical day’s worth). If you look at the archive over the last few years, you can try estimating our growth rate. You’ll find it’s very high. Obviously, the systems used for producing this many stories need to be extremely reliable and efficient – and much of that depends on ease of use. The current system isn’t bad in that respect, but at over 7 years old, it’s showing its age.

Scoop is also at a more advanced stage of development. We  now have our new Article Editor in the hands of all journalists via a gradual process of “live beta”, designing, testing and iterating changes through real-world use since about March. This is the first part of what will be an integrated suite of applications to replace a small hotch-potch of tools in use today.

Design Principles

At MailOnline, we don’t believe in hierarchy or role demarcation. Front and back-end developers and devops alike have as much ability to input on the design of the system as I do.  So as the UX designer on the project, I see part of my role as curating the ideas we have in building the new system, if only to avoid ending up creating a system that’s just hard to use, but in new ways. I do this mainly by referring to a set of overall design principles agreed at the start of the project (AKA “What we are trying to achieve”).

We have 14 UX principles, some examples of which are:

1. Speed over accuracy: MOL is about blasting out content better and faster than the competition. When in doubt, the system should aim for speed and efficiency over the aesthetics of the final layout, fit to display device, etc. Those are secondary considerations.

2. Go from the general to the specific: To support Principle 1, the system should allow the creation of objects first in an approximate state, and then provide refinements and enhancements later (eg cropping a picture is optional; adding video metadata can wait).

3. Simplify the model: Give the user a simple model of clearly defined “objects” to deal with. Have no more than three of such objects: content (articles, images, videos), content modules (carousels, link lists, etc.) and screen furniture (“fact boxes”, pull-quotes, divider lines etc.).

4. Start fast: A new user should be functionally literate in their role using the system in under 60 seconds. (OK – this is a bit ambitious. At the time of writing it’s probably about 180 seconds. But video tutorials are proving effective.)

Other  principles include ensuring all user input is sacred (the system will never under any circumstances throw away your work), and the accommodation of long pages (look at mailonline.co.uk and you’ll see why!)

It would be interesting to know whether these are similar to the principles employed by Scoop  – or indeed if they have any design principles at all. I get the vague impression from the article that the system is being designed by engineers in consultation with journalists. I don’t doubt that you can come up with a good design like that, but in a project of this size it’s rather risky not to be applying at least some design thinking at all times in the background.

Content and Presentation

Scoop’s approach to the presentation of content is another way in which they are clearly a different operation to that of MailOnline.

You have to read between the lines a bit to pick this up, but one stark difference is that Scoop “… is a system for managing content and publishing data so that other applications can render the content across our platforms.” In other words, they take the very sensible and “visionary” view that if you value your content, you will ensure it can be rendered correctly on any platform. 

For better or worse, at MailOnline we see that as a nerd’s pipe dream. This is for two reasons: journalists can’t be expected to work in a context abstracted from final presentation, and even if they could, the pace of change makes it a fool’s errand for us.

In the NYTs case, abstracting content from its presentation is probably a sensible step because they’re interested in their content surviving beyond a couple of years. We don’t really have much interest in  anything after about three weeks in the case of news stories, and probably about two years when it comes to much else.

So instead, Content Creator presents everything to the journalist in faithful WYSIWYG form for the desktop browser. There isn’t even an opportunity to preview the story for any other device. To do so would be seen as wasting time – stories are for the most part simple stacks of text and pictures linearised for mobile web. No doubt if that ever ceases to make sense for us, we will take another approach and will do so extremely quickly. But for now, the desktop experience is the one journalists produce their stories for.

Updating the Publishing Toolset

After article editing, we tackle the “channel editor” – used to place stories on the home page and other “channels” like Femail and This is Money.  We then have the “puff editor” for MOL’s famous side bar; a “module editor” for things like video carousels, polls and sports scores; and video and SEO management applications.

For all this, we have a core team of about 7 or 8 developers who work with devops and others supporting the existing CMS and various other applications (principally ad management, comment moderation, and real-time analytics). Picture management and the supply of images to the CMS is being handled by a separate DMGT::Media project and is not in our main remit.

Wider challenges to the “publish faster” remit are also things like journalists’ interaction with Legal and the picture desk – both of which can be very time-consuming, error prone and generally inefficient. Making those better may depend on an amount of systems integration with Atex in the case of Legal, and the aforementioned bespoke image management system for the picture desk.

The incorporation of real-time statistics (currently existing in a separate, bespoke application) in all this is also going to important. Other ideas relate to messaging and alerts so as to tightly couple the work of editors with journalists – the size latter group growing at an ever-faster pace in both the UK, US and Australia.

 The Design Process

As I mentioned earlier, we have an extremely flat structure at MailOnline Technical. We also operate in what might be called a “post-agile” environment, as outlined by Fred George in his ideas about  “programmer anarchy“.  Consequently, we  have no  firm BA or QA roles on the team, and line managers are similarly absent.

This means the boundaries between the technical team and the rest of the business can be pretty porous if they need to be. And we’ve taken advantage of that in the design process for Content Creator. With no formal project sponsor or hard deadlines, and with the encouragement of the then Technical Director, we were free to conduct a “grass roots” investigation into what journalists wanted. And with no specification beyond the functionality of the current system, were able to test and observe the impact of new features on a gradually increasing number journalists.

In doing so, we incremented through a process of “continuous beta” – effectively using an informal RITE method. I invited any journalist to use the new system if they wanted, and found that  many did with minimal encouragement or instruction. Pretty soon, we had a steady stream of feedback, ideas, bugs to fix and workflow and practices to think about. If we had tried to specify too many functions in advance (or listened only to senior stakeholders), the project would have almost certainly suffered.

Because Content Creator is often an intensively interactive system, I’ve found the best way of demonstrating new ideas and experimenting with news feature is to mock up fully interactive prototypes using Axure and JQuery UI and show them to whoever would spare the time: developers, journalists, and other designers.

I’m always fond of prototyping, but it’s been essential at MailOnline. The UX and design team can’t take journalists and editors away from their work for more than a few minutes at a time. We don’t have meeting rooms, or even a culture of meetings. So feedback is ad hoc, at the person’s desk, showing them demonstrations of small incremental improvements.

It Can Be Done

The Content Creator story has been one of organic design and development. No “big bang” roll out, no “quality gates” or approval process, or much real forward planning. Yes, we’ve made mistakes, and lots of them. But while these mistakes have been frequent, they’ve also been small.

From my own point of view as a designer, perhaps the best thing has been the close involvement with the journalists who would use the system and the developers who would build it. The hardest part has been the inevitable conflict between my own vision of the product, and what the developers have been able, or have wanted, to provide. I’ve blogged about some aspects of that here.

But most of all this shows that a large internal IT systems project can be successfully rolled out without a top-down process applied. Granted, it’s mainly down to the culture of the organisation, but I think the approach could be generalised into other businesses as long as all those involved are willing and able to take on the responsibility.