UPDATE: FeedBurner CTO Eric Lunt was kind enough to explain to me that most of my concerns are unfounded. I should have known that they would avoid these issues. However, as a feed reader developer, I’ve got some additional follow-up thoughts for another post.

FeedBurner‘s FeedFlare announcement has a lot of people excited. While I applaud the concept behind this new offering (making feeds more interactive and containing interesting data), I’m not wild about their implementation.

My hesitance about FeedFlare comes on two fronts: as someone who reads feeds himself and as a developer who tries to create a good environment for reading feeds in FeedLounge. I’ll go over some of these issues, and try to hit points on both sides of the aisle – because I really am sympathetic with what FeedBurner is trying to do.

My biggest concern is about frivilous data changes in feed items that result in those items constantly being marked as unread¹ in feed reading applications. People that use feed readers don’t like it when items they have already read keep getting marked as unread.

There are a few feeds that I’m subscribed to that include comments on a post as well as the post content. When I see items from these feeds pop up as unread, I mark them as read without bothering to look at them. Right now, I only do this for a handul of feeds, but I’m subscribed to many more feeds that are FeedBurner generated.

My understanding is that feeds from WordPress blogs include the number of comments, but not the comments themselves². This is the worst of all – the item gets marked as unread but there is no new content available in the feed item to read.

Users will become annoyed when/if all FeedBurner generated feeds have items that are popping up as unread again because various counters are incremented. When I first started using my Popularity Contest plugin³, I was not excluding the popularity ranking from the content delivered in my feeds. I got strong and immediate feedback from my users that they were not OK with my items being updated all the time. 🙂

People use feed readers so they can consume more information faster – I’m afraid that some of the side-effects of FeedFlare fly in the face of this.

I haven’t played with FeedFlare yet, and perhaps I should have done so before opening my yap on all this, but I’m guessing there is some pretty cool data that FeedBurner will be passing along to their customers from these FeedFlare features. I would expect that any click on a FeedFlare item will be tracked and included in FeedBurner’s reportng toolset. I can see how this is a compelling reason to get on board if you are a content author/provider, but if these features have a side effect of annoying your readership, are you possibly doing more harm than good?

Assuming the FeedFlare features continue to be offered and used in their current state, I know that FeedLounge will be getting requests to: “add a preference to not mark changed items as unread if the only change is within the FeedFlare portion of the item.” I don’t blame them, it is the request I would make too. Unfortunately, that adds quite a burden to the feed reader developers – instead of just checking if an item has changed (using simple checksums, etc.), they will now have to parse the content of the item and compare the non-FeedFlare portions – it’s non-trivial in terms of CPU time.

Many of the features included in FeedFlare have been popping up in feed readers already (post to del.icio.us, Technorati links, etc.). While I don’t think this will discourage feed reader developers from adding cool new features and integrations – I’m not sure that I like the potential redundancy of this information either.

I’d rather see more global solutions, however I do understand the “changing the standard is hard, let’s just push our features in where we can” school of thought too. Who knows, by doing this FeedBurner may inspire the adoption of new extensions to RSS and Atom to “officially” handle some of this information. Having the data structured within the feed would alleviate almost all of my concerns with FeedFlare – I’ve got my fingers crossed.

1. Almost all feed readers treat changed items by marking them unread – that being the best treatment or not is a debate I’ve had with a number of feed reader developers. Treating the item as unread or changed doesn’t really matter – any treatment requires user interaction. Instead of debating that here, let’s just call it the status quo and move on. [back]
2. I suppose this could be added via their yet-to-be-published API. [back]
3. A WordPress plugin that calculates popularity of posts based on visitor actions. [back]

This post is part of the project: FeedLounge. View the project timeline for more context on this post.