Time for RSS and the aggregators to understand small changes

Over 15 years ago I proposed that USENET support the concept of "replacing" an article (which would mean updating it in place, so people who had already read it would not see it again) in addition to superseding an article, which presented the article as new to those who read it before, but not in both versions to those who hadn't. Never did get that into the standard, but now it's time to beg for it in USENET's successor, RSS and cousins.

I'm tired of the fact that my blog reader offers only two choices -- see no updates to articles, or see the articles as new when they are updated. Often the updates are trivial -- even things like fixing typos -- and I should not see them again. Sometimes they are serious additions or even corrections, and people who read the old one should see them.

Because feed readers aren't smart about this, it not only means annoying minor updates, but also people are hesitant to make minor corrections because they don't want to make everybody see the article again.

Clearly, we need a checkbox in updates to say if the update is minor or major. More than a checkbox, the composition software should be able to look at the update, and guess a good default. If you add a whole paragraph, it's major. If you change the spelling of a word, it's minor. In addition to providing a good guess for the author, it can also store in the RSS feed a tag attempting to quantify the change in terms of how many words were changed. This way feed readers can be told, "Show me only if the author manually marked the change as major, or if it's more than 20 words" or whatever the user likes.

Wikis have had the idea of a minor change checkbox for a while, it's time for blogs to have it too.

Of course, perhaps better would be a specific type of update or new post that preserves thread structure, so that a post with an update is a child of a parent. Which means it is seen with the parent by those who have not yet seen the parent, but as an update on its on for those who did see it. For those who skipped the parent (if we know they skipped) the update also need not be shown.


At least in the atom format, you can provide an article feed with both creation and modification dates. It is only the lower quality feed consumers that have a problem with this. My own software replaces any updated article with that in the current feed if the mod date changed. The only thing I find lacking is a visible notification that it got changed since yesterday so I might want to read it over again. I do agree that an indication of change severity would be wonderful. It isn't technically difficult either. Your own website I see is using Drupal, which has built-in article versioning. It wouldn't involve a lot of effort to show a redlined diff on the update.

I'm not talking about creation/modification dates. All the systems seem able to track that something has changed. What I am talking about is understanding how much it changed, through a combination of automatic analysis, and human tagging (aided by automatic analysis.)

Add new comment