Imagine a user who is filling out your form to buy your product. They suddenly come across a field they have questions about. The good news is that you have a help tip next to the field to answer their question. The bad news is that it opens on mouse click, instead of hover. If your help tips open on mouse click, you could make users worry about losing their information.
Fear of Leaving the Form
Many users are afraid of help tips that open on mouse click because they expect the link to take them to another page away from the form. The user has just spent their time filling out a large part of the form. The last thing they want is to lose all the information they entered by clicking a link that takes them off that page.
Even though the link opens the help tip in a pop-up window, the user doesn’t know this. To them, links are affordances used to navigate to another page. When they see a link, that’s what they’re thinking and they don’t want to take the risk. This can either make them skip the help tip or forget about filling out the form altogether.
Your help tips should open on mouse hover for many reasons. When users hover over a help tip, it instantly shows. They don’t have to debate whether clicking the link will take them to another page or not. Therefore, there’s no fear of losing their current information. Help tips are usually short and compact that opening them on hover is more efficient than opening them in a pop-up window.
After a pop-up window opens, the user has to close it so that they can continue filling out the form. This not only takes effort for users to do, but it takes their attention away from the form. A help tip that opens on mouse hover easily closes when the user moves their mouse off it. Help tips on mouse hover don’t just subdue user fears, they’re quicker and easier to use too.
Accessibility of Mouse Hovers
A mouse hover is different from a mouse click, but you can make it accessible too. To create a hover effect, you would typically use the onMouseOver event handler. However, this is not enough for keyboard users. They need the onFocus and onBlur event handlers with it as well. These event handlers allow users to trigger mouse hovers with their keyboard. Visit the links below to learn more.
As users fill out your form, they should feel comfortable every step of the way. If they need help with a form field, your help tips should open on mouse hover so they don’t have to worry about leaving the form and losing their information. Users need to be free of fear and doubt when they fill out forms.
Book
Affiliate
It’s a good point. I totally get the thinking behind this. But, what about the mobile (and tablet) world? More and more, I’ve started rethinking my use of hover simply because it doesn’t exist on touchscreens. Maybe we use a tiny down arrow to indicate that the information expands (rather than taking the user to another page)? That may get at the same thing and work on all kinds of screens…
I’m glad you caught that. The hover is only going work for the web. With mobile devices, it’s going to open on click. You don’t have hover abilities on mobile, so you have to let users know that the help tip is going to open in another window. You can put a new window icon next to the link like this
or this 
And you can click outside the button to close the window. It triggers the onblur event anyway.
Hi Anthony,
I’m concerned that some readers of this article may follow your recommendation without considering the universal accessibility. Have you tested this technique with a wide range of users and on a variety of devices?
If mouse is needed to activate these tips, where does it leave keyboard-only users, users of mobile devices, or users of assistive technologies which may not support/work well with this technique? Besides, hover has its own usability problems, particularly for older users who may not have steady hands.
Caution is needed when implementing this technique…
Your concern is warranted. Accessibility for mouse hovers is something most designers aren’t aware of. I mistakenly forgot to address the issue in the article. So thank you for addressing that for me. I have added information on how you can make your mouse hovers accessible for keyboard users as well.
Nice. Except of course for mobile users who don’t get to hover and who therefore get zero help…
Of course, you also need to make sure the tip works onclick as well, for those on devices where you can’t mouseover (e.g. phones/pads/tablets)
This feels like good sense, but what about touch screen interfaces, where hover isn’t an option?
Makes total sense. But i find the hover option when you don’t need help to get in the way. We recently moved from hover to click for that exact reason. Be nice to see if there was a study on conversion using both with all other things equal.
Good piece anthony.
Two thoughts:
1) If users have the fear that clicking a link will take them away from the page, they may not even go so far as to hover the mouse over the help link since typically you don’t mouse over a text link unless your intention is to click it.
2) So, in addition to adding it as onMouseOver/onFocus to the link, I would consider adding it as onFocus to the input field itself. This way, as soon as the user tabs into/onto the field in question, the help tip shows up in a non-intrusive way. It then goes away as soon as they tab away (onBlur). I’ve seen this approach to good effect on a number of forms recently.
Good stuff –
So, for those users who tend to have the mouse follow their eyes, using onhover as a trigger for these will have unnecessary help panels popping up all over the place, and overlaying the form elements that they are scanning before. I’ve seen it happen in usability tests. It’s not a better alternative to clicking, while your reasoning is somewhat sound. It’s also not 1996 any longer, and most users are familiar with the help-opens-up-as-a-pop-up paradigm.
We need two things.
First, we need browsers to support this natively, without the use of JavaScript. It’s a common-sense thing to do, and it would help HTML semantics.
Second, we need some kind of widely-accepted notation to communicate the difference between typical links, popup links and hover link areas. Actually, there is one for hovers, it’s just not very well-known. Dashed underline usually signifies an element that has a tooltip.
In regards to touch screens, in my opinion, the ideal behavior would be as follows:
1. If you hover over highlighter text, the tooltip shows up with a tiny delay.
2. When you click on the highlighted text, the tooltip is displayed permanently.
3. If you click on the text again, the tooltip is hidden permanently (until you click on the text yet another time).
4. If you “click away” from the open tooltip, you reset it to the default state (closed, opens on mouseover).
I love the idea of dashed underline links for signaling hover. I think more designers need to use it so that more users are familiar with that affordance.
Interesting brief article,
but – as others have already mentioned, it is a good and smart solution, but it depends on your whole form, complexity and the device …
and furthermore the final question is …
‘What do the user, consumer and customer recognize as helpful?’
What will user require and identify as help and as helpful … two years ago I have written an article about that topic …
http://ux4dotcom.blogspot.com/2009/12/help-how-when-and-what.html
maybe it is interesting for one or two.
Anthony,
While I understand your point that users are scared to click a link (especially when a form is half filled), solving that issue with mouse-hover may not be the right solution. It opens up other issues like, to me mouse- hovers are usually ANNOYING. I don’t want windows popping up when I didn’t ask. Moving the mouse is something people do all the time on a web-page and if brings up uninvited pop ups, it will be very irritating.
I’d rather put a small comment underneath the link (that it will just open a popup window and will not take the users away from the page).
Or even better, if the web world can standardize a color for popup links (like blue for navigating to a different page, may be green/red to open a popup within the page).
There is no such thing like “onFingerOver”. It’s time to rethink some old UX.
No javascript required.The attribute
title=”this is a help tip”
works just as well.
Better yet, “This help tip opens in a pop-up window. You can read it, then close it, and return to your work.”
That covers all their fears—that they would leave the page, that they would lose their place, and that they would lose the data they’ve already entered.
The “title” attribute doesn’t work on mobile, unfortunately.
I think a help bubble that can contain formatted text and images (like the security code on credit cards as an example) should appear on focus of the text box or drop down etc. but also be accessible via hover/click events in case the user wants to move down the page reading the help before starting to fill the form in. That would allow keyboard and touch screen users access too. That said I try and use help bubbles as sparingly as possible because they usually distract me when filling in a form.