Design for Tablets: Big Phones or Small Desktops or Something Else Entirely?

As I discussed in my previous post, a well-optimized mobile phone version of a complex website typically requires a completely different approach than the desktop site. The site must be much simpler, and it should focus on the tasks that are most likely to be of interest to someone on-the-go.

iPads are often classed as mobile devices, since they run the Mobile Safari browser and have a touch-based interface. Some sites that have a mobile-optimized version with automatic device-type detection will deliver the mobile version of the site to iPads and other tablets.

Usually, this delivers a poor result. Tablets (at least the larger ones, such as iPads) are better thought of as being like desktop browsers with some modest differences, rather than as being in the same class with mobile phones.

Tablets Are Like Desktops …

iPads do not share the two characteristics that make mobile phones such different browsing environments:

• They are much less frequently used while walking down the street or in a car.
• Their screen size is closer to a desktop browser than to a phone.

As a result, the visual and information design of a tablet site should be like a desktop site, not like a mobile phone site.

… But Not Quite the Same

That said, there are some aspects of the tablet experience that are more like a phone:

• A touch screen does not provide any differentiation between hover and click, so any dependence on hover events should be eliminated.
• At least in the case of the iPad, the browser cannot be extended with plugins, so pages cannot use Flash or any other technology that requires a browser plug-in.
• A tablet may be used in a portrait or landscape orientation, so the site should adjust accordingly. In the portrait orientation, the width (for an iPad) is only 768 pixels, which is narrower than desktop designs have taken into account for many years.

Given this situation, there are two good approaches to serving tablets:

1. Accept the tablet’s limitations for the desktop design as well, so you can use one design for both desktop and tablet browsers.
2. Treat the tablet as a third class of device, delivering a site that is different from both the desktop and mobile sites.

The second approach has the advantage of putting no constraints on the desktop site, but it increases the amount of work involved. Generally, the first approach should be acceptable. Depending on the design, you may want to introduce a few new styles for tablet devices to make click targets a little larger and further apart.

Note that tablet browsers generally will scale a web site automatically, so a 960-pixel-wide site, for example, displays without a horizontal scrollbar on a 768-pixel-wide iPad in portrait orientation. This scaled site, however, will have text smaller than designed and links closer together than intended, so it is less optimal than a site that uses a responsive design approach to scale to a true 768-pixel-wide layout.

For tablets with smaller screens, this issue is even more important. Some Android tablets are only 480 pixels wide in portrait orientation, so a 960-pixel-wide design would display each element at just one-half its intended size.

Our Approach to Mobile and Tablet Design

To summarize, our approach to mobile and tablet design is:

• Understand the top tasks for mobile users of a particular site, and design the mobile site accordingly.
• Deliver different HTML pages to mobile phones, so the site can be fully optimized for mobile users.
• Use responsive design, as needed, along with eliminating any UI that depends on hover, so the desktop site can serve tablets as well. Any Flash components must have an HTML5 alternative, and clickable areas may need adjustment.

The world of mobile and tablet devices is young and still evolving rapidly, and no doubt these approaches will evolve as well. For some sites, a pure responsive design approach will be fine; for others, every platform may need to be treated separately. You should have all of these techniques in your toolkit.