11.2 Updating Updates and Corrections

Not only can we tell people what’s new, but we can (and should) tell them what we’ve gotten wrong. I’ve noted in earlier chapters that a key part of transparency is telling our audiences about our mistakes and fixing them quickly—but that’s not all we can or should do.

As we update our baseline stories (and anything else we publish), we can show our audience what’s changed. Scott Rosenberg, author of several books about the Internet, is among several people to suggest that a software industry technique called “versioning” become a normal part of journalism.

Scott, a friend who has worked with me on several projects, started pushing this after Politico. comexcised a highly relevant tidbit from a story and then pretended that what it had removed—an admission of how insider journalism, Politico’s stock in trade, actually works—wasn’t important in the first place. He wrote:

Any news organization that strives to present a version of reality to its readers or users must come to grips with the fact that reality is always changing. Print publications have always taken daily, weekly or monthly snapshots of that reality, and everyone understands the relationship between the publication date and the information published under it. Radio and TV offer a closer-to-live reflection of the ever-changing news reality, but until the Web’s arrival their content was so fleeting that the new update pretty much obliterated the old version of any story.

The Web changes all of this. It is both up-to-the-minute and timeless—ephemeral and archival. This offers newsrooms a fundamentally different opportunity for presenting timely story updates while honoring and preserving the record of previous versions. Sadly, not a single news organization I’m aware of has yet taken advantage of this opportunity.

The nearly absurd irony is that journalism organizations already do this—internally. Every editing system of any sophistication saves copies of previous versions of articles or other content. What none of them do, save Wikipedia, is to give the audience access to all previous versions. Like Scott Rosenberg, I consider this a no-brainer that nevertheless will take years to catch on, if it ever does.

If you have a WordPress blog or a Drupal site, or have created a wiki using the standard MediaWiki software, you’re in luck. There are plug-ins (or modules, which are essentially the same thing) for WordPress and Drupal that will expose your changes the way Wikipedia does.

What none of these do, however, is give you the best kind of view into what’s changed. If you use Microsoft Word and collaborate on documents, you’ve already seen the “Track Changes” feature that gives you a great view into what’s changed (and who’s changed it, in collaborative settings). What we need most is a Web-based Track Changes feature—and, beyond that, a way to see how documents have changed over time in a more visual way. There’s a terrific opportunity here for Web developers.

A related issue is corrections, which after all are one of the ways we update our work (assuming we’re honest about correcting our mistakes). In Chapter 8, when I said what I would do if I ran a news organization, I wrote about creating a service to notify online readers, should they choose to sign up for it, of errors we’ve learned about in our journalism. Users of this service could choose to be notified of only errors we deemed major, or all errors, however insignificant we believed them to be.

While I’d offer this service for more general updates as well, it strikes me as especially critical for mistakes. By implementing such a system, we could help prevent new viewers from seeing incorrect information. We could also do our best to ensure that people who read incorrect information will learn that it was wrong—and that we cared enough to fix our errors.

Jack Shafer, Slate.com’s media writer, has been offering this service in a technically crude way for some time. At the bottom of his column you’ll find this offer:

Track my errors: This hand-built RSS feed will ring every time Slate runs a “Press Box” correction. For e-mail notification of errors in this specific column, type the word Harman in the subject head of an e-mail message, and send it to slate.pressbox@gmail.com.

See? This isn’t all that difficult!

Leave a Reply

Your email address will not be published.