Jason Shellen has posted a good proposal, Atom Info Proposal: Improving the human readability and understanding of Atom feeds (via Evan's EvHead). It's a practical suggestion, though I can't help but think there is still something weird and unresolved in the relationship between a readable web page and a "feed".

Usability-wise, if autodiscovery isn't sufficient (see Mark Pilgrim's Ultra-liberal RSS locator post), it seems like feed links need to be accompanied by a link to contextual help text (the link to the how this works page on inforworld.com as an example). Or, generally, a feed-indicating link should be for humans and should go to a feed explanation + feeds page, rather than directly to feed data (the feed page on Sam Ruby's blog as an example).

The basic point is that the human readable interaction is probably better accomplished in the human readable context (i.e., the web page HMTL) than in the machine readable context of the feed itself. So, making feeds more readable for this situation might best occur on the website than in the feed itself.

One other thing to note: some of Sam's feeds use mime types like application/rss+xml. In general, if these mime types are used, the browser will not display the file but will suggest the user download it or open it in another application.

RSS and Atom feeds are in the realm of file issues that I mention from time to time here. Communicating through files, in general, reflects human habits more than machine processing needs.

Even with files, a more machine oriented way to handle this might be for a user's feed reader software to install browser plugins that define themselves the viewers for mime types like application/rss+xml.

But, if we look at this as a user-gets-a-file issue, I think it is useful to compare XML files with other file types that are not especially end-user human readable in the browser. For example, PDF files are not natively displayed in the browser.

If a PDF file is served without the correct mime type, the browser will display it and the user will see a mostly unreadable mess. With the correct mime type, the user will either get the PDF in a PDF reader, or will get prompted to download the file, etc.

If you look at how people serve PDFs from their websites, it is common for websites that link to PDFs to include indications that the files are not of a browser-native type (e.g., a [pdf] after the link), and otherwise suggest that the files might be downloaded or viewed outside of the browser. As well, a link to get a PDF viewer is often included.

Anyway, I thought I would think aloud to my blog about this—the iCite net is planned to be very autodiscovery oriented, and perhaps browser-plugin-able as well, and so I think about these things sometimes.