January 20, 2006
@ 02:05 PM
Comments [15]
Indicating Updated Items in RSS Bandit

A user of RSS Bandit recently forwarded me a discussion on the atom-syntax mailing list which criticized some of our design decisions. In an email in the thread entitled Reader 'updated' semantics Tim Bray wrote

On Jan 10, 2006, at 9:07 AM, James M Snell wrote:

In RSS there is definite confusion on what constitutes an update. In
Atom it is very clear. If <updated> changes, the item has been updated.
No controversy at all.

Indeed. There's a word for behavior of RssBandit and Sage: WRONG. Atom provides a 100% unambiguous way to say "this is the same entry, but it's been changed and the publisher thinks the change is significant." Software that chooses to hide this fact from users is broken - arguably dangerous to those who depend on receiving timely and accurate information - and should not be used. -Tim

People who write technology specifications often have good intentions but unfortunately they often aren't implementers of the specs they are creating. This leads to disconnects between reality and what is actually in the spec.

The problems with updates to blog posts is straightforward. There are minor updates which don't warrant signalling to the user such as typos being fixed (e.g. 12 of 13 miner survive mine collapse changed to 12 of 13 miners survive mine collapse) and those which do because they add significant changes to the story (e.g. 12 of 13 miners survive mine collapse changed to 12 of 13 miners survive killed in mine collapse). 

James Snell is right that it is ambiguous how to detect this in RSS but not in Atom due to the existence of the atom:updated element. The Atom spec states

The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value.

On paper it sounds like this solves the problem. On paper, it does. However for this to work correctly, weblog software now need to include an option such as 'Indicate that this change is significant' when users edit posts. Without such an option, the software cannot correctly support the atom:updated element. Since I haven't found any mainstream tools that support this functionality, I haven't bothered to implement a feature which is likely to annoy users more often than be useful since many people edit their blog posts in ways that don't warrant alerting the user.

However I do plan to add features for indicating when posts have changed in unambiguous scenarios such as when new comments are added to a blog post of interest to the user. The question I have for our users is how would you like this indicated in the RSS Bandit user interface?


 

Categories: RSS Bandit
Tracked by:
"buy womens shoes" (buy womens shoes) [Trackback]
« My Favorite SOAP Anti-Pattern | Home | MSN Search and the DOJ Subpoena »
Friday, 20 January 2006 16:10:52 (GMT Standard Time, UTC+00:00)
Actually, Sage gets it right, and Tim's quote was off the mark (see follow-up posts).

You've asked for a date with atom:updated semantics in the past, remember?
http://www.25hoursaday.com/weblog/CommentView.aspx?guid=4c8d83e9-bc7e-432d-b5b2-07965bd959ad
Robert Sayre
Friday, 20 January 2006 16:27:33 (GMT Standard Time, UTC+00:00)
So, Atom may not solve your problem if you want to avoid showing minor updates to users in cases where the atom:updated date has changed.

It does, however, let you not show updates to users when the date hasn't changed. This happens a lot with things like template updates, and with cases similar to MSN Spaces above. Basically anything that might change the hash of an entry. RSS Bandit may not have that problem, but lots of other readers do.

Of course, we can always count on you to ignore facts like that while you strive to find an excuse to write things like "People who write technology specifications often have good intentions but unfortunately they often aren't implementers of the specs they are creating." I'm sorry you spent so many years dealing with obtuse W3C XML specifications, but there's no reason to take it out on Atom. (this spec writer's Atom and RSS code has *way* more users than RSS Bandit, btw).
Robert Sayre
Friday, 20 January 2006 16:27:57 (GMT Standard Time, UTC+00:00)
Sometimes there's no such thing as a minor update though and every change needs to be reflected.

At the company I work for we publish system alerts from our product using the Atom syntax. The content of the event contains a message and a set of name/value pairs formatted using XOXO (and thus XHTML). So for example, we may have an alert (an "atom:entry") indicating that that database connection pool is becoming exhausted which contains such properties as the alert threshold and number of used connections, etc. As the number of connections change, the Atom feed entry is updated, so the "atom:updated" field changes (as well as the "atom:content" field of course).

Because RSS Bandit doesn't support the "atom:updated" field though, we are unable to use it as a client for our alerts.

I hope that you can add support for this field in the future as getting even minor changes is better than no indication at all.
Winter
Friday, 20 January 2006 16:39:10 (GMT Standard Time, UTC+00:00)
I think you have that backward. The assumption, I'd think, is that all updates are significant unless signaled otherwise. For example, the Wikipedia editing screens do that right now, there's a checkbox where you can mark something as being a "minor edit".

In the case where atom:updated hasn't changed, if you want to decide that you don't trust the upstream system and you're going to check the content anyhow and signal the user if it's changed, you're within your rights, although I suspect this will become less common as the tools get smarter.

What you can't do is *fail* to signal a change if the atom:update has changed. Because it could be a non-full-text feed, with a huge, significant change that's in the body of the article or post or whatever, but not visible in the summary that's in the feed. That behavior would be really dangerous.

Or am I missing something?
Tim Bray
Friday, 20 January 2006 17:01:03 (GMT Standard Time, UTC+00:00)
"What you can't do is *fail* to signal a change if the atom:updated has changed."

I don't think I agree with that statement. The spec makes no requirements on the behavior of aggregators.
Robert Sayre
Friday, 20 January 2006 17:14:52 (GMT Standard Time, UTC+00:00)
On how to indicate changed items...

What's wrong with using italics to indicate items with newly added comments?

In the newspaper view, simply list the comments as if they were new posts, and in the feed subscriptions tree and feed details list, identify the original post with italics, and the new comments as they are now, in bold.

This will, of course, mean that you'll have to track which comments have been read, and which haven't, which isn't available in RSS Bandit as it stands.
alun@texis.com (Alun Jones)
Friday, 20 January 2006 17:29:22 (GMT Standard Time, UTC+00:00)
Would it be possible to be cofigurable using preferences?

For example a user could choose to have an updated entry treated just like a new one (showing up in the unread folder etc.) or maybe users just want the updated entry to be marked in some way, like with a different icon. Maybe you could have a separate search folder for "Updated items".
Robert Aitchison
Friday, 20 January 2006 17:49:24 (GMT Standard Time, UTC+00:00)
Rob: Agreed, the spec doesn't say you have to signal updated status to users.

I'm just speaking from usability principles: it seems weird, verging on dangerous, when the feed unambiguously signals that "this entry has changed", for the software not to tell the user.
Tim Bray
Friday, 20 January 2006 18:00:07 (GMT Standard Time, UTC+00:00)
I agree with Tim. If the atom:updated element changes, then there is conscious effort on the publisher to signal an important change. It should show up as changed.

But we also want to put the power in the users hands regarding what changes they wish to be notified. So if atom:updated didn't change, but Rss Bandit detects a significant content change, users may want to be notified.

Since RSS Bandit still supports RSS and RSS isn't going away any time soon, the behavior from a user's perspective should not change between RSS and ATOM feeds. The feed format is abstracted away from the user. The user won't know (nor care) which feeds are atom and which are not.

It might be possible to create notifications for different types of changes (significant, insignificant) but why complicate things any more than they need to be. Either it changed in a way a user cares about, or it didn't.

As for comments, I like the idea of having giving the user an option to specify font settings for items with new comments, just as we do for items that reference the user's own blog.

Is RSS Bandit going to track ALL feeds, or just feeds that the user has posted a comment on? One idea is that the user has to specify that she's watching a feed. To keep the comment watching load on RSS Bandit low. It could be put in a special folder ("watched feed items") or something.
haacked@gmail.com (Haacked)
Friday, 20 January 2006 18:53:07 (GMT Standard Time, UTC+00:00)
The update field in Atom is a good thing. It IS unfortunate that RSS does not support it unambigously. As a user, I would like to be able to change a property on each feed to indicate whether I want RSS Bandit to interpret the update feed for Atom feeds, or apply whatever algorithm to RSS feeds to determine changes to that feed's items. That gives me control over what I see and I can take steps to compensate for either misuse of the update field (sites that mark every syntax change as new), or authors who think more of their "significant" updates than I do. Of course the latter arguement wouldn't apply in the case of RSS feeds since there is no indication from the author that the changes are signficant and RSS Bandit would be applying its own rules. I suppose the rules used for any given feed should be modifiable by the user in this case.
Alan Kleymeyer
Friday, 20 January 2006 21:29:33 (GMT Standard Time, UTC+00:00)
The only issue with that it sort of doesn't fit the Granma acceptance factor. Maybe a web.config setting would be appropriate for those who really care. But for the average user, it's probably best not to clutter the UI with complicated settings that require fundamental understanding of the underlying protocol.

It seems to me, and correct me if I'm wrong Dare, that RSS Bandit hopes to abstract away the underlying feed format. So whether it's RSS or ATOM doesn't matter to the general user.
haacked@gmail.com (Haacked)
Friday, 20 January 2006 21:31:50 (GMT Standard Time, UTC+00:00)
Perhaps this idea of modifying the underlying algorithm for detecting change can best be implemented as a plugin once Torsten completes the plugin model. That way those with discerning tastes in algorithms can do it their way.
haacked@gmail.com (Haacked)
Saturday, 21 January 2006 01:08:37 (GMT Standard Time, UTC+00:00)
Dare: "People who write technology specifications often have good intentions but unfortunately they often aren't implementers of the specs they are creating."

In fairness, the writers aren't to blame for atom:updated. That's just the IETF process at work... we couldn't get consensus around anything more specific, so the purposely vague "updated" is whatcha get.

I'm with Robert, though... I think it works well, as far as it goes, as long as you keep your expectations in check.

Tim: "I'm just speaking from usability principles..."

From a usability perspective, most users aren't going to be interested in seeing most changes. So at the very least, RSS Bandit's behavior makes for a sensible default. After all, one of Atom's selling points was supposed to be insulating us from the tedium of reading the same posts more than once.

Haacked: "If the atom:updated element changes, then there is conscious effort on the publisher to signal an important change."

Not so. Many systems drop their auto-generated "last updated" date into the atom:updated field. "Conscious effort" is not a requirement or expectation of the spec, and you'll get yourself into trouble if you assume otherwise.
Roger Benningfield
Sunday, 22 January 2006 06:17:47 (GMT Standard Time, UTC+00:00)
A windiff-style interface would be cool, showing users of an "updated" post precisely what changed.

Perhaps a churn-% could be used to mark "significant updates," e.g. 5% as a default value.

But then again, that doesn't catch your survived->killed example. :(
Joe Duffy
Wednesday, 25 January 2006 14:27:41 (GMT Standard Time, UTC+00:00)
"The update field in Atom is a good thing. It IS unfortunate that RSS does not support it unambigously."

Until it does, weblog publishing tools could support it in RSS using atom:updated.

Rogers Cadenhead
Comments are closed.