Came up recently in a 37signals podcast:


The straightforward, "brute-force" solution is to just use the first touch on a UI object as the hover.


It works. But are there other, more elegant solutions? For instance, could the hardware ever be made to support actual finger hovering?


8 Answers 8


It would mean a very different technology than what is currently used. I wouldn't try to force touch devices into screen device semantics. Touch devices are developing their own distinct set of user expectations. Touch to hover is perfectly acceptable. I've seen some nice examples of hinting to the user where "hoverable" areas are when the screen first loads. Highlighting hot spots in some way, then letting those highlights fade out after a second or two.

  • I like this solution. I think if this were to take off, it wouldn't be a bad idea in regular UI's to show a border or highlight action areas on a new screen for a few seconds. Commented Aug 27, 2010 at 16:38
  • 6
    Good point about not forcing the new into models built for the old. +1 Commented Aug 27, 2010 at 17:49
  • 6
    Stuff fading out might not be seen. There was a psychology study where they told participants to watch a basketball game and count how many times the ball was passed -- participants did not notice a gorilla going by: viscog.beckman.illinois.edu/grafs/demos/15.html -- On the web, where we already ignore those flashing "YOU'RE WINNER!" ads, subtle fading seems like too weak a visual clue. Commented Aug 28, 2010 at 22:25
  • 1
    Good idea, although as a user, I'd certainly prefer to be able to invoke highlight myself - when the app opens new screen, I'm too busy looking around, and I haven't oriented myself on the screen yet, so there is a little chance I'd remember which items had the initial highlight... Commented Aug 29, 2010 at 22:25

The point of hovering is to make some information available to the user about an element without triggering some primary action.

One approach might be to trigger the display of secondary information when dead space near an element is touched. That's not very discoverable though.

A better approach I think is basically the answer given above - touch and hold. But the first few time the user simply taps reveal the secondary information just before going off to the primary function, so that they know there is something to explore. It's not quite what 37 signals is saying though as I would not block the primary function, I would just reveal briefly it is there.

Instead of touch and hold you could also consider a swipe across something as seeking information, though again that's not easily discoverable unless you present an indication it is possible. I don't think there's anything wrong with the first few passes of an application presenting a few tutorial kinds of illustrations to let the user know something is possible, and many things like touch outside or swipe to reveal are very easy to remember even if they are hard to discover.

  • 4
    Touch and hold these days selects whatever underneath the finger. Because that seems the most appropriate way to enable copy and paste on a touch device. Commented Sep 1, 2012 at 8:27

Read all answers and comments above and with all due respect to you and your solutions, I would simply suggest not to implement hover feature in touch devices. In touch devices users are not expecting something of that sort, So I would prefer not to integrate such a feature.

In mobile devices user and developers/UX engineer prefer lesser footprint as possible. So to reach a new view or to get the details user is not expecting and expected to tap twice on a button or link.


The best solution is what you have in your question - a single touch performs the hover effect. This works just fine on an iPhone and is completely intuitive. I tap a nav item, and it expands to show the secondary nav items. I tap it again, it takes me somewhere (if it is itself a link). I don't see the need to replace something that already works and makes sense to the user.

  • In a time were companies calculate productivity with amount of touches, how can we excuse a doubling?
    – Velkommen
    Commented Sep 19, 2011 at 12:19
  • 3
    @Bluewater - Exactly what companies calculate productivity that way? And what alternative do you see? Commented Sep 19, 2011 at 12:50
  • I see 3 alternatives regarding tooltips without "hover", 1: Tap-Hold makes tooltip appear. 2: Add a legacy help button putting the user into a "help-mode" were a tap will show the tooltip. 3(Your example): First tap to show tooltip, second tap to enable tool.
    – Velkommen
    Commented Sep 19, 2011 at 12:56
  • I can see what you mean by productivity and number of touches, number of clicks and reducing them is a common metric. But I don't think the same rules apply to touch screen tech so strongly. Also- is there really such a time loss in pressing something vs. hovering over it? I dont think so. I guess the key is to just make sure your categories are clearly labelled so users don't have to hunt for what they want. Commented Jan 19, 2015 at 9:46
  • Number of clicks might not make a big difference on touch screens, but if I have to double tab everything I intend to tap and if this happens often, I might get a little irritated using the app. The way I see it, users are forced to see a tooltip even if they only intend to use the element.
    – TDsouza
    Commented Aug 30, 2016 at 13:43

Some touchscreen technologies do support hovering. For example, with Microsoft Surface and some specialized tablet displays distinguish between hovering and pressing. It seems like it might be frustrating, though. I used ZBrush with a tablet, which allows you to literally hover, and accuracy was significantly reduced (the cursor was jumping all over the place). In a graphics program this is okay, since you get the feel of drawing (and the imperfections can make it look more natural), but for things where the user needs to be accurate, I'm not sure it would be a great option.

  • Here is an example of Samsungs "Air View": youtube.com/watch?v=sZxGQ-vHGKE Your're right, accuracy is essential for this to work. But with digitizers getting more advanced I could imagine that "finger hovering" could be a reasonable pattern for displaying tool-tips or alternative content (e.g. revealing the phone number in an address book entry) in the future.
    – J_rgen
    Commented Feb 27, 2013 at 15:36
  • Air View seems incredibly awkward
    – bdimag
    Commented Sep 24, 2014 at 21:53

Don't expect devices like the iPad to support a cursor anytime soon. It's much wiser to focus on avoiding the hover and any other annoying mouse-only feature. I've recently written a detailed post on why we should stop putting anything mouse-over related to the web and what are the best ways to replace it.


If an object has the focus for a period of time with no activity, hover. It's probably an indication the user needs more information. Granted this is very difficult on single-touch action items like links and buttons (Easier to get the focus when in a keyboard environment where you can Tab to it.).


Why not simply write the name of the function on the button (unless it's tiny). That way the user doesn't have to hover over every button until they find the one they want. Having mystery buttons or links that would require hovering is known as Mystery Meat.

If you really want to have pictures instead of text, then I like the idea of one touch to 'hover' another touch to 'press' the button. However, it's not always clear that the UI supports this. Buttons look like you touch them to activate and a new user might be wary of touching a button in case they activate a function they didn't want.

An alternative would be to use little sprung switches.

Swipe Switches

This way it's clear that just touching them won't activate them. However, it doesn't let the user know that they could touch them for a tip.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.