Context menus and the design of design
I often recommend that software developers become familiar with the fundamentals of usability — we are all designers, whether we know it or not. But this takes time. When we are not able to design usable interfaces ourselves, then, it can be wise to rely on frameworks, conventions, and other resources that make design decisions on our behalf. What happens when those resources lead us astray?
The HTML5 specification allows developers to add new items to the context menu. This ability can be useful, especially as the line between web application and native application becomes blurred. But the specification is silent on one very important consideration — placement of custom menu items. Only the following guidance is offered to implementers:
The user agent may… provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page’s context menu as a submenu of the default menu. In general, user agents are encouraged to de-emphasize their own contextual menu items, so as to give the author’s context menu the appearance of legitimacy — to allow documents to feel like “applications” rather than “mere Web pages”.
— HTML 5.1
The specification shows examples where custom menu items appear above default menu items, and Firefox has taken this lead. But there is a problem with this approach. Usually, the most commonly used default menu items appear at the top of the list. Open Link in New Tab, View Image and other useful items are placed here. As a result, users can become so accustomed to clicking these that they stop consciously thinking about their actions. They habituate to clicking the first item in the menu. When that item is replaced with something new, users can find themselves accidentally making the wrong selection.
Jef Raskin discusses habituation at length in The Humane Interface. One passage even speaks to this problem directly (emphasis mine).
Most attempts to make interfaces adaptive are ill-advised; whenever a system changes automatically, even if the change is as small as, say, a reordered set of items on a menu, your expectations are upset and your habituation is frustrated.
Raskin is correct. Like moving the Windows Start button or changing the Mac global menu, reordering the browser’s context menu is likely to impede useful habituation and frustrate users. I have even experienced this first-hand. When Firefox swapped the positions of Open Link in New Window and Open Link in New Tab a few years ago, I found myself frequently making the wrong selection. As it turns out, I was not the only one.
What would be a better approach? I would like to see a submenu dedicated to custom menu items. Perhaps we could label it This Page. When a website provides custom items, they would appear in this submenu. When no items are provided, the submenu would be greyed out. The size and order of the menu would be constant, whether or not custom menu items are provided. Useful habituation would not be disturbed.
It might be tempting to blame web developers for using this feature, but we must remember that web developers are themselves users — users of web technology — and we should not blame users. Instead, we should lobby browser vendors to address this by building design constraints into their products that lead web developers, without their knowing, to build usable interfaces.
Originally published at blog.openjck.com on May 20, 2014.
