Why is there a convention on the web for dropdown menus on hover instead of on click?

Question

This is something I've always wondered. On all major operating systems, application menus (File/Edit/View etc) only appear on click. However, nearly every web site that uses a drop-down menu instantiates it on hover, not on click.

How and why did this convention come about?

Answer 1

I have no idea as to the actual correct answer to this question, but let me speculate: I think it's because the web has hyperlinks. Clicking on something on a web site is associated with visiting a different page, and as such, if you were to create a dropdown menu that activates on click, the expectation of what it may do when activated is uncertain: will it direct me to a new page or will it pop open a menu? So if you continue that line of logic, creating hover menus makes a lot of sense, because before a user clicks you can present them with feedback indicating they've activated a menu.

It may also factor into the famed internet attention deficit problem which is where all the numbers showing people hanging around on your page for only a few seconds comes from. I know the "users don't click" concept is a myth, but a lot of people don't, and it may lead to a lot of menus being implemented using hover state because the designers expect users won't click because they think it may lead them to a different page.

Further, I imagine it's a repeating cycle: designers see hover menus and design hover menus, which more designers see and more designers design. Not everyone thinks about each individual UI control they're using in terms of why they need it and what purpose it has; many designers I've worked with choose controls "because that's what you use" (see: incessant overuse of the autocomplete combo box; a rant for another time).

Contrast the above with desktop breed apps where there is (usually) no hover state, certainly not as a UI pattern for menus, and I think we've come full circle.

Answer 2

Rahul makes an interesting point concerning the lack of a consistent action on a 'click'; however, I think it goes beyond that into a more general sense of discoverability on the page surface.

People may not click due to the desire not to leave a particular page, but many people will 'mouse over' the page looking for active states. Since the menus react to the hover and not the click, the user can more easily discover the structure of the menu system without resorting to clicks.

This, of course, leads to certain accessibility issues. When I click a menu on a desktop application, the default behavior is to leave the menu open until I make a choice, or click off the menu. This helps users who may have difficulty in maneuvering the mouse to the correct command without coming off the menu (which collapses it in the hover paradigm).

Answer 3

Web apps are are wildly inconsistent in terms of UI, but the user must understand them quickly (otherwise his attention span dries up and he'll go elsewhere).

The menu on hover has much better discoverability - when I see a button on a newly visited site, I have no idea whether it will pop a menu with more options (which I want), or it will take me away, destroying the current state of a page (including half-written comment) - which is obviously not what I want. It takes only a few percent of sites with a latter practice to make me fear clicking something I don't know - and intimidated user is not happy user.

By mouse, we explore stuff that's on the screen, hovering means 'I am currently looking at you', so it is pretty natural that the UI element show either what it does (a menu), or a hint (tooltip: this will delete the post you are writing).

On the other side, not reacting on hover is impolite - user asks what the element does, and you don't answer. People love to feel that they have control and know what's happening; every bit of feedback is important, and by not reacting on hover, you are wasting a chance to communicate.

In our recent desktop software (Outlook add-in TaskConnect), we went as far as putting the help tooltip to every active element, and setting the tooltip timeout to zero - therefore making it appear instantly. You can see a short video of how it looks in action. What do you think about that?

PS: In any case, menu should also always pop out on click, otherwise touchscreen users or keyboard people (including disabled users) wouldn't be able to use it.

Answer 4

Just a guess, but hover is probably used as opposed to onclick because css has a :hover pseudo-class.

Or perhaps dropdown was used because user's did not realize that they had to click to open the menu. Half of the time, a dropdown menu looks just like any other menu until you hover. And the expected action when you click a nav button is for the site to take you to that page. So perhaps users simply were not finding the additional menu options.

Answer 5

"Discoverability" is definitely a factor here.

My distinction is the state of mind of the user, especially when comparing an application to a website.

When you click, you mean to do something, perform a certain action - it has to be intentional.
Users are usually operating applications in this state of mind.

However, (some) websites are more about consuming content. You're browsing, reading and perhaps will perform an action. As a matter of fact, one of the biggest challenges it to get the website visitors to actively DO something, not just visit. Hence it makes much sense to try to push you to do something by showing you the options more easily.

There's another difference between the two states of mind:
Usually you'll be using an application several times, hence becoming a bit more familiar and proficient with it. On the web, chances are that a lot of your users are new, hence they might not know where to look for things and might also be "afraid" to do commit to (click) something they don't know.

Answer 6

Typically, the top item of a menu will take you to the page with that title. You don't go anywhere when in an application. Hover for menu items was developed as a shortcut to see subsections within a particular section of site rather than needing to go to the page to see the subsections. With an app you don't go to the "file' section for example. Abandoning web conventions for touchscreen is a mistake to me. They're good to keep in mind and watch but often and app specifically designed for the touchscreen is better. Websites aren't meant for fingers.