Hacker News new | past | comments | ask | show | jobs | submit login
Tooltips: Secret weapon for improving feature discovery (uxdesign.cc)
118 points by xTWOz 49 days ago | hide | past | web | favorite | 63 comments

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

When I was just beginning to use desktop applications everything had tooltips and nothing had guided demos. In my opinion it's a much more natural way of exploring features; you see what buttons do before committing an action, you get to start understanding the scope of features and capabilities of an application, and you get the opportunity to build a mental "map" of the application - but all at your own pace and available whenever you want.

I might be in the minority but guided demos today seem to achieve very little of these desired effects: they usually start at inconvenient times (I might still be configuring my profile or registration settings), as bhauer mentioned they're hard to re-activate and re-visit, they're not comprehensive (usually only cover the top 5-10 actions or functions), and generally a little overwhelming when getting accustomed to a new interface.

I will acknowledge today's user interfaces are different to late 1990's software where everything had an explicit button or menu action, particularly with touch screen interfaces now. But given how often I'm walking friends or family through common actions on popular interfaces I would say today's interfaces are doing a terrible job of teaching users about what feature are available and how to use them.

Fully agree. User activated tooltips are fantastic for learning to use an application, and desktop apps without them are half assed, IMO.

At the same time, I find the forced, “guided” tooltips to be invasive and annoying.

Good analysis.

I love traditional tooltips. They don't work so well for touch devices, but if you've got a mouse they're great and can almost be seen as a progressive enhancement.

I'm also a fan of the even older tooltip cousin where a bottom status bar of a window has info about the object in the window that currently has focus. This has disappeared from many apps, but is especially useful to keyboard users.

I'd call it a "guided demo" when it happens the first time you use the app (I believe Slack does this), or when you ask for a guided demo.

But the examples the OP are pointing out are a bit different. Rather than a "guided demo" which sounds like a sequence of these -- what's being covered here is usually a single solitary one, usually for a newly released feature, that appears on screen load, even if you are a long time user of the app, and without asking for any kind of guidance or demo, until you dismiss it (or in some cases they can time out on their own).

I have been noticing this phenomenon more and more, and think it is worth pointing out and commenting upon. Which is more interesting than debating whether "tooltip" is the right term for it; or talking about traditional tooltips which might be interesting, but isn't what the OP is about at all, someone can write a different article about that.

(They are "tips about tools", and _look_ like traditional tooltips, so I can see why the OP author called them tooltips. But this is clearly confusing many people. I guess I'd call them "feature disclosure callouts" or something like that).

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

Good article on "The problems with tooltips and what to do instead": https://adamsilver.io/articles/the-problem-with-tooltips-and...

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.

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.

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


love it!

I like this a lot. I just posted a comment about touch a bit ago, not seeing this little thread.

Modern smartphones UI do not use tooltips. Explore the app by touching it. Give option to revert the action.

It is an effective way also to learn an app - by doing, not reading.

If you need tooltip or guides like those, your UI has other serious issues.

For mobile devices, what ever happened to having a "HELP" tab that doesn't just open the browser to the FAQ page?

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.

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!

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.

agreed to you and GP. i always skip these, due to sensitization to browser pop-ins.

they are usually beyond obvious, further rage inducing.

when they are actually useful, again still rage inducing because I skipped it and there is generally no way to get the coach tip back.

sorry, ad pop-ins have ruined what would otherwise be fairly useful.

My UX professor told us "if you have to explain it, then it's poorly designed"; I think this is right in most cases. That, or it's well-designed, and you're making it superfluous as you're saying.

i think that's a good rule of thumb and something to strive for, and most interfaces can be made more obvious than they are with more skilled design work... but imagine if you applied that rule to, say, an airplane cockpit.

Sometimes powerful interfaces for doing complicated/powerful things need to be learned.

(And an airplane cockpit can still be designed poorly or well at varying degrees, certainly! A well-designed one will be safer and easier to use. But nobody thinks an untrained person should be able to step into even a well-designed one and fly a plane. That doesn't mean it's a poorly designed interface).

> Myself, I'd say ~75% of the time I dismiss them without even reading them

This is me, too, although I don't read them more than 75% of the time. I find them disruptive. I've even developed muscle memory so any time I see a "got it" button, I just immediately click it so I can get on with whatever I was trying to do.

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.

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?

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.

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.

Then within Settings, there should be "advanced settings" or "more..."

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

Doesn't mean they can't be logically grouped and presented using different tabs or even links, such as "Global settings", "User settings", etc. They may have different contexts, but they all fall under the purpose/concept of "customization". Discoverable doesn't have to imply unorganized.

Put all of the settings in the same area, and then segregate them by type in that area. Like how Firefox broadly does it. Every setting should be accessible from one central hub, and you can also make it accessible somewhere else if convenient.

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

^apple's iOS

Even the HTML level is totally cryptic with framework-generated class attributes, no IDs, no directly event handlers (often all global, using bubbling events), no href= attribute on links. It's a step backwards on all levels.

It was hard to write the software, so it must be hard to use it!


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

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

Someone else in this thread called them "coach marks." I think that sounds like a great term.

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

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.

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.

I was gonna post similar... but the tooltips demos in the article are not necessarily open-on-hover.

They instead seem to be the kind that appear on the page initially, pointing to a new device and explaining a new feature, until the user dismisses them. I don't believe they involve hover at all.

I'm still not personally sure how workable this is on a small screen (because I personally don't have experience with it), and could use some discussion or examples of how this has been done (if it has been done) on mobile. It seems odd to me too to write an article about UX these days without mentioning mobile.

But it is worth commenting on the trend of "initially visible tooltips pointing out new or advanced features." Personally, I almost always dismiss them without reading them, they are usually getting in the way of whatever I came to that site/app to do. I wonder if there is public research on their effectiveness.

> But it is worth commenting on the trend of "initially visible tooltips pointing out new or advanced features."

__To me__ those might be tooltips in terms of implementation (i.e., code) but I'm not so sure I would consider them TTs in the traditional sense. They're more like "feature flags".

Either way, they are what the OP is about. I think?

They are tooltips in the plain language meaning of the word, they are tips about tools. But I agree the term "tooltip" initially made me think they were talking about the appear-on-hover kind.

"feature flag" also means something very different in software discussions, I wouldn't try to re-use it for these. Words are hard. https://en.wikipedia.org/wiki/Feature_toggle

I might call them "feature disclosure callouts" or "feature announcement callouts" or something like that, but that's a mouthful. "callout" is one graphic design term for that bubble with a pointer annotating the the thing pointed to. https://en.wikipedia.org/wiki/Callout

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.

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.

Perhaps on a touch screen device one could use a "help mode" which freezes the UI interaction and displays ballon help over each UI element.

Tap the balloon and it expands with more detailed explanation.

The help mode could be triggered by a tap on an always present (?) icon somewhere in the corner.

Yes. That's the "proxy" I mentioned. But it's not common, and (worse) touch-and-hold is kinda the opposite of hover.

I think the "touch-based world" brought this lack of understanding of features in the first place.

That's where a stylus shines.

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.

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.

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

The Google Doo-what? Sorry, but in the past 15 years I only ever visited Google Search by typing my query into the browser’s address bar. I don’t know what is this “doodle” you’re referring to.

So much this ! I feel like a toddler every time my UI is "upgraded".

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?

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

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

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.

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

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

Also touchscreens get filthy!


Are end users aware of that though?

None of those examples are "tooltips".

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?

*UX features, NOT dataset features

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact