Touch Events and Mobile Web App Usability

3 minute read Published

Why PPKs “Stick with click” may not be the best advice in all situations.

I recently heard a talk from Peter-Paul Koch of QuirksMode on the touch events in mobile at the orbitz.com office in Chicago. During his presentation PPK gave us a great sound bite to use when dealing with the 300ms delay many touch devices use for capturing double-tap (zoom) events:

Stick with click.

Peter-Paul Koch

Under stick with click devs are discouraged from hijacking ontouchstart to make click events occur without noticeable delay. And though a good rule of thumb I view it as more of a best practice than a hard-and-fast rule.

Here’s why…

When considering perceived latency in a UI, it’s logical to first think about the the long-standing guidelines on Response Time Limits by usability guru Jakob Nielsen, two of which are applicable with regard to two-tap zooming:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays between 0.1 to 1.0 second though the user does start to lose the feeling of operating directly on the data.

Three-hundred millis is three times greater than the ideal response time, which, in some user interfaces, could be too slow and cause frustration for users. The Google Voice mobile webapp ran into a similar challenge over a year ago and crafted a Fast Button workaround using some creative event handling a method they called “busting ghost clicks”, which allows click handlers to be used in conjunction with touch events.

A caveat to rejigging the event handling, however, is that zooming should be disabled entirely. If it is not, double-taps on the so-called Fast Button would not behave as mobile web users have come to expect, leading to a less awesome user experience. And though the Google workaround compensates for buttons, working with more complex controls and widgets or multi-touch gestures is likely to dredge up some painful and time-devouring edge cases to handle.

Nevertheless, recent advocacy for  Mobile First (thanks Luke W) and Responsive Web Design seem to play well with the Fast Button workaround by making it possible to build a mobile web application that with a display adjusts intelligently to the viewport and with which zooming a page is not required.

In summary, the 300ms delay used in mobile devices for double-tap detection is three times greater than the ideal 100ms (or shorter!) delay in a UI and, though Google has a nice workaround it should only be used with caution, and only in mobile web apps that do not allow page zooming. And when you find yourself doing a lot of event handling on your own and wonder if there’s a better way, consider stick with click.