4 ms·

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 th

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.

iaskwhy 15y ago
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.
- jeffehobbs 15y ago
  Exactly right. 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. (Having said that, these are lovely animations.)
  - iaskwhy 15y ago
    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.
Xixi 15y ago
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.
- dexen 15y ago
  > ...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.
  - Xixi 15y ago
    > There isn't now, but there well could be. Or not. 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".
einhverfr 15y ago
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.
- rimantas 15y ago
  > drop support for IE due to a lack of BUTTON support We must be thinking about different BUTTON there. IIRC IE supports button since version 4.
  - rglullis 15y ago
    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.

iaskwhy 15y ago

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.

jeffehobbs 15y ago
Exactly right. 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. (Having said that, these are lovely animations.)
- iaskwhy 15y ago
  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.

Xixi 15y ago

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.

dexen 15y ago
> ...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.
- Xixi 15y ago
  > There isn't now, but there well could be. Or not. 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".

einhverfr 15y ago

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.

rimantas 15y ago
> drop support for IE due to a lack of BUTTON support We must be thinking about different BUTTON there. IIRC IE supports button since version 4.
- rglullis 15y ago
  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.