46

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

enter image description here

18
  • 22
    I assume navigation still works via Click too? Because if it's just hover then that's a pretty big accessibility fail.
    – JonW
    Jan 4 at 16:54
  • 5
    Is it just a preview and switch back as soon as you mouse-out of the navigation bar? Or does it really navigate and stay there (including a working back button)?
    – Bergi
    Jan 5 at 0:50
  • 77
    Oh PLEASE don't do this! Jan 5 at 4:25
  • 7
    @DiegoSánchez, submenus only. On the desktop systems I've seen, you still need to open the top level menu with a click. Of course, some web sites have menus that open on hover, but that's still different from the whole page changing, because the menu doesn't cover that much stuff on the screen and quickly goes away when the cursor is moved.
    – ilkkachu
    Jan 5 at 9:22
  • 5
    @DiegoSánchez It's how some desktop menus used to work, decades ago; but drop-down menus (that appear as soon as the pointer moves over the menu title) were annoying and quickly replaced by the pull-down menus (that only appear when the menu title is clicked) are almost universal today.
    – gidds
    Jan 5 at 10:05
59

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.

5
  • 5
    Thanks @Brianna_B My gut told me it was wrong but you've analyzed it well and provided the rationale for steering clear of this pattern! Jan 5 at 12:48
  • 14
    Re "many people hover over things they are reading", Or move the mouse cursor away from what they are typing (possibly ending up over the menu).
    – ikegami
    Jan 5 at 14:46
  • 6
    "The user's colleague/mum moves the mouse to put a coffee/some papers on the table" should not be a trigger for major UI change , is the version of this point about hover changes, that sticks in my mind.......
    – Stilez
    Jan 5 at 17:06
  • 1
    And don't forget: How do you hover on a touch screen?
    – U. Windl
    Jan 7 at 1:22
  • I think content-change on hover can be a valid pattern, if the result is the same as scrolling through content, since scrolling is also just a moving interaction. So if you are just scrolling through static content horizontally when hovering over the tabs, most of the mentioned issues would not be a problem.
    – Falco
    Jan 18 at 14:29
31

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.

2
  • 7
    I think that "annoying" is an understatement... It would probably be infuriating to accidentally moving the mouse over a tab, while trying to read something, and having it change all the time... Jan 5 at 16:47
  • @Laurel Good points. FWIW, I've added the URL for the original example: antv.vision/en Jan 6 at 16:15
15

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.

2
  • "physical disabilities that make transitioning on and off of using the mouse or other pointing device excessively demanding" - or lack of decent surfaces to use a mouse on. Gaming mice work excessively poorly on mattresses in use, and sometimes you simply don't have a table. And the touch pad isn't much better. Jan 6 at 15:14
  • @JohnDvorak: Yes! While the hard mandate for accessibility is associated with not excluding users with disabilities, accessibility helps everyone by improving the ability to use the interface under conditions the designer didn't anticipate. Jan 6 at 16:42
6

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?

2
5

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

enter image description here

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.

mailchimp

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

4
  • 2
    I think the biggest difference between what's shown in the gif and a megamenu is that you need an initial click to enter "menu mode" where hovering over choices then kicks in. If there's a hamburger menu button or something that triggers what we see in the gif it might be acceptable, but as a passive interaction waiting on the top level navigation for the whole page it's an accident waiting to happen. Jan 4 at 21:44
  • 11
    @NathanRabe No initial "click" is required to enter "menu mode" in the two examples given - it's all on hover only. (I wish an initial "click" was required as I'm always accidentally triggering these mega menus and find I'm having to locate/wiggle the mouse to get rid!)
    – MrWhite
    Jan 5 at 1:48
  • 1
    I don't know if there is an already existing discussion on UX regarding "mega menus", but IMHO it's already a very bad UX design with lot of flaws (you need to carefully move your mouse to access the second menu without disrupting the first menu) and I'm not even talking about accessibility and adaptability. One major difference between a mega menu and what Op is suggesting is that a menu at least is not supposed to contain useful information (it's only a way to access information), switching the entire page content on mouse movement alone is another level.
    – zakinster
    Jan 5 at 13:12
  • 2
    Your gif is pretty confusing since it doesn't contain the mouse cursor
    – Bergi
    Jan 5 at 14:42
3

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.

0

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.

0

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.