peterr@utcsrgv.UUCP (Peter Rowley) (10/14/83)
This article was posted to net.cog-eng on Sept. 22nd, but it never made
it out of UCSD. Please mail replies to the original author, not to me.
(Address given at the end of the message: The article has been edited a
bit to reflect the new time frame).
----------------------------------
(from D. A. Norman: University of California, San Diego)
I am fascinated by the development of a "Cognitive Engineering" news-
group, especially when it started with such a nice quotation. I hope
that this newsgroup can develop high quality discussion rather than the
random blithering that seems to plague some net groups. So far I
have seen both interesting discussion and nonsense in this group.
Do not forget that there are already two net.groups that speak on topics
of Cognitive Enginering: net.WorkS and net.editor-people. I know of
many potential participants for this group who are on various UUCP nets,
but there are also others, some of whom are only available via the arpa
net; it would be good if someone were to establish an arpa net connec-
tion.
Some time ago, Phong Vo asked the following question:
"1. Has anyone done hard/scientific studies on what are the trade-offs
among pure menu, pure command or hybrid systems? What are the
underlying parameters that cause one mode of communication to be
preferred to another?
"For example, a large part of the world is still constrained to low
bauds communication. As a result, the verbosity of a menu-oriented
system can cause it to be a nuisance. On the other hand, the ZOG
system at Carnegie-Mellon claims some success with very high-speed
communication line with touch-sensitive screens and all."
It turns out that this is exactly the question I tried to address in my
paper for the December ACM/HFS Conference on Human Factors in
Computer Systems (Boston, Dec. 1983). In this paper I present a
quantitative method of determining tradeoffs. In addition, I give the
following argument about menus that may be relevant. The following is
excerpted from the paper. A hard copy of the full paper is available
upon request (if you provide a US mail address). I recommend the
full paper because the quality of the argument rests on the ability to
do quantitative tradeoffs among the variables, where such things as
display rate (Baud rate) can be taken into account.
The major theme in the paper is that each design technique provides a set
of tradeoffs. I contend that no single technique is "correct" for
all people or applications. Rather, each technique combines virtues
with deficits. Menus provide one set of tradeoffs. Menus provide useful
information, but at the cost of taking up valuable workspace, taking time
to be presented, and requiring search effort. These variables (plus a few
others) must be separated from one another. In addition, the stage of
activities in which the user attempts to determine which operation is to be
done (I call this the "choice" stage) must be separated from the stage of
activity in which the user specifies to the computer what operation is to
be performed (I call this the "specification" stage). Many discussions of
menus versus comand languages confuse this distinction, in part because the
term "menu" stresses the information aspect (the "choice" problem) whereas
the term "command language" stresses the specification mode: naming, as
opposed to pointing. My discussion here is oversimplified to make its
particular point.
----------------------------------------------------------------------------
Excerpts from
Norman, D. A., (1983), Design principles for human-computer inter-
faces. Proceedings of the CHI 83 Conference on Human Factors in Com-
puter Systems. Boston. (Dec. 1983).
Command Languages Versus Menus
------- --------- ------ -----
The relative merits of menu-based systems and command language sys-
tems are often debated, seldom with any firm conclusion. It is useful
to compare their tradeoffs, but before we do, it is necessary to be
clear about what is meant by each alternative. In this context a com-
mand language system is one in which no aids are presented to the user
during the intention or choice stages, and the action specification is
performed by typing a command, using the syntax required by the operat-
ing system. (The distinctions among the intention, choice, and specifi-
cation stages come from a paper still in manuscript form.) Command
languages are the most frequent method of implementing operating sys-
tems. Similarly, in this context a menu-based system is one in which
all commands are presented via menus, where a command cannot be speci-
fied unless it is currently being shown on the active menu, and where
the commands are specified either through short names or single charac-
ters (as indicated by the menu items) or by pointing at the relevant
menu item (or perhaps at a switch or mark indicated by the item). These
are restricted interpretations of the two alternatives, confounding
issues about the format for information presentation and action specifi-
cation. Still, because they represent common design alternatives, it is
useful to compare them.
Command languages offer experts great versatility. Because of
their large amount of knowledge and experience with the system, experts
tend to know exactly what operations they wish performed. With a com-
mand language they can specify their operations directly simply by typ-
ing the names of the commands, as well as any parameters, files, or
other system options that are required. Command languages make it easy
to specify parameters (or "flags") to commands, something that may be
difficult with menu-based systems.
Menus offer the beginner or the casual user considerable assis-
tance. At any stage, information is available. Even abbreviated menus
serve as a reminder of the alternatives. Experts often complain about
menu-based systems because of the time penalty in requesting a menu,
waiting for it to be displayed, and then searching for the desired item.
Moreover, systems with large numbers of commands require multiple menus
that slow up the expert. The problem is that the system is designed to
give help, whether or not the user wishes it.
Two of the difficulties with menus are the delay in waiting for
them to be plotted and the amount of space they occupy. In the full
version of this paper I show that the tradeoff between amount of infor-
mation and time delay is especially sensitive to information transmis-
sion rate. When transmission time becomes fast enough, there is little
penalty for menus, whereas at slow rates of data transmission, the
penalty is high. In similar fashion, a figure in the original paper
shows that the tradeoff between menu size and workspace is especially
sensitive to the amount of total workspace available. When sufficient
workspace is available, there is little penalty for menus. Thus, slow
transmission rates and small workspaces bias the design choice toward
command language systems; high data rates and large workspaces bias the
system toward menu-based systems.
The two systems also differ in the kinds of errors they lead to and
ease of error correction. In a command language system, an error in
command specification usually leads to an illegal command: no action
gets performed. This error is usually easy to detect and to correct.
In a menu-based system, an error in specification is almost always a
legal command. This error can be very difficult to correct. If the
action was subtle, the user may not even be aware it was performed. If
the action was dramatic, the user will often have no idea of what pre-
cipitated it, since the action specification was unintentional.
Command languages tend to be virtuous for the expert, but difficult
for the novice; they are difficult to learn and there are no on-line
reminders of the set of possible actions. Menus are easy to use and
they provide a constant reminder. On the other hand, menus tend to be
slow - for some purposes, the expert finds them tedious and unwieldy -
and not as flexible as command languages.
In the argument over which system is best, the answer must be that nei-
ther is: each has its virtues and its deficiencies.
-------------( end of excerpt )-----------------------------------------------
This analysis has somewhat simplified the range of possible menu systems,
especially those with high resolution screens (lots of workspace) and bit
mapped displays (minimum time penalty to introduce menus). In addition,
appropriate formatting and selection of just what information is to be
desiplayed is as important as how much is to be displayed. Still, these
analyses make a start toward showing that system design, like life itself,
is a tradeoff among many dimensions: One cannot expect a unique answer to
what amounts to a complex, multi-dimensional problem. A former student
(Gary Perlman -- now familiar to cog-eng readers) has provided a useful
critique of this section taking these other factors into account. I will
ask him to provide his critique directly to net.cog-eng. I still feel the
analysis stands, but I leave that for further discussion if anyone feels
the topic worthwhile.
For hard copies of the original paper, write to me directly.
Donald A. Norman (ucbvax!sdcsvax!sdcsla!norman or norman@nprdc)
Cognitive Science C-015
University of California, San Diego
La Jolla, California 92093lorien@dartvax.UUCP (10/27/83)
I read D. A. Norman's "Design Principles for Human-Computer Interfaces"
and the net.cog-eng article in which it was summarized with interest.
In the paper, Norman presents a method for analyzing the tradeoffs between
aspects of user interface design. An example he presents is the tradeoff
between menu-oriented (easy for the novice, verbose for the expert) and
command-oriented (quick for the expert, opaque to the novice) systems.
In his conclusion, Norman points out that it's important to analyze
separately these different design considerations that affect user
satisfaction.
In this particular example of a tradeoff (and perhaps you can suggest
other examples), however, I find a blind spot. Have we so soon given
up on creating a system that is *both* command- and menu-oriented? I am
thinking in particular of a design suggested to me by my colleague,
R. C. Call, in which a command, with arguments, can equally well be
seen in the traditional sense as in a climb down a menu tree with
typeahead. For example, in a tree that looks like:
-----Main Menu----
SEARCH LIST
/
--Search Menu--
AUTHOR TITLE SUBJECT
|
<supply
author
name>
, the command SEARCH AUTHOR JONES, J. can be seen by people who are
used to operating systems as the SEARCH command with arguments
AUTHOR and JONES. A novice user, however, might begin by typing only
SEARCH. The system is so designed that if a particular command sequence
doesn't land one on a terminal node, a menu full of choices is presented
the the level at which they've landed. So our novice would see the
"Search Menu".
The (yes) tradeoff to this approach is that after executing a terminal
node, you're always returned to the Main Menu, so you can't sit around
in 'Search' trying out 'AUTHOR', 'TITLE', etc. searches, but must
type SEARCH every iteration. Perhaps this feature could be a toggle?
This is only a first shot at such a system, meant to stimulate discussion
not necessarily of this particular design but of other possible schemes
in which the interface is intelligent enough to recognize the user's
level of ability.
We shouldn't ignore the Future, either, as a resident Expert system in
such an interface might be just the thing to tailor output based on
a constructed cognitive model of the user.
Right now I have written a standard climb-through-the-branches menu
interface (with a few places where we were forced to compromise and
allow some "Tarzan" swinging between branches without returning to
the root), where you stick at whatever node you're at and have
to explicitly type 'R' (for 'Return') to climb towards the root.
In a few weeks, I'm considering implementing something of the above
design and I'd appreciate any comments, critical included.
Also if any of you folks are writing interfaces for bibliographic
databases (especially online card catalogs like mine) I'd like to hear
from you.
thanks in advance,
Lorien Y. Pratt
Dartmouth College Library
Hanover, NH 03755
decvax!dartvax!dartlib!lorien