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 to that control. the user can explore the action without invoking it just by hovering the mouse pointer.

The touch devices make this paradigm basically impossible. this limits the usability of the app, which becomes in some cases pretty mysterious.

Do you know if a substitute for the tooltip concept exists for touch devices? they effectively lack one degree of freedom in ui interaction: the pointer position. how to regain this communication channel effectively?

Answer 1

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 2

Perhaps persistent labels giving short descriptions of each more or less "obscure" functionality available on the interface, combined with contextual notification messages when actions are performed -e.g: the user modifies data => notification appears reminding him not to forget to save by using a button that would briefly highlight during this notification.

Answer 3

To paraphrase Einstein, a touch should be as simple as it needs to be, but no simpler.

The underlying problem here is not touch, but state. What state is the object in when you touch it? Does touch change its state? How is the change in state reflected to the user?

From the design perspective, trying to encompass all actions in a single touch will work only in the simplest cases. For any more useful application, a first touch may change state, and that state can be reflected by changes in an object's image, by tooltops (even transient tooltips that go away after a set time), or by other means. Touching a selected object should have different meaning than touching a non-selected object. This needs to be a discoverable aspect of the interface.

Answer 4

Depending on who you ask, they might even tell you that an interface that needs tool tips to be understandable needs to be redesigned, badly (cf. Jef Raskin: The Humane Interface).

In fact, tool tips are a solution to a very specific problem: Iconic buttons with no labels, such as seen on toolbars. Whenever you have labels, use them. No need to provide a tooltip because you already have text to tell what a particular control is going to do.

What's more is that touch interfaces map not very well to today's WIMP interface model. Many controls are good to handle with a mouse pointers but are frustrating to use with a finger. Menus, checkboxes, radio buttons spring to mind. So the interface paradigm for touch interfaces has to look rather differently to today's mouse- and keyboard-driven interfaces.

So I think it's not so much a lack of tool tips that's the problem here but rather that we didn't explore many new ways of interacting with a computer in the past 30 years (basically not since the research done by Doug Engelbart and Xerox PARC in the 60s and 70s).

Touch input is just similar enough that it kinda works for most purposes. But it not only lacks a location-without-touch component but also precision. Basically all touch input is good for is touching something and dragging something. Even double-tap is difficult so what we really need is some fundamental change in how to design and craft UI specifically for a touch interface.

You'll see some of this in dedicated devices, such as the iPhone simply because that's a platform that neither has a mouse pointer nor a keyboard and only touch. This means you don't have to build a UI which has to be usable with all possible methods of interaction (a problem with plagues Windows currently; I do have a multi-touch laptop but for many many tasks touch just doesn't work) but only with one. But a general-purpose solution for "normal" software and computers is pretty far off at the moment, I think.

So I'd advise you to just think a little different about how you design your UI. As said before (and can be read in Alan Cooper's About Face), tool tips are for labeling controls that don't have labels or where space wouldn't suffice to place them. Key usage scenario here are tool bars. But an interface designed for touch would make all controls larger anyway. Many small icons, closely grouped together are a pain to use with touch input even if you had tool tips, simply because it lacks precision.

Answer 5

Reading here got me thinking. Tooltips are generally used for giving a label to textless buttons, but are also a great way of giving more information in the reduced space available in an interface. Sometimes, it's used to provide context sensitive help, or a detailed explanation of a single widget.

Tchalvak's idea of giving all GUI elements a single click common behaviour, and providing a tooltip on double click has its merits, and can even be somewhat discoverable, as many people are used to double clicking on everything they see, regardless of the element.

But I recalled the old ? button that was so popular years back, wich once clicked would transform the cursor into a question mark. Once you clicked a widget, you would see a small tooltip or information balloon. I believe that something like that could be easely used on a touch interface. Because of the lack of a cursor, another visual cue should be given to the user telling him that he is in provide help mode. May be change the tint of the screen and give a small text. It could be also done through multitouch by requiring the ? button to be pressed while pressing another widget to get the tooltip (which should be shown in a slightly separated place in order not to be too obscured by the finger).

But even if it's possible to keep the same technical functionality for us programmers to have tooltips, we should be thinking about the intent, what we'll be using it for.

I would use it only to give extended help when you are faced with a small screen, otherwise, make a help area visible at all times on the bottom of the "window" (refferring to any kind of square-shaped-io-interface), that changes its contents to provide a detailes explanation and/or help for the selected widget, as is done in some preferences windows on hover.

In conclusion, even if we are able to provide easy to use tooltips, we should be thinking of what would you put in it. In a touch interface, I would not put a labeless ambiguous button that needs a tooltip to be understood, but would use it to give context sensitive advanced help and troubleshooting.

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...