Designing for the New Array of High-end Phones

For a while there, designers and developers could ignore screen and pixel size, at least for "high end" devices. Let's be honest here, "high end" meant iPhone-like: touch or multi-touch screens, high end Webkit browsers, and 320 x 480 pixels.

That time is now over. To our mind, it really wasn't here in the first place.

Why is the time now over?

1. Android has matured a bit, and manufacturers are putting it on everything. Consider this ARCHOS Internet Tablet (800 x 480 pixels, 4.8 inches), this Vega Picture Frame (1366 x 768 pixels, 15.6 inches), this 7 inch tablet, or the nook's 3.5 inch screen with what looks like a 5:2 aspect ratio
2. Even Palm's WebOS devices will not be consistent, with Pre's pixel dimensions matching the iPhone's, but Pixi's are at 320 x 400 pixels (80 pixels shorter).
3. Normal Android phones, such as the Motorola Droid at 480 x 854 pixels, no longer have a predictable size. Who knows what the next devices screens will be like?
4. The Motorola Droid's pixels, like the ARCHOS pixels, are much smaller than the iPhone's; bitmaps that work well on one may not on the other.

We wrote Photoshop layout is not your friend in March; this new array of high-end devices forces a choice: design for iPhone only, or start designing for multiple screen sizes.

If you're designing Android applications, you have some tools available to you. The Android Developers' Supporting Multiple Screens gives designers and developers a way to deliver the correct layouts and graphics to the correct devices.

For now, however, Android doesn't really support the full array of screens upon which Android is found. Here is what the document's Range of Screens Supported section says about device support:

The Droid is there, as a high-density, normal screen. The iPhone (were it an Android) and early Android phones are medium-density normal screens. The ARCHOS is a medium-density large screen. The nook and the Vega are ... not in the table at all.

Android's support of screen issues is incomplete, but many steps better than previous cross-device platforms like browsers and Java ME. Despite this, many developers have simply ignored the possibility of different screen types. My favorite example is the Fuzzy Clock widget, which is supposed to take up 25% of the screen with a single line of text. Apparently they used a single-sized bitmap font because on the Droid, the "glanceable" clock has the equivalent of about 8 point font. Not at all readable.

And frankly, I don't expect Apple to keep to the current screen dimensions. I don't have any inside information, but they will make a smaller screen or a bigger screen, or a higher-density screen, or probably all three. So even those of you focusing just on the iPhone may want to look at your process in the next few months.

The hardest type of applications to design for multiple screen types are games, as many create mazes, game boards, and levels for a specific aspect ratio. If your application uses scrolling or other pagination techniques, however, you can probably design it to comfortably manage a wide variety of screen sizes. (But all bets are off for supporting the Nook's screen, which will really want to scroll laterally, not vertically). How? Go read the resources linked above in this article. Or hire us.

Thanks for continuing to educate on this issue, Barbara. One related concern we need to design for: changes in screen orientation. This is not only a feature on most high-end phones but even many middling messaging phones, thanks to the popularity of the QWERTY slider. It’s a wrenching experience to deal with this feature late in the product development cycle (voice of experience here!) so plan for it early. Or raise the alarm if you’re a developer and see early designs that don’t take it into account.