---
title: Designing for Touch
teaser: How to think about design on touch screens.
tags: design,ios
author: Reda Lemeden
published_on: 2012-05-18
---

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.

## Why Touch

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 Me Not

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.

## The One Centimeter Rule

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][shamiabd] [studies][schmidt] 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.

## Space Invaders

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.

## Delay No More

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][fast-buttons] and
[here][faster-click].

## Closing words

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](http://www.flickr.com/photos/blakespot/)

[iPhone HIG]: https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html
[shamiabd]: http://www.citeulike.org/user/shamiabd/article/4302090
[schmidt]: http://www.citeulike.org/user/dominik_schmidt/article/4635323
[Fitts' law]: http://en.wikipedia.org/wiki/Fitts's_law
[fast-buttons]: http://code.google.com/intl/de-DE/mobile/articles/fast_buttons.html
[faster-click]: http://luwes.co/faster-click-events-on-mobile-webkit/