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.
Bad Solutions
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.
Repeated Items
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].
Good Solutions
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
Click-Opened Submenus
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.))
Again, this pattern comes with some advantages:
- 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.
Fingers Crossed
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.
In my two latest projects I had hover drop-down menus, and in both cases, the clients were aware of the need to create content for the top-level items in the menus (i.e. “landing pages”), but did not want to. They instead wanted the landing page to be the first sub-menu item, which is in essence a variation of your “repeated items” case.
The way I implemented this was to have the “default item” of the folder (aka the “landing page”) be a link to the first sub-menu item, so when the top-level item is selected, it redirects automatically to the first sub-menu item. The “Link” is a standard content type in Plone, so this is very easy to do. The “default item” of a folder by default is hidden from navigation, so you don’t have to worry about duplication of menu items.
Indeed, that does sound like that repeated item version. My concern there is always that people who expect a unique top-level item will click both that and the first submenu item and be confused. The click-toggle menu gets around that by claiming the click event for the submenu rather than a link.
I’ve also run into clients that don’t want to write that top-level content. While I don’t always think that’s a good idea, I do think there are cases where it’s better to let them avoid writing what would otherwise be “filler.”
Interesting post. The main advantage for submenus in my opinion is it allows users to get to any page on the site from any page. Maybe it’s the “Poweruser” in me, but I want to navigate around the site with as few clicks as possible, and the submenus allow me to do that.
I don’t really see the click to open submenus very often with the exception of just one link on the navigation bar (usually it’s a “More” or “Change language” dropdown).
Thanks for sharing you thoughts, Austin.
The power user in me is totally on board with you. I do think there is a value to exposing the site structure easily to users. Hovers still feel like the most elegant solution to me but they just weren’t working for my clients and some of their users.
I think a no-submenu solution only makes sense for small sites where those landing pages contain a majority of the site’s most important information. On larger sites, that’s not the case and so I’ve switched to the click-based menus.
The click-trigger also has the advantage of working really well on mobile and doesn’t require playing “catch a mouse” with a poorly-implemented hover-triggered menus.
The “visit the site” link in the second paragraph here is broken. I think its supposed to be “seattleawc.org”?
Thanks, Nicole! Got it fixed now.
“a significant number of people don’t know the top-level menu item is “clickable.”
Surely the answer is obvious – and in the yellow Menu bar example too ?
The example Menu links are plain text – with no visual clue to suggest they are anything other than a header – a passive word.
Before the (dreadful) fad of minimalist websites, Menu bars had distinctive detailing – one or more of:
– bevelled edges
– drop shadows
– borders around each link
– rounded tabs
– colour gradients
– colour changes
– bullet (asterisk, arrow etc)
Despite the many ways to signify an active element – somehow we still “knew” there was a link there.
Now, with designers following the fad of “paring down all unnecessary detail” (in who’s opinion unnecessary ???) – doubt, confusion, delay and micro-stress occurs.
Very thoughtful post! It’s seven year later, and there is still no “standard” way of building website navigation menus. The problems with hover are many, while click is unambiguous and easy to use. Now that mobile is ubiquitous, it makes even less sense to build hover-based menus.