Handling RSS in the browser

Two things slowing the understanding and adoption of RSS by mainstream consumers are that feeds are rendered as raw XML by the browser, meaning that someone clicking on a feed link gets a lot of code they see as gibberish; and that subscribing to a feed is usually a multi-step process of finding a feed, copying the link, opening up the subscription mechanism of the feed reader, and pasting the link in.

To solve both these problems some feed readers have created buttons that can be placed on a web site for a one-click subscription to that feed in the reader. Instead of getting code when you click it, you get your feed in the feed client. Web-based readers take this a step further in that you don’t even need a reader installed to for the button to do you some good, so anyone who likes your content can easily add it to My Yahoo for instance. This has lead to a proliferation of “Subscribe with X” buttons on some sites (indeed, look at how my feed is rendered in the browser with a stylesheet and you’ll see some of these buttons on the right).

Dave Winer has a problem with this, and rightly so. But his solution is a little heavy-handed. We don’t need some big centralized service (or lots of little centralized services) that process feeds and figure out how to make them work on the end-user’s particular preferred setup.

Jeremy’s right in saying this is a client-side problem, not something that needs to be solved at the server level, but the idea of creating a single helper app that lets people easily add a feed to their preferred aggregator still makes things too complex and shifts the responsibility for improving the user experience away from where it belongs: to the feed client itself.

There’s more than one client that can handle audio files on the Web. When I click an audio file, I don’t get a bunch of code, or some generic server- or client-side helper app figuring out what I want to do with the file. What I get is the audio opening up in Winamp, or Zinf, or Media Player, or whatever is the default player for audio files on my server. This happens because my browser recognizes that the file type it’s downloading has a default action and the OS knows how to open a file in the player. With a PDF, the browser sees a content type of application/pdf and opens the PDF in whatever application the user has installed to handle PDF files. If I have more than one installed, then the default one is used (default generally being whichever one I installed last).

Feed readers need to do the same thing. When I install a desktop reader, the reader should (perhaps optionally) find all the browsers installed on the system and configure them to open files with a content type of application/rss+xml in the reader. The reader then does whatever with it, perhaps showing it to the user and allowing them to subscribe.

Web based readers would need some sort of small install that would redirect that request to them, just as web based mail clients like Gmail need a small program to get mailto: links to open the web mail composition widget.

Of course this would also require that everyone serve RSS as the same content type or for the readers to handle multiple content types. Unfortunately the RSS spec doesn’t specify which content type should be used, so people have made up their own, often different, content types.

People often forget that many of the problems faced by RSS and Atom are not new. They’ve already been solved, so instead of reinventing the wheel we should use the existing standards.

Update: Joe Gregorio has mentioned this before and describes in technical terms how a reader can do exactly this with C# and Windows for Atom. The concepts, however are applicable to and feed format, programming language, and OS.