Mon, 25 Sep 2006

Recognition versus Recollection

I originally posted this on Advogato on 4 Jun 2000. Advogato might be shut down, so I'm reposting it here.

Jim Gettys gave a keynote speech at Linux Expo, wherein he spoke of the need to support disabled users. He's quite right. We need to support them -- not out of any bleeding-heart concern for them. We need to support them because the interfaces that enable them to use computers *at all* enable us to make better use of them. A good interface is a good interface whether you can't see or can't hear or can't type or can do all of these. In particular, people who can't see have trouble with a GUI, and people who can't type have trouble with a command-line.

You may have noticed some tension between users of the command line and the GUI. There is a very simple explanation. The command line is based on recollection, and the GUI is based on recognition. This paper explains why each has its place, and explores ways in which they can be combined. We start by explaining how a "pure" version of each works, how they are combined in real life, and how we can use this perspective to find new avenues for exploration.

Contrasting the two

With a recollection interface, you must recall the correct next step (for example, to get a directory listing you must remember "ls"). With recognition, you have to recognize that what you are looking at is a listing of files. With recollection, you must supply the "-l" parameter to ls to get all information on files. With recognition, you have to recognize the "View" menu, and the "Details" entry underneath it.

Recognition is more approachable because it does not require much training. Recollection is more efficient because it wastes no time on the recognition search. As a consequence, class distinctions have been brought into the mix. Typically, new users prefer recognition because they can get more done. Experienced users prefer recollection because they can get more done.

These class distinctions are not firm, however, because new users are only new for a short period of time. Usage *is* training, and the more they use a recognition interface, the more they wish they had a recollection interface. Experienced users are not evenly trained, and in any case have to learn new software from time to time. They often wish they had a recognition interface, knowing the while that they'll soon wish they weren't forced to use it.

Recollection Interfaces

Exactly how does a recollection interface work? Actually, initially by recognition. The first step to recollection is to understand the current context. Most often in a recollection interface, only a small set of the possibilities is valid. In the Palm Pilot stroke interface, only some of the possible gestures are valid. Three of the gestures are prefix gestures that change the context.

Or consider the Unix command line. It typically starts with a verb followed by modifiers followed by nouns. The verb is distinguished from the nouns because it is the first word entered. In order for a user to accurately enter a verb, they must first recognize that the command line is empty.

So, in order to reduce the number of choices one must recollect, a recollection interface retains a context. A typical recollection interface will have a zero point -- a home position, along with a way to clear all context. The control-U character is often used in Unix to clear all characters currently being typed.

A recollection interface will always have a way to remove part of the input, or to clear back to a certain context. Input mistakes are an inevitable part of the human-machine interface. The command-line interface uses Back Space, the Palm pilot uses a left-moving stroke, a pie menu uses a "click in the middle of the pie".

Recognition Interfaces

Recognition interfaces are easier to learn because the possibilities are tabulated and categorized. The canonical recognition interface uses a hierarchical menu. Another form is a button bar. The advantage of a recognition interface is clear: the user need only recognize which command they desire.

One cost of a recognition interface is the need to scan through a large number of commands to locate the desired one. Commands are always grouped together by function to help reduce this cost.

Another cost of a recognition interface is the large amount of screen real-estate occupied by the interface. This problem may be addressed several ways. The items may be represented by small pictures of the function of the command. Since these pictures do not always invoke the right concept, they are sometimes accompanied by words which pop up when the mouse cursor hovers over the picture.

Entire groups of commands may be removed from the screen, only to reappear when the mouse cursor is clicked or hovers over a special area of the screen. A new set of commands are added, which expose the groups of commands. This is how a menu bar works. Sometimes the entire menu bar itself disappears.

But this creates another cost -- locating the hidden command. If a method is used to collapse some of the commands, then a command must be located in its collapsed location. This combines the difficulty of a recollection interface with a recognition interface.

Combining both interfaces

Each technique can and should borrow from the other. The solution to the shortcomings of each is to combine both approaches. It's necessary, though, to preserve the full virtues of both, and not produce a compromise.

GUIs often have a primitive, bastard-stepchild recollection interface. One may often press the two-key sequence "Alt-F O" to Open a File. The Alt modifier introduces the beginning of a command. Essentially it starts a very short command-line interface. However, it's only ever used to introduce the verb of the command. Little attention is paid to the nouns. For example, an advanced recollection system would allow one to type Alt-F O /etc/passwd <Enter>.

A command line interface could do something similar. The FO command would open a file, prompting the user for the name of the file. The F? command would list all the File commands, and simply ? would list all the types of commands.

The TOPS-10/Kermit/Cisco interface

An example of a very well-done recollection interface with recognition assist is the command interface first used in TOPS-10, later used in some implementations of the Kermit data transfer protocol, and currently available on Cisco's IOS. This interface has two magic characters which may be typed at any time: HT (tab) and question-mark. The tab character would complete the current item being entered, according to the current context. If entering a command, the command line would be consulted. If entering a filename, the list of files would be consulted. if a question-mark character is entered, the list of possibilities is printed.


Rarely do GUIs implement a recollection interface well. Rarely do command-line interfaces implement a recognition interface well. We can do better. We should do better.

Posted [16:06] [Filed in: opensource] [permalink] [Google for the title] [digg this]