Object vs. Feed: vs. Mime-type

Follow up on RFC: RSS one-click subscription

As I'm progressing on the prototype I have received some interesting feedback and thought a lot about how this solution compares to the two previous ones (feed: and mime-types).
Thanks to Dare Obasanjo, Joshua Allen and Greg Reinacker amongst others for their comments.

Cross-platform and cross-browser?
The main criticism I have received so far (from Dare and Greg) is that this is platform specific. I believe it is not, although the html I posted so far is.
Flash works on lots of platforms and lots of browsers.
The FeedSubscriber button should be the same, instead that the media isn't some flash content, but instead a feed information blob (currently just a url).

Feed: scheme
The main problem I see with the "feed:" URI scheme is that it isn't friendly to new users.
Other than that, I rather like this solution (maybe it should be made a little bit more extensible, but that is a separate discussion).

As an RSS-unaware user, how the heck am I supposed to do with this weird orange button that links to feed://blog.monstuff.com/index.xml or feed:https://blog.monstuff.com/index.xml ?
This is what the FeedSubscriber control and XSL transformation of the feed tries to address.

Also, the other URI schemes (http:, https:, gopher:, mailto:, irc:, nttp:, ftp:) all correspond to a different transport mechanism. Whereas feed: doesn't care about the transport (most feeds us HTTP today, but there is no reason why this couldn't change).
On the other hand, the feed: approach is much simpler to deploy on the publishing side, compared to mime-type based solutions (which needs an extra file to be published containing the feed description or advertisement, and served with the correct mime-type).

FeedSubscriber object
Cross-browser support
As mentioned above it should be completely possible to make the FeedSubscriber be cross-platform and cross-browser.
But the html needs to be a bit more complex than what I originally proposed, to support this. A List Apart describes how to combine the "embed" and "object" tags for flash controls.
Also, supporting the embed tag involves declaring a new mime-type, which in this case would be a "feed information" media type.

Cross-aggregator support
Lots of aggregators use a web request to subscribe to new feeds, like http://127.0.0.1:8082/subscribe?url=...
The component I'm prototyping will read this url from a configuration setting, so that it can be re-used for most aggregators. Only aggregators that have a very specific subscription method would need to re-implement the FeedSubscriber object.

Right click
I recently saw some Firefox plugin to add "subscribe to this feed" to the context menu for the feed button. But that isn't optimal: the most common/useful action should be on the left click instead and secondary actions should be in the context menu.
The FeedSubscriber allows this: a right click on it will open a context menu that allows newbies to get more information ("learn more") and power-users to get to the actual feed ("view feed").
Actions like "copy feed location", "copy feed subscriber", "technorati" or "subscribe in another aggregator" could also be useful.

Is object overkill?
Honestly, the FeedSubscriber object seems a little overkill, because it adds lines of html to every feed button and needs to be installed separately (until the aggregators integrate it).

Also it may be a bit confusing when you installed the FeedSubscriber and go to a site that doesn't support it: the feed button will be a regular button (no one-click subscription).
I'm planning on addressing this by having the FeedSubscriber look similar to the feed button it replaces, but slightly different (using visual cues when hovering, like a tooltip or an image effect).

Then why?!
The FeedSubscriber object solution is the only one that gives us a way to handle the fall back case.
This is really important because user experience is a major roadblock in wide adoption of feeds outside of the blogger community.
Of course, if the deployed browsers had even minimal support for the feed: URI scheme (by showing you a help popup/page about feeds if you don't have an aggregator installed), the FeedSubscriber object approach would be un-necessary.

It should be combined with a smart RSS beautification, to try and improve the "newbie scenario".
"smart" means the solution that I implemented so far is confusing experienced users.
I'll include a new approach in my prototype: the beautified RSS shouldn't display the feed, only a text for "this should not be viewed in a browser, get an aggregator instead" and two buttons: "view raw feed" and "view beautified feed".

Future
I think the FeedSubscriber can be made pretty extensible to support future types of subscriptions. Currently the only thing you need to subscribe is the url of the feed. But richer distribution systems could appear similar to BitTorrent, where to actually subscribe to a feed you need a more complex "feed info" blob (a la .torrent file).

This brings us a little bit closer to the mime-type solution:
The one where a mime-type is created for "feed information" (or "feed pointer") and may be hosted in a separate file, rather than inline in the <object> tag. Another difference is that the subscription is triggered by an action in the client, not merely downloading a file.

[Not the one where downloading the RSS triggers the subscription: that's bad for multiple reasons, including that a feed should not be confused with a "feed information" data type. The aggregator only needs the "feed information" (url), not the feed itself. This is different from the PDF or QuickTime examples that Tim Bray raises. An aggregator is not an RSS viewer, it is a subscription manager.]

FeedSubscriber parameters should be maintained backward compatible when such upgrades occur. But I'll include a "required version" parameter that can be specified in the object tag, so that the FeedSubscriber can detect the situation and offer to upgrade itself.

"Subscribe Feeds" button in the browser
Joshua Allen and Gina Venolia brought up another approach, that I didn't understand right away but is pretty interesting.
The idea: users shouldn't have to search through the page for a "feed" button, the same way they don't have to search for a "print" button.

The solution would work by looking for linked resources like <link rel="..." application="..." ...> in the page. If multiple links are present, the user should be allowed to select which one he is interested in.

[This functionality can even be implemented with a bookmarklet or a remote context menu entry in IE. The javascript needs to be aggregator specific, and can popup a window with links to subscribe to the linked resources that it extracted from the DOM.]

In itself, this doesn't make it easier for feed un-aware users. Something else, like a prompt the first time the user encounters a feed-enabled page would help educate users. Also a little symbol next to the "SSL lock" could appear when feeds are available on a page.
It seems Mozilla Firefox would be a good browser to start experimenting with this, as the version 0.7 added a very similar feature for detecting alternate stylesheets and switching them.

Also, one could argue that the location of the feed button within a page does in fact matter. It gives context as to what it actually will suscribe to: the main feed, the current category feed or the comment replies feed.
Whereas with a "print" approach, you don't know that there is a comment replies feed on this site until you activate the browser functionality.

Work items
... for me and anyone who can help ;-)

• Complete a working FeedSubscriber object prototype, with at least support for IE and Mozilla on windows. A simple demo site to be provided.
• Dig in the feed: solution a bit more and investigate whether that's something IE/wininet team would be ready to support.
• Investigate adding a "feeds are available on this page" icon in the statusbar for Firefox (via a plugin/extension for a start).

Links:
Singing the One Click Subscription Blues.
One-Click Subscription to RSS and ATOM Feeds.
Request For Comments: The "feed" URI Scheme [final draft].
Windows XP Expert Zone implemented the XSL transform for RSS.
Introducing Aunt Tillie to RSS
One-click RSS subscriptions, continued: the lesser of two evils?.
How To Use Mime-Types To Get Your Aggregator To Subscribe To An Atom Feed.
A list of RSS aggregators.
Standards Compliant method to add Quicktime movies to pages.
Embedding flash without <embed>.

One idea would be to create a community edited site (like a Wiki) with a name like www.syndicatehelp.com. All the content of that site would be free and without commercial ads. That site would be very simple and explain clearly what the advantages of RSS are.

Then, we could provide a standard html block (like Paypal do for example) that provides a beautiful standard image for RSS feeds. Also, that html block would also have a "help" link that goes to syndicatehelp.com.

Then, every content site could paste that html block on their web site and new users would find a very convenient and easy place to educate themselves about the technology.

Jean-Francois Nadeau
I have started an easy to use aggregator project: http://www.clickthenews.com