Don’t Force a Concert Pianist to Write Music on a Ukulele

Surveying the tools and frameworks that our team members like to use, we found that our editorial team’s developers and designers were using command line tools and static site generation frameworks to rapidly prototype and develop the code that would go into our editorial features and news apps.

Unfortunately, when it came to getting that code into production, a lot of copy/pasting and code massaging had to be done to make the final pieces come together. In some cases new code had to be written just to get the story published.

To overcome this, we built out a system that allows our designers and developers to use tools and frameworks they are fluent and expressive in so that they can focus on ideas and leaps of imagination rather than workarounds.

We call this system the Editorial Apps System (naming things is hard) and it leverages local development tools like Middleman and Compass to facilitate speedy prototyping and build-out as well as Git and Github to facilitate collaboration and review. Taking a page from Heroku, it uses post-receive hooks to make the deployment process to our production Chorus servers as simple as doing a git push.

With this system, folks can build out the code for a story or news app using the tools they are comfortable with and are most expressive in—and they can easily deploy the project to production with confidence that there will be 100% fidelity to what they designed and developed locally.

Our first experiments with this system turned out great, but there was an important aspect of news app development that the system did not handle well…

If You Can’t Get Everyone in the Same Room, Get Them in the Same Doc

In the process of writing this post I have made approximately 11,000 edits. Imagine how many copy changes four or five writers or even several dozen writers might make. Initially our Editorial Apps System did not facilitate the incorporation of copy at all, much less the incorporation of copy edits. This turned out to be a big problem because tons of time had to be spent manually plugging copy into pages, making copy edits to those same pages, forgetting which pages were updated, accidentally overwriting those changes, and then muttering profanities about life, the universe, and everything. All this time shuffling paragraphs around and muttering is time not spent making pages look lovely or words ring true.

To overcome this, we incorporated facilities that allow folks to write their copy and edit their data using Google Docs and Google Spreadsheets. The Editorial Apps System makes use of the Google Drive API to synchronize changes and allow copy and data to be easily incorporated into the design.

Our first experiment with this process was the The Verge 50. In this project, the copy, data points, and categorization about each person was managed via a series of Google Spreadsheets. In an upcoming project about the NFL Playoffs we will be using the same process to manage the bracket, preview, recaps, and data points—all from a series of sheets within a Google Spreadsheet document.

With this in place, rather than being bogged down by having to send and respond to copy edit changes via email and IM, editors, developers, writers, and designers are freed up to focus their time on important matters—like debating who should be in the top ten, trying out that new font, or making vim (> emacs) bindings work for navigation.

Rube Goldberg Machines Are Bad, but Rube Goldberg Machines that Require Many Emails Are Worse

Liberating editorial teams from tedium has long been the objective of folks who build workflow systems for newsrooms. But the circle of creative folks that contribute to a story now includes developers and designers and even sysadmins, so it make sense to foster their creativity as well by removing tedium, facilitating collaboration, and catering to their means of expression.

This means building out tools that may feel like a Rube Goldberg machine (as our Editorial Apps System sometimes does). But building out Rube Goldberg machines is fun, and making them more efficient is an interesting challenge—and if all of this contributes to better storytelling and a delighted or more informed audience, then it is certainly worthwhile.

It is worth noting that building out templates, command line tools, and git workflows for developing and deploying news apps is nothing new. And neither is using Google Spreadsheets as a data source. The NPR News Apps team not only produces innovative news apps and stories but also publishes a great blog and working code. The tools and techniques that have accumulated around the Data-driven journalism concept have also produced useful resources.

Channeling the Creativity and Energy of Technology Teams Is the Key to Not Going the Way of the Dinosaur

Working in a newsroom these days really does feel like the early days of terrestrial life. There is a whole new environment to explore, whole new appendages and organs to discard or evolve into more useful forms, and all sorts of crazy ideas to try about how best to get around. A lot of the time it may seem that newsrooms are merely flopping about in the mud using misshapen flippers for feet, but it’s exciting to think that all the creativity and experimentation being brought to the newsroom by the inclusion of technology and design teams could lead to same kind of evolutionary leaps that brought about wonderful things like flight and the human brain and pizza delivery.