pt. IX: the Menu


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.


  1. 2008-09-14 4:23 pm
    • 2008-09-14 4:38 pm
      • 2008-09-14 5:26 pm
    • 2008-09-15 3:30 am
  2. 2008-09-14 4:49 pm
    • 2008-09-15 2:18 am
  3. 2008-09-15 4:51 am
  4. 2008-09-15 4:49 pm
  5. 2008-09-15 5:05 pm