University of Huddersfield, Huddersfield, UK. email: alan@hcibook.com
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.
Keywords: toolbar, accelerator key, short-cut key, menu design, learning by doing
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.
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:
Of these only the last gives a reasonable incremental route from novice to power-user. So, how well does it work in practice?
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!
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 16x16 or 32x32 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:
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:
However, they may be hampered by the toolkits they are working with, so there are also two messages for the toolkit developer:
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, pp.
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.