Skip to Main Content

Building an Editorial Platform for the Forgotten User

Posted on 9.04.2013

:: By Matt Murphy, Director of Client Services at Ashe Avenue ::

Editor’s Note: In a “content is King” era, brands are building editorial teams and content management systems (CMS) with little to no experience to rely on. Despite this, their content/media-heavy sites require custom editorial platforms. Ashe Avenue, a boutique Web development agency in Brooklyn, N.Y., explains the disconnect between developers and editors who will actually be using the CMS on a daily basis and provides tips for developing a CMS.


Some of our biggest clients (AOL, High Times and Vice) all had one thing in common when they came to us – an abundance of disorganized online articles, photos and video. As a result, we’ve learned a lot about building content management systems (CMS) from the ground up. One important lesson we’ve learned from our client work is this: When developing a CMS, don’t forget to accommodate for the most important user – the editor.

The disconnect between editors and developers isn’t secret. Editors hear “CMS” and think about the program they use to publish a story; developers hear “CMS” and envision lines of code.

Hoping to bridge the gap, we met with industry friends from CNN, Huffington Post and the Daily News for a roundtable discussion on their editorial platforms. We had a conversation about the good, the bad, and the features they feel every editor should have access to in a CMS. We learned a lot, and hopefully any developer or designer reading this can gain some insight on how to approach CMS design.

The Process and the Pain

Prior to the discussion, we were interested in hearing about the step-by-step process of posting a story. How many people are involved? Who has access? Where does the process become muddy?

After much discussion, Gersh Kuntzman, Daily News deputy managing editor, summed it up with one sentence: “There’s just too many steps to get a story up!”

The Daily News has more of a “traditional” newsroom setup, compared to the Huffington Post and CNN. While the Daily News made the transition from print to Web, the CMS is lacking in certain areas.

A CMS needs to feel OK to the old school editors. As outlets like the Daily News continue to smooth the transition going from print to digital, processes are being grafted on to the old system, and aren’t necessarily editor-tested and approved.

For the Daily News, problems begin as soon as a story package is created. There’s no alert system to get the editor, reporter and photo desk on the same page, so this adds additional steps from the get-go. Editors are also unable to create or edit any graphic element within the CMS, so the photo desk is responsible for cropping and inserting photos with captions into the package at some point before it goes live.

When it’s time to go live, the graphics and associated text are pretty much surprises for the editor. Photos may need additional cropping, and captions may need to be re-written by the editor, depending on Web layout. Even embedding hyperlinks and video requires an editor to backtrack after a story gets posted to insert them correctly.

Other problems within the CMS include inefficient archiving/search features to access story packages; the lack of an effective messaging or chat feature to communicate; and difficulties linking up related or sidebar content for a story.

When it’s all said and done, the process could take up to 10 steps to get a story live on the site.

For an organization the size of the Daily News, their workflow is extremely inefficient. Much of the burden falls on the editor to publish an article, and there isn’t a tremendous amount of Web support to assist, or incorporate a change that may be requested.

The Huffington Post and CNN, by comparison, work slightly differently.

The Huffington Post began on the Web, with a CMS designed by former editors. This led to the implementation of an editor-centric publishing tool and, as a result, they actually enjoy using it. From cropping graphics within the CMS to real-time metrics for posted stories, it’s a pretty intuitive platform.

On the other end of the spectrum is CNN, where the reporter we spoke to doesn’t work in the CMS at all. He views it as an end-point and just copies and pastes a completed text document into the CMS once he’s done with the story. He prefers the Microsoft Word features that aren’t incorporated into the platform (auto-correct, look-up features and standard Microsoft tool bar, for example). The primary reason, however, that he didn’t have much contact with the CMS is simple – he didn’t need to. CNN is big enough to employ a dedicated staff responsible for taking a story and guiding it through the CMS with minimal reporter or editor involvement.

Not altogether surprising, we learned that the three different outlets have three different processes for publishing a story. This may be the case with every website, but we found that all of our guests have encountered similar CMS pain points throughout their journalistic tenures.

In no particular order, here are the general gripes the editors have encountered:

— Asset servers and the CMS don’t interact seamlessly.

— Including photos can add multiple steps to posting a story.

— Custom graphic features (slideshows, collages) can’t be edited within the CMS - a separate team handles this.

— Story or asset archiving can be messy, and not user-friendly.

— Messaging systems within a CMS don’t work well, forcing newsrooms to turn to email or a third-party service.

— Ineffective tracking systems for story edits/updates.

— Unnecessary categories and sections that create a confusing layout for the editor.

— Requested development changes for the CMS take a long time to implement (if they happen at all).

Finding the Sweet Spot

The main thing we learned after talking to our guest editors, and our clients, is that there isn’t a one-size-fits-all solution when it comes to developing a CMS. The best approach is to listen to the specific needs of the editorial team and strive to meet those needs. While we don’t have a magic bullet solution, we like to think that being responsive and introducing iterative changes and improvements is the best way to build a successful CMS.

Based on our experience, we’ve compiled a few tips to consider that should keep the editors happy and the content flowing:

Merge systems: Many news entities have an asset management system outside of their CMS. For a company starting from scratch, or lacking a large amount of archived material, two systems aren’t necessary. Incorporate everything into the CMS.

Photo editing: The most popular stories on the Web are photo galleries. Everybody loves a slideshow or a best-of story. Give the editors the ability to easily edit and publish photo galleries, collages or slideshows within the CMS. The advertising team will thank you.

Digitize the news desk: Most CMS are built around multiple people writing or compiling story packages, but they don’t give the editor a dashboard view of the workflow. Adding a “news desk” feature provides a high-level view of content in its various stages. This allows everyone to work within the same system as assignments are updated and approved.

Proper tracking: For posting updates or follow-up stories, if there isn’t some type of threading system built into the CMS, there’s no easy way to link related content to a current story. Take the burden off the editor by allowing them to add the story to an existing thread, or create a new one. If an editor doesn’t have easy access to related content, there’s a good chance he won’t take the extra step (or three) to integrate it.

Again, every outlet has different needs, but understanding the editorial process, and the specific needs of each team, is the first step to building a successful CMS.

Leave Your Comment

Login to Comment

Become a Member

Not already a part of our community?
Sign up to participate in the discussion. It's free and quick.

Sign Up

 

Leave a comment
    Load more comments
    New code
  •