Logo. Two Rivers Consulting is Hagan Rivers and David Rivers, user interface design consultants located near Boston Massachusetts specializing in web application and enterprise application designtwo rivers flowing

follow us on

    writeto [at] tworivers.com or (978) 352-2585

Stop nesting menus

Written by Hagan on February 3, 2010    Return to Blog Home

I started my career as an interaction designer working on desktop applications. I designed for the Windows, Apple and Motif interfaces (and still do). Each of those platforms had a toolkit of interaction controls that we could use: buttons, text fields, radio buttons, check boxes, and of course menus. We had a menubar and also context menus (which appear on PCs when you click the right mouse button). When web applications came along they copied these controls (and are still adding many new ones). But one particular control I wish had been left behind: nested menus. Some call them “pull-right” menus. Here’s an example:

A nested (or pull-right) menu on Windows

A nested (or pull-right) menu on Windows

In a desktop toolkit, there are only two ways to make groups: using separators and using nested menus. Those are the only available choices.  Designers of desktop applications used nested menus to group commands together – for example, these are all commands that relate to choosing a layout.

We also use nested menus when the menu got too long. Desktop applications were originally running in an environment that was 600×480 pixels in size, and it was quite easy to have so many menu commands that your menu literally fell off the bottom of the screen. So the nested menus were a way to make sure that never happened.

So what’s wrong with using a nested menu?

Nested menus hide commands. All menus hide commands, which is the main reason that we use them – they let us squeeze an enormous number of commands into a tiny space. But nested menus hide them even further, forcing the user to drill down further and further to find what he was looking for. Here’s a simple example:

Nested menus hide commands

Nested menus hide commands

In this example, it’s at least easy to guess what’s inside the nested menu. But I’ve seen plenty where it’s not clear, forcing the user to open the nested menu to see the commands. This is especially tedious when you’re looking for a command and you have to open every nested menu in the menubar.

Pull-left sucks. I’m sure you’ve encountered this situation. You’re opening a menu on the right edge of the window, and then you need to open a nested menu. Since there’s no room to “pull-right”, it opens to the left. Seriously? Why would web applications want to copy something that is so obviously wrong wrong wrong.

A nested menu pulling-left because there's no room to the right

A nested menu pulling-left because there's no room to the right

What happens here is that the user started moving to the right, and now he has to move to the left to complete the command. And if he’s opened the wrong nested menu, then he has to go back to the right and open another one, which will also pull left, and so on. It’s really quite wretched.

Nested menus are error prone. The sad truth is that “pick errors” in nested menus are really common. Most users are clicking and holding the mouse button while they use menus. So they have to hold down a button and move the mouse around, moving over key locations in order to acquire their final target. It’s easy to close the menu without picking anything or just to pick the wrong thing entirely. Consider the example below. The user’s cursor is just over the word “Import”. To complete this command, he has to move the cursor to the right and stay within a “hot zone” that is just 22 pixels high. Move too far up and the “Folder” nested menu opens. Too far down and the “Export” nested menu opens. And remember – many users do all of this while holding down the mouse button.

Tiny errors in movement can open the wrong nested menu

Tiny errors in movement can open the wrong nested menu

It’s actually quite hard for us to move cursors in a straight line because we’re pivoting on our wrists and elbows, which means that most mouse movements are in little arcs on the screen. No wonder there are so many mistakes!

What’s the alternative?

That’s easy. HTML gives us so many more options for the presentation of information in menus. Here’s an example from an airline’s web site. This menu has two nested menus, which pull to the left.

A web application using nested menus

A web application using nested menus

The same menu could use headers and indentation to group commands and eliminate nesting.

The same menu, using indentation to eliminate nesting

The same menu, using indentation to eliminate nesting

What do you do when there are a lot of commands? The same site uses nested menus to conceal a total of 29 commands. But by reorganizing the menu, we can reveal all of the commands at once, making it easier to find commands and making good use of “positional memory” (which allows the user to remember where to find a command by its location).

(click to enlarge) Top: Lots of nested menus. Bottom: Nested menus are eliminated in favor of a multi-column approach.

(click to enlarge) Top: Lots of nested menus. Bottom: Nested menus are eliminated in favor of a multi-column approach.

I’m curious: Do you think nested menus still have a role to play in the designer’s toolkit? Have you seen other examples where nested menus were eliminated from a design? Do you think I’m missing something?

Category: Navigation, Rant 8 comments »

8 Responses to “Stop nesting menus”

  1. Keith Anderson

    Interesting, but it seems to me that netbooks are taking us backwards a bit. I have noticed my wife’s netbook has display issues with large dialog boxes and many menus run off the screen. What do you suggest?

  2. Calum

    One advantage of nested menus is their keyboardability, which is important for accessibility. File>Import>Windows Contacts? No problem: Alt-F,I,W, a sequence unique to the whole application, which quickly becomes a memorable if used often.

    Show more than a few items at once, and you’ve lost the ability to assign meaningful shortcuts to every item.

  3. Stuart Moore

    I love it. Esp since the solution could be added to the Windows or OS X API any day now. Keyboard shortcuts and all.

    The only thing that I see needs exploring is scrolling. What if the menu is too big for a netbook? Do we scroll vertically and horizontally? Of course it’s a code thing, but dynamic re-columning would be great to prevent 2D scrolling.

    And what if a “sub-menu” just has too many repetitive options (eg Google Chrome’s Encoding menu)? You don’t want to display them all. Maybe a scroll box inside the menu? Or a pop-up control?

  4. Henrique

    I like the multi-column menu approach, makes sense with today’s screen resolutions, and let’s you see everything that is available at one glance.

  5. Mike Starr

    Calum makes a great point. Far too many applications are adopting a “presumption of mouse usage” (Office 2007 anybody?). In fact, the latest versions of Windows adopted a default setting of *not* displaying the keyboard shortcut underlining. It is displayed if one presses the {Alt} key but I found over the years that just seeing that underline often enough during mouse actions brought them into my subconscious enough that I could begin using them.

    When a menu has twenty or more items, it’s likely extremely difficult to come up with an appropriate {Alt} key letter for a particular menu item.

    Perhaps the solution might be more menus but this becomes a challenge when an application becomes so powerful and complex that there just might not be enough room on the menu bar for enough menus to display all possible menu items in a single level.

    For those of us who adopt keyboard shortcuts, flyout menus are much more user friendly.

  6. Hagan

    Mike & Calum – You’re right: the design that I presented doesn’t make use of keyboard mnemonics, at it would be difficult to add them, given the sheer number of items shown (I show 39 items in one menu, readily exceeding our 26-letter alphabet in one menu).

    Unfortunately, you are among a small number of users who actually use keyboard mnemonics. In my 20 years as an interaction designer, the only users I’ve seen who regularly use mnemonics are software engineers. Most users are accustomed to moving back and forth between mouse and keyboard and aren’t usually engaged with activities that have them at the keyboard for hours every day (unlike someone, for example, who is writing code).

    That said, I do think that there are some applications that benefit from being keyboard driven, especially data entry intensive applications. Watching airline attendants check in passengers is a vivid example of an interface entirely driven without a mouse. My experience working with users in those environments, though, is that they prefer to rely on arrow keys, tabs, and enter keys rather than mnemonics… and the design that I’ve shown could certainly support that.

  7. Stop nesting menus — two rivers flowing I saw this one on the…

    [...] Stop nesting menus — two rivers flowing I saw this one on the…By things that confuse me – February 6, 2010Posted in: Web design Stop nesting menus — two rivers flowing [...]

  8. Hagan

    I strongly believe that menus should never open on hover – only on click. Once a menu IS open if you have a pull right (which I hope you don’t) the pull right should open on hover or click.