Re: [Usability] Disable Tooltips, what is that about?

[John Levon <levon movementarian org>]

On Thu, Jul 24, 2003 at 10:18:34PM -0400, Dan Zlotnikov wrote:

> 1) The delay in getting one. I am forced to wait for whatever was
> determined to be the appropriate delay before finding out what the
> bloody thing is. In a new program that translates into inordinate delays.

This is a compromise and a perfectly sensible one IMHO. The alternative
would be unbearable (a big "hello" to MacOS 9 balloon help here - that
road has been travelled, and it really did not work too well).

Also bear in mind that the after the initial delay, the user can sweep
along a toolbar and the tip persists.

> 2) The restriction of tooltips to icons only. First, if you need a tooltip
> for an icon, then the icon is most likely not a very well-chosen one.

It's a fact of life that icons are an imperfect way of giving
information. Users need more than that whilst learning their way around.

> Second, how do two words in a menu give me more information about what
> that option does, as compared to an icon? I'm on a Win2K box at this

And I find myself wishing I still had those URLs ...

> Who was it that decided tooltips should only be restricted to icons and
> buttons? Frequently, specialized commands (other than "cut," "copy," etc.)
> are unclear in their one- to two-word descriptions in the menu.

I don't think it's as easy to have unobtrusive tips for menu items. The
use inside the Applications menu probably makes sense but I would not
like to see this adopted in program menus.

> 3) The salience (for lack of a better word) of the tooltip itself. If my
> cursor is positioned over a button in such a way that the tooltip appears
> underneath the cursor, I will be unable to click that button without
> moving the cursor.

A straw man. I've never seen a tooltip application that does this, thank
god.

regards
john