IOS browsers have a 300ms click delay - But developers can bypass it • Hacker News Board

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#51

Post by lukifer » Fri, Jun 08, 2012, 9:04 PM UTC

cargo8 wrote: post #49

wgx wrote: post #21

Article asserts it's there to detect double taps, but I'd add that it's a very useful user experience tweak to help deal with mis-taps. On HN, for example, I'll frequently hit the article link instead of the comments and this delay (combined with the network latency) often lets me re-tap the right link.

Seriously, you are claiming that network latency and a delayed response to click events is a GOOD thing because it lets you fix mistakes that you made? Sorry, that is not how you design a product/feature. The problem you are mentioning has also been solved by Google. In Ice Cream Sandwich when you click on a link that is close together with others, it will magnify the area to make it very clear which link you want to…

What's right for web sites (300ms delay) need not be what's right for web apps (0ms delay). I think it's a smart default, and devs making usability tradeoffs can decide when to remove it.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#52

Post by miniatureape » Sat, Jun 09, 2012, 12:02 AM UTC

t413 wrote: post #46

falling wrote: post #45

The article talks about “mobile browsers”. Neither iOS, Safari or even WebKit are mentioned. Why does the submission title say “iOS browsers”?

Probably because it's mostly fixed in Android ICS, as is slyly stated at the very end of the article: "We hope that browser developers will solve this problem in future releases by firing click events immediately when zooming is disabled on the website (using the viewport meta tag). In fact, this is already the case with the Gingerbread Android Browser."

Is it really fixed in ICS? Last time I tried my test case with my ICS phone it was still happening. Further, the iPhone wasn't exhibiting the ghost click behavior.

I really wish Google would make the Android browser blow mobile Safari out of the water. It'd be good for their business. As someone who used to do mobile web development full time, Android felt like IE 6/7 half the time.

I say this as an Android user.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#53

Post by yesyes » Sat, Jun 09, 2012, 2:31 AM UTC

Users told us they would rather have tactile buttons as on a PC keyboard or Blackberry. We're working on a small "smartphone keyboard" for fast "two thumbs" typing like on a Blackberry. The user can plug it into the smartphone when the user wants to type quickly and detach it when they are done and want to store the device.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#54

Post by teamonkey » Sat, Jun 09, 2012, 3:12 AM UTC

wgx wrote: post #21

Article asserts it's there to detect double taps, but I'd add that it's a very useful user experience tweak to help deal with mis-taps. On HN, for example, I'll frequently hit the article link instead of the comments and this delay (combined with the network latency) often lets me re-tap the right link.

Unfortunately I'd blame this down to this site's poor user experience on iOS. The 300ms delay is thee to support all cases of user gestures, not be a crutch for poorly-designed sites.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#55

Post by lazerwalker » Sat, Jun 09, 2012, 5:06 AM UTC

For the project I'm working on, whenever I would bind to a 'click' event (via jQuery.on or a Backbone event hash), I instead just pass in a variable that's set to either 'click' or 'touchend' based on touch support detection done on pageload.

If the element is within a scrollable area there's a little bit of extra logic needed to get everything to work happily (so it doesn't fire the event handler if you stop scrolling with your finger on the element). In that circumstance you'd probably better off grabbing one of the many libraries people have written to take care of this, but if that's not a concern (and it isn't in my case, since the parts of the app that shouldn't have the 300ms delay don't scroll), the advantage of this is that the only logic it requires is the touch detection code.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#56

Post by dave1010uk » Sat, Jun 09, 2012, 7:19 AM UTC

kylemathews wrote: post #42

dave1010uk wrote: post #41

I created a jQuery plugin called fastClick that does this a while back: http://dave1010.github.com/jquery-fast-click/

I've used this plugin on a number of webapps. Works great! Very simple to integrate into my Backbone.js apps.

Thanks for the feedback. One problem with GitHub is it's hard to get a sense of how many people are actually using your project.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#57

Post by fiznool » Sat, Jun 09, 2012, 11:09 AM UTC

Danieru wrote: post #31

fiznool wrote: post #19

Earlier quoted context omitted.

Great library, going to give it a shot in one of my upcoming projects. Quick question - I just tried the demo on IE on a Nokia Lumia 710 running WP 7.5 Mango, and there was no difference between A and B. Do you have any idea why FastClick might not work on Mango?

They only support Windows with IE10 as he said above?

Yep, saw that, just wondering if there are any insights into why it won't work for WP7.5, in case it is a work in progress or a complete no-hope.

Re: IOS browsers have a 300ms click delay - But developers can bypass it

#58

Post by ejdyksen » Sat, Jun 09, 2012, 9:52 PM UTC

wgx wrote: post #21

Article asserts it's there to detect double taps, but I'd add that it's a very useful user experience tweak to help deal with mis-taps. On HN, for example, I'll frequently hit the article link instead of the comments and this delay (combined with the network latency) often lets me re-tap the right link.

It's not just that...

The delay is there to allow you lift your finger and see the link turned gray (or whatever the selection color is). This feedback is crucial even in cases where you tapped on the right thing--how else would you know you got the right thing?

There are valid reasons to override this, but developers and designers should be sure that their tap targets are huge when they do. Otherwise they're depriving users of a pretty important piece of feedback.