When I joined City AM, one of the first things I experienced was the post editor. It did the job, but it was not particularly quick or intuitive to use. We had to add new fields in a predefined way – and doing so usually added extra work for the content team. Plus, there were a number of tasks that had to be done outside the system – such as finding and resizing images from Getty.

I knew we needed to take a radical approach and consider scrapping the existing post editor.

Why we decided to rebuild

For a web publisher, the post editor is the most important screen in the whole of the CMS. Due to its importance, you can’t screw it up. And due to how much it does, it’s no small task to rework.

I’d been saying “this will be possible in the new post editor” for some time, whenever we tried to do things that weren’t possible without totally rebuilding parts of Drupal core or rebuilding modules. Ultimately, it reached the point where continuing to use Drupal was holding back what we wanted to do with the CMS. It was at this point we decided to start building the new post editor (we’d already done almost all of the screen designs).

We wanted to move it onto the web framework we were already working into other areas of the platform. We wanted to make the entire publishing process much more user-friendly than the existing platform allowed. We wanted complete control over the post editor UI and its workflow. And we wanted to make it responsive. Rebuilding would give us the best opportunity to do all of this, while also cleaning up the underlying code.

Reviewing the old post editor

Below is a screenshot of the old post editor:

We reviewed every aspect of this screen with the content team. What were the pain points? Could we drop some of the fields, or hide them if they weren’t used often? Could we reorder the fields or improve the layout to make it easier to use? Where were errors occurring? Where was time being lost?

Once we understood these points, we started by designing the new screen. We designed versions for desktop, tablet and mobile – as the existing screen did not work well on anything except desktop. We went through several iterations before we started building anything.

The final design

The new post editor looks like this:

While the layout is not radically different, we cleaned up a lot of the UI, added inline error messages, added a sticky sidebar, added a word count and character counts for a few of the fields, and totally reworked the image section.

Five of the biggest benefits

Reordering, adding or removing fields wasn’t a huge challenge, and we could do this in the old post editor. However, there were a few things that proved very problematic until we did a full rebuild. These included:

1. Getty integration

Previously, a reporter had to login to Getty directly, find an image, save it, resize it in an image editor, and upload it.

We totally refined the process by adding a way to search Getty without leaving the post editor. Selecting an image automatically downloads and crops the image (if needed). A huge timesaver, and a major reason why we went with a full rebuild.

Screenshots:

2. Automatically filtering pasted content

Many writers prefer to use third-party tools such as Google Docs, Microsoft Word or others to write their content. In an ideal world we’d suggest everyone writes directly into the post editor – but it can’t hurt to have a backup in case anything goes awry.

The issue with using other tools is that when you paste into the post editor, a lot of junk formatting can come with it. You can ask reporters to paste into Notepad first, or to use “strip formatting” – but this adds an extra bit of manual effort to every story, and it’s easy to miss doing it.

We initially stripped out all formatting but allowed line breaks when pasting into the editor. However, we tweaked this recently, as it meant even if you copied and pasted within the editor itself, any formatting such as bold, italic, hyperlinks etc was stripped out.

3. Solving issues with scheduling

The old post editor made use of a couple of Drupal modules that enabled drafts and content revisions (Workbench), and scheduling (Scheduler). The combination of these two plugins, along with some custom code that fires whenever a story is created or updated, meant that scheduling was seen as unreliable.

We built a reliable way to create new versions of content, and also schedule a story to go live at some point in the future. Reporters can now use the scheduling feature and be confident in its ability to work correctly.

4. Built-in Varnish integration

We actually did most of this work in the old post editor, but it’s an extremely important feature for us.

When a story is updated, the old version will be cached for logged out users for a period of time. Drupal attempts to solve this by clearing its own cache – but as we also cache in Varnish, logged out users will see an old version of the story.

We initially built a tool where reporters could paste a URL into a screen and the Varnish cache would be cleared. Later, we added a cache clear that happens automatically when a story is updated.

5. Responsive interface

We designed the new post editor to work well on tablet and mobile, not just on desktop. It works a lot better than the old post editor, which wasn’t designed to be responsive.

How we reduced risks

Building big, new functionality can cause teething problems during production. Here are a few ways we minimised the number of issues that occurred when we went live.

1. Talking to the content team first

As Head of Technology, I lead a team of design and development experts. We’ve designed and built a lot of functionality in our careers. However, we aren’t the ones who use the post editor day in, day out. We can’t just shut ourselves away and emerge after six months with a perfectly-formed, shiny new post editor.

So the first thing I did before any work was undertaken was to talk with the content team. This wasn’t a quick, one-off meeting. We had multiple sessions where we discussed the post editor at length. It’s also not a process that ever really ends. Keeping the communication flowing has helped us to add in a few tweaks after the initial launch.

2. Early reviews of screen designs

Once we had all the requirements, we designed how the screens would look. After reviewing these within the tech team, we started sharing them with the content team. We tweaked and improved the designs until we were happy.

This doesn’t mean we acted on every bit of feedback we received. In some cases, people had different views. We collated all of the feedback into a set of clear, coherent designs.

3. Focusing on the critical path

When we reached the build stage, we did it in a way that allowed us to submit parts of it for review quite early in the process.

We focused on getting a usable screen in place with the bulk of the core functionality, even if not everything was complete. This allowed us to start testing much sooner – a very important thing to do when there is a lot to test. We mostly identified small UX tweaks at this stage, but it meant some of these could be done before the screen was considered feature-complete.

By the time we approached the end of the build stage, most of the major issues had already been resolved.

4. User testing

Once internal QA had approved the bulk of the tickets in the list, we involved members of the content team to test on our staging area. We got a lot of feedback this way, and were able to address most of it before we went live.

5. Staged rollout

To minimise impact on the content team, we didn’t switch everyone to the new post editor on day 1. Instead, we gradually added users over a period of 2 weeks. This reduced the number of users reporting the same issues early on. It also meant that as new users were added, early adopters could help them get up to speed – rather than the tech team being the only point of contact.

What’s next?

We’ve never thought of this as something to build and forget about. We have lots of small things we’d like to tweak and improve, and some bigger things to add in later. There’s also other areas of the CMS to work on, and unrelated projects we can now plan out.