Quicksilver: Text Interfaces Beyond Launching

Posted on Wed, 19 Jan 2005 in Lisp by Brian Mastenbrook
This is the second part in my series about evolving text-based user interfaces. The first part can be found here.

As originally conceived, LaunchBar's purpose was to launch applications through efficient keyboard abbreviations and shortcuts. Quicksilver extends this concept by supporting a variety of actions for files. Let's revisit one such action:

This screenshot shows what Quicksilver looks like when moving a file from one directory to another. I selected the file by typing a prefix of its name, and then hit tab to select the "action" field. Typing part of "Move" selected "Move To...", at which point I could hit tab to select the target field.

Quicksilver automatically picked the CommonLisp folder as being a possible target. I would guess that it does this through a simple alignment score of the item's name over the current catalog, similar to how it finds information altogether.

There are few ways in which an interface could deviate from this, but in fact most text-based interfaces are significantly different, in that they start with an action instead of an item. To some degree, this makes sense, because there's little way then to select an action which has no arguments. However, in a human interface, such actions are rare: more commonly, the user has some object or item that needs to be manipulated. In a visual interface, the object is usually selected first, and then a keyboard shortcut, toolbar item, or contextual menu invokes an action involving what has been selected. What Quicksilver does is to extend this thinking to a text-input based system.

Outside of Quicksilver, the two text-input based interfaces I use the most are the UNIX shell and McCLIM. UNIX is fundamentally irredeemable, but I think McCLIM and presentation-based interfaces could learn a thing or two from Quicksilver.

Right now, McCLIM is close to the Quicksilver mode. The interactor allows completion of commands, though not in the same abbreviation or substring-based way that Quicksilver does.

However, the way CLIM receives arguments for commands is the reverse of the order that Quicksilver does.

I think this order is backwards. Though real life and intuition are often not good gauges of what's intuitive in a computer interface, I think that the way we think is strongly directed to doing things to objects, not just doing things. Though this concept has often been applied to excess, in this case, I think it justifies ordering interactions so the (first) argument is selected before the action. Often times, selecting an action then becomes redundant, as there's only one common or even possible action.

CLIM does get this right for running a command on an already-presented object. I don't know if the CLIM specification would allow this to be the primary mode of interaction of a CLIM application.

Regardless of what can be accommodated in the CLIM specification, I think that designers of future user interfaces oriented around text input ought to consider this. One type of application where text input is primary is in devices with restricted input and no touch screen. These devices are becoming more common in the form of cell phones with thumb boards.

Quicksilver is not a perfect match to the needs of a device like this, because selecting an item often depends on knowing what items are around to select. If you don't know what functions your cell phone can do, it's hard to go looking for it. But I think it makes sense to apply the concepts to a device like this. Instead of selecting a top-level menu item by scrolling up and down on a slow D-pad, abbreviation searching could pick out the item instantly. This would work fine even when used on a standard number pad and letter equivalents, too. Typing something which doesn't correspond to a menu item could trigger an address book and other data source search. If you open the address book, abbreviation search would work well to select a desired contact, and then select an action to perform with the contact.

The design of an interface based around this mode of entry would come to resemble a context-based user interface: at a top-level context, the search is heavily weighted to the top-level menu items, but selecting something not on the menu is OK, too. But selecting a top-level item narrows down the context and allows the user to filter down to the specific object they want to perform an action on. Accessing resources like URLs or new email addresses could be handled the same way Quicksilver does, by switching to text input when no match is found.

I think that such an interface could greatly exceed the usability of current interfaces for text-based devices like the Blackberry, which relies on a scroll wheel to select items.

On the next boring episode of software-inspired rambling, I'll present a theoretical model of usability that Quicksilver conforms to, and areas in which it defies expectations.

Trackback pings for this entry are listed below. The URL to ping for this entry is: http://www.iscblog.info/blog/trackback/45