views:

451

answers:

6

I'm thinking of setting the timeout on all my tooltips in a WinForms application to infinity (or an extremely large value). The motivation is that it's annoying for the user if the tooltip disappears while I'm still reading it, without providing any extra value whatsoever as far as I can tell.

Normally I wouldn't ask something like this on StackOverflow, but the overwhelming majority of all software sets timeouts on tooltips, so it makes me wonder whether perhaps there is some important consideration I'm missing? Or is this just an old convention that nobody gives further thought to?

If you would hate infinite timeout as opposed to a short timeout, please explain why.

(If you just think tooltips are a bad idea altogether then that's a separate consideration; this question is specifically about the infinite timeout.)

+1  A: 

I hate tooltips to begin with -- I hate them even more then they disappear while I'm reading them.

I would say go for the infinite timeout as long as it's not getting in the way.

But overall, I think tooltips are a poor idea and they've just been dragged along "because that's the way we've always done it". The trouble is finding a nice, intuitive alternative that solves the problem of providing concise, on-demand, feature-targeted help.

Jonathon
The question specifically said that this is not about the pros and cons of tooltips, but only those of the timeout. Please consider keeping your answers relevant.
Timwi
+1  A: 

I'd go with the indefinite time out. These really short ones like when you hover over your NIC's Connect Using value to see your MAC address always times out before I'm done with it and it drives me nuts. However That said I'd avoid tool tip use as much as possible. Especially if its used to show additional info like the MAC address example. Use them to explain what things mean to the new user, not display new data.

jamone
A: 

There is no benefit to the timeout. Although tooltips were sporadically used before Windows 95, Windows 95 overused them and had them consistently time out everywhere. I find it most likely that everyone just copied the convention without thinking about it properly.

Timwi
+1  A: 

What can your tooltips occlude? If they don’t occlude anything, then infinite timeout is okay. Then again, if you have that kind of space to leave empty, then may be you should use something other than tooltips, such as longer more descriptive labels.

The purpose of the timeout is for the tooltip (which the user didn’t necessarily want) to get out of the way of something the user needs to see. Consider the case of a user hovering over a toolbar control trying to decide if the command is appropriate for a selected item in a document, then a tooltip appears hiding a key part of the selected item they were studying in order to decide. Timeout makes this problem solve itself. This is also one reason tooltips should have a delay.

If the tooltip text is too long to read with a short timeout, you’re kind of stuck between a rock and a hard place. If you leave the timeout short, then the tooltip may disappear while users are still reading it and they’ll have to move the pointer around and re-acquire the hotspot (and wait for the delay), which is annoying. You can increase the timeout, but that means increasing how long other stuff is occluded (and because the text is long, it’s more likely to be occluding something of interest). You force the users to move the pointer to see the stuff, and then possibly move it back to choose a command, which is also annoying. The former is probably more annoying than the latter, but, depending on the density of your windows, the latter is probably more frequent than the former –tooltips should only be used for supplemental nonessential information, which, by definition, means that users seldom need to read them.

If you have long text, the maybe you shouldn’t be using tooltips, but what are the alternatives? I can’t recommend using the status bar because users rarely notice things in the status bar since it’s far from where they’re likely to be looking. You could put empty space right under the controls that needed tooltips and dynamically display text there full time with no delay and no timeout, but you don’t always want to use so much real estate for something users seldom need.

Maybe the solution is transparent tooltips with infinite timeout –or the tooltip turns transparent after timeout to provide optimal readability at first. Cool if transparency would for once improve usability.

Michael Zuschlag
If a tooltip was in the way and I had to wait for it to time out to see something then I'd be annoyed even if the timeout is as small as 1 second, so I'd say if the timeout is needed for this reason then I'm already annoying the user anyway, and need to rethink the UI.
romkyns
I don't have data for the average user, but MS Windows UX Guidelines recommends a 5 second timeout, which seems right around the threshold of annoyance for me. If your tooltips only have a word or two (like they should), you could test 2 or 3 seconds and see if that improves user performance and satisfaction. For more verbose "infotips," MS does indeed recommend no time out.
Michael Zuschlag
+1  A: 

If you go with infinite timeout, 1) make sure to provide plenty of inactive space, 2) make sure they expire properly onMouseOut. Because the only thing more annoying than a tooltip you can't read because it expires too quickly is a tooltip that obscures an important piece of information and doesn't want to go away.

I think the most blatant abuse of non-expiring tooltips was the early Enlightenment desktop manager. EVERY desktop element provided non-expiring tooltips, and the desktop itself did too, producing a tooltip good half a screen high and wide containing a comprehensive help on all you could ever do with the desktop, except of how to switch tooltips off.

SF.
+2  A: 

Note that using the Win32 ToolTip API (which is what the .NET ToolTip class does), you can't set an infinite timeout on Win32 (max is ~32 seconds). Actually MSDN states that you can't set a delay of more than 5 seconds, but oddly enough 30 seconds works well for me. If for some reason it doesn't work for you, there are workarounds. I think 32 seconds should be good enough for most tooltips, otherwise you'd have to roll your own (see here and here for ideas). Lastly, you should probably address the reappearing problem. For more information see the CodeProject articles here and here.

Good luck !

ohadsc