1995’s paper by Alan Dix,
published with author’s permission. Reprinted from Adjunct Proceedings of
HCI ‘95, Huddersfield, 1995.
Menus are excellent for novice users, requiring minimal prior training, but
experts complain that they are too slow. Toolbars and keyboard accelerators
(or short-cuts) are both ways of making common actions faster, but the
user has to explicitly learn them as even icons are rarely self-explanatory. This
paper proposes two methods to make accelerators and toolbars easier to learn.
First, keyboard accelerators ought to work when menus are active. Second, menus
ought to display the appropriate toolbar icon against the relevant menu option.
These simple measures would enable incidental learning whilst menus are being used.
Menus are a major part of virtually every mainstream computer application. Their
success rests largely on the psychological observation that recognition is easier
than recall. Much of the research and many guidelines on menu design are
therefore targeted at improving the process of finding things in menus (navigation)
and then recognising the appropriate option. For example, typical advice is to
ensure a logical division of options between menus, to limit the depth and
breadth of menu hierarchies (often including incorrect use of the 7±2 rule
for short-term memory (Miller 1956)), and to use consistent language in menu
titles and options.
Some interesting developments in the psychological understanding of menu
usage stem from recent work on display-based interaction. Most older cognitive models
used in HCI concentrated on the elaboration of goals into sub-goals and
eventually into physical actions. This is of limited utility in understanding
menu use, especially of novices or first time users. However, a strand
of research has grown up around the recognition that interaction is a cyclic
activity including perception and action. The menu is an excellent example of this
and has prompted work on cognitive modelling and associated experimentation
(Howes 1994; Payne 1994).
Unfortunately menus are slower than old-fashioned keystroke-based interfaces
and expert users may grow weary of wading through long lists of menu items,
waiting for the menu to appear etc. This has prompted work on developments of
the menu paradigm, for example adaptive menus which present frequently used items
first and pie menus which allow more rapid selection and easier mouse-ahead
(Callahan, Hopkins et al. 1988; Kurtenbach and Buxton 1994). Few interfaces include
these features, but most have keyboard accelerators or short-cuts and
many some sort of toolbar of icons. However, we do not want the novice user
to have to explicitly learn these, ideally the learning would be incidental
to menu-based interaction.
Some systems with a long pedigree added menus as an alternative to the
existing keyboard commands. Other systems were developed with only menus,
but then introduced keyboard short-cuts under pressure from users. Most
modern PC-based systems include both as standard, although often not all commands
are available via standard keyboard accelerators.
Learning accelerator keys
In the days when everything went through the keyboard, good developers realised
that the various key combinations would be hard to learn and attempted to
generate logical and consistent sets of keys. Those systems where this
failed (for various reasons) have become infamous in the HCI community (e.g. vi,
emacs). Even when the developer thought about the issues, it was hard to get
right. There are often several ways in which one can abbreviate commands to
one- or two-letter combinations (e.g. initial letters of longer names, physical
position on keyboard). Accordingly this area has generated its own literature
of design advice, empirical and theoretical research – including the
development of TAG (Payne and Green 1986).
This tradition of care has largely dropped by the wayside. Some accelerators
are pneumonic but many are not (Z for undo!). Furthermore, many short-cuts
are bound to function keys – it is far from obvious what “F3”
should do! Clearly, learning accelerators in order to progress from
novice to power-user is no easy path.
Systems offer three main mechanisms to aid learning of accelerators:
|manuals and help systems – but it is well known that these are
principally used by experts anyway! This method is only useful if one
explicitly “studies” the system.
|consistency between applications – particular keyboard combinations have,
by common usage, or by edict of style guides, become standardised across
all applications on a platform, for example “V” for “paste”
on a Macintosh. However, these are often limited and each application has
additional, non-generic commands.
|display on menus – the novice user performs operations through the menus
and is thus constantly faced with the short-cut keys and will hence –
it is hoped – learn them.
Of these only the last gives a reasonable incremental route from novice to
power-user. So, how well does it work in practice?
Machines that lie
Let’s look at the way this works on a typical MS Windows application.
This is particularly interesting because of the use of drop-down menus
[see footnote 1], together with the universal use of “Alt”
with initial menu name letters for keyboard-based menu selection. To some
extent the “Alt” combinations act as instant accelerators.
However, in addition to these two letter combinations, single keystroke
accelerators (bound to control keys or function keys) are also supplied.
For example, on typing “Alt-E” the edit menu is shown, one of
its options often being “Find.” This is usually displayed with its
initial letter underlined (as pressing “F” will now select it)
and also the function key short-cut:
Imagine you are a novice user and have got to this stage. You have mastered
the basics of navigating menus using mouse or “Alt” keys and are now
wanting to progress to power-user status. You see this menu item. It says
to you “F3 does a find”. So, in innocent naivety you press the
“F3” function key (yes, we’ll assume you are savvy
enough to know it doesn’t mean “F” and then “3”!). What
happens? Beep! It doesn’t work. The computer lied. Will you ever
trust it again?
In fact, you can only use the accelerators when the menu is not visible!
So, assuming your confidence has not been shaken too much to the roots,
your only way of learning is to remember for next time. However, this
contradicts the first great rule of education – you learn by doing. Unless
you use the accelerator key when you see it, it is unlikely you will
remember it next time. The only way to learn by doing on such a system
is to get the menu, see what it says, cancel the menu and then do the
accelerator – hardly incidental learning!
In case any Macintosh users are feeling smug, the behaviour of the Mac menus
is even more obscure. The mode of use (pull-down) does not suggest this sort
of learning, but if the user does try it the keystrokes are buffered
until after the menu is released. The resulting behaviour is apparently completely
What goes wrong
The reason for this strange behaviour lies largely with the toolkit designers.
The interaction with menus is usually modal; that is, the application program
yields control to the toolkit entirely during the menu interaction. So,
the part of the application code which recognises keyboard accelerators never gets
to see the keystrokes, they are either ignored (with beeps), or buffered by
the toolkit. The only way an application can get the required behaviour is
if it can tell the toolkit to recognise the additional short-cuts during menu
interaction. But, you guessed it, most toolkits do not give you this
ability. You are allowed one keystroke for each option (sometimes it has to be
one of the characters of the menu option’s name). So, if you want the
menu option to be able to be invoked by its initial letter, you cannot have
the function key accelerator and vice versa – argh! [see footnote 2]
The appearance of the toolbar in many applications is more recent and so there
is little research aimed directly at it (an exception is Debevc (1993) on
adaptive toolbars). However, a toolbar is largely a collection of iconic buttons
and so there is extensive background upon which one can draw concerning the design
of sets of icons and the behaviour of buttons. (It is worth remembering that
button behaviour is far from trivial (Dix and Brewster 1994).) One fact which
is certainly well known is that designing self-explanatory sets of icons is
very difficult – if not impossible.
Where icons are used to represent things (as in a file browser) there may
be obvious representations although once reduced to 16×16 or 32×32 pixels
they may be difficult to recognise. However, the icons on a toolbar refer to
actions, which are far more difficult to show in a small static image. A
classic example is the paint-pot icon for the “fill” operation in paint
programs. In a quick straw-poll, interpretations included a mortar-board, a
tap filling a bath, an operating table and a diver jumping into a pool! One
solution which has been proposed is to animate the icons, thereby making
the processes more apparent (Baecker, Small et al. 1991), which clearly helps
for visual actions (as in a paint program), but would not be expected to solve
the problem completely for abstract operations like saving a file, or making
a link in a hypertext program.
Lack of immediate recognition is not too great a problem if the user can
easily find out what icons do and then in time learn which is which. Commercial
interfaces offer three ways in which the user can find out what an icon
on the toolbar does:
|read the manual – this time the paper manual only as the icons rarely
appear in the on-line help.
|try it out – rather risky if the icons include actions, like saving a
file, which cannot be undone.
|object centred help – for example, balloon help on the Macintosh which
says what each screen object will do.
Only the last of these is potentially acceptable as a way of obtaining incidental
learning. Let’s see how it would work. You are using a word-processor
and want to find a word in the text. You look at the toolbar, there is a
magnifying glass, perhaps that is it (like a detective looking for clues), you
switch on balloon help and hold the mouse over the icon – no good, it
is the zoom function. You move the mouse, pausing over each icon in turn, until
you find the one you want (if it is even there). Notice how this disrupts the
interaction – only the really curious user will bother.
There is a obvious solution – put the icons on the menus in the same
way that accelerator keys are written there. So in the “Edit” menu one
might find the option:
|Figure 1. Add the toolbar icon to the menu|
Imagine now selecting this. As the mouse drags down through the menu selections
each highlights in turn. If the mouse is dragged down the extreme left, then
the effect will be very similar to selecting the icon from the toolbar, except
that it will be incidental to selecting the menu item. So, the toolbar icon
will be naturally learnt from normal menu interaction.
|Figure 2. Selecting the menu option = selecting the icon|
This is a trivial fix (although again some toolkits may not allow both icons
and text in menu items) and, based on accepted and tested knowledge of learning,
will obviously make a difference to the learnability of toolbars. Surprisingly,
the only places I have seen this are on the Macintosh “Apple” menu
and application selection menu (the one at the top right of the screen). Clearly
it should be used everywhere.
I have shown two ways in which minor changes to the behaviour and appearance
of menus of any application could have a dramatic effect on the ease with
which users can achieve incidental learning of keyboard accelerators and
toolbar icons. The design advice for developers is straightforward:
- Make sure accelerators work when the menu is showing.
- Include toolbar icons against the relevant menu items.
However, they may be hampered by the toolkits they are working with, so there
are also two messages for the toolkit developer:
- Allow several keys to activate each menu item.
- Allow both icons and text for each menu item.
The result for the user will be a more pain-free transition from novice to power-user.
R. Baecker, I. Small and R. Mander (1991). Bringing icons to life. Proceedings
of CHI ’91, New Orleans, ACM Press. pp. 1-6.
J. Callahan, D. Hopkins, M. Weiser and B. Shneiderman (1988). An empirical comparison
of pie vs. linear menus. Proceedings of CHI ’88, ACM Press. pp. 95-100.
M. Debevc (1993). Adaptive Bar. INTERCHI ’93 Adjunct Proceedings,
Amsterdam, ACM Press, pp. 117-118.
A. Dix and S. A. Brewster (1994). Causing Trouble with Buttons. Ancillary
Proceedings of HCI ’94, Ed. D. England. Glasgow.
A. Howes (1994). A model of the acquisition of menu knowledge by exploration.
Proceedings of CHI ’94, Boston, ACM Press. pp. 445-451.
G. Kurtenbach and W. Buxton (1994). User learning and performance with
marking menus. Proceedings of CHI ’94, Boston, ACM Press. pp. 258-264.
G. A. Miller (1956). The magical number seven, plus or minus two: some
limits on our capacity to process information. Psychological Review, 63 (2)
S. J. Payne and T. R. G. Green (1986). Task action grammars: a model of mental
representation of task language. Human-Computer Interaction, 2 (2) pp. 93-133.
S. J. Payne (1994). Acquisition of display-based skill. CHI ’94 Conference
Companion, Boston, ACM Press, pp. 299-300.
 Drop-down menu – where you click the menu bar and the menu stays down, as
opposed to pull-down – where you have to keep the mouse depressed and drag it.
 One toolkit I have used is even worse: if the find option can be invoked by
“F” then “Alt-F” does not work, so the user has to
remember to release the Alt key before pressing the second half of the Alt-key sequence.