One of the fundamental principles we lived by throughout the process of redesigning the ITV News website was that we needed to ground what were doing in the real needs of users. Cath explained our approach in an excellent post a few weeks ago.
All too often on content management projects a very significant group of users are taken for granted: those who will create and manage the content. On this project, we were detemined that we would really try to understand the editorial experience in depth, and provide tools that fit the journalists’ requirements.
We started with a fascinating and intense day in the ITN newsroom with Jason Mills and his team. We were allowed to attend the morning editorial conference and busy journalists tolerated our interruptions and stupid questions throughout the day. Finally, we were allowed to have a nose around in the studio and then watch the ITV Evening News transmission from the gallery.
Alastair Stewart in the ITV News Studio
Cath, William and I tried to run a couple of live blogs using the prototype we had made, which at that time was very limited. Cath ran a blog dedicated to the government’s press conference on the NHS “listening exercise”, while I ran a general news blog and William focused on Royal Ascot.
In doing this, we learned a great deal about how a busy newsroom works, but more than anything we found that running a live blog was an incredibly intense and difficult thing to do well. We were absolutely convinced that we couldn’t just take a standard CMS off the shelf and give it to the journalists. It was essential to create tools that were tailor made for the newsroom rather than the other way around. While the journalists would need to learn how to cover rolling news in a digitally native way, we needed to figure out how to make the publishing process as painless as we possibly could.
The bewildering sensory assault that is a TV gallery
The prototyping we did was key to learning about what tools were required, but just as vital was watching the journalists using the prototype tools and learning from their experiences. We were encouraged to find that they liked using even the crude tools that we had created for them at this point better than the ones that had been used to using for their existing site.
One thing that we were all agreed on was that none of us had ever used a web-based CMS that we liked. One of the reasons for this is that the browser-based WYSIWYG editors built into CMS products are like mini word processors shoved into the page and are consequently terribly difficult to use. Moreover, they’re technically ugly and often don’t generate properly structured data.
We also agreed that many liveblogs felt like they had been shoehorned into an existing CMS and page templating system, which apparently explained why none of them felt truly satisfying as user experiences. Given that live coverage was at the heart of our new proposition, we were determined that we would make a first-class liveblogging platform rather than repurpose something else.
We wanted to make it incredibly easy to bring in content from around the web, particularly from Twitter and YouTube. We also wanted to make an efficient way to prepare and use images. Luckily, we were able to target only modern, HTML5 compliant browsers like Chrome and Firefox, so we weren’t forced to compromise on features because of an obsolete corporate browser standard.
We decided that we would create two key editorial tools: a drag and drop rich text editor and a browser-based image cropper, which would be tightly integrated with each other.
The Image cropper before any content has been uploaded.
Content items are made up of “blocks”. There are a number of supported blocks: text, image, video and tweet. You can reorder the blocks by dragging and dropping, and add new ones by clicking an icon. It’s a very stripped down interface compared to most of the CMSes I’ve seen.
The image cropper with an image uploaded, ready to zoom and crop.
We were equally concerned to make sure that we stored the content in a display-neutral and structured format. In the past, this would automatically have meant XML. Browser-based editors usually emit HTML, but we felt that doing it that way encourages you to forget the display-neutral angle and it becomes increasingly difficult to support non-HTML platforms in the longer term.
Instead, we chose to store the text data as Markdown, a very simple format for structured text content that does not presuppose a particular display technology. We convert the Markdown into HTML at the front-end for the website, but we remain free to generate other formats in the future for other platforms.
A detail of the text editor with a tweet inserted and the block selector below.
The Markdown is wrapped in a JSON structure, which we chose for its simplicity, native browser support and relative brevity. This means that we can also store other kinds of structured data such as the data for a tweet or YouTube video in their native form. Each block is represented by an entry in the JSON produced by the editor, which can then be independently reasoned about in code.
Starting in January, we ran an internal alpha in which journalists from around the country used the software to publish news using the new tools in a sandbox environment. This gave us the opportunity to learn about how they were using them, to improve the workflow and also to catch some nasty and subtle bugs before going live.
The result is an editorial experience that lets journalists spend their time finding and creating good content rather than fighting with their tools. Uniquely in my experience, the editorial team are enthusiastic about their CMS.
Of all the things we achieved with this project, I think I’m proudest of the work we did to create these tools. Special credit for this work belongs to Andrew and Andy who conceived of and worked tirelessly to perfect the implementation.