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:
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:
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.
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.
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.
The same menu could use headers and indentation to group commands and 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).
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?