There is no arguing that the platform-agnostic nature of web applications is one major advantage they have over their native counterparts. Developers and designers have always aspired to reach users on a multitude of devices and contexts using the same codebase, and we’re almost there thanks to the web technology we have at our disposal today.

On the flip side, the versatility of web applications comes at a price as we transition from the traditional mouse and keyboard input setup to touch-based interactions. Our present day interfaces are optimized for the former, rarely taking into account the rise of touch as a natural interaction that may soon overtake other input methods as the de facto standard. Designing web interfaces that cater to both worlds is not an afterthought; it’s a non-trivial challenge that requires careful planning from the early stages of the design process.

Most web interfaces nowadays are designed based on the premise that users will be interacting with them using a mouse and a keyboard. While that may still hold true for the most part, there is a clear trend where users are increasingly expecting web interfaces to work just as fine on touch-enabled devices. Unless you build a native application and explicitly redirect your users to it, there is little you can do to prevent them from using your web interface on an iPad and getting frustrated along the way.

That is to say that optimizing your web app for touch is critical if you value your users and strive to offer them the best experience regardless of the device they’re using.

Here is a non-exhaustive list of the most essential points to keep in mind when designing for touch.

Hover states are the bread and butter of present day web interfaces, and they do a remarkable job at decluttering the interface and leveraging the mouse as a pointing device. Notwithstanding, the absence of an equivalent state in touch input renders hover interactions ineffective: unless the same interaction can be performed using single taps, avoid using hovers in the key areas of your application.

Unlike the mouse cursor, our fingers were not designed for pixel precise pointing; touch targets (buttons, links, controls, etc) should be large enough to prevent input errors and the frustration they cause users. The rule of thumb (pun intended) is to make your touch targets no smaller than roughly 1cm in either dimension. In pixels, this value would vary depending on the density of the screen. It is roughly equivalent to 60px on the original iPhone and 120px on retina devices. Even though Apple recommends a 44x44pt target size (roughly 7x7mm) in its iPhone HIG, most studies suggest that the average human fingertip is 16-20mm in diameter and a 10-11mm touch target is the absolute minimum. Regardless of these discrepancies, making touch targets large enough without compromising the native feel of the interface is key to a great user experience.

Beside their dimensions, the positioning and spacing of touch targets equally affect the overall usability of the interface. Fitts’ law holds even more true in touch-centric interfaces since moving fingers around to reach dispersed targets may prove more tedious than doing so with a mouse. Place related controls and navigation elements close enough to each other such as they require minimal finger and wrist movement to be reached. For good measure, leave 1-2mm (3-6px on 72dpi screens) between adjacent targets to make them easier to hit, especially when one or more of them break the 1cm rule.

Most touch-optimized browsers force a delay (300ms) on single taps to make sure that the user didn’t intend to double tap or perform a gesture. While this can be useful in interfaces that rely heavily on gestures, it is a nuisance in most cases as it makes the application feel less responsive. Make your UI elements respond to touch events using Javascript as detailed here and here.

It goes without saying that designing web interfaces which work with various input methods calls for significant compromises, which in turn may result in a sub-optimal experience across the board. Lacking a sane way to detect input methods in the browser, there is little we can do besides fine-tuning the interactions on our web apps to preserve their main functionality on touch-enabled devices.

Photo credits: Blake Patterson