Context menus and the design of design

John Karahalis
May 20, 2014 · 3 min read

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?

Image for post
Image for post

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 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.

Image for post
Image for post
A user accidentally selects a custom menu item

Jef Raskin discusses habituation at length in The Humane Interface. One passage even speaks to this problem directly (emphasis mine).

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.

Image for post
Image for post
An improved context menu interface. “This Page” would be greyed out if no custom menu items were provided.

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 on May 20, 2014.

Reflections on Building Software

Thoughts on software development from John Karahalis

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store