I researched what was preventing our editorial team from truly adopting a “digital first” workflow and facilitated the creation of Observer’s first open source plugin.
The Problem
Observer’s newsroom had long ago adopted a “digital first” motto but the day-to-day publishing schedule was still largely dictated by the production of the weekly newspaper. After a few interviews with editors and writers, we determined this was in large part to blame on the publishing tools in use—mostly a content management system designed for print publication cycles rather than the frequent publishing demands required of digital news outlets. The process required editors to file stories in one program, alert the print designers that the stories were ready for layout, and then extract copy from print galleys after the stories had been cut and formatted to fit the constraints of newsprint to paste into the WordPressWordPress wordpress.org post editor and prepare to publish online.
Not only did this make the content on Observer.com feel delayed, but pasting copy from tools these tools often led to messy HTML formatting. Not to mention the entire process was filled with unnecessary redundancies which in a small, time-strapped newsroom can distract editors and writers from doing what they do best—developing beats and writing stories.
Research
After mapping the current workflow with editors, we brainstormed how we could reduce the time between a reporter filing a story and when that story was posted online. One glaring delay was the copy editing stage. In the current workflow, the copy chief couldn’t sign off on a story until the copy desk had approved the story as a print galley even though much of the copy edits after the story was submitted to the print designers had to do with copy fitting—something that wasn’t an issue online.
Another issue was the amount of copy-and-pasting the writers were doing to move their story through the print process and eventually online. Each had to paste their story from whatever word processing application they had initially wrote it in to to a program where it could be copy edited and then they had to copy the story at the end of the process and paste it into the WordPress post editor. Along each step, the copy would pick up odd formatting tags from each piece of software it was extracted from and editors often had to spend time re-doing formatting once the copy finally made it to the post editor.
The Solution
I coordinated a simulation of the current system which allowed us to brainstorm new workflows that would allow the copy editors to sign off on a version of the story that could be used online. The idea was to do all editing in WordPress so editors and writers could continue working on stories no matter the print schedule and all formatting would be done in the post editor.
We created a plugin that allowed editors to create sections and track where and when stories would be published. The plugin also allowed editors to update the status of each story so the copy edit team would know when a post needed their careful eye or a writer could see when a post was ready for them to review.
After a post had been copy edited and approved, final formatting could be completed in WordPress and the status changed to alert the print production team that the post was ready for layout. The designers on the team could export the post from WordPress, import into into their print templates and map the html formatting to print styles. The post status would automatically update, alerting the writer to take one last look before scheduling the post to go live online before the final print product was finished.
Read more about how we released the project as open source code.