When the iPhone was released I thought it would be the end of hover. I know that's what I think about when I see something like a menu which only works on hover.
Always surprises me that developers let platform makers dictate what they can use and what they can't.
If developers chose to use stuff on the basis of what they as developers think should be used - and if that meant iphone users couldn't use them - guess who would ultimately win that battle? Not Apple.
IE would have died years ago if developers had adopted that culture en masse.
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.
That would be right if this was about platforms but it's not, it's about interaction. If you can't hover then why depend on it?
Also, it's easy to add a touch event to do the same as the hover event, it's up to developers to do it. I was just thinking about the dependency of hover which need to go.
The thing I don't like about hover is that at core, it's a leap of faith -- you're asking your user to mouse around blindly (like Myst, anyone remember that frustration?) until the page rewards their fumbling with some sort of UI treat. It's a symptom of inefficient and poor design.
Events like hover (or swipe, or trying to scroll out of the box) are really good for the experience side of design. It's that leap of faith that works that sometimes creates such a special connection between the user and the interface. If one ignores usability to favor experience then it's inefficient and poor design but I believe sometimes there's a good compromise between both.
It's also important to note that discoverability is really different than it used to be due to touchscreens and that plays a major role in usability.
I'd actually agree with you. On LedgerSMB we made the decision to drop support for IE due to a lack of BUTTON support. Then IE7 came out which was still too broken and we didn't support IE. Then IE8 came out and supported buttons so we could support them again.
The tradeoff was simple: marginally greater market share at the time vs the fact that if we supported IE we would not be able to use BUTTONs to separate labels and inputs for i18n purposes. Really, there was no case to be made for IE support at that point.
So developers hsould consider the tradeoffs carefully.
You are both correct. IE always had a <button> element, however it only started working like other browsers on IE8. Before that it behaved like an <input>; you had to add "type=submit" to get it to actually submit the form.
