IOS browsers have a 300ms click delay - But developers can bypass it(developers.google.com)
developers.google.com
IOS browsers have a 300ms click delay - But developers can bypass it
https://developers.google.com/mobile/articles/fast_buttons?hl=de-DE
22 comments
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 click. This is a solution to your mis-clicks - not a latency delay on every click so that you can fix it if you clicked wrong...
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 click. This is a solution to your mis-clicks - not a latency delay on every click so that you can fix it if you clicked wrong...
In the absence of zoom-on-ambiguous, why is it so bad? I certainly have trouble accurately clicking links on a phone, so having no click correction is certainly worse than artificial latency.
Don't confirmation dialogue boxes and password confirmation fields fall into the same category? They assume imperfect user input, and their mechanisms for avoiding errors slow the user down.
Don't confirmation dialogue boxes and password confirmation fields fall into the same category? They assume imperfect user input, and their mechanisms for avoiding errors slow the user down.
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.
From the article: "...since we wanted users to be able to dial phone numbers rapidly."
I think there are specific cases where eliminating the delay is appropriate. The very real concern is that developers will use this with abandon. There are many sites where it's easy to mistap, and the delay behavior serves its purpose well. Developers should think twice before breaking whole-platform conventions. Whatever they might personally think is "the right way," breaking with conventions almost always surprises and frustrates users.
I think there are specific cases where eliminating the delay is appropriate. The very real concern is that developers will use this with abandon. There are many sites where it's easy to mistap, and the delay behavior serves its purpose well. Developers should think twice before breaking whole-platform conventions. Whatever they might personally think is "the right way," breaking with conventions almost always surprises and frustrates users.
The other reason it's there is to detect scrolling instead of simply touching. If you don't move your finger in those 300ms then it's a tap, if you do then it's a scroll. This tweak breaks that.
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.
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.
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.
Good point.
What I would say is that my mobile apps have very large buttons. Any 'miss' could only really occur at the edge of each button.
So in that case I could use the event coordinates in contrast to the dimensions of the button to decide whether to revert to onClick() behaviour.
What I would say is that my mobile apps have very large buttons. Any 'miss' could only really occur at the edge of each button.
So in that case I could use the event coordinates in contrast to the dimensions of the button to decide whether to revert to onClick() behaviour.
Edges ==> onClick()
Center/Sweetspot ==> onTouchStart()My father has minor tremors. I wonder to what extent the feature purposefully -- or inadvertently -- assists such people.
This is a known problem, but it's surprising how often it is overlooked. I personally use FastClick.js for this (http://assanka.net/content/tech/2011/08/26/fastclick-native-...), from the guys who did the Financial Times app.
You can see a demo here: http://assanka.net/content/tech/files/2011/08/fastclickdemo....
Of course, that only works if you are on an iOS device.
You can see a demo here: http://assanka.net/content/tech/files/2011/08/fastclickdemo....
Of course, that only works if you are on an iOS device.
One of the developers of FastClick.js here. We made this thing because we thought that the problem deserved a thin compatibility layer as a solution, rather than forcing developers to rewrite their code to use a different kind of button all over the place (then rewriting it again when the devices change their behaviour).
The code is in production use on the FT web app, which is deployed across iOS devices, Android (both Chrome and the Android browser), Firefox (in test), Blackberry (both Playbook and phone) and Windows (IE10). We've fixed a bunch of bugs since the initial release and we should be putting the new code on GitHub in a few days (http://github.com/ftlabs).
Feel free to post questions about FastClick on Stackoverflow if you have any problems... I'm monitoring it for mentions of FastClick and will answer most of the time.
The code is in production use on the FT web app, which is deployed across iOS devices, Android (both Chrome and the Android browser), Firefox (in test), Blackberry (both Playbook and phone) and Windows (IE10). We've fixed a bunch of bugs since the initial release and we should be putting the new code on GitHub in a few days (http://github.com/ftlabs).
Feel free to post questions about FastClick on Stackoverflow if you have any problems... I'm monitoring it for mentions of FastClick and will answer most of the time.
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?
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?
[deleted]
> Of course, that only works if you are on an iOS device.
It also works in Chrome Beta for Android.
It also works in Chrome Beta for Android.
Excellent, I did not test that yet. I mostly meant to say that you cannot see the delay if you are browsing on a non-touch device (because there is no delay).
This article was from 2011 (EDIT: oops, I said 2010 but the article says "January 2011" - though I'm sure they had it out before then) - I think everyone who's done iphone web dev is either using this, or has come up with something similar.
The HTML5 Mobile Boilerplate project uses "Fast Buttons": https://github.com/h5bp/mobile-boilerplate/wiki/JavaScript-H...
The HTML5 Mobile Boilerplate project uses "Fast Buttons": https://github.com/h5bp/mobile-boilerplate/wiki/JavaScript-H...
Am I the only one who can't stand when people use IOS instead of iOS?
I don't mind a little typo, but IOS [1] is a completely different operating system...
[1] http://en.wikipedia.org/wiki/Cisco_IOS
I don't mind a little typo, but IOS [1] is a completely different operating system...
[1] http://en.wikipedia.org/wiki/Cisco_IOS
In this case it's because HN capitalizes the first letter of story titles. There should really be some hardcoded exceptions; it's surprising how often titles begin with iPhone, iOS, or jQuery!
Yeah, but it's still less annoying than seeing MAC used for Apple's desktop and notebook line.
Mainstream Apple Computer. MAC.
Oops, looks like HN capitalizes the first letter. I always use iOS ;)
This is already well known, and the case with most browsers on touch devices.
So terrible title, useful article.
So terrible title, useful article.
Why is it a terrible title? I personally didn't know about the 300ms delay, and the title seemed to describe the article perfectly.
Because the title is "IOS browsers have a 300ms click delay", when in fact it affects a lot of mobile platforms (BB, iOS, WP7, some older Android versions), not just iOS. The article itself doesn't even mention iOS or iPhone.
Note that Google doesn't mention iOS or Apple anywhere in the article, yet the submission is "iOS has a 300 ms delay". It's in Android webview, too, not just iOS (probably it's something in WebKit?)
ex http://stackoverflow.com/questions/7375575/android-webview-v...
ex http://stackoverflow.com/questions/7375575/android-webview-v...
[deleted]
[deleted]
This makes sense for mobile templates where zooming isn't necessary. On sites that retain a desktop style on mobile devices (nytimes), double tapping is extremely valuable to zoom in on particular columns. Hopefully developers don't overuse/misuse this, as it would effectively break that behavior.
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.
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.
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.
I think any solution needs to check that only one finger was touched - some solutions forget this check. An iOS quirk to be careful of is that the event.touched array count for a touch event on an element is different if there is also a touch event registered on document (spooky interaction, but true).
Also I would check no modifier key (ctrl,alt,shift,meta) is down to handle mixed keyboard/touch devices. This check is often missed for mouse events, and causes various UI faults in pages.
Also I would check no modifier key (ctrl,alt,shift,meta) is down to handle mixed keyboard/touch devices. This check is often missed for mouse events, and causes various UI faults in pages.
[deleted]
Googles fast button is too hard to implement imho. I use jquery tappable for that: http://aanandprasad.com/articles/jquery-tappable/
Provides a great and easy interface + fallback for click input.
A lot more resources on touch/tap events here https://github.com/bebraw/jswiki/wiki/Touch
I like cubiq's solution:
http://cubiq.org/remove-onclick-delay-on-webkit-for-iphone
It uses event capturing so you can bind the listener to an outer div containing many buttons, rather than each button individually.
http://cubiq.org/remove-onclick-delay-on-webkit-for-iphone
It uses event capturing so you can bind the listener to an outer div containing many buttons, rather than each button individually.
I heard about this a looooong time ago from Scott Jehl at jQuery con in San Fran. jQuery mobile has known about this for a while. I am glad to see everybody seems to know about it cause I could definitely see devs getting frustrated over this.
I actually built something similar to this for where I work. We just recently open sourced it: http://jetsetter.github.com/MobileSafariQuickTap/
Instead of all that complicated workaround, how about just onmousedown instead of onclick.
I'm pretty sure onmousedown fires before click/doubleclick and would dodge the 300ms delay.
I'm pretty sure onmousedown fires before click/doubleclick and would dodge the 300ms delay.
Also, avoid doing as much work as you can inside event handlers.
I guess the tap-event in jQuery Mobile is based on this or am I wrong?
Is there a JS fiddle somewhere where you can see the difference?
FWIW this is broken on Opera Mobile Android. Tapping Layer B once results in it switching to green and then back to white, like it was tapped twice. Layer A works as expected, with a slight delay.
On the stock Gingerbread browser though, both Layers do not respond to taps at all.
On the stock Gingerbread browser though, both Layers do not respond to taps at all.
You may know this already, but running this test on Android ICS (stock browser) and B can't be selected.
edit http://bit.ly/L2JatN Short url for easy mobile typing
edit http://bit.ly/L2JatN Short url for easy mobile typing
Or, how native development still beats "web apps".
The article talks about “mobile browsers”. Neither iOS, Safari or even WebKit are mentioned.
Why does the submission title say “iOS browsers”?
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."
"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.
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.
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.
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.