We all know what an RSS feed is these days - basically it allows the syndication and reuse of content.
And this content can be anything, text, images, data, and as such provides a really easy way of getting the data out from one instrument and into something else. A nice example is the Canberra weather feed which provides a nice set of structured data wich you can periodically poll and extract the data you want to display it in a nice little application.
This is in fact what iPad and Mac weather widgets do. And that's fine for structured data. As it's structured we can interpret and pick.
Then we come to RSS as a substitute for usenet news, or indeed using it for article and document syndication, and then using applications such as Google reader as an aggregator, or newsreader substitute.
And this is where we come to usability, and twitter can teach us a lot here.
One of the virtues of twitter is that it limits you to a 140 characters, so, if you share links on a regular basis it's basically article headline, article source, and a shortened url.
Headlines of course can be misleading, but it does have the virtue of being easy to scan a scad of posts and choose the interesting ones.
RSS aggregators (well now Bloglines has had a near death experience, we basically mean Google Reader) uncritically display the feed content.
Which is fine. Except if one wants to scan a load of aggregated material in a hurry one only really wants the first paragraph or so.
But of course there are these publications (ok the Guardian) who put the full text of every article in the feed - great is you're viewing it a a Guardian reader app, not so great if you are using an aggregator. And this is why the Guardian's feed is less usable than say the SMH's.
This of course doesn't matter if you are using individual custom apps, as they can be configured to work with the individual feed. However generic readers are different, they have to work with all feeds and rely on the individual feed being sensibly formatted.
For example, a number of blogging solutions allow one to configure the feed to only show the first hundred or so words, the idea being to attract eyeballs to content (hey, this post about the Byzantine spice trade looks cool, let's go read some more).
And this works well in aggregators - enough to scan to see if it's worth following up.
Now, one could of course write an aggregator that read a feed and displayed only the the first sentence of an article, or the keywords, or the first hundred words or whatever. But the trouble with rules like these is that they will break something, like the really key update that's a 102 words long that's not worth clicking through to the article itself.
Configuring the rss content at the originator end at least means that the originator knows not to put anything more than a 100 words in the first paragraph, and to make it punchy (The spice trade played an important part in the sex lives of Byzantine Greeks ...)
But then there's a view that RSS is only a distribution mechanism, and certainly newspaper publishers like the idea of locking people into individual applications rather than having them read widely, but if one wants to read widely one needs some sort of aggregator like tool.
Google Reader (it's what I use so that's why I use it as an example) is basically no more sophisticated than the Pan Usenet newsreader.
Perhaps what we need in these presentation centric days is something more like paper.li, a twitter aggregator that aggregates content from twitter feeds.
It of course requires processing time and power and hence is not realtime. The trick would be is to offload processing to the client machine and download all feeds raw, but then we start getting away from the great advantage of web apps - it's always the same be you on mozilla, chrome or ie and if you're on a mac, a pc, or some ten year old recycled machine running linux...
So I'm stuck. Remote and simple is truly platform agnostic, local and sophisticated starts asking questions about os and host restrictions ...