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

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.

Accelerator keys

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 random!

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]

Toolbars

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.

Learning icons

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.

The solution

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.

Summary

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:

1. Make sure accelerators work when the menu is showing.
2. 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:

1. Allow several keys to activate each menu item.
2. 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.

by Alan Dix, University of Huddersfield, Huddersfield, UK

References

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) pp. 81-97.

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.

Footnotes

[1] 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.

[2] 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.