The hover is not an iPhone vs developer problem, it's a touchscreen problem. Hover feels very natural with a mouse, but there's no logical equivalent on a touchscreen.
"on hover" is a side effect of pointing at things with a mouse. With a touch screen you touch things directly with your finger, you don't hover. So you have to design your website/app with that in mind: users will touch whatever they want to interact with. That's neither a mouse "on hover", nor a mouse "click".
Of course you can forgo people who use touchscreen, or even mouse and go keyboard only... it's a choice.
> ...but there's no logical equivalent [to hover] on a touchscreen.
There isn't now, but there well could be.
Suppose for a moment that you get a good old cursor on iPhone and it follows your fingertip as you move it around the screen. It wouldn't even have to be user-visible. To click, you press a bit stronger, or you raise & lower your finger (`tap' if you will). The hover's back.
There's nothing inherent in touch-based technology that prevents hovers from working. Such behavior has been available way on (decent) touchpads for well over a decade now, modulo user-level configuration.
On touch touchscreen it feels natural to just touch the part of the screen you want to interact with. I hate the word, but it's intuitive. It doesn't feel like something you need to learn and become familiar with. My daughter understood how to use my iPad when she was less that one year old. She just touched the screen and something happened, she was happy. Even my mother-in-law understand how to use a touchscreen.
Neither my daughter nor my mother-in-law can use a mouse: it requires too much dexterity. I've seen people hovering a mouse in front of the screen hoping that something will happen. It's less intuitive, but it's familiar to all of us on hackernews.
What I'm trying to say is that there is something intrinsically natural and easy with a touchscreen: touch - interact. We won't go back from that.
I might be proven wrong, and tomorrow everybody will do on hover with its phone/tablet with the process you describe, or the one described by grovulent, or another one. But my guess is that it will remain mostly unused, except for a few "power users".
That's some very narrow thinking backed only by your anecdotal evidence.
Twenty years ago, I'm sure people would have been skeptical if you told them that someday, they would be able to wirelessly interact with a mass network of information via a touch-responsive, glassy device that fits in the palm of their hand.
Now where would be today if we'd listened to THOSE skeptics...
It's funny that we get this kind of response after that rant about the future of UI earlier this week
If we think about the future of touch and gesture interfaces, I absolutely think we'll see a hover state be implemented, but it won't be connected to a mouse cursor. That's moving backwards.
There will likely come a point where a touch or gesture interface will be able to tell if your hand or finger is quite literally -hovering- over a touch-enabled element, and will be able to give you context.
It's seems completely intuitive. If you're hovering over an element, you're likely hesitating, so give more context. Preview the next screen, provide info in a tooltip. Why wouldn't you take advantage of this?
> There will likely come a point where a touch or gesture interface will be able to tell if your hand or finger is quite literally -hovering- over a touch-enabled element, and will be able to give you context.
A Synaptics touchpad can do that, no problem. Used for, at very least, the `palm detect' functionality. Catches a single finger at a few milimeters' distance, configurable to the boot.
But I believe pushing that is a prime example of backwardnes -- a metaphor taken literally overriding ergonomics concerns. It taxes your muscles more to hover your hand in air with no support, than to slide it on screen. Perhaps that doesn't concern a person nearing top physical fitness, but that's a limited segment of market. Also, keeping fingers away precludes tactile feedback of reaching edge of active area, or some sort of active tactile feedback: http://www.macrumors.com/2009/12/24/apples-research-on-tacti...
I never said it was an iphone vs developer problem - I said it was a platform vs developer problem.
If developers choose en masse various interface methods that a particular platform doesn't support - that platform loses.. end of story.
Nor is there anything inherently impossible about hover + touchscreen. Double tap to prevent scrolling (and at least on my nexus S I'd prefer that to zooming which 3/4 times doesn't actually zoom at all). Move finger across screen - stop over element without additional tap. That's hover baby!
Not sure why folks voting me down. What I'm saying is not only right - it's sensible... and it's also preferable. Developers should be deciding UI reality.
"The hover is not an iPhone vs developer problem, it's a touchscreen problem. Hover feels very natural with a mouse, but there's no logical equivalent on a touchscreen."
Build your interface around the inputs. One nice thing about using CSS in this manner is one could (along with some discrete use of JS) build equivalent interfaces which are useful on touchscreens.
"on hover" is a side effect of pointing at things with a mouse. With a touch screen you touch things directly with your finger, you don't hover. So you have to design your website/app with that in mind: users will touch whatever they want to interact with. That's neither a mouse "on hover", nor a mouse "click".
Of course you can forgo people who use touchscreen, or even mouse and go keyboard only... it's a choice.