Re: tooltips

On Jul 10, Joseph J. McCarthy wrote:
> What really confuses me though is the fact that *turning off* tooltips
> seems to be in higher favor that simply changing them in an innocent
> (but perhaps never-to-be-found) way. The worst case scenario of my
> suggestion is that people never actually use the tooltips (which is
> identical to having them turned off!), while the best case is that
> tooltips become useful in a non-annoying way.

I agree here.

I've always hated conventional "tooltips" for two reasons:

1) They are help messages that appear without any explicit user
   request, (think annoying as in Microsoft's paper clip).

2) They often obscure other information, forcing extra user
   interaction just to make them go away. (And, in the worst of
   worlds, this might trigger more tooltips and we get into a nasty
   loop here).

Shifting to a model where a tap-and-hold brings up some additional
help information seems a very valid solution to point #1.

The fact is that on a limited size display, where we are trying to
cram lots of functionality into toolbars, etc. there's only so much
information that can be encoded in tiny little buttons, so it *is*
helpful for a user to be able to verify that a button actually
performs the expected action before it does so. And letting the user
hold the button down for a bit before releasing it seems a logical
mechanism.

If this route is decided, one thing to keep in mind is that the
tooltip that pops up will likely be obscured by the user's hand and
stylus. So it should probably remain there and render the button
release ineffective so the user can move away to read the message,
then click on it to make it go away.

At least, it seems like this might be a workable solution that would
address both issues that I mention above.

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth_at_east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725