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
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.
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 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.
Bash already completes on tab, and pushing tab twice will print all the
options. This works for both commands and file names. I believe this
is just part of the standard GNU readline library.
Emacs goes far beyond this even, with static and dynamic completion,
apropos to search for functions, ability to bind functions to keys,
menus, button presses, and most functions and variables have built in
GUI interfaces are just annoying after a point. A quick <tab> <tab> on
a blank command line shows that I have 2430 executables in my path.
Menus may work well for a couple dozen of these, but throwing 2430
little icons on my desktop is unworkable. Even putting them in menus by
grouping is very cumbersome to look through after a time. Emacs is even
worse, a blank apropos shows 7364 items. Trying to fit a gui on that
would be like trying to write this article by looking up every
individual word in a GUI dictionary. Even the cute little task bars are
annoying to me, as I'm currently running around 20 applications and I
don't want the bottom third of my screen filled with little pictures of
them all. If anything, I want more space on my desktop for important
stuff, not less.
Well, that's my rant for the day :)