theme selector

light blue screenshot grey screenshot navy screenshot dark green screenshot red and black screenshot

by Tony Chang

All opinions on this site are my own and do not represent those of my employer.

Creative Commons Attribution License

hyperlink usability

Jun 06, 2005, 12:11am EDT



Jeffrey Veen writes about the usability of subscribing to feeds. This same problem has been pointed out about greasemonkey user scripts multiple times. People see links to user scripts, but don’t know how to install them in the same way that people see links to feeds and don’t know what to do with them.

Part of the problem is that we’re using links to point to data objects. This breaks the typical user experience of links which provide navigation (visiting a link) or a way to download a file. These are the two actions users expect out of a link (and hopefully the two different actions are clearly labeled).

Feeds and user scripts (and even torrents to a lesser degree) are represented as links, but have different actions associated with them. I want to subscribe to a feed or I want to install a user script. Links like the Add to MyYahoo! or Subscribe to Bloglines help, but only if you happen to use a particular web aggregator. Alternately, some aggregators use the feed:// protocol, but again, this only works if you happen to use the right aggregator. Of course, you could use quicksub, but it’s a usability nightmare and will scare away anyone new to feeds.

I think we’re going to start seeing more data files get passed around on the web because it makes a whole lot more sense to use the web than building a new communication system.

So what can we do to improve the usability of data links? My initial thought is that it’s going to require easier ways of adding pseudo protocols to web browsers. What other options are there?

Nikolas ‘Atrus’ Coukouma at Jun 06, 2005, 04:49am EDT

The two common ways I’ve seen are @type and @rel. @type is limited to mime types and generally works well. @rel is intended for relationships (first, next, alternate), but has recently been hijacked for denoting how use, or perhaps a meta-type. The two are used in simulatenously for feed autodiscovery (Atom spec). I’m not a fan of pseudo-protocols because they don’t fail gracefully (“unrecognized protocol”). I think most of the existing protocols are real, if misnamed. mailto: is SMTP, aim: is OSCAR, irc: is IRC.

tony at Jun 06, 2005, 11:26pm EDT

Autodiscovery works ok. It defers the usability problem to the browser, for better or worse (probably worse as each browser will handle it differently).

On second thought, I don’t like the (pseudo) protocol method because that’s even more confusing— you click on a link and a different application starts up.

Julien Couvreur at Jun 08, 2005, 01:50am EDT

I had suggested a different approach for subscribing to RSS feeds:

It is admitedly rather heavy and ugly, but it’s still the only solution so far that could both work and degrade gracefully. The usability of Flash objects or Quicktime videos is much better than that of the little orange RSS icon: if you don’t have the required program to handle that type of data, it falls back to some text…

Julien Couvreur at Jun 08, 2005, 01:57am EDT

I forgot to mention another alternative: built a generic mechanism for handling small blobs of structured data in the browser. The blob should include some documentation about itself, so that the default handler in the browser can let the user know how/where to get a more appropriate handler.

This would not only support the RSS subscription and Greasemonkey script install scenarios, it would also allow more user control over which service to use for blobs such as address or ISBN blobs.

Read on at