It’s all your fault. It’s all my fault too. It’s your neighbors fault and your office tech person’s fault. It’s all our faults, really. Or maybe it’s nobody’s fault. Hover-triggered drop-down menus are broken and now we have to fix them…or maybe even abandon them.
What’s Wrong With Them Exactly?
Take a look at this image. You can click it for a larger size if you want or visit the site to try the menu.
The image shows two states of a hover-triggered drop-down menu on a site I built. When a user hovers over some of the items in the yellow bar, the submenu slides down. To be clear, “Home,” “About,” “Membership Benefits,” “Scholarships and Awards,” and the rest of the top-level menu items all represent unique pages with content. You can click any of them. The same goes for all items in the submenus.
So far, so good. Most people are familiar with this pattern, but here’s the catch: in my experience with clients—and the feedback they get from their stakeholders and site visitors—a significant number of people don’t know the top-level menu item is “clickable.” That means many people are looking straight past what may be the most important content on the site. ((In other cases, I’ve had clients not realize they need to write content for the top-level items in the menu for this same reason.))
How Did This Happen?
I’m not sure why such a significant number of people think this way. If I had to guess, I’d posit that because some sites don’t make those top items clickable or don’t show the drop-down until a user clicks the top-level item ((In the age of touch-screens, the click-to-open-drop-down pattern is gaining popularity.)) people just plain got confused. It’s quite reasonable really. Had web designers adhered to a simple standard—every menu item leads to a unique page—we wouldn’t be here. Sadly, that didn’t happen.
I’ve also mostly ruled out visual interface problems as the cause. Even when the top-level items have a unique hover state and trigger the “pointer” cursor—the two main ways we indicate clickable links in web design—it doesn’t seem to help in my experience. ((There are other problems too, such as those outlined in “Why Hover Menus Do Users More Harm Than Good.”))
Unfortunately, after giving this much thought, I don’t think there’s an easy solution other than making at least one significant departure from the hover-driven submenu navigation model.
One of the main reasons I think a major change is warranted is that the incremental changes I’ve seen to address the hover menu shortcomings cause new problems.
No Top-Level Page
This essentially embraces the model that caused the problem. Some people stick with hover drop downs but don’t make the top-level items clickable links. I don’t see that as much of a solution and it confuses people who expect the top-level item to be a page. Confusing one group of users at the expense of another is the opposite of what we’re aiming for.
Some people put the top-level item also as the first item in their submenu. Often, to avoid visual repetition, they change the name of the repeated item! This means that users who do know how a hover-based drop down menu system should work will be “punished” for thinking there are two pages when there are in fact one. Same problem as before. Not good.
Meaningless Landing Pages
This is probably the “best” of the three bad options, but it’s still not good. In this solution, people write unimportant information or information repeated in sub-pages so that users who click the page find something but those who skip it don’t miss anything. Again, this may inconvenience users who know about top-level menu pages. It also fills up the best URLs on the site like MRWweb.com/services/ with unhelpful information and pushes important information lower into the site like MRWweb.com/services/about/ [not a real page].
Luckily, there are alternatives. I’m shifting to one of these two solutions on all sites I design and build in the future. Both come with different advantages, and I hope that embracing those advantages will lead to more intentional and effective sites
As the title implies, these menus require a user to click top-level items to display the submenu. The top-level item is not a link and the submenu contains all pages including any “landing” or “summary” pages. Try the example on “Bootstrap” with the “Dropdown” menu items:
In that above example, “Dropdown” is more like a folder of container and doesn’t represent a page. Only the submenu items are pages. It sits alongside other items that are links and that don’t have drop-down menus.
This has a number of distinct advantages:
- Prevents confusion regarding clickable top-level menu items.
- Matches the “touch” action on mobile devices like phones and tablets which don’t support hover. ((This is big technical drawback to hover menus.))
- Reduces chances of users accidentally opening a submenu. ((This and other “hard to manipulate” problems caused by drop-down menus were possible to avoid, and I did so on sites I built. However, even after solving these problems, the underlying usability issue remained.))
One problem with this solution is for editors of WordPress sites. The WordPress menu builder only makes menu items out of links, so this pattern does not fit with the mental model created by the default tool for building menus in WordPress. Working around this will require a plugin to modify the menu builder, “hacking” around the issue, or moving to a completely different way of managing menus. I’ll cross that bridge when I get there.
No Submenus in Main Menu
Who said we need submenus anyway? On many sites, submenus are useful. They can provide contextual information to users about the site structure and what’s available. However, on many smaller sites, that information is of limited use. What’s more, if the “top-level” pages contain essential information that nearly every user should know, then limiting the initial navigation choices may make sense. ((The point comes with a healthy dash of salt. Restricting a users options on a site is a decision not to be taken lightly. In some cases the maxim of “decisions not options” is an important way to simplify an interface, but it can have the unintended consequence of restricting the freedom of users to read and do what they want on a site.)) Without submenus, users of navigation on the site have fewer possible paths and will consume more of the first level of information before diving deeper.
Once a user clicks through to a top-level page of a site without submenus, the submenu is presented either below the top menu or in the sidebar, as on this site: ((Note that this site also uses a hover-based submenu, but provides the sidebar submenu as a fail-safe of sorts.))
- Encourages authors to write strong top-level content and funnels users to those pages.
- “Saves a click,” so that menus only contain links and no other drop-down interactions.
- Displays all the available submenu pages for a section to visitors without them taking any action.
I’ve known about this issue for a long time yet felt paralyzed in doing much about it. However, I think that I’ve mostly worked through the problems and potential solutions and I’m ready to plunge into the unknown and start making what I think will be better menus and better overall websites.
What Do You Think?
So is this news to you? Did you not realize that top-level items were clickable or did you not realize others thought so? What are the root causes of this problem and do my proposed solutions address them? I sure hope so. Leave your thoughts in a comment.