To prepare for our upcoming Navigation Design seminar, we've been running user studies of various navigation features. As always, some test poorly. Also as always, the more faddish features — such as tag clouds — exhibit major usability problems.
Luckily, other Web trends fare well in user testing because they have inherently good usability and match user behaviors and goals. Indeed, one particular navigation design — the mega drop-down menu — tested well enough that I want to encourage its wider use.
Given that regular drop-down menus are rife with usability problems, it takes a lot for me to recommend a new form of drop-down. But, as our testing videos show, mega drop-downs overcome the downsides of regular drop-downs. Thus, I can recommend one while warning against the other.
As the following screenshots show, mega menus have the following characteristics:
Big, two-dimensional panels divided into groups of navigation options
Navigation choices structured through layout, typography, and (sometimes) icons
Everything visible at once — no scrolling
Vertical or horizontal form factors when activated from top navigation bars; when activated from left-hand navigation, they might appear as mega fly-outs (not shown).
Vertical mega menu from foodnetwork.com.
The Food Network's mega menu has a close button (the "x" in the upper right corner), but this isn't necessary. Mega drop-downs are inherently temporary and go away on their own when users move the pointer to another top-level option or to a "regular" part of the screen.
Horizontal mega menu from actionenvelope.com.
Stylistically, mega drop-downs are similar to the gallery menus in the "Ribbon" GUI component introduced with Office 2007 (and also popular in other recent application UIs).
Gallery menu from Word 2007's Ribbon.
As this ribbon-gallery example shows, mega drop-downs offer yet another benefit over regular drop-downs: they let you display tooltips when the user hovers over choices. For simple navigation menus, you'd typically use link titles instead of true tooltips.
Mega-Menu Drop-Downs Beat Regular Drop-Downs
We know from user testing that mega menus work. Here are some arguments to support this empirical fact:
For bigger sites with many features, regular drop-down menus typically hide most of the user's options. Yes, you can scroll, but (a) it's a pain and (b) scrolling down hides the initial options. As a result, you can't visually compare all your choices; you have to rely on short-term memory. People have enough on their minds, and messing with short-term memory reduces their ability to accomplish their tasks on your site. Mega drop-downs show everything at a glance, so users can see rather than try to remember.
Regular drop-downs don't support grouping unless you use kludges, such as prefixing secondary choices with a "-" to indent them. Mega-drop-downs let you visually emphasize relationships among items. This again helps users understand their choices.
While plain text can be wonderful, illustrations can indeed be worth a mouthful of words, as the Word 2007 example shows. Mega drop-downs make it easy to use icons and pictures when appropriate. And, even if you stick to text alone, you have richer typography at your disposal (letting you differentiate link sizes according to their importance, for example).
Speed is essential to making any user interface feel responsive. Interface elements must render within 0.1 seconds to suggest physicality and make users feel like a display's changes are a direct result of their actions. Slow-rendering GUI elements seem sluggish and make users feel like the computer is making things happen, not them.
You should test your mega drop-down implementation's response time on a variety of computers and browsers. Include the best-selling platform from 5 years ago, because a good number of your customers will still be using it.
Don't make response time too fast, though: the mouse should remain stationary for 0.5 seconds before you display anything that's hover-dependent, such as a mega drop-down or a tooltip. Violating this guideline will make the screen flicker insufferably when users move the mouse. Only after 0.5 seconds of resting the pointer on a navbar item can you assume that a user actually wants to see its associated drop-down.
Thus, the timing should be:
Wait 0.5 seconds.
If the pointer is still hovering over a navbar item, display its mega drop-down within 0.1 seconds.
Keep showing it until the pointer has been outside both the navbar item and the drop-down for 0.5 seconds. Then, remove it in less than 0.1 seconds.
One exception to item 3: The very best implementations can sense when a user is moving the pointer from the navbar item to a destination within the drop-down. When the pointer is on such a path, the drop-down should remain visible. This supplementary guideline addresses the diagonal problem, which happens when the path temporarily takes the pointer outside the active area. The drop-down shouldn't disappear when the user is on the way to point to something within it.
The diagonal problem:
The pointer path goes outside the area that keeps the drop-down active.
In the above example, the user first pointed to the "Holidays & Parties" navbar item and now wants to select "Appetizers." Moving the pointer between these two spots makes it cross the "In Season Now" navbar item. Many users will move so fast that the pointer will exit the active area for less than 0.5 seconds. However, older or leisurely users might move the mouse so slowly that the drop-down would disappear while they're still aiming for a menu item. Very annoying.
Grouping the Options within a Mega Menu
The main grouping guidelines are:
Chunk options into related sets, such as those you discover after doing a card sorting study of users' mental model of the features.
Keep a medium level of granularity. Don't offer huge groups with numerous options that require extensive time to scan. Conversely, don't make the individual groups so small that the drop-down has an overabundance of groups that users have to spend time understanding.
Use concise, yet descriptive labels for each group. Remember the standard rules for writing for the Web: enhance scannability by starting with the most information-carrying word and avoid made-up terms.
To keep words short and direct, the base form of verbs ("shop") is usually better than gerunds ("shopping").
Differentiate labels. Action Envelope's "Ways to Shop" and "Shops," for example, don't work well together.
Order the groups. You can do this using an inherent order among the features (as for a workflow) or according to importance, putting the most important and/or frequently used group on top (in a vertical design) or to the left (in a horizontal layout, assuming a left-to-right language like English).
Show each choice only once. Duplicating options makes users wonder whether the two occurrences are the same or different. Also, redundancy makes the entire interface bigger and more cumbersome.
Keep Megas Simple
The standard usability guideline to "keep it simple" also applies to mega menus. Just because you can put anything into them doesn't mean that you should.
In particular, avoid GUI widgets and other interface elements that involve more advanced interaction than simply click-to-go. Mega drop-downs are a fleeting screen presence and shouldn't replace dialog boxes, which are the natural home for more complex interactions and can support them better. Among other benefits, dialog boxes have a standard dismissal method (the OK/Cancel buttons), stay on the screen until they're dismissed, and can be moved around if users need to see something that the box obscures.
Action Envelope offers a complete login mini-screen within the navbar's "My Account" drop-down. It would be better to simply have a one-click "My Account" link that takes users to a full-featured page that supports login for existing users. (Better still: put this link in the utility nav, which is where people actually look for it according to eyetracking research.)
Similarly — but worse still — Novell hides its search box within a mega drop-down of the site's main navigation options. This is bad for two reasons:
The search box should be continuously visible on the page rather than displayed only when users activate the drop-down menu.
Having GUI widgets (a text field and a command button) makes the drop-down a heavyweight interaction area instead of a simple navigation menu.
A final point here: just because mega menus are big and have room for many options doesn't mean you should overload them. Simplicity applies to interaction semantics at least as much as it applies to the presentation layer. Fewer options mean less to scan, less to understand, and less to get wrong.
Because dynamic screen elements always have the potential to cause accessibility problems, it's important to code them with screen readers and other assistive technology in mind.
Even if coded correctly, mega drop-downs can cause problems for low-vision users who use screen magnifiers to enlarge tiny portions of the screen. (The same issue impacts iPhone users and other users of zoom-capable mobile devices.) If the user is unlucky, the zoomed view might show only a portion of the mega drop-down, which will appear to be the complete menu.
For example, in the Action Envelope screenshot above, the screen magnifier might show the "Paper & More" and "Ways to Shop" groups but not the "Shops" group. The missing drop shadow, which appears on the full menu's right edge, is too subtle a signal to help most users. Thus, the site could lose orders if it had many low-vision customers (a common situation for sites targeting older users). Having a strong visual signal for menu borders is one way to alleviate this problem.
In addition, having tiny selectable items hurts touchscreen users, and overly finicky show/hide behaviors hurt people with motor skills impairment.
There are two main approaches to improving the accessibility of mega drop-down menus:
Simple: Don't bother making the drop-down itself accessible. Instead, make each top-level menu choice clickable, leading to a regular Web page where you present all drop-down options in plain, fully accessible HTML.
Advanced: Emulate the "keytips" approach designed to add accessibility to Microsoft's ribbon controls. Keytips are an alternative to access keys and are easier to understand. The keytips interaction sequence is:
Press "Alt" to enter keytip mode.
Press a character to choose one of the top-level navbar items and display its mega drop-down. In the drop-down, show the access key next to each menu option.
Within the drop-down, let users press one (or two) characters to choose options. Because the access key displays while the drop-down is in keytips mode, users who can see don't have to rely on memory.
If you're a rich site and/or especially concerned with accessibility, you should implement both the simple and advanced features. Most sites, however, will probably have to make do with the simple approach.
Mega menus may improve the navigability of your site. (Of course, it's always best to test.) By helping users find more, they'll help you sell more (or meet other business goals, such as attracting donations or disseminating helpful information for non-profit or government sites).
Share :Twitter | LinkedIn | Google+ | Email