tecznotes

Michal Migurski's notebook, listening post, and soapbox. Subscribe to this blog. Check out the rest of my site as well.

May 14, 2005 8:15pm

regarding competition for bloglines

I sent this mail to Richard MacManus the other day. It's a response to his post about the suckiness of online feedreaders, and a manifesto of sorts about the qualities that make a good RSS reader. Writing it helped clarify some of my thoughts about potentially interesting extensions to ReBlog.

In Competition for Bloglines, you say: "...the User Interface of Bloglines is beginning to get very creaky. It still uses frames, for crying out loud! There's not a whiff of Ajax in the Bloglines UI and narry a hint of tagging."

I don't know if Ajax and tags are the magic bullets that can make or break a web-based feed aggregator.

Ajax is a great tool, but I don't think it's really relevant here (more below).

Tags are post-processing organizational aids: encounter a resource, read/view/understand it, and then tag it for later recall. This does not help with the efficiency of processing of new information, and in fact hinders it by creating an additional categorization step for new items. It's analogous to Apple's new Spotlight feature in Mac OS X Tiger: they added a file-processing step to the kernel that indexes resources as they are written to the filesystem, and this takes time. Thankfully it's just CPU time and not cognitive time - tagging always explicitly takes someone's attention.

The great strength of Del.icio.us is that it helps people leverage each others' attention, creating something like a distributed computing application for categorization... "Taxonomizing@Home!" =oD

The problem with a lot of feed readers is that they have a simple list-of-lists UI. None of them learn from past behavior to affect incoming information. You're just presented with a list of feeds, and a list of items in each of those feeds. If you're subscribed to the "Map" tag from Del.icio.us, for example, you see Map24 and Google Maps scroll by a few dozen times a day. Over time, this detracts from the value of the Del.icio.us feed by continually showing too much old information. There have been suggestions on the Del-discuss list to include a link in the feed for a tag only when it is first added, but it has been rightly pointed out that this strips out too much information: it's important to know that 100 people tagged this link, while only 10 people tagged that link.

I think there's some pent-up demand for an RSS client that handles this logic, because no matter how intelligent Del.icio.us gets about dupes, it will never be able to know that you've just seen the same link on Waxy, Kottke, Slashdot and Mefi. Steve Gillmor has written about an idea he calls "Information Triage", which describes a possible approach to dealing with the deluge.

I have a personal interest in all this, because I am one of the maintainers of ReBlog, a web-based feed reader whose specialties are republishing (an outgoing feed of items you deem interesting is published - this is currently used to run Eyebeam's ReBlog, Unmediated, and other sites) and a swanky user interface that makes feed-processing faster and easier through respect for Fitt's Law and a forthcoming keyboard-navigation interface.

Unfortunately, my own experience with subscribing to 200+ feeds has been frustrating: if I don't keep up with them, they quickly spin out of control. I don't think it's unusual for heavy RSS users to open up their reader software in the morning to find 1000+ unread items, with no sensible way to understand which items are new, which ones are repeats, or where to devote attention first. My personal feeling is that in order to successfully handle a large number of subscriptions, a good RSS reader must have some concept of statistical analysis, similar to Bayesian spam-filtering methods. If you've ever use DEVONThink, you'll know what I mean.

If the software can tell me that an item I'm looking at contains similar language (or links to the same URL) as 20 other items from 5 different feeds I'm subscribed to, this is tremendously valuable. I can start to operate on information in the aggregate. I can use my reader as a force multiplier, to get a high-level overview of the information flowing my way. I don't have to drink from an RSS firehose all the time.

Ajax has a place here as an interface assist. ReBlog already uses Ajax techniques heavily, to archive & publish items. These could be extended to providing more information about items as well. I'm imagining a reader that slowly fills in context about a given RSS item as you read it, by requesting and displaying stats about the popularity of that link within your set of subscriptions, or historical data such as when it first crossed your path. It could provide an option to ignore all future occurrences of the URL - who needs to see 30+ links to Backpack in a given week, after you've seen one and acknowledged it?

This kind of smart-client aggregation triage could be a serious advantage for anyone who needs to keep up with large volumes of information on a regular basis.

December 2017
Su M Tu W Th F Sa
     
      

Recent Entries

  1. planscore: a project to score gerrymandered district plans
  2. blog all dog-eared pages: human transit
  3. the levity of serverlessness
  4. three open data projects: openstreetmap, openaddresses, and who’s on first
  5. building up redistricting data for North Carolina
  6. district plans by the hundredweight
  7. baby steps towards measuring the efficiency gap
  8. things I’ve recently learned about legislative redistricting
  9. oh no
  10. landsat satellite imagery is easy to use
  11. openstreetmap: robots, crisis, and craft mappers
  12. quoted in the news
  13. dockering address data
  14. blog all dog-eared pages: the best and the brightest
  15. five-minute geocoder for openaddresses
  16. notes on debian packaging for ubuntu
  17. guyana trip report
  18. openaddresses population comparison
  19. blog all oft-played tracks VII
  20. week 1,984: back to the map

Archives