I just came across Jason Brome's quickSub (via Sam Ruby's post, which also includes some good comments). Jason also talks about quickSub on his blog. QuickSub is a popup menu UI meant to make subscribing to RSS-type feeds easier.

I have been plotting out some interfaces for iCites that will make it easier to add things to iCites. With iCites, there is a lot less distinction between links and subscriptions, so there are some similarities to the issues with the interaction of subscribing to RSS-type feeds, like: multiple feeds, multiple feed formats and multiple ways / places to subscribe to a feed.

Another example of this genre of website interaction is the Google toolbar 2.0 and its inclusion of a "Blog This" button.

What I think is interesting about all of this, besides any techniques to make these kinds of interactions easier, is that it is becoming very important to account for these interactions. In other words, there is a rising expectation / desire that people who visit a website will take something away from that website to use in some other context / mechanism.

The most established example of this genre of interaction is bookmarking. With bookmarking, you take a website URI and save it as a bookmark in the browser context. A piece of the website becomes part of your web browser.

With the iCite UIs in this genre, I am thinking of a number of them as bookmarklets. QuickSub takes a different approach of building a popup menu in the web page view. The issue with both of these is that neither really has a well-established place in the UI: bookmarklets are somewhat esoteric to most users, and popup menus like quickSub are pretty awkward at best.

I have often thought it would be ideal if there were both a website context menu and a user context menu in the browser UI itself. The website context menu would be loaded from the current web page being browsed (i.e., via a special link element in the web page header), and the user context menu would appear whenever a particular user is using the browser.

In most cases, the website context menu has a scope of the kinds of things that people put in popup menus, and the user context menu has a scope of the kinds of things people put in bookmarklets.

QuickSub basically offers choices of RSS clients / aggregators in a popup, which are actually the kind of thing that could be handled more directly in a user context menu. So, for example, a user could have a bookmarklet that looks for the RSS feed on a page and adds it as a subscription in the user's one specific RSS client / aggregator.

I think quickSub might be useful because few people have bookmarklets like I described. But, it is also basically bad UI in that it presents the user with mostly irrelevant choices (i.e., the user really only needs zero or one choice from the popup menu that shows 15+ choices).

I don't want to complain much about quickSub, because I think it is a good thing in that it further shows how website interactions are changing. People do need a mechanism that encompasses what quickSub provides, and quickSub provides a fully functional mechanism—seeing it certainly helps me think about how to approach this genre of interaction for iCites.

Actually, I have been thinking about "contagiousness" as a way to describe a core goal of this particular genre of interaction, and will post more about this shortly.