Feeds have existed on the web for some years, but higher market penetration continues to be difficult as the vehicle for feed discovery (the browser) too often stands in the way of easy subscription. While syndicated content is not for everyone, it is very useful for people who like to read news and receive lots of information every day.
The goal of the Feed Handling changes proposed here are to make a useful experience for the ~15% or so of folk I predict will find feeds very useful, and not provide a horrible experience to the remainder.
When the user clicks on a link to a feed, rather than displaying the raw data contained within the feed, a page should be shown that displays some metadata about the feed, and some of its content. Front and center should be the ability to subscribe to the feed.
Since feeds are a relatively new concept to the majority of users, the page should succinctly but clearly explain what a feed is.
Because a site might offer multiple feeds for subscription, some content from the feed should also be shown to allow the user to know that they are subscribing to the correct feed (since it can take some work to remove it from their reader once they have added it) (the argument against this is that the reader should provide this preview, but this not consistently implemented across all readers).
The user should be able to choose their favorite reader to subscribe in. This can be a web service, a client application, or an internal component (e.g. Live Bookmarks). The preview page should present these options.
I think that showing the different major types of options (client vs. web reader vs. Live Bookmarks) may be worth breaking out into separate lists, since it may not occur to the user that they can change the value of a single menu list, and the method for changing the selection from one client app to another (using a file picker - OS maintains a list) is very different to choosing another web service (menulist - browser maintains a list).
At the same time I am hesitant to make the page appear too "heavyweight", so perhaps the detailed subscribe options could be hidden by default until the user decides to actually subscribe (remembering expand/collapse state the next time they view a feed, of course).
The user should be able to ask the browser to remember the decision they made and never ask again. When they choose this option, when opening feed content they are taken directly to their reader automatically, regardless of what the reader is.
Feeds are beginning to be used as a transport for other data, e.g. multimedia. We had a problem with feeds where the variety of types feeds are incorrectly served as means that we need to perform content sniffing of all data that comes through. Since these new data formats ("podcast" and "photocast") do not have a mime type that is distinguishable from a regular feed, we have no way of telling them apart. However they have functionality that requires a very different reading experience than news or blog postings. As a result we do not support "automatic handling" where the preview page is by-passed for these multimedia feeds. The user must always visit this page and choose the appropriate reader. We will do our best at that time to detect the implicit "content type" from the data in the feed and offer intelligent choices.
When the user browses to a site that exposes a feed through the tag, a button appears adjacent to the URL bar that offers them the ability to subscribe.
When there is only one feed linked, clicking the button will load that feed in the content area (thus showing the Inline Feed Preview which gives the option to subscribe).
When there are more than one feed (feeds that look like the same data with the only difference being a change in syndication format - e.g. RSS vs. Atom are collapsed), a menu is shown that lets the user pick one to display.
If the user has already selected a handler and asked not to be asked again, clicking the Subscribe button automatically subscribes them in their selected reader.
Right clicking on the button should show a context menu option for viewing the feed content and subscribing using a different reader (as an override, analogous to "Open With...")
An API is to be exposed to web services so that they can offer to be added to the set of available choices in the Subscription experience. A description of this API can be found in the WhatWG Web Applications 1.0 specification.
When the user browses to their reader web service, the site can provide a link that uses a special javascript call on the navigator object to add themselves to the list of choices in the Reader Selection UI. This is analogous to adding a Search Engine to the search box. There are various security considerations here:
After you add a reader how do you switch to it? We cannot easily determine when someone installs a new reader application on their computer. We can however detect when someone registers a new web service using the javascript API. When this happens we could force the Preview Page again, with the subscription box opened and some indication that a new item had been added to the list, akin to the Start Menu's "New Programs have been Installed".
The last option is configuration...
The "Download Actions" window should be modified to have two views: Basic and Advanced. Advanced shows all download actions for registered types and plugins, as with Firefox 1.x. Basic shows common types and how they are handled, such as feeds, mailto: links, etc.