4 ms·
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'l
by wgx 14y ago
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.
- teamonkey 14y agoUnfortunately 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.
- tezza 14y agoGood 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. Edges ==> onClick() Center/Sweetspot ==> onTouchStart()
- pasbesoin 14y agoMy father has minor tremors. I wonder to what extent the feature purposefully -- or inadvertently -- assists such people.
- dwc 14y agoFrom 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.
- malyk 14y agoThe 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.
- cargo8 14y agoSeriously, 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...
- praxulus 14y agoIn 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.
- lukifer 14y agoWhat'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.
- ejdyksen 14y agoIt'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.