Live data from Hacker News

Tooltips need a delay, and then they need to skip it

blog.master.dev

41–50 of 92 posts

Re: Tooltips need a delay, and then they need to skip it

#42

Wouldn't it make sense to use mouse movement for this. Display the tooltip only if the cursor is not moving (same position two frames in a row).

Tooltips pop up in many cases where there's no more being used. Tabbing through items, for example.

Re: Tooltips need a delay, and then they need to skip it

#43

It will never cease to amaze to me that Apple (under Jef Raskin who also wrote about this in The Humane Interface) observed and fixed problems with interactions like this in SYSTEM 6 in like 1993 or something - only for the same problem to have to be re-descovered and re-fixed decades later.

Because every single application rebuilds their own operating system

And mail client!

Re: Tooltips need a delay, and then they need to skip it

#44
The example shown at the top is really bad.

“Before (Without the delay of 200ms)” shows obvious delay in appearance. I think this is because of the very inappropriate fade-in.

“After (With the delay of 200ms & instant tooltips)” doesn’t show the instant behaviour at all, only one tooltip.

Re: Tooltips need a delay, and then they need to skip it

#46

Wouldn't it make sense to use mouse movement for this. Display the tooltip only if the cursor is not moving (same position two frames in a row).

a rather poor idea - esp. the frame part, mouse movement is not related to the display frame (rate). The latter can be rather high, e.g. 240Hz which is 8ms. Having a set delay and be in the boundaries (and not leaving it) is a significantly easier solution and easier to test too.

Overall the delay in tooltips (and configurable) has been a feature since the 90s (could set the delay in millis in some UI frameworks)

Re: Tooltips need a delay, and then they need to skip it

#48
I'm always amazed by solutions for user interactions.

I once built a Bomberman clone that had control issues.

The first iteration of the controls were clunky, because I only checked if a player was touching a block in the direction they wanted to move and if there was, I reset the position.

Move down, hit block, stop.

After a bit of experimenting I checked if a player was halfway behind or ahead of a block and added perpendicular motion after resetting the position. That way the player would glide around the blocks.

Move down, hit block, stop, move left or right until moved around the block.

That change alone made the game 100x more fun.

Re: Tooltips need a delay, and then they need to skip it

#49
post #21

Earlier quoted context omitted.

I know right? It's like interaction design came and went over a period of 30 years and now we're back to the beginning again.

I spend a lot of time seething at how poorly modern software interaction is, and I've come to the belief that they basically solved most of the window-based GUI computing interactivity problems by around XP, and have just been gutting them since then. My three most-hated modern trends - Disappearing scroll bar with content that you have to scroll for - Pills going across the top of the screen that are "most-used" fil…

It's phones. Nobody uses computers anymore (for some statistical definition of "nobody"). There's no pressure to make precise and consistent UIs because poke poke poke poke.

Re: Tooltips need a delay, and then they need to skip it

#50
post #8

I think I would describe this as an example of hysteresis. Neat! https://en.wikipedia.org/wiki/Hysteresis

>> Hysteresis is the dependence of the state of a system on its history. For example, a magnet may have more than one possible magnetic moment in a given magnetic field, depending on how the field changed in the past. How is this different from the observation that, say, a non-magnetic iron ball may have more than one possible velocity in a given gravitional field, depending on whether it was recently thrown upward o…

[deleted]
Post reply on HN