
Tooltips: Secret weapon for improving feature discovery - xTWOz
https://uxdesign.cc/tooltips-your-secret-weapon-for-improving-deature-discovery-e1c380562f2e
======
bhauer
I consider tooltips [1] to be explanatory information about user interface
elements that appears in response to voluntary action taken by the user
(namely—at least traditionally—when hovering over an element).

The example screen-captures in the article appear to be of something subtly
different: involuntary promotion of new features or recent changes. There is
probably a more established term for this UX tactic, but I know it as a
"guided demo." These guided demos are often employed when orienting a new user
with key elements of the application's user interface.

Some distinctions:

1\. Tooltips are in response to voluntary exploration by the user. Guided
demos are usually involuntary.

2\. Tooltips are available at will and infinitely repeatable; they always
appear when the user is "inspecting" an element. Guided demos usually are
once-and-done (and are notoriously difficult for users to revisit later if
they elected to skip them).

3\. Because tooltips are voluntary, they occur at the user's area of
attention. Guided demos are typically attempting to draw user attention to
somewhere it's not already. Hence, guided demos are often coupled with some
form of obfuscation of other UI elements (e.g., a dimming mask layer over the
rest of the UI).

4\. Tooltips are immediate both in and out—they appear on hover and disappear
on exit. A tell-tale of guided demos is that the pop-ups usually include some
form of dismiss button ("OK" button or close button), because they are
involuntary and therefore need to confirm they've successfully captured user
attention.

5\. Tooltips are individual and paced by the user's interest. Guided demos are
commonly linked into a "wizard-like" sequence (e.g., let's walk you through
the three most important elements of this UI.)

If it's not clear from the above, I feel traditional tooltips are generally
good because they reward exploration while remaining entirely voluntary.
Meanwhile, guided demos are a mixed bag: sometimes a necessary evil to clear
an especially difficult UI hurdle, but easily used to excess and disruptive to
users.

[1]
[https://en.wikipedia.org/wiki/Tooltip](https://en.wikipedia.org/wiki/Tooltip)

~~~
chrisweekly
Nice summary. Tooltips are great for self-guided discovery when there's a
cursor; what about touch interfaces?

~~~
frosted-flakes
Less useful because they're only available on long press and your finger often
covers the tooltip, but still available. I imagine most people don't even know
how to invoke them.

For example, on Android, long pressing an icon in the top bar of an app will
show its label.

~~~
java-man
One possible solution could involve showing help bubbles for _every_ ui
component when tapping a dedicated Help or (?) icon.

Tap on a bubble and it expands into a larger one or navigates to a separate
help page.

~~~
wlesieutre
Affinity does this with their iOS apps. Everything shows labels while you hold
a finger on the ? in the corner.

[http://imgur.com/HGQiAtK](http://imgur.com/HGQiAtK)

~~~
java-man
love it!

------
jrochkind1
Please note, the article does not seem to actually be about appear-on-hover
tooltips that many of us think of when we hear "tooltip".

But rather "callout bubbles" that appear on initial screen display, to point
out/explain a new feature (or a feature they want to 'advertise' for some
other reason). They usually either stay there until you dismiss them, or until
they time out.

I have been noticing these more and more, and I think they are worth
commenting upon, I'm not sure this article does a great job of it, starting
with calling them "tooltips" that is misleading some people not reading the
article carefully to miss what it's actually about, as evidenced in the HN
comments here. (To be fair to the OP, they are "tips about tools"...).

One thing I wonder is how effective they are, or if there's any public
research on it. Myself, I'd say ~75% of the time I dismiss them without even
reading them, as being there on page load (and often covering up other parts
of the page), they're getting in the way of whatever I came to site/page/app
to do, and have in mind to get done when I see them.

~~~
badwolf
We generally call them "coach marks" tooltips as most people know them are a
bit of a tricky thing to do on mobile apps.

Coach marks/app tours can be great, however apps that have them, but don't
have an easy method to skip make me rage!

~~~
jrochkind1
There's also the distinction between providing a _sequence_ of them as an app
tour (the case where your comment about skipping them is relevant, i think),
and providing a _single_ one, to ordinary users of the app who don't know they
are taking a "tour", to advertise a specific (usually new) feature/UI device.

The OP examples seem to be more the latter.

"Coach mark" is a good term, thanks.

------
vezycash
Bless you. When I was started using the PC around Win 95, 98 era, tutorials
weren't needed to figure out how to use programs. All I had to do was slow
down every few seconds to read tool tips. And that was the time when intuitive
icons were use.

Now I need tutorials to figure out simple programs - even web apps -
frustrating.

And while we're at it, "Tips of the day" on opening a software dripped
important knowledge.

~~~
throwaway2048
The latest design trend of featureless, flat buttons that don't even have
tool-tips is immensely frustrating.

How is anyone supposed to figure this stuff out?

~~~
3pt14159
What frustrates me to no end is when people have multiple "settings" pages for
a single app. One is under a gear, the other one is under three little bullets
on a secondary page, another is under your own profile image if you click on
it. It's infuriating.

~~~
enraged_camel
That’s because some settings are commonly changed, whereas others rarely.
Cramming every single thing that can be construed as a “setting” into a single
page results in a mess.

Also, like anything else in the app, settings are context-dependent. Some are
system-wise, whereas others might be user-specific. Therefore, it makes sense
to segregate them, IMHO.

~~~
RandomBacon
Then _within_ Settings, there should be "advanced settings" or "more..."

Also _within_ Settings, there should be a tab for "system" and "user".

------
layoutIfNeeded
These are not tooltips. I’d rather call them something like “onboarding
bubbles”. And I hate them. They get in the way when I open some app with a
specific goal in mind, so I dismiss them without reading. But once they’re
dismissed there’s no way to bring them up again - the knowledge is lost
forever.

Compare this with _real_ tooltips, like the one you get in MS Word when
hovering the floppy icon! It appears consistently on hover; tells you the
button’s functionality (Save) and its hotkey too (Ctrl + S).

~~~
ben509
> And I hate them.

It's hard for me to think of them as anything but "fuck off boxes" after
cursing them dozens and dozens of times.

------
pavel_lishin
> _Compare this tooltip to the one below, which is from LinkedIn’s SlideShare
> app. It’s a lot more attractive visually speaking, and the copy is simpler
> and punchier:_

It also doesn't block the actual thing _I care about_. I'm incredibly likely
to just slap that tooltip out of the way so I can get back to what I'm doing
instinctively, and then wonder what it was trying to tell me.

Any sort of tooltip that obscures the thing I'm trying to accomplish that I
didn't request, or that I can't bring back on demand, is a shitty user
experience.

------
whoisjuan
The author is wrong about the name of this UI element. That's called a coach
mark. A tooltip appears in response to a hover interaction and it's perpetual.
A coach mark shows up in the first paint of a new UI feature or interaction
and once is dismissed it's gone forever.

------
chiefalchemist
I do use them but not as much as I used to. The main reason is they're not a
good fit in a touch-based world. Yes, there are gestures that proxy a hover,
but I don't believe that's the nature of most people usage and expectation -
on a touch device or not. That is, using touch so much so often that
influences non-touch expectations.

~~~
laurent123456
Some mobile apps use long press for tooltips. I wish it would become the norm
as it's often that I have no idea what a button does, and tooltips would help
with that.

~~~
tomlong
There's also a pretty long standing convention that long press gets you right
click type functionality. It's a difficult thing to be consistent with.

For me personally it would be nice if there was a reliable way to detect a
quick jab (tool tip), vs a press, vs a long press, but I could see this does
not working well for people with mobility issues etc.

------
Causality1
The biggest UX problem in the world is the hard-on developers have for
constant change in the pursuit of "innovative aesthetics". New and shiny beats
old and useful. I'm sick of having to Google how to do basic things because
using English text on a button is some kind of unforgivable sin.

~~~
kerkeslager
It's not just an arbitrary decision to keep changing things. It's a function
of the fact that companies are in a constant need to grow, and at some point
users get bored with interfaces and leave, even if those interfaces still
serve them the best.

I think one of the big innovations Google Search brought to the table is the
Google doodle. The main features of their interface have remained the same for
over a decade: type what you want to search into the box, click "Google
Search" and a list of results appears with links and brief intro text. There's
new stuff on the search results page that wasn't there ten years ago, but it
doesn't really interfere with the functionality. Such a simple interface would
feel stale after 10 years for most applications, but having the Doodle means
it changes over time, keeping it fresh in a way that doesn't interfere with
the functionality. This allows them to keep users from getting bored with
their product, while also not forcing users to learn a new interface with
every refresh.

I have a lot of problems with Google and don't use their search (I use
DuckDuckGo). But I think we can still learn some valuable things from them.

~~~
Causality1
Ironic that their own products like Gmail are some of the absolute worst
perpetrators of this.

------
smush
Wow. This must be what it is like to be old.

Tooltips are as old as the hills from my perspective, but they've been uncool
for years, only BLOBs use 'em, too confusing for modern users, etc. I use 'em
anyways.

Suddenly someone writes an article and throws up some material design clipart
and poof, tooltips have been re-invented and are cool again.

Is this what it is like for the old timers seeing SOA and ESB coming back as
microservices and 58323213455233999 layers of container/docker/k8s/rancher
abstractions?

~~~
ben509
Worse, we're old enough to see people completely forgot about something and
try to reinvent it, poorly.

------
KaoruAoiShiho
It's just part of the standard onboarding process now. You need to call out
features so people know, but naming them tooltips is perhaps misleading
considering the baggage that word has. There's many different ways to do the
callout, I like this animation from discord for example:
[https://imgur.com/a/fwaAPs9](https://imgur.com/a/fwaAPs9)

------
kazinator
Tooltips are fantastic; you almost can't use them too much, especially if
their appearance/disappearance is sensibly managed by the UI framework.

By "tooltips", I'm referring to those canned pieces of text in a balloon that
show up when the pointer is hovered over a UI element.

The article is stupidly calling something else "tooltip"; namely "tip of the
day" type dialogs that pop up and must be dismissed, which teach the user
about features or usage.

Such events are not called "tooltips".

Please don't contribute to confusion in naming.

------
fortran77
And impossible to do on a touchscreen (where there's no "hover")

~~~
npongratz
That's one reason I dislike using touchscreens and form factors that
effectively require them (tablets, pocket surveillance devices, etc.).

~~~
fortran77
Also touchscreens get filthy!

------
pkamb
None of those examples are "tooltips".

------
pugworthy
Serious usability question that I should probably ask on the UX stack...

How do you provide the same impact of tooltips on a touch-only based
interface?

------
mojomark
*UX features, NOT dataset features

