• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Ben Barden

Products - Projects - Process

  • Ben Barden
  • Home
  • Music
  • Weekly blogging in 2021
  • About
You are here: Home / Publishing / Rebuilding the post editor at City AM

17th October 2015 by Ben Barden

Rebuilding the post editor at City AM

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:

01-drupal-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:

02-new-post-editor

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:

03a-getty-search

03b-getty-image

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.

Filed Under: Publishing Tagged With: bespoke cms, cms, laravel

About the author

Web dev, bug finder, writer of niche music
Founder/coder at switchscores.com
Product Manager at Octopus Energy / Kraken Technologies Read More…

Primary Sidebar

benbarden

New music now on Spotify! It's a disco EP - well, New music now on Spotify! It's a disco EP - well, some of it. Search for GFD and look for this pic. Or use this link, but you'll have to copy it: https://open.spotify.com/album/04eiQOEeJZiOThpRyjm60w?si=gsRT8JHwQHeQFXIPqTyw_g&utm_source=copy-link
New disco/dance album, coming to Spotify etc in a New disco/dance album, coming to Spotify etc in a couple of weeks 😁🕺💥❤
I love this game. Very happy to have it on the #Ni I love this game. Very happy to have it on the #NintendoSwitch !
So much food, but it was good! So much food, but it was good!
What? You got up, it's not your seat anymore #cats What? You got up, it's not your seat anymore #catsofinstagram
Lots of snow! #uksnow Lots of snow! #uksnow
This was good! Nothing clever but 😁👍 This was good! Nothing clever but 😁👍
Watching Sophie Ellis Bextor on Graham Norton with Watching Sophie Ellis Bextor on Graham Norton with a band wearing animal masks/heads. A very 2020 way to round out a very surreal year. Great music, too! #HappyNewYear2021
Lunch was good today! Lunch was good today!
Guildford Castle, 25th Dec 2020. Merry Christmas. Guildford Castle, 25th Dec 2020. Merry Christmas. 

#loveguildford #guildford #guildfordcastle #christmas
Winter sun. Winter sun.
Sunday walk. Sunday walk.
Sunday afternoon walk. Sunday afternoon walk.
This year's #topnine ... This year's #topnine ...
#glutenfree beers 😁🕺 Oh hey, my latest musi #glutenfree beers 😁🕺

Oh hey, my latest music is now up on Spotify! Link in my profile!
New music coming soon to #spotify and most other o New music coming soon to #spotify and most other online stores. Release date tbc.

This is my 3rd release, containing 2 tracks: November Dawn, and Legacy Layers.

The tracks originally featured as part of my self-produced albums, Symmetry 1 and 2. Each track on Symmetry 1 has a companion track on Symmetry 2. These two are cut from the same cloth and are a kind of "trance guitar" style.

Newly-mastered for 2020, I think the music sounds nice and fresh. Maybe you'll like them!

Slowly building up my discography... you can find me under the name "GFD".
4pm. Must be November. 4pm. Must be November.
The #glutenfree way to have beer and Pringles. 🕺
Just arrive: Thirty years of #thedivinecomedy boxs Just arrive: Thirty years of #thedivinecomedy boxset 😁 this should be good. I've been a fan since 1996, and know the albums well. But I've missed loads of B-sides - and I know there are plenty. This set is a huge collection of music and will take some time to get through fully!!
Coffee time! Coffee time!
Load More… Follow on Instagram

Recent Posts

  • Posting on Medium
  • 4 tips to get your in progress column moving
  • Navigating estimates and due dates in Agile
  • The Agile board should reflect reality
  • Why personal projects are worth pursuing

Archives

Categories

Handcrafted with on the Genesis Framework