I work on a web-based medical records system. In the previous version, main horizontal menu employed ExtJS. It used the standard click to display the sub-menu found in ExtJS. I'm considering whether to change this to hover to display. Certainly hover is more common on websites, but I know some web apps follow the desktop app model of click to display.

I'm read about some of the usability concerns with hover, but it seems if done well (ie - employing hoverIntent or other plugin to avoid the tunnel problem) it can be just as usable and perhaps a little quicker.

Any reason not to use hover for dropdowns on a web-based application? Is there quantitative research showing one method is better than the other?

One note about the audience - this will be used by people in rural clinics in developing countries. They don't have high computer literacy. However, they will be using the app regularly so they will have lots of exposure to the UI.
–
VoodooNov 4 '11 at 22:47

One more note - we are not concerned about access via mobile devices at this point. Desktop only.
–
VoodooNov 4 '11 at 22:48

"we are not concerned about access via mobile devices at this point" = why not? So much better to make that assumption now rather than later.
–
DA01Nov 4 '11 at 23:07

True @DA01 - I totally agree, but this app is pretty specialized. There are privacy concerns with the health records, so they're wary of allowing access via more devices. Makes a lot of sense to eventually move to mobile though.
–
VoodooNov 4 '11 at 23:16

3 Answers
3

Even if you are not considering mobile devices, newer desktops are ever increasingly being sold with touchscreens so the mouse is losing its total dominance as a guaranteed user input device. Even in rural clinics in developing countries you cannot count on them having mouse only interfaces as India is leading in cheap touch technology that could become a big seller in specifically those areas.

So for the easiest answer and to future proof your web solution I would not rely on hover menus even if they could be a little faster for navigation. It takes too much on faith for what your end user will have available.

Good point Benjamin. will keep this in mind for the future, but am still looking for thoughts if we're talking strictly about mouse/keyboard desktop interface. This system is only used on a specific set of computers and none will be upgraded to touchscreen soon.
–
VoodooNov 5 '11 at 0:25

1

Well a rule of thumb for business applications is to make every action explicit. Hover menus are good for browsing nonspecific or general tasks but application users have a learned behavior of the application they are using and are put-off by automatic behaviors independent of conscious action. I take it this is a heavy use application so you would want to make every behavior explicit. Avoid hover menus as the initial novelty quickly turns to annoyance for the power users.
–
benjaminNov 5 '11 at 1:49

+1 for the point about making actions explicit. Perhaps I'm just playing the devil's advocate, but can we really say "Avoid hover menus as the initial novelty quickly turns to annoyance for the power users." - if done well doesn't a hover menu have similar functionality to a click-based drop down? You go to the item target area and then either hover (presuming happens instantly) or click to display? Just curious...
–
VoodooNov 7 '11 at 7:51

And that is where the catch is. A hover menu has to happen instantly else a click would be faster and the menu would slow them down, but if it happens instantly then the area of the screen where it exists becomes a hot zone. Graphically changing even when the user doesn't want it to and can be distracting. Generally speaking the menus are usually located in high traffic areas near other controls or near the top of the browser where they are likely to pass over as they move from clicking the URL or bookmarks. If not in a high traffic area then your menus are probably not intuitively placed.
–
benjaminNov 7 '11 at 17:39

I'm against hover menus for a simple reason: it can be activated accidentally. For instance, on SE, if you have the mouse pointer at one spot and just use the down key to scroll down, you might activate the hover. So, instead of seeing the expected text or image, you are looking at the hovered whatever.

The 'only' exception (that comes to my mind) is a hover in-place: A command button that changes color when the pointer is over it, for instance. Anything that occupies more space is a no-no for me.

I work on a website in India, and we recently implemented information that shows up on hover at many places on the site - we've noticed during qualitative research that most users tend to completely miss out on the functionality, and we've gone back to showing the information without hover.

Hence, if you are developing an application to be used in rural areas in developing countries I would strongly suggest that you do not use the hover functionality - computer literacy levels are very low. In a country like India you will see that even a tier-1 or tier-2 city user is someone who accesses the web largely out of a cyber cafe and so would be using an ancient desktop on a very slow connection. Hovers may not even load fast enough for the user to spot.

Interesting - thanks for sharing your results. When you say "information that shows up on hover", are you talking about menu items or other workflow paths? Or is it where you were providing more information about a certain element shown on the page?
–
VoodooNov 7 '11 at 7:46