Tooltips in the era of touch

Question

Tooltips are an incredibly useful interface paradigm to know an application. They are the mapping between the visual control and the application specific action associated t

Answer 1

I find tooltips very helpful and I think everybody arguing they are not needed on a good UI design thinks very limited.

Just to give you some idea ...

Generally a good UI design (as a lot of other things in life) is one that is effective and efficient over a certain period of usage time. Effective means, you can do what you expect you could do (e.g. making a call with a mobile). Efficient means, it is doable with minimal user effort (e.g. just typing the numbers and pushin some "dial" button, not having to navigate through some menus first). Over a certain period of time means, that it may not be optimal on first usage or, the other way around, after you got to know it and everything in between (e.g. an airport terminal screen maybe needs to be more focused on one-time-user "dummies" than a video editing software for professionals like Adobe Premiere).

This said I find tooltips extremly helpful in situations, where

• as a designer you do not want/cannot explain every detail about some GUI functionality within some given UI area
  • due to usability, available overall space etc.
  • e.g. taking the above examples it may be helpful even on a simple mobile call scenario for elderly people.
    • That may be not familiar with a lot of things we "freaks" ;-) find trivial.
    • And they should be encouraged to click around without the fear to accidentially call some shopping hotline and beeing finally convinced that they cannot live without the 1000 EUR vacuum cleaner.
    • so in this case a one-click tooltip paradigm could make sense
      • generally I wouldn't recommend it though
• as a user you are not sure about the meaning of some provided action/button etc.
  • again sticking to the previous examples, even an experienced Adobe Premiere user may not remember all the details about a certain functional area of all the available modules/plugins
    • e.g. if most of the time you cut videos and seldomly adjust audio settings
    • whereas others may have the problem vice versa

Now back to the limitations and possibilities of a touch interface...

• :-) Hover: I recently saw somewhere, that some devices can recognize the finger before it actually touches the touchpad or it differentiates between the touch intensity (e.g. only very soft touch). This would seem the perfect pendant to the established tooltip functionality on WIMP interfaces to me
  • of course it would be dependent on the touch hardware capabilities
• :-) Zooming UI: I actually like the Zooming UI concept mentioned by Joey as well
  • the concept of using only two fingers is already quite common for zooming and the idea is quite intuitive, e.g. showing more details, like typical tooltip infos, on zooming on a button
  • but it admittedly introduces the problem of differentiating between I like to have a tooltip for this button and I like to zoom the whole area in/out, not having the button tooltip near my fingers in mind
    • although I would think that typical tooltip-enabled areas are quite different from zoomable areas in general
      • e.g. some PDF readers content area is generally visually quite separated from e.g. some toolbar (button)
    • tooltips for non-action areas, like some text area are again not trivial to handle or would require some more "gesture differentiation agreement"
  • from the development perspective it seems also quite robust
• :-) QM: the question mark click or drag'n drop feature solution could be a good alternative too
  • having a lot of these everywhere on the screen seems stupid, especially when they have to aquire a certain space to be clickable/draggable
  • having one to drag everywhere seems better, but again would require the space for it on the screen
  • from a development perspective I would find it at least a little difficult as a general solution because the drag'n drop is a common feature and differentiating in a UI between here comes some tooltip drop I have to handle and here comes some file drop I have to handle (e.g. on a file upload area) may not be easy or at least common ground to existing frameworks
• :-| Hold: the idea to trigger the tooltip if the user does not release the push after a certain period of time, e.g. 1s, seems to be a 2nd best solution to me
  • it is already a common feature in some scenarios, as the mentioned on-screen keyboard popups (e.g. resting on an "o" and getting a list of choosable alternatives like oóòô)
  • again it requires some trust from the user, that it won't execute the areas action on the release
  • on some buttons it may be difficult to differentiate what the user wants to do, e.g. clicking on a "+" sign/button to increase some number and holding it down to increase more or faster may contradict this tooltip functionality
  • for non-action areas a push-hold action may not seem intuitive
  • from a development perspective it could be rather easy although some behaviour contradictions like mentioned may exist
• :-| SCT/DCA: the solution single-click showing tooltip, double-click executing action I could imagine to be useful in limited scenarios
  • e.g. the mobile call for some elderly or dummy people mentioned above or where the action should be kind of protected from unconcious or unsure usage
  • again the development perspective looks robust again here
• :-/ SCA/DCT: the solution single-click executes action, double-click shows tooltip seems very strange to me
  • if you are not sure about some functionality you would hesitate to click a button at all, and surely not twice, especially if you cannot be sure if you can expect this behaviour
  • the development perspective could be problematic here:
    • after which time is a double-click two single-clicks?
    • what if the second click is not recognized or cannot be recognized, e.g. because some other popup comes up, the UI layout changes suddenly, the user did not carefully aim, ...
• :-/ Other Gestures: using other gestures mentioned or I could think of, like drawing a question mark over the to-be-tooltipped-area, swiping over the area in some way etc.
  • because this seems no common ground I wouldn't like it because it also may block other functionality otherwise available

Answer 2

The tooltips on onscreen keyboards - echo the letter being touched - is evidence enough for me that tooltips are very useful on a touch interface. I came to this article to see how I could implement that on a mobile web page.

Answer 3

Well, the benefit of the tooltip is that it adds an overlying stage of (very minor) information before an action occurs. So it seems to me that adding that layer back in via a "double click" to perform the action with a "single click" to display information would be an equivalent idea.

I think that we've all seen the movies with the future screen interfaces where someone touches the screen and it splays out a geometric shape of information around that touch. Why not use that concept, have the first touch expand the information about the action as a useful in-page tooltip, and then the second click on the same spot would confirm/perform the action.

If not "click-on-item-shows-tooltip-second-click-performs-action" how about proximity? If you want information about a UI widget, with enough spacing, you could touch next to the widget and receive information on it, touch -on- the widget and perform the action.

Tooltips provide so little information, generally (pointer vs. hand, text-tool-tip, hover bolding) that I think that you could also just duplicate the tooltip information by paying close attention to user action history. If they've been clicking on two thing more frequently than another thing recently, have the default tooltip & added value & emphasis appear for those few more frequently clicked things instead of others.

Edit: Also, thinking about it more, drag in a space that doesn't need scrolling or the like seems like an alright trigger for tooltip information. Take the iphone's keyboard, for example. Each letter has a tooltip while you drag it, whereas the letter itself is actually activated when you release. Aids in repositioning precision.

Beyond that, I think that specifics come into play. Are you talking laptop tablet? phone touch interface with very limited space? I think available space plays a large part in how you have to do things with a touch interface.

Answer 4

My answer isn't perhaps so practical, but...

The problem would be solved if apps all supported undo functionality, and people got used to knowing that they could ALWAYS reverse any action.

As Andreas says, "if you are not sure about some functionality you would hesitate to click a button at all".

But with undo as the safety net, there can be more "doing", and less "hesitate, worry, find out what will happen before I tap... tap".

This is one of the reasons why the Back button is so popular, and Android even made it operating system-wide.

Unfortunately (here are the impracticalities...)

• building reliable pervasive undo is far harder than tooltips
• enough apps need to support it to change the mindset of all users (ha!)

Answer 5

Keeping in mind that hover tooltips are terrific help for beginners and they need no action to learn for them because beginners are always slow and they pop up while insecure moving the cursor. On the other hand, they are excellent because they do not slow down the power users.

For tablets I would pick up the idea of the question mark but add some more complexity:

1) When you tap on the question mark, it switches on the "Help" mode. 2) you can then tap on the control in question and it shows the tooltip. 3) if you then tap on the same control again, it terminates the help mode and executes what ever the control should do. 4) if you tap on any other control, it shows the his tooltip and the help mode keeps switched on. 5) one can terminate the help mode by tapping the question mark again.

Answer 6

What about touch and hold? I think that would be a fairly simple interface rule in terms of both usability and implementation. Like a lot of things to do with usability though it will be hard to say until any one idea has been around for a bit of time to see it used in a bunch of different contexts...