Characteristics
The layout of a menu is fairly straightforward: a series of text labels, possibly organised by separators. However, more thought has gone into the design of the menu than you may think. I’ll talk you through the various standard elements as they appear in menus all across the spectrum of graphical user interfaces.
The most interesting element is that of the desire to use verbs in menus. I always thought that “file” referred to the noun form of the word, but in fact, it’s the verb form – to file. The same applies to many of the other usual suspects; edit, view, open, save, quit, help, and so on. However, designers soon realised that single verbs are often not descriptive enough, and so the idea of using nothing but verbs has been abandoned a long time ago. Apple’s Human Interface Guidelines for Mac OS X, for instance, say that “menu item names should be either actions performed on an object or attributes applied to an object”:
Actions are verbs or verb phrases that declare the action that occurs when the user chooses the item. For example, Save means save my file and Copy means copy the selected data [ed. note: …to clipboard]. Your action menu commands should begin in the same way, with an action verb in its base (simplest) form.Attributes are adjectives or adjective phrases that describe the change the command implements. Adjectives in menus imply an action and should fit into the sentence “Change the selected object to…” – for example, Bold or Italic.
Another interesting element is the ellipsis. Whenever a menu item is followed by an ellipsis, it means that additional actions need to be taken before the actual command can be completed – it almost always means a dialog window will pop-up where you have to set some options or input some data for the command to work from. The “Save as…” menu item is a good example; this command needs extra data input (a new file name and location) before it can execute and complete itself. The Aero guidelines explain this concept quite well.
Sometimes, menu items are disabled (indicated by greying them out) because the command cannot currently be executed. This common practice (endorsed by many HIGs, including those of GNOME, OS X, and Aero) is the subject of some controversy, as some people claim that disabling menu items without offering an explanation leads to user frustration. “Don’t do this,” Joel Spolsky urges, “Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.” Spolsky suggests leaving the menu item enabled, showing a dialog of some sort when clicked explaining to the user what he needs to do in order to get the item to work.
There are more discussions concerning the design of menus. One of those is whether or not to use icons in menus. Apple’s guidelines basically come down to “Please don’t use icons in menus, only we are allowed to do that as we deem fit”. Apple’s argument is that users should be able to associate certain icons with actions, and by adding icons to every menu item, you hinder this process because the menus become too cluttered. Microsoft’s Aero guidelines say more or less the same thing, but are far less strict, urging developers to only add icons for common actions, or icons that are already well established. “Cryptic icons aren’t helpful, create visual clutter, and prevent users from focusing on the important menu items.” GNOME’s HIG appears to be mum on the issue.
Most graphical environments also indicate which shortcut keys activate which menu commands, allowing users to learn these commands easily. Windows also has something called ‘Access keys’, which can be seen as a ‘local shortcut key’ that only works when the menu is activated – the underlined letters in menus. Other environments, such as KDE and GNOME, have also adopted the concept of access keys, while Mac OS X shuns the idea.
The menu evolves
While the menu will most likely not go away any time soon, there have been a number of developments – mostly on the Windows platform – that shift the focus away from traditional, static menus. First introduced in Internet Explorer 7, and later adopted by many Windows Vista applications, are hidden menu bars. Many Vista applications lack a menu bar, instead preferring ‘toolbar menus’, or worse yet, ‘tab menus’ (see Windows Media Player). This isn’t actually implemented at random, but instead follows a set of guidelines put forth in the Aero guidelines.
- Consider eliminating menu bars with three or fewer menu categories. If there are only a few commands, prefer lighter alternatives such as toolbar menus, or more direct alternatives such as command buttons and links.
[…]- Consider hiding the menu bar if the toolbar or direct commands provide almost all of the commands needed by most users. Allow users to show or hide with a Menu bar check mark option in a toolbar menu.
- Hide the menu bar by default if your toolbar design makes having a menu bar redundant.
- Hide the menu bar instead of removing it completely, because menu bars are more accessible for keyboard users.
- To restore the menu bar, provide a Menu bar checkmark option in the View (for primary toolbars) or Tools (for secondary toolbars) menu category.
This behaviour will find its way to other environments, for instance via applications such as Google’s Chrome, which also eliminates the menubar. While Chrome is currently only available on Windows, it will also be released for Linux and Mac OS X.
Another development is embedding special elements into menus. For instance, Apple allows you to embed a Spotlight search field into applications’ help menus, so that users can search help contents directly without opening additional dialogs or windows. Microsoft is doing similar things with its Start menu which ever since Windows XP can hardly be recognised as a menu. It’s filled to the brim with items that traditionally have no place in a menu. Some KDE and GNOME “Start menus” seem to have adopted this let’s-stuff-as-much-weirdness-into-our-start-menu-as-possible mentality.
Designing good menus
A good menu is one that you see the least. The less you see a menu, the less time it apparently takes to find the proper menu item. Consequently, the more you see a menu, the longer it apparently takes to find the item you’re looking for. This may all sound rather simple, and it is – which makes you wonder why so many programs have menus that make me want to cry my eyes out while curling up in a foetal position.
I could regurgitate the various hints and tips and guidelines concerning proper menu design, but I won’t, because I don’t want you to take all the HIGs into account when designing your menu. No, I want you to follow the HIG of your specific platform, so that even the annoyances are consistent within a single platform, so you can learn to live with them.
Pity that you didn’t mention the menu behaviour.
The classic Windows-like behaviour is for menu to expand when a menu item is hovered by a cursor. It lets you access submenus faster but it often makes you lose your menu path when you get into deep submenu and accidentally hover the cursor above some higher level menu. This is annoying as it requires you to select all your menu/submenu/submenu2 path again.
Another type of menu behaviour is the requirement to click on a menu item to access a submenu (available in new KDE Kickoff menu and in Windows Vista). It won’t make you lose your menu selection path, but it will require you to click on every submenu you want to dive in.
I guess you could explain this topic in more detail.
It seems like a failure of design to have more than /Menu/Submenu as the depth of your menu hierarchy. There has gotta be a way to flatten it out because no user wants to search that deep for an item (especially if it’s something that’s used regularly).
thats the reason why office 2007 has the ribbon instead of a menubar
especially annoying if the submenu is so large that it covers the main one, and your still not at the right target…
I love this series. It makes me think more about usage patterns, which helps me with my video/mograph/graphic design work. Good job, Thom!
I agree. None of them are completely comprehensive, but there’s often some good insight in them.
Hey Thom, I have a request. Why not write a Human Interface Guideline for a Thom Concept OS? You could use ideas from the GROW project, and we could all hone in on an ideal interface.
Wouldn’t it be prudent to make up a dedicated landing page that holds the links to these stories so you could post that, rather than 8 links you have now?
I dread the posting for part XXX.
You mean like this?
http://www.osnews.com/tag/Common+Usability+Terms
Just retroactively tagged all the articles, looks good, huh?
Yes, excellent. Thank you.
>> Sometimes, menu items are disabled (indicated by
>> greying them out) because the command cannot
>>currently be executed. This common practice
>>(endorsed by many HIGs, including those of GNOME, OS
>> X, and Aero) is the subject of some controversy, as
>> some people claim that disabling menu items without
>> offering an explanation leads to user frustration.
>> “Don’t do this,” Joel Spolsky urges, “Users see the
>> disabled menu item that they want to click on, and
>> are left entirely without a clue of what they are
>> supposed to do to get the menu item to work.”
>> Spolsky suggests leaving the menu item enabled,
>> showing a dialog of some sort when clicked
>> explaining to the user what he needs to do in order
>> to get the item to work.
This is just plainly wrong from my experience. There are three ways of dealing with menu commands that are not accessible in the current context:
1) Hide them
2) Disable them (gray them out)
3) Leave them “on” and display a message
1) If you hide menu items that are currently not available, users are confused that some command that was there previously is now gone and they get frustrated searching all the menus. That is why the Office XP style menu that hides infrequent used menu items confused the hell out of people, because the menus look different each time they are opened and you can not as easily memorise where a command lives. The cost of hiding any menu items are usually greater then disabling it.
2) Graying an item out shows that the command that you are seeking is unavailable in the current context. While not explaining how to make them available this is a good, fast and non-intrusive way of showing the user: Stop, you can’t do that at the moment!
3) Leaving the item “on” and display a message is really evil in my opinion (except for some rare corner cases). Messages are almost always displayed using a modal dialog box which takes a lot of “effort” to read and close and then to return to the work you are doing. A reaaaally bad example of this are the selection tools of Photoshop (if you use it regularly you know what I am talking of and how much it gets in your way!!!).
Of course every rule has an exception and all solutions have a case where they can be used adequatly 😉
——————————–
>> While the menu will most likely not go away any
>> time soon, there have been a number of developments
>> – mostly on the Windows platform – that shift the
>> focus away from traditional, static menus. First
>> introduced in Internet Explorer 7, and later
>> adopted by many Windows Vista applications, are
>> hidden menu bars. Many Vista applications lack a
>> menu bar, instead preferring ‘toolbar menus’, or
>> worse yet, ‘tab menus’ (see Windows Media Player).
>> This isn’t actually implemented at random, but
>> instead follows a set of guidelines put forth in
>> the Aero guidelines.
I can only speak for myself here but I prefer the Vista and Office 2007 way of hiding and removing the menus altogether. Take the Windows Explorer in Vista as an example: The menu was removed there because with the new breadcrumb navigation you would get sort of two menu bars one living under the other with could get in the way when navigating through the directories using the breadcrumb menus (which I like a lot by the way because it makes navigating with the mouse very fast). The toolbar-menus in explorer (and Windows Media Player, that thing on the top is a toolbar not a tabbar!*) as you call them are actually so called button-menus because if you click on the name of the button (and not the space and arrow around beneath/next to it) it performs the default action of that button and the menu that belongs to that button provides “similar” actions as the default one. Vista and Office achieve by this that you just need one or two mouseclicks at most to reach a command via a toolbar/ribbon. Hiding the menubar saves precious screen space (you can have never have enough of it!), and toolbars need usually fewer clicks.
* Media Player toolbar not tabbar:
Look with Spy++ in the Windows Media Player Window.
The Top window beneath the title bar is of the runtime class ReBarWindow32 which is a host for a reziable toolbarwindow on Windows, in the case of WMP11 it hosts a single old boring ToolbarWindow32. (WMP hosts a whole lot of other ToolbarWindow32s all over the place.) Clicking or selecting one of the toolbar buttons sometimes changes the view state of the media player (DocumentView model) which could arguably be interpreted as some kind of tab view… I think not though…