Web Design for Touch-Based Devices

You may have already read on this blog that I’m an early adopter of a tablet computer, the iPad.

Now that Apple have just announced the release of the second incarnation of it and other manufacturers have started to enter the market place, I thought it an idea time to look at a couple of issues I’ve found with some web design practices.

(Mis-)Use of the Hover State

The hover state is great when using a mouse. It allows us to highlight links as we move the mouse over them, reinforcing the fact that a user is pointing to a ‘clickable’ link. I fully advocate its use in this context and do so myself.

The problems start to occur when hover is used to reveal more substantial content or functionality.

Revealing Buttons and Links

One fine example of this is the web-based Twitter stream. (I know, I know, who uses that when there’s so many cool clients out there!?)

Example: My Twitter Stream

Example: My Twitter Stream

This is my stream, cropped to a few posts. As it is it’s nice and clean, showing just relevant information at this point. When you hover over each tweet a few more links appear allowing you to retweet, reply or favourite that tweet.

Tweet Options

Tweet Options

This is great and intuitive when you’re using a mouse as by hovering over something you haven’t really committed on making an action. On a touch screen, however, this is completely different. There’s no such thing as hover on a touch screen.

On the iPad, these options appear when you tap anywhere on a tweet NOTHING happens, but when you tap on a link in a tweet, these options appear. When I tap on something that looks like a link I’m expecting to make an action, for example, open a link or go to someone’s profile. Instead of this happening, these other options appear which is potentially confusing to the user because there are no visual clues to the user that this will happen instead of what they think should happen.

Ideally, in my opinion, there should be an Options link, most likely in the bottom right of the tweet that reveals these extra options when clicked or tapped. In fact, through the use of media queries or browser detection, there’s no reason why both solution can’t be used. The current hover version for desktop-based machines and a touch-specific solution for the appropriate device.

Drop-Down Menus

A very similar issue to that discussed above, however, potentially worse.

On a fairly large site, it’s common practice to use drop-down menus to reveal sub-sections. While this makes navigating these sites a lot easier, bad implementation can be very user unfriendly for both touch and ‘traditional’ devices.

This example from the Clinique website is fairly typical. There are top level menu option which each reveal a secondary menu with sub-sections.

Example: Clinique Navigation

Example: Clinique Navigation

For the most part, this is fine, you can hover the top link to reveal the sub-menu and click the top option or any of the secondary options available. However, again, there’s no immediate clue that a sub-menu is going to appear. I don’t know which of these top level are going to reveal more options or take me straight to another page.

This is even worse on the iPad as I tap on an option, expecting to go to a page but it reveals more options. “Hmmm, maybe I’ll try tapping that button again…?” Yet again, a seed of uncertainty has been planted.

Now take a look at how EA have done it.

Example: EA Menu

Example: EA Menu

By using some very simple visual clues, I can easily see which options will take me directly to a page and which have sub-menus. I’m unsure whether it would be better to make the word ‘Games’ a link direct to that page and just the little arrow opens the sub-menu, it might be a bit too small to click on. The main point is, there’s less uncertainty here as to what to expect when I tap or hover over something on the main navigation.


I’ve found a couple of irritating things when using forms on my iPad. They involve the built-in auto-correction features of the device. They’re great features when writing emails or other forms of prose, however, when filling in forms, they can be a nightmare. Auto-correct automatically corrects your spelling, or rather it attempts to. Without care, this can catch you out on all iOS devices, including the iPad and iPhone/iPod touch and various silly and potentially embarrassing faux-pas have been well documented over on Damn You Auto-Correct. While not quite as embarrassing, this feature can be really irritating when trying to fill in an online form. Imagine you’re trying to log into your account on a website and while typing your username, you fail to notice that your magical device has decided that your username has been spelled incorrectly. You submit the form and are met with an error message…. “OMG, WTF, I totally got my password right!!??”

It’s really easy to stop this. All you need to do is apply the following to your input tags: autocorrect=”off” and autocapitalize=”off”

The former will disable the magical dictionary of Fail and the latter will stop capitalisation of the first letter, important for case-sensitive credentials.

<input type="password" autocorrect="off" autocapitalize="off">
<textarea rows="4" cols="50" autocapitalize="off"></textarea">


These are only a few of the things I’ve found while using my iPad and I’m sorry if these seem fairly obvious, but, well, they are but they’re easily overlooked. As tablets start to become more and more widespread, we as web designers have to consider that a growing number of our users are going to be using them. By being sensitive to the differences in interaction with such devices, we can start to adapt both our visual designs and our code to suit everyone without having to really create a new design specifically for each devices.

Have you found any problems with web sites on your tablet? Any opinion on what I’ve said? Please feel free to leave a comment.