Editing on the Web: We’re Using the Wrong Tools

A plea for newsrooms to work together to build open-source copy-editing solutions.

By Ernie Smith

On the grand scale of public disasters, the New York Daily News’ embarrassment involving writer Shaun King, an editing process that involves copying and pasting emails into a CMS, and an awkward removal of attribution, certainly wasn’t the worst thing to happen this week.

But still, I find myself wincing. Because I know that, if the considerably massive New York Daily News is struggling to figure out the best way to efficiently handle copy in the digital era, they’re far from alone.

It’s frustrating that as a news culture, we’ve largely failed to crack that nut — a common problem that probably is being felt in newsrooms of all sizes. Instead of working in one app, we’re working in five. Instead of being able to auto-populate copy where it needs to go, we’re having to copy and paste it, repeatedly. And fixing the formatting errors that arise is a sunk cost — a waste of everyone’s time that could be solved if developers worked on ways to prevent those errors in the first place.

My solution, as I posited in a comment on a Max Read piece in New York Magazine, is that journalists should get comfortable with Markdown, a lightweight scripting language that works as a subset of HTML. Instead of writing a <h1> tag, you simply write a # at the front of the line. You bold and italicize using various combinations of * symbols. You link stuff using [brackets](http://link.goes/here/). And so on.

But the problem I see is this: This solves the problem for writers, but it doesn’t solve the problem for editors, who often face the cumbersome task of copying and pasting numerous times just to get the dang article into the CMS. Microsoft Word and Google Docs each have excellent track-changes capabilities, but their reliance on rich text formatting ensures that, when you’re trying to push this code through the system, odds are the formatting is going to get messy.

And plus, these tools are built for an approach that assumes the end path for the document you’re writing is an 8.5" by 11" sheet of paper. Shaun King and his Daily News colleagues were writing and editing so fast that printing probably wasn’t even an option, and the extra stuff that comes with writing in these tools — the rich text, the line spacing, the awkward way Word handles links — just gets in the way.

Startups that are working to solve this problem are few and far between, and the ones that do exist are either out of reach for small newsrooms or focused on the wrong things. There have been a couple of startups that have nailed down the problem pretty effectively, but they both got acquired:

The startup Editorially was offering a bold product that used a lot of simple visual cues to help writers and editors through the process of going through a story. It was vibrant, and easy to use. And it had an impressively stacked staff, many of whom were associated with the critically-acclaimed A List Apart and A Book Apart series. In my own newsroom editing process, I used this tool so much that I think I overloaded their servers a couple of times. But when asked for them to allow my company to pay for it, I was told they’d get back to me in a couple weeks. Soon after that, they announced they were shutting down. Later on, they moved over to Vox Media, where I’m sure they’re doing awesome things.

Another tool, Poetica, had an equally interesting editing model. They approached editing in much the same way that you would on a sheet of paper. If a copy editor was looking at your page and wanted to make a change, it showed a visual strikethrough that looked like it came from a pen. At first, this approach was a little too playful — a copy editor whose opinion I trust found the focus on visual cues a bit much. But eventually, they found their balance, and made it into a plugin that was compatible with WordPress. Their story ended very similarly to that of Editorially; their technology was picked up by Condé Nast, where it’s expected to be integrated into the company’s internal CMS, copilot.

There is a startup out there that I think has gotten closer than most, called Camayak, and it built its name working mostly with student newsrooms around the country. It doesn’t use Markdown, but it has done an admirable job tackling the workflow issue that Shaun King and company ran into. The cost of the product, however, might be tough to swallow for smaller newsrooms. But they survive, in part, because they’ve properly priced the product for larger newsrooms.

(For what it’s worth, my copy editors work with me on the Nathan Kontny’s excellent app Draft, but that has some concerns as well — it’s not super-scalable to multiple editors, and while the app survives for now, Kontny himself has moved onto Highrise, so it doesn’t appear that he’s actively working on it.)

The world of open source has actually come up with something of a solution for the raw editing problem — an Markdown extension called Critic Markup, which allows for notes to be added, deleted, and approved using a lingo that’s compatible with the way Markdown works.

But it’s not a perfect solution by any means, and solves only one part of the problem — ignoring the larger workflow problem. We need to ensure that editors are able to work faster and more efficiently, and aren’t bogged down by hundreds of emails a day, just trying to get stuff moved over.

There are apps that have solved some of these problems while attempting to solve others, like the collaborative word processor Quip, which was built as a way to encourage people to work together, rather than to copy-edit. It has potential, but it’s not all the way there yet.