|
I'm watching the very good Jon Udell Bloggercon session video, and hearing so many kernels of good ideas, with non-technical people getting pooh-poohed by the hardcore techies here and there. There's a lot of handwringing about the privacy hazards of publishing your RSS subscription list and a bit of a dismissive attitude about what I think is the best complaint of all: that RSS aggregators, to the last, are much too techy. Hell yes.
Bloggers regularly publish blogrolls as a matter of course. Obviously, most bloggers are perfectly happy to share some part of their reading habits with the public. In most cases, these lists are hand-maintained or at best, maintained separately from that person's aggregator subscription list.
If aggregators were designed well at all, it would be easy to maintain a "public" blogroll as a subest of your subscribed feeds. What ever happened to side-by-side list interface, with all your subscriptions on one side, and a list to which you drag, drop and arrange them in your public blogroll. I'm not much of a UI designer. Imagine what a real one could come up with. It's not rocket science unless you're one of the techies designing all the major aggregators around today.
The blogroll should be published out as OPML to your blog's root. The OPML should be LINKed, like your RSS feed, from the homnepage's header so aggregators and indexers can find it automatically.
And aggregators should, across the board, pay as much attention to aggtregating OPML as they do RSS--or integrate with an OPML aggregator that does. When you subscribe to an RSS channel, you should also fetch that site's OPML blogroll, and from there, chew on the most meaningful part: the URL of the blog's homepage, since with RSS 0.91, 1.0 and 2.0 and Atom and RDF feeds, the site homepage URL is the one consistent thing you can grab on to for the next key step, which is that..
Aggregators should draw conclusions based on the frequency with which the same entry appears in your subscribed blogrolls. If this is done right--and UI design is key here--the user may well find all the relevant feeds she or he wants by looking through lists, piles, fly-throughs, whatever, of blogs and other RSS sources that his or her current favorite bloggers tend to link to, or, drawing on centralized indices of the same OPML feeds, perform searches against the central index using constellations of one's already-subscribed feeds as the search terms, and draw inferences about how you rank your subscriptions based on how actively you read each one's items.
These last bits--searching a central index and auto-ranking your tastes--are the only points where privacy becomes an issue, and while it's important to keep in mind, how much of a barrier is it? Publishing your entire blog subscription list in order to search for more recomendations is obviously troubling, but what's really so bad about revealing bits of it? Hardly anyone seems to have qualms about searching for information on whips and chains and syphillis and their weak bladder on Google by hand, so why is it such a big deal to make it easy and semiautomatic to do related-items or collaborative-filter searches using your RSS subscription patterns as parameters?
Still, I think central databases are secondary here. I believe that your own reading priorities and the collection of OPML feeds you have on hand are enough to make massive strides in making it easier to find what you want before you know what you want, without revealing a darned thing to a central database.
Two things have to happen to get any of this started: OPML blogrolls have to become a default companion of RSS feed. (1) The major public blog tool providers should make that happen, including getting blogging tools and aggregators to generate and publish OPML as a matter of course. And (2) aggregator developers should spend a bit of time in front of iPhoto and less time imitating their e-mail software and their IDE.
discuss
|
