Is it good practice to allow users to navigate simply by hovering on a menu item without clicking?

Question

A pattern I have noticed recently on some (desktop) websites is that users can navigate simply by hovering on menu items.

While this is more efficient (fewer clicks) it feels unexpected and therefore unintuitive to me. I am wondering if it feels "wrong" only because it is a newer pattern, made possible by single-page applications etc.?

In short, is there any fundamental design principle being violated here?

Edit/Update: The example, which some have asked about, was taken from https://antv.vision/en

Answer 1

This seems full of usability issues, as well as possibly performance issues loading interim unnecessary pages (e.g., user moves mouse across tabs to access one several over). To start, if there's user interaction within the tabs, even as simple as selecting a filtered option, are these changes preserved when tabs are swapped? Is there some reason swapping tabs would cause data loss? Is the hitbox going to overlap with reasonable movements within individual tabs?

Using this heuristics list from NN: https://www.nngroup.com/articles/ten-usability-heuristics/

I'd say this violates #4 at the moment: consistency and standards

Follow established industry conventions (external consistency).

As well as possibly #1, Visibility of System Status, since it changes the state of the whole page without a typical 'interaction'. Hover interactions are expected to possible show more information, not change your context.

Sites and apps should clearly communicate to users what the system’s state is — no action with consequences to users should be taken without informing them.

And is also likely to be problematic for accessibility unless this is something you can navigate with your keyboard, and depending on the size of the hitbox for the hover, plus many people hover over things they are reading.

Changing the whole page view on hover is definitely not the current convention, though I agree with Danielillo that this could derived from megamenu interactions.

I also think it's a problem for #2, user control and freedom. Because this is a non-standard interaction, users may not understand why the page is changing. They may think they accidentally clicked, and may rapidly swap pages without intending to.

Part of a great user experience is nurturing users’ feeling of control over the user interface (UI) they happen to be using.

Similarly, as discussed in this this mega-menu article, there's the challenge of "what constitutes a hover with intent to interact", also covered more generally in Timing Guidelines for Exposing Content

If mega menus are displayed on hover, one challenge is to distinguish between two different user intentions:

1. The user is just moving the mouse towards a target on the screen, and the mouse trajectory intersects the link corresponding to the mega menu.
2. The user actually looks at the navigation categories and needs more information about them. The second situation should trigger the mega menu, but the first should not.

and

If the hidden content displaces or covers other elements on the page, designers need to be extra careful and require a longer mouse stop over the triggering element before exposing the hidden content. In other words, the more disruptive the content displayed, the more certain designers need to be of user’s intent before triggering the animation.

So, how long must a user hover over a tab before you alter the whole page? Since the current standard for changing pages/views is clicking, users would likely just click if the waiting period is half a second or longer, but if it's less than that, they are likely to accidentally trigger while moving the mouse across the screen. Essentially, you'd be choosing between losing whatever benefit you hope to gain from making this a hover interaction instead of a click, or making it likely to happen accidentally. Furthermore, if click is not a back-up option, it will cause the opposite: fast moving users will be frustrated.

I'd say that unless there's some reason why rapid, no-click movement between tabs is a major efficiency gain, this does more harm than good. I'm not sure how, though, since the user still has to move the mouse to the item, which is usually the more inefficient step in a move-click combo.

Answer 2

This is annoying.

Ignore any hypotheticals we can't judge in the gif. There's still an enormous usability problem. There are a lot of buttons and whatnot at the top of the browser (or even above that on some setups) and trying to access them isn't an indication that the user wants to go to a different tab on the website. For example, you might want to go briefly check on your email in another tab, but now you can't just fling your mouse to the corner of your screen because that will take you to a different page on the site. You have to carefully navigate around the menu, or you need to spend more effort to get back where you were.

It doesn't matter if it's an uncommon pattern or not. (But being uncommon only works against it.) It's just not good for navigating.

Now, another answer mentions (mega) menus. These are different because they don't get in your way when you're looking to move your mouse somewhere else. The hover to get somewhere else only applies to deeper parts of the menu, and you still need to click to go to a new page. And the menu, of course, doesn't have content anyone wants to look at. It's only a means to get somewhere else.

---

Now, I visited the site and tested it for usability problems that weren't obvious from the gif, such as if it could be used with a touchscreen or keyboard. (It can't.) The interface failed miserably in too many ways to mention.

But what does this have to do with the menu opening on hover? Nothing, absolutely nothing. There's no reason why having a menu that opens on hover would cause these issues. But also having the menu open on a click wouldn't per se fix the issues. Only putting effort into identifying and fixing the issues would be adequate.

Answer 3

Having content-obscuring changes happen at all on "hover" is an accessibility bug, so this is a non-starter. Not only may it be difficult or impossible for users with particular accessibility assistance devices to discover or trigger the hover behavior. It can also limit accessibility for:

• users who do not use assistance tech but who have perceptual/attention issues whereby the hover reaction severerly disrupts their reading,

• or who need to use the mouse pointer to track what they're reading, only to find what they're reading becomes hidden or altered as they do so,

• or who have physical disabilities that make transitioning on and off of using the mouse or other pointing device excessively demanding, who find only a moment after they take their hand off the device (possibly shifting it at the same time) they have to try to regain control of it again just to get rid of whatever just popped up in front of what they were trying to read.

Accessible design can at most use the hover action for non-essential visual cues that do not reflow the page or obscure any content.

Answer 4

I'm curious what are the websites where you have seen this pattern emerge. To my knowledge this is not common.

I'd see this is unexpected and likely problematic. Imagine for instance if a user performs some actions partially, like filling a form, then moves the mouse above to switch to another tab on their browser and accidentally hovers over the navigation, they would go to another page and their progress on the from would be lost.

Also, as most websites these days are expected to be web friendly, what would be the mobile equivalent to this hover navigation?

Answer 5

I think it's a derivative of the mega menus hovering effect where it's a fairly common pattern:

What is different in the example of the question is that each menu has vertical submenus and this makes it a bit unpredictable because of the unusual, although it would be necessary to see how the effect continues on the page.

Mailchimp.com use exactly the same effect with menus and submenus and is quite well done. I think it's because of the location always on the left, and the following content placed in panels, without occupying the entire screen, which makes it easier to interpret that the next step is to follow the same process on each submenu.

Smashingmagazine.com has an extensive study about the possible conflicts and solutions presented by the hovering effect in menus.

Answer 6

This violates the principle of least astonishment fairly significantly. Hover events fire regardless of whether a browser window has focus. You can test this by opening another program and while that program has focus, hover the mouse cursor over a hyperlink in your browser and watch your cursor change.

If my mouse cursor turns into a pointy finger when it hovers over a link in an unfocused background window, that might look odd but it's ultimately harmless. You're talking about changing the state of the program. A user doesn't expect to have that level of interaction with an inactive window that's just sitting in the background.

I usually have multiple overlapping windows open at any given time. My cursor frequently moves past my intended target by a couple of pixels, briefly moves outside my current program's bounds, and then moves back to the button I was aiming for (especially if I'm using that little eraser-nub mouse stick thingie on a laptop). I absolutely do not want to have to worry about accidentally messing up my work in a background program just because my cursor slid 3px too far to the left or because I alt-tabbed the browser back into focus without thinking where my cursor would sit on a page that I cannot currently see. Your customer support people will get endless calls from confused users complaining that their current report "... just started changing settings all on it's own. Now all my splines are reticulated and I can't get them back".

Changing the state of your program should only be done by an intentional act of the user. Clicks are a clear signal of intent and rarely happen inadvertently. The current X/Y coordinates of the mouse are just a transient piece of information that users don't (generally) expect to be significant to how the program operates. Please don't use that information to change your program state.

Answer 7

It's important that simply moving the mouse never changes any state. If the user wants to change anything, clicking should be the absolute least action that does so. (Bear in mind that it may be the user's cat or infant child playing with the mouse! )

With that proviso, as a means of allowing a user to explore the menu, I don't dislike it. I would think of it more as an efficiency issue. How expensive is it to throw all that detail at the users, when much of the time they do not need it? Will there be real cost issues when the number of users increases ten-fold? a thousand-fold? Will it get overloaded, and become something that seriously degrades the user experience? (I can think of one commercial site I use, where the combination of high-resolution no-click graphics with an overloaded website is intensely frustrating.)

Related to my original point, might a user be afraid that if he actually clicks on one of the top menu items, he will initiate some sort of state change without understanding what he has set in motion? This is a point in favour. If you don't do it this way, the other ways are pop-ups on hover, or using the standard blue-circle-i icon, clicking on which is clearly intended to inform rather than initiate an action.

At the implementation level, if the user settles on L7/L7plot (top menu towards right hand side) is there a built-in annoyance that when he wants to go to the left-hand panel to do something with his chosen "view", he may touch one of the other menu items with his mouse and find when hew gets to the left hand side, it's no longer what he was expecting with no clear reason why? Making the menu items activate as a consequence of hovering for (say) half a second, ought to eliminate this problem.

Answer 8

The design principle is that it should behave the way the user expects.

Of course this depends on your user and where they are coming from, and it depends how often they use the app and how they learn to use it. Having some magic capability that's invoked by swiping from the top right corner of the screen is fine if people are using it so often that it's second nature, but no new user is ever going to guess the capability is there.

I have a banking app on my phone where there's a button that does different things depending how long you press it. I couldn't imagine a worse, less intuitive design, but apparently to regular gamers it's second nature. So you have to know your audience.

Answer 9

I haven't seen this used much, but like others have said. It sounds like a terrible user experience.

But what if timeouts were added? For instance, you hover over a menu item and keep your cursor there for 1, 2, 3, 4... seconds. Does that change things? I think it does. More time added would reduce the annoyingness of this UX. But at the same time, if you were expecting the menu to open on hover, you wouldn't want to hover there for a long period of time.

Think of tooltips, and how they open after a certain amount of time. That is not an annoying UX to me. So it might work with menus too.

I guess, what I'm trying to say is. I obviously don't like this UX. But if it were added, I wouldn't despise a 2-3 second delay, as long as you also have the option to open said menu item with click events.