6 min read

News articles shouldn't be static

But news sites need software to make revisions transparent by default.
News articles shouldn't be static

I'm an independent journalist working to create a new kind of news organization. In Rethinking News, I explore the state of the news business and ways to make it better. Please support the project by subscribing. It's free.

The Save Journalism Committee is a newsletter by Jeremy Arnold that highlights problems with conventional journalism and explores ideas for fixing those problems. In a post on Friday, Arnold offered four principles for better journalism. I was particularly interested in his first idea: that news articles shouldn't be static.

This was an idea we tried to execute when I was at Vox between 2014 and 2017. Our efforts were hampered by a lack of software support, but I continue to believe it's a good idea.

If you go to any Wikipedia page, there's a link in the upper right that says "view history." There you can see a list of every revision of the document going back to the time the article was created, and you can compare any two versions to see what changed. Each revision is supposed to have a brief summary explaining what was changed.

I think that every news article on the web ought to have a feature like this. It would improve the way news organizations handle corrections and how they cover breaking news. It would also allow journalists to work more efficiently by re-using background material across multiple articles.

Better corrections

The most obvious benefit of Wikipedia-style versioning is that it could improve the way news organizations handle corrections. It's standard practice for online news sites to append a correction notice after fixing an error in a news story. But these correction notices are simultaneously too conspicuous and not transparent enough.

For minor errors, most readers don't care that the article has changed—they just want to read the correct version. Because of this, most news organizations are selective about which changes are significant enough for a formal correction notice. Very minor mistakes—like spelling errors—get fixed without a formal notice.

But there's an obvious danger of abuse here. Reporters and editors are tempted to classify embarrassing mistakes as minor ones to avoid having to publicly acknowledge that they were mistakes. Of course, that sometimes backfires when people notice and perhaps even keep screenshots of the original article.

For example, Vox recently got some negative attention recently for retroactively editing an article about the coronavirus lab leak theory. The author of that piece was a former colleague, so I don't really want to weigh in on the specifics. I'll just point out that Wikipedia-style versioning would have avoided this situation altogether. Writers wouldn't be tempted to try to hide their mistakes if they knew any reader could easily see what was changed and when.

There's too much stigma about corrections

My hope is that versioning software wouldn't just make changes more transparent, but it would also shift the journalism profession's attitude about fixing mistakes.

The fact that a correction notice is displayed prominently at the bottom of an article encourages reporters to view it as a mark of shame. That causes reporters to resist making corrections unless they've made a clear, unambiguous error.

In practice, errors are not always so clear-cut. Sometimes an article is misleading or omits important information—even if it doesn't contain any outright factual errors. If the options are "keep the article as-is" or "admit you made a mistake and post a correction notice," reporters are going to resist making any changes.

But the most important thing isn't getting the reporter to admit he made a mistake—it's making the article better. Better publishing software with transparent revisions would lower the stakes by enabling reporters to treat updates as a normal part of the publishing process—not as an admission of guilt. Making transparent updates technically easier might make them more common and hence less fraught.

Better breaking news

Most of the time, reporters write a finished story on a topic, publish it, and move on. But there are some types of events—elections, terrorist attacks, ongoing military operations—where this process is too slow. The situation changes minute by minute, and readers are hungry for real-time information.

Some news organizations deal with this kind of story with a "live blog" format, where reporters post one-paragraph updates as new developments come in. This can be useful for people who have been following the story for a while. But it's not so helpful for someone checking in on the story for the first time.

The ideal journalistic product in this situation would provide both an overview and a feed of real-time updates. People who are just tuning in could read the overview. Once they were up to speed, they'd switch to following updates to see what has changed since the last version they read.

That's exactly what a Wikipedia-style editing system provides. Imagine at two-column news format where the left-hand column contains an explainer about a particular news story and the right-hand column contains a reverse-chronological list of recent updates to that explainer. To make this work for breaking news you'd edit summaries to provide enough detail that they work as a stand-alone source of information.

More efficient coverage of long-running stories

A similar approach could also work for explaining complex stories that play out over a period of months or years. Take the Oracle v. Google copyright case, which I covered several times at Ars Technica. The last three major developments in the case were:

Each article had to explain how Google used the Java platform, why Oracle sued Google, how lower courts ruled, how the fair use doctrine works, etc.

Because we have an industry norm that new articles should be new, journalists often re-hash information multiple times. But does that norm make sense?

A lot of information in the first article was historical information that didn't change from one year to the next. A lot of people reading the second article never saw the first one. Even if they did read a previous article they might appreciate a refresher.

So a different approach to covering these stories would have been for me to start with an earlier story and just modify the parts that are out of date. I'd replace the first few paragraphs to describe what just happened. Depending on the situation, I might change 20 or 40 or 60 percent of the article.

Of course a reporter can do this with current publishing platforms by just cutting and pasting the text of an old article into a new draft. But it would be better if this was a native feature of the publishing software. When you revised an article, readers would be given options to see the old article and to compare the two pieces to see what had changed.

There are lots of other situations where this approach would work. Say you're a political reporter and you write a profile of an up-and-coming congresswoman. The next year she announces she's running for president. The year after she wins the Iowa primary. A couple months after that, she's forced to drop out due to a scandal.

Each development brings in a wave of new readers. So you might be able to re-use the majority of the profile, updating relevant parts as necessary. That's significantly less work than writing articles from scratch. The less time journalists have to spend doing unnecessary re-writing, the more time they can spend on higher value tasks.

Vox's evergreen experiment

At Vox we did a lot of this.  For example, I originally published this story about net neutrality in November 2014 (you can tell from the URL, which contains "2014/11/10"). Then I published an updated version in February 2015.

This wasn't an unusual occurrence in the Vox newsroom—it was encouraged by our leadership and most reporters did it. And I think it was a good strategy because it let us do more original reporting and less re-hashing of previous stories.

But it would have been even better if we had a publishing system that was transparent by default. Then curious users could see how the articles changed without cluttering up the article itself with a list of changes. During my time at Vox I asked the tech team to build us something like this, but it never became a priority for limited engineering resources.

I think a big reason there isn't more experimentation with dynamic news articles is that it would require simultaneous experimentation in software and editorial culture. A lack of good software support limits how much an editorial team can do. Conversely, improving the versioning capabilities of publishing platforms won't add much value if newsrooms don't take advantage of them.

Taking full advantage requires significant changes to editorial workflows. So I'm excited to see Arnold experimenting with this, as it might be only a brand new newsroom that can explore the full potential of dynamic articles.

I'm an independent journalist working to create a new kind of news organization. In Rethinking News, I explore the state of the news business and ways to make it better. Please support the project by subscribing. It's free.

Image by aymane jdidi from Pixabay.


Only members can comment.
Please subscribe to a free or paid plan or sign in to join the conversation.