[haiku-development] Re: WebPositive misleading tool tip on new tab
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 22 Feb 2013 19:17:35 +0100
Am 22.02.2013 um 18:06 schrieb pulkomandy@xxxxxxxxxxxxx:
>
>> Whether or not other elements of the UI have tool-tips in Haiku right
>> now doesn't convince me in either direction. Basically your view on when
>> a tool-tip is needed is arbitrary. It seems the programmer should decide
>> on gut feeling and in case of doubt he may also assume that the user has
>> read the user guide or is willing to just click on things to see what
>> happens at least once.
>>
>> Your line of thought does not address my point in the least that having
>> tool-tips does not hurt. I tried to provide an argument why they can't
>> possibly hurt on small icons.
>
> By adding atooltip, the programmer thinks he has solved the issue of
> discoverability of the button action. But, the tooltip discoverability is
> even lower than what you get by just trying to click the button. Hovering a
> button and waiting for the tooltip to show up is not a standard UI action, so
> it is not discoverable. It is also not compatible with touchscreens, or other
> input systems.
>
> Tooltips are an attempt at self-documenting user interfaces. I don't think
> they work well. You only get two or three words to explain what the button
> will do, which usually isn't better than a small picture. Tooltips are also
> sometimes misused to display important information. An example is our screen
> preflet that will show information about the graphics card being used when
> hovering the screen preview.
>
> To solve the issue of non self-explaining icons in toolbars and other places,
> the proper solution is explaining the meaning, in great length and details,
> in the user guide. I feel this is what people expect : a lot of everyday
> tools and hardware comes with lots of buttons and pictograms that you either
> already know about, or can learn about in the user manual. There's no point
> in adding an explanation text on a label near each of them.
>
> Another solution, for toolbar icons for example, is allowing the user to show
> a label next to the icon and use that as the initial setting (Beam does that,
> for example). The text allows quickly exploring the UI at a glance, without
> having to hover each icon and wait for the tooltip to pop up.
You are making some good points. However I am not much into user guides that
explain every button in great detail. Those are exactly the ones I can not
bring myself to read. In a guide text, I would like to understand concepts and
workflows.
I can think of so many examples where a tool-tip is exactly the right solution.
Usually it's the icons that represent some concept in your software that just
can't be explained by a 16x16 graphics. Rather you try to think of something
that can be memorized and it simply works well to explain the feature in a few
words in the tool tip, maybe giving additional non-crucial info like the
short-cut. Also there might be buttons that are obvious to use and even
explore, but there is another, non-obvious way to use them and you can explain
it in a tool-tip. Doesn't matter much if it is never discovered, but
potentially helpful.
Agreed that it doesn't work with touch screens (at least it would work with
tablets and pens). Take iPhoto on the iPad. When you open it the first time, it
sort of displays all "tool tips" at once like dialogue bubbles in a comic. I
don't think that works so well, since you get a lot of information all at once.
What I tried to say originally is that there is a situation in which a tool-tip
can be helpful - hovering a small icon wondering what it does. And my point is
that this use-case doesn't get in the way of anything else, so why not support
it?
Best regards,
-Stephan
Other related posts:
