Hacker News new | more | comments | ask | show | jobs | submit login
Hover on iPhone/iPad (trentwalton.com)
47 points by nreece on July 8, 2010 | hide | past | web | favorite | 25 comments



Let's ask ourselves why hovering to expose interface elements is so very prevalent in web interfaces, when it's all but absent in native computer software. The answer is that classic web interfaces are static rendered pages spruced up with some CSS and javascript interactivity patches, while native software is dynamically interactive. As web apps move to being AJAX-y or HTML5 interactive javascript experiences instead of a collection of static pages, then the interface conventions of native software will become more prevalent. When you want to edit something in a list, you hit the 'edit' button, and your whole interface goes into 'edit' mode. No more needing to patch fake interactivity onto a static canvas. No more worrying about users being afraid to click on a link or button, for fear of not making it back to their current status, or of being lost while they wait for new content to load. The interactive nature of emerging web standards renders the lack of hovering irrelevant. Current interfaces were all going out the window anyway; touch devices just bring the problem to the forefront.


So far, the only place I really, really miss hover is xkcd.


Do you know http://m.xkcd.com ? No hover needed.


I had no idea this existed! Thanks for the link!


xkcd uses title attribute, which does not require hover.

Browser is free to implement it any other way (and I think Apple should show title on tap-and-hold gesture).

So it's not lack of hover, it's just Safari's incomplete HTML support.


I'd like to see a 3-fingered magnify gesture, which would double as a hover indicator.

3 points define a triangle, which can be circumscribed by exactly one circle. Associate the 3 fingers in a triangle gesture with a reticle/magnifying glass. Initial placement of the 3 fingers defines the "magnifying glass." Expansion or contraction of the circle defined by the fingers does not change the size of the reticle but instead controls the relative zoom. The cross-hairs in the reticle can also be hovered over GUI items to give a hover functionality.

This would have utility beyond enabling hover. (Sometimes it is more convenient to momentarily magnify a portion of the screen than to zoom the whole screen. One example is Google Maps, where a zoom-in/zoom-out sequence can cause unwanted downloading of map tiles.)


I see more than one problem with this approach. First, I cringe at the idea of trying to explain this finger manipulation pattern to my mom. Second, placing three fingers from the same hand on the touch screen would block the place on the screen I am trying to magnify/manipulate from my view. Using two hands to perform this task would be very cumbersome on the larger tablets like an iPad (I just tried without putting my ipad down, didn't go so well). Third, there are already use cases where three fingered swipes are used, increasing the possibility of performing the wrong action.

Hover is a way of hiding complexity in a design. Eliminating that complexity is the best way to hide it.


> First, I cringe at the idea of trying to explain this finger manipulation pattern to my mom.

Just have her put her 3 fingers down on the iPad. No words necessary!

> Second, placing three fingers from the same hand on the touch screen would block the place on the screen I am trying to magnify/manipulate from my view.

Wrong. Only certain triangular placements will do this and users will easily learn not to do that. Very flat triangles will have the hand off to the side, just as if you were holding a magnifying glass with no handle. With the right hand, you can do this by having the index finger and thumb extended, with the middle finger bent to sit just below and to the right of the index finger, like so:

                 x
                   x



          x
Since your hand is forming a backwards L, less than 1/4th of the magnifier circle is obscured by your hand. There are many other possible positionings which result in an unobscured view of the reticle.

EDIT: This gesture would only work on the iPad. The iPhone would be too small to accommodate it.


This is too difficult for users to discover.


All they'd have to do is to put 3 fingers on the surface.


I thought about this a bit and I think there is a valid "hover" motion for the brave new world of touch, but it's not available on the iPad yet.

Once the iPad has a front facing camera, in theory eye tracking can serve as a hover. It would be modal, so that you'd have to be holding down a button (perhaps on the edge of the iPad's bezel) to enable "hoverability", but it would probably work well. If you want to see more detail on a certain DVD in Netflix, look at it, and hit the button on the side of the iPad. This will require less physical motion on behalf of the user than even a hover, and much less than a click.


Wow, this sounds over-engineered.


Eh, not really. Imagine that there are four buttons on the iPad instead of just one. They're each at the midpoint of the bezel on each size. Depending on your rotation, the bottom one acts as home, and the left and right act as buttons that act on what you're looking at. (not sure about the top one :))


Utilize tap to reveal a hover state.

I like this approach, but as noted, often the problem is "users get no cue that tapping... is even an option".

I think a suitable solution is to start with one item 'pre-tapped', with strong cues that it is 'selected' (via highlighting, intensified colors, icons, etc.). That provides a strong clue that its peer items could be tapped to show the same 'hover' controls.


The technology to enable a hover-state in a touch input device is certainly there. Hopefully in the near future OEM's will create a UI that allow you to see a hover state as your finger approaches a target element. Ideally, you'd get three states: hover distance, touch, and touch-pressure.

This would then allow the hover state to live long and prosper.


Thoughts on hovering: My laptop has a capacitive Wacom panel which can detect the presence of the pen about an inch above the screen. You can track the mouse around the screen without ever actually touching the screen. This allows for full hovering ability. Why not implement this for smaller devices like phones?


There's a lot of technology in a Wacom pen that is missing from a finger. I'm not aware of a practical way to identify and measure the location of a fingertip that's any significant distance from the screen, except by using cameras.

Ultimately, I think any tablet made for serious work will have to implement Wacom pen tech and multitouch.


With a capacitive device, it's possible to detect things like fingers some distance away from the surface, but the signal is so noisy that you get a lot of false positives.

The endpoint of all this stuff seems to be the Minority Report UI (http://www.ted.com/talks/john_underkoffler_drive_3d_data_wit...) or Kinect, where the computer is detecting what you're doing with your body in a holistic way; it can infer intent, rather than measuring specific points of data without knowledge of where they came from.

Of course, that requires bigger and more expensive sensors than you're likely to find in a $499 device today.


Why is it okay to design layouts that require a pointing device, yet it's not okay to design for hover? How does one draw this line?

I think this is just a matter of designing for your audience, not a matter of "moving forward".


You're welcome to design solely for an audience that has hover support, just as you're welcome to design solely for an audience that has IE installed.

Perhaps you should also put up a popup: "This site best experienced with a computer that has a mouse. If you are visiting with a phone or touch-screen tablet, please consider buying a computer, or visiting one of our many fine competitors."

Remember when lots of websites had messages urging you to visit with specific browsers? Remember how much fun that was?


I don't think that's unreasonable if you're reasonably sure your audience is close to entirely IE.

When I make websites I have no time for ideals or philosophical statements, I look for where my market is now and where it's going in the short term, and make my decisions based on that.


I've seen many applications that were created under that assumption ("they're 'intranet' apps, and IE is our corporate browser") only to become extranet applications quite suddenly - undermining that assumption by merely replacing "in" with "ex" in the functional spec.

It's not just a philosophical statement. It's a practical matter. Unless your plan is to high-tail it out of there and leave it to someone else to maintain your mess, that is.


The difference between philosophical statements and practical matters is surprisingly difficult to articulate. You can rarely point to a single moment when the one becomes the other.

Every practical situation starts out life as a philosophical position. The atomic bomb was once a napkin doodle.


Where would accessibility fit into all of this? Ideally we should all be designing sites in a way that doesn't rely on hover, to make our sites accessible to the blind and disabled.

Edit: Isn't the problem with touchscreens ultimately "focus", and not "hover"? There's no way to select an element without activating it at the same time.


I guess I want to blame web apps in general - our hands are tied until only the simplest controls and the least helplful experience is possible.




Applications are open for YC Summer 2019

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

Search: