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

This may be helpful:

Google Material Tooltips

They say tooltips are

Summoned by:

• Hovering over an element with a cursor
• Focusing on an element with a keyboard (usually the tab key)
• Upon touch

It doesn't have a lot of information about mobile only. About the only one you can meet is the on touch, which is frustrating if your button does something, you don't want to touch it before you know what it does. Long press may work but some apps require long press for other functions, it's a used UX path and a user would not expect long press tool tips unless you tell them.

I am thinking that tooltips may just not work the wonders on mobile that they do on desktop. Without hover, you need another reserved way to quickly remind or show a user what an icon or button does.

The best thing I can think of is the help mode. Pressing settings then 'help', displaying short card on the bottom saying something like 'click an element for help' and a 'dismiss' button. Then hitting tool tipped elements will show you a the extra information for them.

I see above this mentioned but another modern use case for this are games. They are often designed with a joystick in mind, which means they have roughly 14 buttons to work with, yet most are taken up by game functions.

In RPGs they typically have complex stat screens that are guaranteed to be unknown by the player (often they invent new systems for each game) full of numbers that are important, but players don't know. Many of them let you hit the select button to get into a tooltip/explanation mode.

This may well work in an app that is complex enough to require tooltips on mobile and is the only pattern I can see right now that isn't so far outside common ux designs.

Answer 2

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 3

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 4

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 5

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 6

I can think of a couple of solutions to this problem

1) Design your app to not need tooltips. Put text on buttons (however small), use straightforward icons, or show a "help bubble" on "first use of a button" (with option to "not show this again" once user has learned what a button is for)

2) Respond to events on touch up, not touch down. Respond to touches that have been held for 0.5-1 second by displaying a "help" bubble. If the help bubble shows, the button's normal event does not fire on touch up (so users looking for help don't end up triggering actions).

3) Use the "question mark" drag & drop paradigm that @voyager suggested. Or, have the user "tap" the question mark first, then tap the item he needs help with.