Applying Hick’s Law to the Firefox context menus

23 July, 2012 § 25 Comments

Almost exactly a year ago I wrote about applying Fitts’ Law to commonly used buttons. Fitts’ Law is pretty well known among user experience professionals and front-end developers as it can be used to make commonly accessed user interface elements much easier to target. Hick’s law is probably less known, but its effectiveness is just as great.

Hick’s law “describes the time it takes for a person to make a decision as a result of the possible choices they have.” This law can be applied to the number of options for a question on a form, the number of dishes offered on a restaurant menu, as well as the number of menu items on a context menu.

In the case of Firefox’ context menus, we were able to remove a very seldomly used menuitem (“Send Link…”), and combine the “Reload” and “Stop” buttons.

Our new heatmap data showed us that only 0.89% of users clicked on the “Send Link…” menuitem. This is not really a surprise, given that the location for the majority of webpages can be found by looking at the location bar. This is in contrast with “Send Image…” which was used by 3.34% of users. “Send Image…” likely has higher usage because the majority of image URLs are not available in the primary UI.

Combining “Reload” and “Stop” gives us another nice win because the two states are mutually exclusive and the combination reflects the default state of the two actions in our location bar. Making this change led to discussions about removing the “Forward” menuitem when it is disabled, similar to how we remove the Forward button in the navigation toolbar when it is disabled. While removing the “Forward” menuitem would align with internal consistency, it would also make the remaining menuitems more ambiguous (“Back” and “Reload”).

The disappearance of the Forward button in the navigation toolbar does not make the Back button ambiguous. The back button is visually connected to the location bar (signifying a relationship between the two items), and the arrow describes moving backwards. If the context menu only contained “Back” and “Reload”, or potentially “Back” and “Stop”, then there is a much greater chance of confusion as to what “Back” really does. In other words, the presence of “Forward” helps to provide a navigational context for the other menuitems in their group.

These changes are available today on our Firefox Aurora and Firefox Nightly channels. Let me know what you think πŸ™‚

Tagged: , ,

§ 25 Responses to Applying Hick’s Law to the Firefox context menus

  • kensaunders says:

    What is the reasoning behind showing disabled/unavailable items in menus? It can’t be consistency since the forward button isn’t always visible.

    It would seem to me that not displaying them would allow users to make a choice faster since when they’re visible (yet unavailable), a user still reads them and has to process them.

    • I’m not part of the Mozilla project, but I’d assume it’s because people tend to memorize how to navigate menus based on their layout and hiding inactive entries results in a constantly shifting layout that you can’t readily build intuitive habits for.

      I know that, when I run into the odd app which hides inactive menu items (usually games which implement their own right-click handling), I find myself stumbling much more often… especially while tired or distracted.

      It’s disorienting enough when something I do like accidentally leaving some text selected, clicking just off the edge of an object, or right-clicking an that’s really a background-image leads Firefox to display a different menu than expected.

      The failure of “Personalized Menus” in one of the older versions of Microsoft Office serves as a good hyperbolic example of this issue.

    • msujaws says:

      We do hide menuitems that don’t apply (for example “Send Image…” when right-clicking on a paragraph). Disabled menuitems provide positive information that the feature is not available. For example, the presence of the disabled “View Background Image” does show that the capability exists but there is no background image on the page.

      With that being said, it’s definitely a delicate line to walk.

    • Simon says:

      Speaking generally (rather than of Firefox), the rule would be that if an option is temporarily unavailable (e.g forward button when no forward pages), it should be disabled. This is so that a) the menu layout doesn’t change unexpectedly, and b) people can see where the disabled option would be.

      It’s always a judgement call, though.

    • msujaws says:

      Good point, I like this approach.

  • julo says:

    Looking at this I’ve to ask how much users does use “Inspect Element” menu item.

    • msujaws says:

      The “Inspect Element” menuitem is fairly new, so measurements as to its adoption are probably too early to make any judgements on. Inspect Element is special in its own ways as well. This menuitem helps to teach users a critical part of how the internet works, and in that way it helps spread Mozilla’s mission. While it may or may not have low usage among the general population (I don’t have any numbers), the menu item provides a critical entry point for a feature that would otherwise lack a position-based entry point for inspecting pages.

  • Sam says:

    Stop and Reload aren’t mutually exclusive… In fact, combining them here actually does a disservice to users who might want to reload a page that’s hasn’t yet finished loading (or maybe is stuck loading because of background Ajax). It then requires stopping first, then reloading. In some cases, pages with ajax will start to reload even after stopped, so unless they user is very fast, they won’t be able to reload with the context menu as changed.

    • msujaws says:

      The combined action that is described here is a very small edge case. This change in our user interface does not represent a change of functionality. The underlying implementation here always treated Stop and Reload as mutually exclusive. The workaround for users (Stop, then Reload) is not painful enough to warrant the extra brain cycles spent for every other time that the user views the context menu.

    • An says:

      For those few users there’s the Menu Editor extension.

    • The Menu Editor extension breaks the HTML5 context menu entry support by preventing them from appearing.

      I’ve been using Stylish and a XUL userstyle to strip out Stop, Bookmark This Page, Send Link, Send Image, Set Image as Desktop Background, and other stuff that’s either better suited to an extension or used infrequently enough that I prefer to access it via the toolbar.

  • […] tweaked the context menu, removing the ‘Send link…’ item and combining the ‘Stop’ and […]

  • pd says:

    Another way to read this change is that you’ve disabled useful functionality for 0.8% of users. I’d really like to see Mozilla take the difficult path of innovation which is to care about existing users whose experience is effected by changes like this by catering for them with options to reverse the change. In a case like this, is it an issue of saving much developer time by maintaining this functionality as at least an about:config option? If not, perhaps that is at least a reasonable start in terms of catering for users who don’t like this change.

  • amnylou says:

    in context menu is the “Bookmark this page”. When the page is added to the bookmark element should be somehow distinguished eg by adding a star

  • Sz says:

    Talking about all this usability fine tuning, Fitts’ law, etc … have you ever tried using the toolbar in fullscreen mode? It’s much worse than a menu being a little crowded.

    First you have to move the cursor to the top of the screen to unhide the toolbar. Then you have to move it down again to press a button. But if you move it down fast, it’s likely that you’ll overshoot the bottom edge fo the toolbar! And then the toolbar disappears, you can start again from the beginning …

    The fix would be so easy. Just don’t hide that toolbar unless the mouse has moved at least 50 or 100 pixels below it. Just like Internet Explorer.

    I’ve been complaining about this for years, but I was always dismissed.

    • msujaws says:

      Thanks, I see what you mean as to it being annoying. Can you please file a bug for it? https://bugzilla.mozilla.org

    • Simon says:

      When I try (Firefox 14), there’s no problem. The buttons are visually offset from the top of the screen when in fullscreen mode (which isn’t ideal), but they’re live – I don’t need to move the mouse down again in order to click on them.

      With one exception, at least – the same isn’t true of the text fields (location and search), so you *do* have to move down a little to select them. That could certainly be fixed…

  • Markus says:

    Personally, I can live very well with cleaning up menus and these particular changes. However, I noticed that these “exotic” menu items are typically used by not so computer-experienced/affine persons, like e.g. elderly people etc., and for them it might be a big problem to remove such a menu item. While I send around links to a webpage by simply copying the adress-bar into an eMail, e.g. my father (who is approaching an age of 70 years) is explicitly looking for an menu-item to do something like this. It’s actually the same when the UI of an application gets changed: I can adapt quickly to a new UI, but it takes him quite some time and new learning. Please also consider these people before changing things, in particular if the gain is small (like here)

  • Manoj Mehta says:

    What % of users clicked on the “View Background Image” menu-item during the study?

    • msujaws says:

      I don’t know the answer to this, but I’ve asked one of the people on the user research team this question. I’ll update here when I find out.

  • So when I highlight a text, and do a right click, one of the options is ‘Search Google for “Lorem ipsum text text text” ‘ . I was wondering if it would be more neat, to have the text replaced by a magnifying glass / google symbol and keep it minimalistic?

    Also currently when I do a ctrl + F, I get a full panel in the bottom stretching my entire width of screen. Again, I have a feeling that unwanted area of it can be cut down to make it un-obtrusive to the main content, and have just a small tab like area for the search. Also, text in it may not be necessary. Simple icons for Next, and Previous should suffice instead of Icon + Text right now.

    Also, another redundant UI feature for my usage is the “Display your bookmarks” Icon. I dont use it, and I doubt a huge number of people use bookmarks as such. And those who do, use it extensively and have the bookmarks toolbar visible. So would it be a good idea to remove / disable the icon? At the same time, the bookmark star in the location bar could gain the same options in a right click context menu on it. This will remove two separate instances of bookmark functionality on an otherwise sleek Navigation Toolbar. Again, about the point of “less usage of bookmarks functionality”, with the speed dial on a new tab page, only helps as people can access their favorite website through it with using bookmark icon. Probably “pinning” of bookmarked links on speed dial would also be a good option to reduce the need of the bookmarks icon tremendously. Whatever the additional need may be, can always be met through the bookmark toolbar.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

What’s this?

You are currently reading Applying Hick’s Law to the Firefox context menus at JAWS.

meta

%d bloggers like this: