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).
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).
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.
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.
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).
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".
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.
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.
... for me and anyone who can help ;-)
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>.