Today I want to talk about using Context Menus in web application design.
What is a context menu?
A context menu is a menu that contains commands specific to the object that the cursor (* see note about touch screens, below) is currently pointing at – the “target object”.
These are also sometimes called “right click menus” or “right mouse menus” since they were, historically, activated by the Windows right mouse button.
Should I use context menus?
Context menus are not for every application. I certainly wouldn’t consider them for a consumer shopping site like Lands End or Amazon. I also think that context menus don’t make sense at low-use consumer oriented sites: banking, dating, even Facebook.
I find that context menus are most useful in large scale enterprise class applications, with users who are accustomed to using them. And in that environment, they are blindingly useful. Why is that?
First, context menus save mouse movement. This means that when your users are involved in highly repetitive actions, they can conserve movement. Instead of selecting an object, then going up to a toolbar and choosing an action, they can perform the action in place.
Second, context menus help users learn about objects in the application. By opening a context menu, the user can see what commands are available. This can help him to understand what it is he’s looking at, and what the application is capable of doing to this type of object.
Even in these environments, though, you will find that many of your users don’t use context menus at all. These are many of the same people don’t use keyboard accelerators. You’ll have to accept that context menus won’t be used by everyone in your application and plan accordingly (more on that in a moment).
So, assuming you’ve decided that context menus are right for your application, let’s make sure that you get them in there correctly.
How is the menu opened?
Traditionally, in Windows Desktop applications this menu is brought up by pointing at a target object and clicking the right mouse button. On the Mac desktop, the user can use a right mouse button (if his mouse is configured to use one) or he can hold down the Control key and click the mouse on the object. This is usually just referred to as the “right mouse click”.
The right mouse click should work anywhere on the target object. If it’s an icon with a label, the right mouse click should work on the icon and label and the same menu should come up for both. If the target object is a row in a table, then the same menu should open no matter where in that row the user clicks. Never EVER open different context menus depending on the column the user clicks in for a given row).
* Note about touch screens: In the world of touch screen applications such as mobile and iPad, we don’t have a cursor to identify the target object. I can quickly think of three possible ways to determine the “target object”. One would be to bring up the menu after the user selects the object (probably annoying), another wound be to bring up the menu after a touch and hold gesture (always the learnability problem, but that may get better), and the third way would be to add a menu control, as described below (probably the best short term solution).
Adding a menu control
In some web based applications there is an explicit menu control that the user can click on to open the menu. It’s usually a “menu icon” – an icon of an arrow pointing downward, that appears right after the name (or the image) of the object to be selected. The user should be able to either click OR right click on this control to open the context menu (do not ever use hover to open context menus). The worst thing you can do is to offer this control and then refuse to open the menu just because the user failed to right click on it.
If you offer a menu control, consider that clicking on a menu control is probably different from clicking on the object. In the example above, the user can click anywhere in the table row (the object) to select the row “Ahmed Hussain”, but if he clicks on the menu icon, he opens the context menu for “Ahmed Hussain” (and does not select the row). Furthermore, the user should also be able to right click anywhere in the row to open the context menu for that row – he doesn’t have to use the icon.
Should you use a menu control? They’re very useful in dealing with one of the big problems with context menus: many users have trouble discovering that they are available. In web applications, users often assume that the context menu just isn’t available (this can even happen on desktop applications). The menu control provides a strong visual clue that the menu is present, and can help your users learn to use them. On the other hand, there are some users that just assume that context menus will be available and they will naturally try to open them. If you serve such a user population, then a visible menu control is not necessary for your application.
The big problem with the menu control is that it can get very repetitive and clutter a screen. A solution to this is to only show the menu control during mouse-over (hover) to reduce this clutter.
Another problem with menu controls is that there sometimes just isn’t an easy object to attach the control to. For example, the context menu for editing a toolbar – the toolbar is a large element of the UI and it’s not really clear where you would place a menu control to indicate that a context menu is available. So menu controls won’t work everywhere.
What does the context menu contain?
The menu should contain commands that apply to the target object. This means that it can include commands from the toolbar or menubar or other controls on the screen that apply to the target object that the user has indicated.
The menu does NOT need to contain ALL the commands for the target object – in fact it usually should not because doing so will make the menu long and unwieldy. Concentrate on the most commonly used and important commands for that object. One of the single worst things you can do to a context menu is to fill it with so many commands that it’s tedious to use. Focus on important stuff – reduce clutter.
In the example below, you can see the context menu for selected text for Dreamweaver, Microsoft Word, and Apple Pages. The Dreamweaver menu is definitely taking the “kitchen sink” approach – including many possible commands in the menu. It’s so large and has so many pull-right menus that it’s tedious to use. I avoid using this menu when I use Dreamweaver.
The most commonly used items (“Cut”, “Copy” and “Paste”) are far down on the menu. Contrast this with both Word and Pages, who put these commands near the top of the menu, and they push their pull-right menus to the bottom menu. They have also done a much better job of culling the items that should appear in these menus and organizing them well.
You’re much better off making a context menu that contains the 60% of really common important commands for a given object than making one that contains 100% of the commands, simply because the 100% menu is larger, more difficult to navigate, and therefore slower. Remember: the whole reason for having a context menu in the first place was to save time.
The menu should NOT contain commands that do not apply to the target object. Try to avoid commands that are generic to the page, such as “Refresh”. Focus on what’s useful for this thing the user is pointing at.
Group commands together into sets of 1-6 when possible. Use separators or gaps to create groupings.
Frequently used commands should appear higher in the menu than less frequently used commands. If you have a really infrequent command, then maybe it doesn’t belong in the context menu.
Pull-right menus are ok. They belong at the end of the list, when possible. I dislike pull right menus because they are error prone and time consuming to open – remember the whole point of the context menu is to save time.
You can also include alternate controls – don’t feel limited to simple bits of text in a column. For example, Microsoft Word 2007 has its floating palette (below, left) and Apple has little colored boxes for “Label” (below, right) in their file context menu on the desktop. Just because we say “menu” doesn’t mean you have to be overly restricted in what it contains.
There should not be any commands in the context menu that are unique to the context menu. In other words, the context menu should contain commands that are available through other means in the application (such as the toolbar, menubar, or commands elsewhere on the screen). Remember, the majority of your users may never open a single context menu in your application. You don’t want to hide commands away that they might need.
I often place the “default command” first in the context menu. This is the command that would occur if the user double clicked on the object (for instance on the desktop this command would be “Open”, as Apple does in the example above). Sometimes there really isn’t a default (as in the Windows text example above), in which case you can concentrate on frequently used commands.
You can use the object’s name in the context menu to clarify the meaning of the commands. So, for example, you can say “Open snap.png” rather than just “Open”. It may be hard to strike the right balance here between being explicit and being too repetitive. Apple’s menu (above) includes specific labels for some commands and not for others. Use your best judgement.
I don’t ever use icons in my context menus – I don’t use icons in menus at all, to be honest. I find they clutter up the application and add absolutely nothing for the user. This is really my preference. You, of course, should do as you wish.
Most application designs do not put accelerator indicators into context menus. What are accelerator indicators? The text that shows the user what accelerator keys to use to activate this command. I think the reasoning here is to keep the menu lightweight – use your own judgement.
What about multiple selection?
Most of the time the “target object” for the context menu is the item the cursor is pointing at – but what about a situation where the user has selected one or more objects and then opens the context menu? Let’s look at a few examples.
There are actually a number of cases to handle. Let’s imagine a folder with 6 items in it: A, B, C, and D are all folders. E and F are image files:
The user selects A B and C and then opens the context menu on D. Note: D was NOT part of the original selection. In this case, A B and C should be deselected and the context menu that appears only applies to D. You can see this interaction in a movie: Multiple selection and context menus
If the user selects A B and C and then opens the context menu on C, then we have to ask ourselves an important question: are A, B, and C the same type of object? To be specific: do all 3 items share the same context menu? If they do, then you can go ahead and open your context menu and the commands in that menu will apply to all the selected objects. So if the user says “Open”, all 3 objects will open. If there are commands that cannot apply to more than one object, then disable that command: don’t remove it from the menu.
Earlier I said that you might want to say “Open snap.png” in the context menu to show what item you’re referring to. Now that your context menu affects more than one item, you can use labels like “Open 3 items” to help the user understand that the menu applies to all the items in the selection. So your menu might look like this:
- Open 4 items
- Delete 4 items
- Copy 4 items
Apple does this on the OSX desktop, but they are inconsistent about it. I can’t find any rhyme or reason for why we say “Compress 3 Items” but not “Open 3 Items” (see below). It’s a bit odd.
Let’s take it up a notch: What if the user selects A B and E and E is a totally different kind of object from A and B? A and B are folders, E is an image file. E has a completely different context menu! This is what we call a mixed-type selection. In the example below you can see the context menu for a folder on the Windows desktop (left) and the context menu for an image on the Windows desktop (right). They’re very different.
So, when the user selects these three items, what context menu should we show in this situation? The general answer is to fall back on our simplest behavior: you use the context menu for the item that the user is pointing at (the target object).
Use the Context Menu for the Target Object
The user clicks A, B, and E in a mixed selection and then right clicks on E. The context menu that you see is the one for E. (You would always see the context menu for the item that the cursor is actually pointing at). So in our example below we see three images. On the left: A (a folder) is selected and we see the context menu for folders. Then, in the center E (an image) is selected and we see the context menu for an image file. Then, on the right A, B (both folders) and E (an image) are selected and the context menu is opened on E. We see the context menu for E, the image.
But if you happened to choose a command from that menu that could also apply to A and B, then the command would apply to A, B, and E. So, if you choose “Delete”, then A, B, and E will be deleted.
On the other hand, if you chose a command that has no effect on A or B, but did affect E then the command would just apply to E. So, if you choose “Export” and that can only apply to item E, then only E is exported.
You can see in the example below that we have the same selection: A, B, and E. in the image on the left we’ve opened the context menu on B and we see the menu for folders. In the image on the right we have the same selection, but we’ve opened the context menu on E and thus we see the menu for image files.
Although it sounds convoluted, you’d be surprised at the number of applications you’ve used that apply exactly this approach. Think about it: if you choose Delete, you would expect it to delete all 3 items and it would just work correctly. It just seems to work – it’s one of those things that sounds complicated, but generally succeeds.
The problem with this approach is that it’s not predictable. You can’t always tell if “Export” is going to Export A, B and E before you choose the command. The only way to predict it is to know the application so well that you know that Export can’t possibly apply to A and B, and therefore won’t work on them. You can mitigate this by how you word the commands. For example you can say:
- Delete 3 items
- Export “snapshot.png”
And I think that actually improves this widely used solution.
This approach isn’t a no brainer – you need to go through each of the commands in the menu and consider how it does (or does not) apply to mixed selection on the current screen. The more similar your context menus for different objects are, the easier this job will be. The Apple OSX desktop uses virtually the same menu for folders and images, which makes things much simpler for them, as you can see below.
This example suggests that another way to solve this problem is to avoid having it. If you can avoid having different context menus for objects on the same screen, then the mixed selection problem will never happen for you. Remember, the mixed selection solution only matters if the context menus are different. So one solution is to craft the context menus to be the same, no matter what type of object is selected on the current screen.
What about Dropping the Selection?
The user clicks A, B, and E in a mixed selection. When the user opens the context menu (on any item) the selection is dropped. Instead, the item that the user clicked on becomes the selection and the menu only applies to that one item. I’m really don’t like this approach because sometimes the user goes to a lot of trouble to create a particular selection. Dropping it can be a major pain. I think this is one to avoid.
What about Building a New Menu?
Another solution is to construct a new, on-the-fly context menu that contains only the commands that are shared between A, B, and E.
I say: don’t do this. Really. It’s bad for a number of reasons. It’s a design, engineering and QA headache – every time you add any command to any context menu on the screen you have to refactor all the menu possibilities. It’s not fun, trust me.
But the bigger problem is that it just doesn’t work for users. It’s a nonstandard design, so it throws them off. Users rely on “positional memory” in menus – that is, there remember WHERE commands are in the menu. If you’re making custom menus depending on selection, then your messing with their positional memory and making the menu take a lot longer to use. In other words, you’re making the menus error prone and time consuming: exactly the opposite of why we put context menus in the application to start with. So, don’t do this.
Let me close with a few other thoughts:
- Context menus are not for every application. Make sure that your users will use them, and that it will be useful to them. If you’re not sure, run some usability tests and see if users even TRY to open a context menu. If you test people doing typical tasks and none of them ever open a context menu, then don’t bother.
- The purpose of context menus is to save time. Design them so that they are, indeed, time savers. Keep them short and well designed.
- Think about ways to improve upon context menu design. I’ve mentioned a few ideas: adding a menu control that appears on hover, showing the items that will be affected by the commands in the menu – I’m sure there are plenty of others. Don’t hesitate to take this “standard” design and improve upon it.