iPad devsugar: Letting go of iPhone visual design patterns

The new iPad has lots of space. The screen offers 1024x768 pixels. That's way more room to work with than the iPhone gave you. And because of that room, it's time to re-think the way you designed iPhone applications. Things that worked well with the iPhone's limited space -- things that were meant to expand the device's virtual world beyond the screen's tiny reality -- are the things that you need to readdress and confront. Why keep using visual tricks when you can expand into real pixel space?

Take the traditional UINavigationController class for example. Its entire role on the iPhone is to provide the same kind of tree view used in Mac OS X's Finder windows (View > As Columns, Command-3). The animations as you select and push view controllers and the back button are both there because you can't reasonably see an entire tree structure at once, in columns, the way you do on a Mac.

On an iPad, the rules change. You have enough space to reasonably present that kind of tree based view, whether you use two columns, or three columns, or more. An iPhone-style view controller begins to make less sense, unless it is embedded into a larger visual design where it needs to conserve space on that layout.

Another iPhone space conservation approach is the tab bar. The UITabBarController class allows you to see up to five tabs at once, each tab hosting a separate view. Applications from YouTube to the iPod music player use this class (and its built in "More.." and customization features) to expand an application into multiple view modes. Users can flip between tabs by manipulating the buttons at the bottom of the screen.

On the iPad, with its extra space, tabs may not be needed at all. Instead of a settings tab, for example, you might use some sort of pop-up element or flip part (instead of all) of your interface to reveal details. With the iPad, you can present more complicated interfaces, although I'm sure both Apple and your users would appreciate if they are well designed and not cluttered. Things that needed to be separated due to space limitations on the iPhone might just work together on a single presentation on the iPad.

There's another visual design consequence for working on the iPad that stands out from Steve Jobs' speech last Wednesday. Over and over, he repeated the mantra: "Any orientation. Landscape or portrait or portrait or landscape," as he turned the iPad around and around in his hands. Apple wants you design your applications to work, regardless of how the user picks up the physical device. The interface should always "point up".

So what does this mean to you as a developer? First of all, it's time to give up what I'll call the "Cover Flow mentality". On the iPhone, when you flip the iPod music application to its side, the presentation changes. It goes from a standard UITableView navigation controller to a Cover Flow view, where you can select an album and browse through it. The iPad kills this design convention. When every way is up, every interface must be consistent. (Update: Apple software demonstrated at the media event shows differences between landscape and portrait presentations.) Sure, you can still use Cover Flow but it's time to switch to that view by introducing a button or gesture rather than by reorienting the device.

It also means that it's time to really start paying attention to those UIView resizing and stretching rules that are presented both at the class level and in Interface Builder. Uncle Steve wants your application to forget about orientation and the best way to do that is to ensure that the geometry stays consistent regardless of device orientation. Your app needs to work consistently whether the horizontal space offers 1024 pixels or only 768.

The key to today's lesson is that you need to step back from your ingrained iPhone visual design patterns. Re-evaluate how you might need to adapt your applications to the new iPad design rules. Sure, most App Store apps will work out of the box on the iPad -- but does that mean you won't want to make your application work better on the iPad? Maybe there are some iPhone habits and design elements that it's time to move away from.

Thanks Emanuele Vulcano, Scott Lawrence, ashH, sneakiness, raingrove