When it comes to dropdown menus, opening on hover vs opening on click is a topic that’s been discussed enough and by now should clearly be settled in favor of click. The UXMovement article – Why Hover Menus Do Users More Harm Than Good – has some very strong arguments against hover menus. And it doesn’t even consider mobile devices which do not support hover at all.
Still, there are people who want their menus to open on hover. In this post, I’ll quickly go over the arguments on why it’s a bad idea. I’ll also describe a compromise for situations where you absolutely have to implement a hover-based menu.
TL;DR: unless you have a very strong reason to implement a hover-based dropdown menu, just use click and feel free to not read the rest of this post.
After I clicked on “My Profile” instead of the huge green “Start” button for the 6th time in a single day, I decided to record this gif and complain to Toggl customer support. They still haven’t fixed it : (
A very brief overview of why hover-based dropdown navigation is not a good solution
The first of the two main arguments against hover comes down to the fact that many computer users are not very good with their mouse. If the user accidentally moves the cursor away from the dropdown menu, it closes. This means the user has to slow down to accurately land their cursor on an item in the dropdown. Also, the user can accidentally trigger the dropdown menu opening when actually moving the cursor towards something else – which is a fairly annoying behavior and something that even experienced computer users have problems with. This topic is discussed in detail in the UXMovement article I mentioned earlier.
The second major argument is touchscreen devices – including, but not limited to mobile. Since these devices don’t support hover, you will need a separate system to make navigation usable. The first solution that comes to mind would be to simply display a typical mobile navigation to devices with touch capabilities. However, it’s actually not possible to reliably detect whether or not a device has touch support. In addition to that, devices with both touch and mouse support should be taken into account (touchscreen laptops are gaining popularity). So as Stu Cox put it, you will have to assume anyone may have a touchscreen.
There is one more very important difference between click and hover menus: the accessibility of the top-level or “parent” item. Take a look at the following very typical two-level menu item:
About Us
Company
Management
Contact
Assuming the menu opens on hover, there is no way for the user to know whether “About Us” is a separate page or just the title of the dropdown menu. If it is indeed a clickable link leading to a separate “About Us” page, many users will not realize that and will consequently never land on that page. And it gets even more complicated: when the parent link is expected to lead to a separate page, the same page structure cannot be used in a mobile nav as there would be no way for the mobile user to expand the contents of the submenu – clicking on “About Us” would lead them to the “About” page instead of expanding the nav.
Opening on click on the other hand is very straightforward. It should be clear that “About Us” is just the title of the dropdown (of course, a visual cue should be used). It’s also not possible to end up in a situation where mobile users don’t really have access to sub-menus.
Taking all that into account, it should be clear that even if a hover-based dropdown menu is used, it must also work on click. Which leads me to the last point against hover-based menus: they are more expensive. Hover-based menu usability is quite difficult to get right anyway and implementing a solution that works properly on both hover and click is definitely extra work.
Why people still want hover-based menus
Some users feel that it’s more convenient when they don’t have to make the extra mouse click to open a menu (although only if they’re capable of moving the mouse accurately). It’s also easier to get an overview of all the submenu links on a page, which is something I do agree with.
But in my opinion, it still comes down to the convenience of some users vs general usability + additional work on implementing a good solution.
A compromise
As developers, sometimes we’re not in a position to make decisions by ourselves. If the client specifically requests hover-based menus and asks if it’s possible to “make them work on mobile too”, we should be able to offer a solution. I’ve put together a brief description of a solution that should work more or less comfortably for all users:
- The dropdown menu must open on both hover and click;
- The top-level menu item must not link to another page;
- If the menu is opened on mouseover, it should only be closed on mouseout (and not by clicking on the top-level item, for example);
- If the menu is opened on click, it should close when another element on the page is clicked (and not on mouseout);
- A “hoverintent” solution should be used – on hover, the menu should both open and close with small delay to compensate for users’ inaccuracy.
The main drawbacks of this approach are the extra work required to implement a proper hybrid solution and the chance that users might unintentionally open the dropdown menu. So we still recommend using click-based menus whenever possible.