How one newspaper rebooted its workflow with Google Docs and WordPress

How one newspaper rebooted its workflow with Google Docs and WordPress

Goodbye clunky CMS. Hello low-cost agility.

by Jenn Webb | @JennWebb | +Jenn Webb | Comment | 30 June 2011

Bangor Daily News Google Docs Digital media not only forces newsrooms to face economic challenges, but also workflow issues. In a recent post, Todd Benoit, director of news and new media at the Bangor Daily News addressed the root of the workflow problem in his newsroom:

Like many newsrooms, until very recently we were production heavy because we had to be. Moving stories to the web was a copy-and-paste affair, but that's not where the trouble started. If you begin with a print-directed front-end system, as we did, how does that system accommodate a story being updated from the field? Or how would the full possibility of story assets land online, to be chosen among for print? Even simpler: When do reporters add links? The answers, as countless journalists know, are: It can't; they won't; they don't. From there, it's all production, not creation.

The Bangor Daily News attacked the problem head on, incorporating Google Docs and WordPress into a new front-end system that handles the flow of news in the digital era. As Benoit describes the solution:

... the guiding ideas we have put into practice are to match the tool to the job we need done (rather than the reverse), reduce the number of steps required and anticipate how our audience will want the information next. And the cost should be next to nothing.

To find out more about how the project came about and how it works in practice, I reached out to William Davis (@williampd), the online editor at the Bangor Daily News and the architect of the new system.

Our interview follows.

How did you end up gravitating toward a Google Docs / WordPress / InDesign system?

William Davis: My boss [Todd Benoit] has a great post on our dev blog on the topic, and I talk about it a bit on one of my blog posts as well.

We picked Google Docs purely for its ease of use and its collaboration tools. We wanted a place where reporters could work on their articles easily from wherever they are — we have quite a few bureaus, and our reporters often file from events. The collaboration tools are terrific and have really proved useful, for example, when we're editing articles on tight deadlines or when reporters are working on stories together. On Election Day we had three reporters at different campaign headquarters all working in one doc, and it went very smoothly.

We chose WordPress because we wanted a content management system (CMS) that allowed us to develop components quickly and easily. WordPress has a great API and it's very extendable — we've been able to easily change pretty much any part of the CMS without hacking the core, which allows us to maintain the integrity of the system.

Both systems are quickly evolving and pushing boundaries in their fields, without any prodding from us. WordPress has frequent updates that push the platform to a new level, and Google Docs' collaboration tools, for example, are second to none.

Finally, we chose InDesign because it is the industry leader in page design software.

TOC Frankfurt 2011 — Being held on Tuesday, Oct. 11, 2011, TOC Frankfurt will feature a full day of cutting-edge keynotes and panel discussions by key figures in the worlds of publishing and technology.

Save 100€ off the regular admission price with code TOC2011OR

What was involved in developing the system?

William Davis: We started development in August [2010] or so, and it's still ongoing. We launched things on a rolling basis by department, and started with sports, which turned out to be the hardest because it's the most complex. We then rolled out politics in time for the elections. We got the entire newsroom using Google Docs early this year.

The display desk transitioned to InDesign in April, and then earlier this month we finished the website transition and turned off our old systems. As we developed the components needed for each department, we would move them over, test and tweak things, and then move on to the next department.

What are some of the major challenges you've encountered?

William Davis: We've had a few instances where Google has changed the way they structure their content in Google Docs or changed the way a part of the API works and we've had to adapt. We've also faced the usual technical problems that come with hosting any large website, but we haven't really encountered any challenges that we weren't able to solve fairly quickly.

Some components we've rebuilt a few different ways and will probably rebuild again. The wire feeds are an example. Those were originally running directly into WordPress. We decided we didn't want to put the strain of tens of thousands daily stories and photos on our website and so we tried running the wires directly into Google Docs. We encountered problems there, as well. I`n the third iteration, which we're using now, we have a separate script that ingests the wires and provides a way to browse them, then sends the stories we want into Google Docs. That's worked pretty well, though that's not to say we won't rebuild that component or others in the future as needed.

The great thing about building our own system is that we can tailor it to our needs. Because we're doing it all in-house, we can change quickly, rather than waiting for a corporation to adapt with us.

Was it difficult for people to adapt to the new system?

William Davis: With a transition to any new system, there are of course going to be problems, but I think the ones we've encountered have been pretty minimal. Reporters seem to have had a pretty easy time adapting to writing in Google Docs — many of them, especially bureau reporters, were already using the system to write their articles. They understand why it's important to move content quickly through the system so their articles have the best chance to succeed online.

Can you give us a walk-through of the publishing steps involved — from story idea to final web and print versions?

William Davis: Reporters start their stories in Google Docs, and when they're finished, they drop them in a folder for their section — Metro, State, Business, etc. Editors read the story and move it on to a copy editing queue, where a digital desk editor reads it before sending it to WordPress.

In WordPress, the digital desk editors will categorize it, attach media such as photos and video, and then they will publish the story. This is done throughout the day — we have digital desk staff on from 5 a.m. until midnight. When the display desk comes in to lay out the paper, all they have to do is find the story in the InDesign plugin we built and bring it onto the page.

Everything comes onto the page fully formatted, though the digital desk is responsible for writing their own headlines for print. They can do this either on the page or in a module I built for WordPress that provides a WYSIWYG headline-writing interface.

Davis offers a tour of the new system in this screencast:

How many people actually touch the copy before it's published?

William Davis: As is the case in any newsroom, that varies by article. The digital desk editors, in addition to being copy editors, sometimes act as backfield editors, such as on the weekend. Other articles are seen by four or five editors before they're published. In general, though, articles go from reporter to assignment editor to at least one digital desk editor before being published.

How much manual labor is involved?

William Davis: We've managed to do away with pretty much all manual labor. Previously, all stories were written in our print CMS, and the web staff was responsible for copying and pasting the story into our web CMS, finding and adding links, writing a web headline and, quite often, doing that multiple times for the same story after it was updated. The copy editing was all print-centric, so at the end of the night, most of the stories would need to be updated. Now there's no copying and pasting — everything flows from one step to the next.