89 pointsby ibobev6 hours ago10 comments
  • ProxCoquesan hour ago
    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.
  • brixie2 hours ago
    This looks it's describing the same technique as the last example in https://emilkowal.ski/ui/you-dont-need-animations (and that whole post is worth a read, I think, if you found this interesting).

    It's such a small detail that I wouldn't have otherwise noticed (because I don't build animations, so it doesn't cross my mind), but now that I know about it, I think about it all the time.

  • hurrell3 hours ago
    I think I would describe this as an example of hysteresis. Neat! https://en.wikipedia.org/wiki/Hysteresis
    • xg153 hours ago
      Interestingly, there are more use cases for hysteresis in UI design, e.g. it was famously used in nested menus in Windows: https://www.mackido.com/Interface/hysteresis.html

      I think there was also an article about it on The Old New Thing, but I can't seem to find it anymore.

  • compiler-guy5 hours ago
    I greatly appreciate this attention to detail, and there isn't enough of this in the world. For example, in Visual Studio popups on hover happen so fast you can barely select anything, or you end up clicking on the popup instead of selecting a word.
    • gblargg4 hours ago
      Opus Magnum suffers from this. It feels like punishment for taking the most direct route to get the cursor where I want it.
    • wang_li4 hours ago
      If there is a primary UI element on screen that the user can interact with and moving the mouse towards that causes a secondary, alternative, UI element to appear, the second element needs an active modifier key to bring it up. Tooltips and such are total trash and get in the way of usability. If you have something important then put it on the screen to begin with don't have it randomly jump in front of the user who is already mid action with something else.
  • phyzome5 hours ago
    I ran into the same problem about 20 years ago when implementing hover-based dropdown menus on a website. It was only about 10 lines of JS and a couple global variables but I was the only person who understood it. :-P

    (These days I would have included more comments.)

    Naturally, there was a fallback to pure CSS menus, because we weren't barbarians.

    • dylan6043 hours ago
      what did the JS provide that the CSS solve wasn't the only solve?
      • jcranmer3 hours ago
        Not OP, but my guess is things like timing delay--20 years ago, CSS animations and transitions weren't a thing yet, especially since 20 years ago also puts us in the era of IE6 being a major browser.
  • goda902 hours ago
    What about using mouse velocity? If the mouse is changing position at a certain rate, don't show the tooltips.
    • jareklupinski2 hours ago
      i only show tooltips if you wiggle the mouse cursor over an element
  • self_awarenessan hour ago
    Hilarious. Web devs discovering UX from Win95. What's next, 3d buttons?
    • ProxCoques42 minutes ago
      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.
  • nayroclade5 hours ago
    Chris Coyier also posted a version using only HTML/CSS, no JS: https://blog.master.dev/delayed-then-instant-tooltips-with-h...
  • halostatue5 hours ago
    The pure CSS version seems more interesting to me: https://blog.master.dev/delayed-then-instant-tooltips-with-h...
  • jay_kyburz2 hours ago
    Perhaps I'm just an old grump, but I prefer the No Delay version in the example.

    I like predictable, consistent, and fast.