Article - 6 Jul 2022

The hovering period has ended.

The hovering period has ended.

This is my UI design suggestion inspired from “Eval is evil.” You shouldn't rely on the hover tooltip to show you what's going on or give you critical information. Distracting, clumsy, hidden, and difficult to use; these best describe Hover.


When you display a certain element of your UI layout using hover, unhovering would hide the same UI. That could cause the user interface to flicker as the user scrolls or moves the mouse. Do you remember when adverts would appear on websites when you hovered over a word? Remember those feelings? That sensation is exactly what caused Anakin Skywalker turn to the dark side.


To overcome the problem of distraction, UI designers incorporate delays, so the concealed component is only visible when you wait long enough on the specified location of the interface. That eliminates the distraction problem, but now you have a cumbersome UI that makes you wait much longer. Every time you have to use the same UI, you’re charged a non-distracting UI price from your time.


There’s no uniform UI language that indicates “this object may be hovered, and will do this if you do so.” You either don't know about hoverable UI until it's pointed out to you, or you have to go through the entire interface one by one, like in the old LucasArts adventure games, when you had to identify the exact pixel coordinates of the items you needed to solve the puzzle. I like the game itself, though I found the pixel-finding sections tedious.


Hover-based UI designs are not only difficult to find, which is an accessibility problem in andof themselves, but they also necessitate dexterity with the mouse. You risk losing the hover if you click and drag the mouse too much. Many methods have been devised to keep your hover state on a drop-down menu item.

You have to be able to target a specified place with mouse without mistakenly click on it either. I’m sure operating systems give certain fallback strategies to address some of these concerns, hover isn’t accessible by default. It’s tricky to utilize.

Some screen readers might take hover text information and present it in a meaningful way, although there are other, better suited solutions for it like ARIA labels without relying over the hover itself.


Hover state can easily get lost by accidently moving the mouse and that can cause the user to click on something else instead unknowingly. Similarly, removing hover would make you wait another second to see the UI again. It’s all prone to blunders, mishaps, tears, and screaming.

As an additional downside, we have yet to develop screen sensors that would allow hover to work on mobile devices. Mobile web browsers treat clicks as hovers. That means when you click an element that shows a different style while hovered, you’ll have to click on it once again because your first click will just register as hover. Arguably, any rational designer would add conditionals to avoid such behavior on mobile, but it means there’s a disconnect between the UX given by platforms which is an issue in itself. Users will experience frustration as they are forced to adapt to new ways of using the software, no matter how little those differences may be.

The hoverless way

Simply incorporate the exposed UI element into the main UI or as a clickable action. While this may seem like an unnecessary extra task when interacting with the user interface, it actually saves time compared to bringing up a menu.

When would you use the word "hover?"

Ideally, never use hover. If you have to, utilize hover only to amplify the quality of the user’s experience, and never as the center of your user interaction flow. Your UI should be totally useable and accessible without hover.

Let's build something together! Shoot me an e-mail or contact me on my socials.