Correct errors, but also acknowledge them

Is there any evidence that “the speed and the immediacy of the Internet makes it more likely that online news sites will rush information out without careful checking and verification, and therefore be prone to more errors”? Robert Berkman posed that question on Poynter’s “online-news” e-mail list last week.

There are some great responses. David K. Every says the Web’s speed and immediacy actually allows errors to be corrected more quickly when they do occur, rather than waiting 24 hours for the next newspaper. If Web sites lived up to that potential, Every suggests, they could on balance be more accurate than other mediums.

To live up to that potential, I have argued, news sites first have to actually make corrections to the original articles — something some newspapers are not doing. Second, and this is critical, they need to preserve a copy of corrected articles in their original form, with a changelog. Without preserving the original, as Norbert Specker notes on the online-news list, the mistakes never happened. If news sites won’t do it themselves, Specker recommends an “independent body” that would keep copies of pages as they changed.

A section of Beau Dure’s graduate school research project, also mentioned on the online-news list, reminds news sites they violate traditional journalistic values by failing to acknowledge that they made mistakes and/or fixed them:

The Web sites [in Dure’s study], including the newspaper and television Web sites, do not acknowledge the mistake; it is simply removed from the site. This approach is at odds with the traditional approaches shown by the newspaper and television journalists.... Still, some readers will have seen incorrect information and may not be aware of the mistake unless they read the updated version of the same story.

Are there any news sites that do fess up when they make mistakes, in a way that works on the Web? Yes; Adrian Holovaty has found several. But I still haven’t seen any news sites that preserve the articles’ original versions for history. Given how easy that would be in a content management system, are online publishers trying to hide the fact that they make mistakes?

Ads in a list of news stories

What were they thinking? The Heber Springs (Ark.) Sun-Times runs links to advertisements on its local news page right between links to news stories. News and unlabeled ads appear in the exact same style:

The ad for “Drasco Trading Post” is even worse than the masquerading house ad that The (Columbia, S.C.) State ran last month. The Sun-Times’ advertisers are essentially buying placement of their ad as a news item, whether or not it’s marketed that way.

Newspapers have always run advertorials, but I think the critical issue is whether they are labeled as ads. Advertorials should always be labeled. When their formatting is identical to editorial content it is total evil not to label them.

Does the Sun-Times really want to join the ranks of evil user-unfriendly search engines that don’t disclose “sponsored links”? Selling ads to pay the bills is fine. Presenting an unlabeled ad in the middle of a list of news stories is not.

Name your sections carefully

One of today’s URLs at the East Valley Tribune in Arizona troubled me. The article, headlined “U.S. says Iraq shot down unmanned drone,” has a URL of http://www.eastvalleytribune.com/war/war11223.shtml.

By naming a section of their site’s containing articles about Iraq “war,” the Tribune seems to have jumped the gun on whether the United States will decide to go to war with Iraq.

At least, that’s what I thought at first. It turns out the section has a larger scope — “America’s War on Terror” — as seen in the silly American-flag header graphic on the article. There’s no index page for the section, but I browsed the server-generated directory listing and found some of the articles are about homeland security or Al Qaida. Still, most of the recent ones seem to be about Iraq.

Putting aside the political question of whether or not a possible war with Iraq is related to the “war on terror,” the use of that section name for Iraq news is not just unfortunate, it is journalistically inappropriate (until if and when there is a war with Iraq). Perhaps a better URL fragment for the section would have been “waronterror” rather than “war”? And I’d prefer it if news about Iraq were posted separately, perhaps in a section named “iraq”.

This is a great example of the problems with adding too much information to URLs — information that might be misleading or wrong at a future date. Tim Berners-Lee recommends basing URLs on documents’ creation dates (something this Tribune section does do) but leaving out practically everything else: “After the creation date, putting any information in the name is asking for trouble one way or another.” Berners-Lee mentions how it would make more sense now for the World Wide Web Consortium’s section on HTML to be at http://www.w3.org/HTML, but the section’s original location was http://www.w3.org/MarkUp/, and changing it would alter the URL.

The East Valley Tribune’s similar experience with changing content in an established section underscores the critical importance of naming sections carefully in the first place. Online editors might want to ask themselves whether their section names will still be appropriate 10 years from now.

Intelligent relative dates

Reporters love to use relative dates, for good reasons. Writing “yesterday,” “today” or “tomorrow” rather than, say, “Dec. 18,” “Dec. 19” or “Dec. 20” doesn’t just sound better. It’s also a lot easier for a reader to understand.

Print journalists can use those relative date references only because their readers have a shared understanding of what “today” refers to — the day that particular newspaper was delivered. On the Web, it’s not that simple:

• Good sites, ones that understand the importance of breaking news quickly, regularly post some or all of the next day’s newspaper articles before the next day.
• Some sites’ front pages tease to particularly good articles not just on the articles’ day of publication, but for several days thereafter. Many sites archive coverage by topic and offer it weeks and months later.
• Many readers don’t discover articles on the day of publication. Maybe friends e-mail them a URL or the text of a story itself. Maybe they clicked on a link to the story from another Web site.

In short, since many site visitors don’t read articles on their actual publication dates, referring to dates in relative terms can get confusing, even if a site identifies the article’s publication date well. This “Rams notebook” from Nov. 8 at stltoday.com uses “today” six times, “Friday” five times, “yesterday” four times, “Thursday” three times, “Sunday” twice and “Monday” once. The relative dates in this article — only 348 words long, by the way — are just incomprehensible after the fact.

One solution would be to make all relative dates into absolute dates. But it would be better to take advantage of something computers do well and make dates “intelligent.” What if Web sites automatically made dates relative to the current date rather than the publication date? For example, suppose I refer to “Dec. 20, 2002” — which right now for me is “tomorrow” — using some JavaScript that will display whatever “Dec. 20” means to you, at the time you access this page:

If you’re reading this blog entry within a few days of when I wrote it, you should see a relative date above — “today,” “yesterday” or “last Friday.” Otherwise, you’ll see the absolute date, “Dec. 20.” If you read this in 2003 rather than 2002, the script will add the year for clarity: “Dec. 20, 2002.” Give this a try below. Choose a month, day and year on the left, then press the “Show” button. You’ll see a relative reference if that date is within the past week or coming week (according to your own computer’s clock). Otherwise, you’ll see an absolute reference to that date.

This is accomplished with some pretty simple JavaScript that you should feel free to download, use and modify. If you include this script in a Web page, you can write out an intelligent date reference like this:

<script type="text/javascript">dateReference("Dec 19 2002");</script>

You want to make sure you display a dumb absolute date in browsers that don’t understand JavaScript, so in practice you should use something like this full code:

<script type="text/javascript">
<!--
dateReference("Dec 19 2002");
//-->
</script>
<noscript>Dec. 19, 2002</noscript>

I am a realist (even if I’m also a dreamer) so I’m not expecting news Web sites to begin using something like this anytime soon. The main problem, of course, is the kind of staff time it would require to code these dates. And because of proper nouns, this isn’t something that could be done with an automatic search and replace of print edition stories — what about the story that refers to NBC’s “Today” show?

There are further problems:

• Often whether a relative date is in the past or future is determined from context. The script’s inclusion of the “last” in “last Thursday” or the “this” in “this Monday” could be redundant or confusing.
• This method assumes the clock is set correctly on readers’ computers. They could be quite misinformed if it isn’t.
• Sometimes dates appear in direct quotes. Making the dates intelligent would alter the quote.
• Finally, some people (like me) have fairly nocturnal lifestyles, in which the division each night at midnight between “today” and “tomorrow” is arbitrary and would make automatic relative dates confusing.

Intelligent relative dating like this couldn’t be implemented without some solutions to these problems. But if there were a way to do it reliably, we could take advantage of computers’ ability to calculate and reduce the confusion over what day “Thursday” refers to in an article published a month and a half ago.