During our two-year long usability test study on how users navigate e-commerce sites, we’ve verified that having a category navigation that uses a hover-based drop-down menu (aka a “Mega Drop-Down”) can provide major usability benefits.
In fact, using a hover-based drop-down menu for the category navigation has become a web-convention among e-commerce sites. Our benchmark of Homepage & Category Navigation of 50 top US e-commerce sites reveals that in 2013 86% of e-commerce sites used a mega drop-down, and it has remained almost unchanged since (88% in 2017).
However, despite the popularity of using a drop-down menu, we’ve also observe that 43% of drop-down menu implementations suffer from “flickering” issues that disrupt users’ ability to control the main navigation and navigate the drop-down “frustration free.”
In this article we’ll therefore dive deeper into our usability test findings on the “flickering issues of drop-down menus,” and provide two solutions that were verified during testing.
The ‘Flickering’ Issue of Drop-Down Menus
The core of the flickering issue is that, once users hover a parent category in the main menu and within the drop-down menu that unfolds spot the sub-category they were looking for, they will instinctively move the mouse cursor in a direct line from the parent category to the sub-category. However, in this process the mouse cursor will often temporarily hover the trigger area of the next sibling parent category in the main navigation — causing the entire drop-down content to change.
During testing we see that moving the mouse cursor in a direct line towards the target hit area is such an ingrained and instinctive user behavior that the issue takes just milliseconds to provoke, and that users are often unable to even spot or articulate what went wrong, beyond noticing that “the menu just changed.” Hence, we’ve internally at Baymard named it “the flickering issue.”
43% of drop-down menus suffer from “flickering” issues that will disrupt users’ navigation
At first this issue might appear as a minor interaction detail, but this “flickering” caused great frustration to all test subjects who experienced it. The consequence is that the content of the drop-down menu will change from displaying the hit area that the user has just decided is their best path forward to displaying something completely irrelevant.
To solve the accidental activation of the sibling parent category, users will
- first have to notice that the drop-down content is now all wrong, and speculate what may have happened,
- then they will have to re-orient themselves in the site’s main navigation, to re-locate the correct parent category once again,
- next, hover their mouse cursor over the parent category (once again) to reveal the hover-based drop-down menu,
- now re-locate the correct sub-category within the drop-down menu,
- and lastly, try to move their mouse cursor toward the sub-category, once more, only this time they will have to follow an invisible, non-linear “safe” hover path.
Due to how ingrained this low-level “direct-line” mouse cursor behavior is, we often observed users having the same issue multiple times in a row, before they were finally able to stop their direct-line mouse cursor movement and stop their accidental activation of the wrong parent category.
What makes this “flickering” issue so severe is that it’s simply caused by users trying to interact with something as vital and heavily utilized as a site’s main navigation.
One Simple and One Advanced Solution
When benchmarking the top 50 US e-commerce sites we find that 43% of sites make no attempt to solve the flickering issues of their drop-down menus. Luckily, we during usability testing also observed both a simple and a more advanced drop-down menu implementation that will solve the flickering issue.
1) The Simple Solution: A Hover Delay. A large part of the “flickering” issue can be solved by adding a minimum amount of time the user has to hover a new trigger area (the parent categories) before the current drop-down content is replaced. Typically a delay of around 300 milliseconds is observed to eliminate the worst “flickering” without introducing needless friction for intentional-hover interactions.
2) The Advanced Solution: Mouse Path Analysis. The above solution of using a hover delay is a slightly crude implementation as it has a built-in dilemma:
- On one hand just using a hover delay means that we will also add a hover delay/interruption to all users’ intentional hovering of the parent categories (hence the delay cannot be too long)
- On the other hand, the hover delay should be long enough to actually avoid the issues of accidental activation. Horizontal drop-down menus with narrow navigation items (e.g., the prior-shown Pixmania example uses very narrow double-line items) and vertical drop-down menus of low height (seen in the Amazon example below) are especially prone to the issue, and will need a long delay, as the “safe” non-linear mouse path is relatively small.
By using a more advanced implementation that accounts for the direction of the user’s mouse path we can create the ideal hover delay. We can eliminate any accidental activation of the sibling parent categories by adding an extra-long hover delay if the mouse cursor is moving in a direct line from the cursor’s current position towards the sub-categories. (Or just between the hit area of the parent category and its sub-categories.) In the above Amazon example this is seen in the area marked in red. At the same time we can remove the hover delay entirely when users are not moving their cursor towards the sub-categories, e.g. if they are deliberately moving it towards a sibling parent category.
This more advanced Mouse Path Analysis solution will be a prerequisite for making vertical drop-down menus work decently, as the height of a vertical drop-down menu item will always be low compared to its width (causing the “safe” hover area to be very small). However, the Mouse Path Analysis solution will also greatly improve a horizontal drop-down menu.
(Tip: If a Mouse Path Analysis sounds like too-much coding, Ben Kamens has kindly provided us all with the jQuery-menu-aim script that has this exact type of behavior.)
Using Hover-Based Drop-Down Menus
One might ask why we don’t simply get rid of the hover-based drop-down menu and instead have it be click based. The greatest usability benefit of hover-based drop-down menus is that users are able to read through the main categories, then hover one which might be appropriate, and then based on the revealed sub-categories infer if it is in fact the appropriate category or if they need to explore other main categories. Indeed, during our Homepage & Category Navigation study we found that 55% of the test subjects deduced the correct parent scope and category taxonomy solely with the help of hover-based drop-down menus — it allows them to probe into a parent category without a click commitment.
While the overall concept of a hover-based main drop-down menu is great, real life implementations often fall short, as we find that
- 22% of e-commerce sites do not even have something as basic as a hover delay
- Another 21% have a drop-down menu design that is very prone to accidental activation of sibling parent categories (i.e., they either use a vertical drop-down menu or use a horizontal menu with narrow multi-line menu items) without at the same time using any Mouse Path Analysis feature to more intelligently control the hover delay.
For something as important as the site’s main navigation, using either a basic hover delay or the more ideal Mouse Path Analysis is required to attain a good performance for any hover-based drop-down menu where users can otherwise experience “flickering” issues by accidentally hovering sibling parent categories.