Need a better view of Uncle Harry’s hairy nose? Just hover over his thumbnail and you’re all set! Want more info about that remote-controlled beer pager without leaving your current page? Hover, friend. Hover.
It has become common practice for many sites and web apps to display certain types of “pop-up” UI elements on hover (mouse-over). For example, banner menus, contextual help, and preview cards (e.g., person cards, movie cards, etc.) all commonly display when users hover over a link, icon, thumbnail image or other UI element.
The good and the bad…
When using a mouse (or other device that controls cursor movement & interaction), this behavior can be really useful – allowing a single UI element (e.g., a link) to provide two different capabilities for hover and click. For example, it’s common that hovering over a person’s name link will display a person card; whereas clicking the name navigates to the person’s profile.
The biggest criticism to allowing hover to invoke pop-up UIs has been the complaint that these pop-ups can appear without user intent – for example, when the user drags their mouse across a screen and inadvertently passes a hover help icon, a link, or a banner menu. This complaint is especially strong (and valid) when the pop-up interferes with a user task or displays something that the user considers of no value (e.g., an advertisement).
Enter the sustained hover!
Sustained hover is just what it sounds like...we don’t display the pop-up on simple pass-by, but require that the pointer rest over the underlying UI element for a sustained period. This allows users to request the pop-up and usually prevents inadvertent display.
So, what’s the right delay?
We believe that delay times should range from 300-700 ms, depending on a number of factors including the likelihood that the user’s cursor will inadvertently come to rest on a particular UI element (largely determined by placement and density of pop-up UI hover targets) and user expectations driven from common industry practice.
For example, 300 ms appears to be the appropriate delay for invoking a banner menu. We have user data indicating that immediate display annoys users who intend to simply drag the cursor past the menu. However we’ve also found that if we set the delay to more than 300 ms users report that the menus feel “sluggish” (this is likely largely in comparison to the common industry practice of implementing zero delay or a very small delay).
On the other hand, object preview cards and the like are often invoked from lists or grids of data and are invoked on hover over thumbnails and/or displayed names of items. These types of elements often populate a fairly substantial portion of the UI; therefore it’s generally more appropriate to allow for a little longer hover. In this case, we believe it to be a best practice to also provide a subtle, but immediate visual change to the underlying element. This is a good way to tell the user that a pop-up is coming if he just holds his little horsies for a half second or so
Does sustained hovering solve everything?
Nope. Unfortunately, this technique does not prevent inadvertent display in the less-common scenario in which users rest their cursor on an active UI element. It also doesn’t tackle other concerns of hover-invoked UIs like how best practices for dismissal and how to handle touch screen interaction. I’ll look to blabber about those in a future blog post.