Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Content Management

Handling RSS in the browser

Freshness Warning
This blog post is over 19 years old. It's possible that the information you read below isn't current and the links no longer work.

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.

Recently Written

Video calls using a networked camera (Sep 25)
A writeup of my network-powered conference call camera setup.
Roadmap Outcomes, not Features (Sep 4)
Drive success by roadmapping the outcomes you'll create instead of the features you'll deliver.
Different roadmaps for different folks (Sep 2)
The key to effective roadmapping? Different views for different needs.
Micromanaging and competence (Jul 2)
Providing feedback or instruction can be seen as micromanagement unless you provide context.
My productivity operating system (Jun 24)
A framework for super-charging productivity on the things that matter.
Great product managers own the outcomes (May 14)
Being a product manager means never having to say, "that's not my job."
Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. But failing is an important part of innovation. If you can't let it fail, it can't succeed.
Go small (Apr 4)
The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.

Older...

What I'm Reading