Matt Gemmell

TOLL is available now!

An action-thriller novel — book 2 in the KESTREL series.

★★★★★ — Amazon

iPad Application Design

development, interface & tech 12 min read

I held a 6-hour workshop at NSConference in both the UK and USA recently, focusing on software design and user experience. Predictably, an extremely popular topic was the iPad, and how to approach the design of iPad applications. I gave a 90-minute presentation on the subject to start each workshop, and I want to share some of my observations here.

Please note: this is about the user interface conventions and considerations which apply to creating software for the iPad platform (and touch-screen tablet devices in general). It is not a technical discussion of iPad-related APIs (which remain under NDA at time of writing in early March 2010).

As I watched the iPad introduction keynote, there was one thing above all which struck me:

iWork for iPad

That’s iWork (Keynote, Pages and Numbers) for iPad. It’s also a message.

It's not just a big iPhone

The iPad may be a larger version of the iPhone in terms of the hardware and operating system, but treating it as the same device would be foolish. It turns out that increasing the display size of touch-screen hardware can transform it into an entirely new class of device. The iPad is a productivity platform in a way that the iPhone rightly never tried to be. (And it’s officially OK to charge $9.99 per app.)

When Steve Jobs introduced the iPad, he did so in a very specific way:

iPhone, iPad and Mac. iPad in the middle.

The iPad is in the middle, between the iPhone and the Mac. This isn’t just an acknowledgement of relative display size or processing power, it’s also a strong indication of the market position of the device and its software.

The iPad is a target for apps from the desktop, not just from smartphones. There are some very interesting opportunities here.

The Missing Link

We already have iPhone apps on the iPad (they can run at their native size in the middle of the screen, or be scaled up to fit). That’s useful, but it’s not particularly interesting. Far more relevantly, we can bring desktop-class applications to iPad - but we need to rethink our user interface and design in general. What works on iPhone won’t automatically work on iPad.

The essence of the new opportunities on iPad is that this class of device is a natural home not just for the viewers and small utilities we’ve seen on our phones, but also for creators and editors as we see on desktop platforms. Productivity applications, and sophisticated workflows. There are entire genres of applications which haven’t been truly feasible on an iPhone OS device until now; this is an opportunity to literally pioneer a high-profile touch-screen version of those applications.

In order to work out how to do that effectively, we need to talk about what exactly is different about the iPad compared to the touch-screen smartphone platforms. It all comes down to input and output.

  • The display is much larger; 1024x768 pixels. Apps with more demanding presentation requirements will be at home here.
  • The virtual keyboard is larger, and external physical keyboards are supported via Bluetooth or the dock. Apps which focus on typing are now much more feasible.
  • The iPhone supports multi-touch, but only the iPad can credibly claim to support two hands. We'll talk more about this later.

These facts lead to a shift in how we can think about what applications and interfaces can exist on the iPad. We just need a set of guidelines to follow.

The iPad introduces and lends itself to some new UI conventions. I’ve compiled a list of thoughts that I’m going to discuss below. Some of these are simply from looking at the built-in apps on the iPad, and some are subjective impressions.


This isn’t new, but it’s new to the iPhone OS platform. Master-Detail is an interface concept whereby you can see both a list of things, and also additional information about the currently-selected thing in the list. On iPhone, either the Master or the Detail was visible, but not both - there wasn’t room. On iPad, we can again have Master-Detail, as exemplified by Mail:

Mail for iPad

This gives us an easy set of conventions:

  • Master-Detail is feasible and acceptable on iPad.
  • In landscape, both Master and Detail are visible.
  • In portrait, the Master is shown in a transient pop-over.

Two-pane and three-pane interfaces are once again worthy of consideration on this class of device.

Look like a Viewer

The primary warning about designing for the iPad is: more screen space doesn’t mean more UI. You’ll be tempted to violate that principle, and you need to resist the temptation. It’s OK to have UI available to cover your app’s functionality, but a bigger screen doesn’t mean it should all be visible at once.

  • Hide configuration UI until needed.
  • Look like a viewer, and behave like an editor.

Pages looks like a beautiful reading app:

Pages for iPad; document viewing with loupe.

until you interact with something to display relevant editing UI:

Pages for iPad, displaying editing UI

This leads us naturally to the next point.

Edit in place

On the Mac and other desktop platforms, there’s a convention where we have globally-positioned editing UI. Common examples include floating inspector palettes, toolbars, menus, and status-bars. That won’t fly on the iPad, because it introduces a level of indirection between the editing action and the object being edited. It’s a touch-screen device; we should interact and edit directly.

  • Edit object properties in place.
  • Attach the editing UI to the object. Show/hide/move as necessary.

For example, when you edit transition/build animations in Keynote, you do so on the actual object to be animated:

Keynote for iPad, showing an animations editing UI attached to a bar-chart.

Upon adding an animation, the list of available types is similarly attached to the relevant object:

Keynote for iPad, showing an animations list attached to a bar-chart.

The same goes for slides as a whole:

Keynote for iPad, showing an animations list attached to a slide.

It’s a good principle to follow; it’s direct and immediate, and it’s intuitive for a device where it feels like you’re interacting with the actual objects using your fingers.

Inspectors should be Contextual

There can, however, sometimes be value in keeping standard editing interfaces in standard positions; the key consideration is how much UI to show. On the desktop, this is something we often get wrong. Here are two familiar examples:

Inspector palettes for Keynote and Microsoft Word on the Mac, each showing many controls.

These inspectors (for Keynote and Microsoft Word on the Mac) are difficult to use because they show all possible editing controls at once, disabling those which don’t apply to whatever is selected. It’s not easy to find which options apply to what you’re editing at the time, and the density of controls requires the pixel-precision of a mouse pointer and considerable screen space to display.

On the iPad, any globally-positioned inspectors should nonetheless be contextual in terms of what editing UI they show. Don’t overload the user with irrelevant options; hide anything that doesn’t apply. If you’re editing text, show only text editing controls:

Pages for iPad, showing an inspector with text-specific controls.

If you’re editing a chart, show only options relevant to charts:

Pages for iPad, showing an inspector with chart-specific controls.

The guideline is simple, and it’s good advice even for the desktop:

  • Inspectors should present context-relevant UI.
  • Hide controls which don't apply to the selection or focus.

The concept of context is key to iPad software design. In human-computer interaction, we often discuss this under the title of modes.

Use Modes to simplify UI

Modes, or modal interfaces, are where the user deals just with one particular area of a piece of software at a time. They see only the relevant controls and information for one particular task or type of work; an example would be iPhoto’s photo-editing interface, or the Ribbon in the recent versions of the Microsoft Office applications.

There’s been a history of modes getting some bad press on the desktop. The issue is that they trade stability (things always being in exactly the same place in the UI, and not changing) for simplicity (not having too many controls to look through at once). On the iPad, it’s clear where the winning side of the balance is: simplicity. Modes are completely appropriate on this device.

The challenge is in keeping our UI clear and uncluttered. Not only that, but our UI has to be actually usable with a finger - an incredibly imprecise, enormous, screen-hiding input device - rather than a pixel-perfect mouse pointer. Modes can help us keep plenty of space around. Move UI elements into modes, and/or position them contextually and temporarily - but just don’t go overboard with the number of modes.

  • Modes are preferable to clutter.
  • But removing a feature might be preferable to adding a mode for it.

The modal organisation of features is better than an all-at-once approach, but don’t let it become an excuse for feature creep. One of the primary rules of iPad app design must surely be that less is more.

Fewer Features

Feature-creep or bloat is the bane of desktop software. Any application with a non-trivial feature set isn’t fully used by most of its users; that’s pretty obvious to anyone who has ever used Microsoft Office or Adobe Photoshop or even the iWork apps on the Mac. There are plenty of features there which you’ll never touch, and would probably never miss if they were gone.

Most users need only a small set of features, and software is better when it’s focused. A nice side-effect of focused software is that the UI is easier to design and comprehend (because there’s less of it, and it’s more obvious why each thing is there). The trick is to figure out which small set of features are actually important, and implement only those.

  • Offer only the most-used/needed features. If in any doubt, remove a feature.
  • Discard optional/niche or highly configurable functionality.

This is another rule which is equally true for the desktop. The difference is that people have been trained to accept fuzzy-edged applications on their computers, whereas they probably won’t do so on the iPad. Be focused, targeted and comprehensible. You can add things later when it becomes clear what’s important, but you’ll never recover from a confusing first impression.

Two Hands

Many people are excited about the fact the iPad is large enough to support two whole hands providing input simultaneously. The hardware support is no different from the iPhone, but the available space certainly is. Suddenly we have visions of really usable card games and air hockey and so forth; it’s hard to underestimate the importance of this factor.

The worrying thing is that I’ve heard people talking about providing twice the UI, with strips of buttons and controls down both sides of the screen, just because there’s enough room for that kind of thing now. Resist that temptation at all costs. The way to support dual-handed input on the iPad is in a discoverable and optional way. There are a couple of interesting examples in Keynote:

Phil Schiller using Keynote for iPad, showing two-handed input features.

During the iPad introduction keynote, Phil Schiller was using Keynote on the device, and demonstrated some subtle dual-hand input features. Whilst resizing a photo, you can tap another photo with your other hand and the one you’re resizing will match that other photo’s size. Similarly, whilst dragging a slide you can tap other slides with your other hand to add them to the group being dragged, thus moving them all at once.

The important point is that there are other, more obvious ways to accomplish these things; the two-handed input features are conveniences and power-user features. They’re useful and time-saving and possibly discoverable, but they’re not the only way to accomplish those tasks. We’re only just beginning to come to terms with the possibilities of dual-handed input; essential functionality shouldn’t require it yet.

  • Dual-handed input is acceptable.
  • Be usable with one hand. Don't require two hands for essential features.
  • But don't be afraid to offer time-saving, discoverable dual-handed functionality.

The fact that users can use their hands to interact is something to capitalise on; it’s a very important aspect of the attraction to this type of device. Understandably, it’s rooted in human psychology.

Use the Psychology of Touch

This is where it gets touchy-feely, and thus where we engineers are least comfortable. It’s also where we find the explanation as to why your grandmother wants an iPad but wouldn’t touch a Mac or PC. The twin key factors are touch, and the device’s unique form-factor.

Touch is emotionally important to humans; it conveys the identity and “realness” of an object. Direct touch bypasses abstraction and creates a strong connection with the touched object. This is particularly true when the object itself triggers associations in our minds. Due to its very size and weight and display area, the iPad triggers powerful associations with:

  • Printed documents
  • Notepads of paper
  • File-folders from the filing cabinet
  • Clipboards
  • Books

There is something intrinsically “right” about seeing the iPad as a technological successor to, or version of, these physical objects. We’re immediately ready to accept the one as a substitute or enhancement for the other. This is a powerful, and novel, position for the iPad software developer.

It wasn’t true with the iPhone or iPod Touch; the devices are too physically small. The “Notes” app on the iPhone will forever be a simulation of a legal pad; the similar app on the iPad is a legal pad (to your user). It’s an incredibly important distinction in terms of how it influences our design.

There’s a predilection towards “realness” on the iPad which overrides mere fashion and aesthetics as seen on the iPhone; it’s a core component of the attraction of the hardware. The standard apps on the iPad build directly on this by using virtual materials. The form-filling view in Numbers is a good example:

Numbers for iPad, showing the form-filling view: a simulated card file with paperclip and paper.

We’ve all clipped those card dividers into our binders, and seen them become dog-eared. We know how the slightly waxy laser-printer paper feels, and we’ve bent and reshaped that paperclip a thousand times. These are real things, presented virtually.

The iBooks app, showing wooden bookshelves and printed paper.

We’ve all been in the room with these varnished bookshelves, lit by afternoon sunlight. We’ve all bought a new novel, opened it and guiltily buried our nose in the pages just to enjoy the smell of books.

The Notes app, showing a yellow legal pad in a leather case.

We’ve all used this legal pad to sketch ideas. Perhaps we’ve even seen it on the telephone table in the study or hallway, slid into its leather slip-case with an index sheet (all those things are visible in the interface above if you look for them).

The Calendar app, showing wood-backed hard-bound day planner.

We’ve all seen this quality day-planner and wished we had the discipline to use it, because it’s a beautiful analogue thing in an increasingly digital world. We’ve paid ridiculous prices for Moleskines and diaries and fountain pens.

The Contacts app, showing a hard-bound address book with a fabric bookmark.

We’ve all seen this address book sitting on a desk, hard-bound and meticulously re-indexed, with a red fabric bookmark sitting loosely over the cover.

Did you feel an emotional connection to any of these images and statements? Your users will feel those connections too, even if they can’t articulate them. You can, and should, directly capitalise on these feelings and connotations.

Even if you can’t find a way to make your interface be a real thing, you can often make it into a surface for real things. It’s one additional level of abstraction, but it’ll still work.

The Photos app, showing stacks of photos and a light-box view of a single image.

This is the table you empty the photos drawer onto when you want to find a particular image from childhood; the stacks are all that’s left of the long-discarded paper wallets the photos originally arrived in. The full-screen display is a photographer’s light-box. The device becomes physical surfaces we know in the real world.

The iPod app, showing CD album covers laid out in a grid.

Even resolutely abstract concepts like playlists of music can be represented as surfaces of CD albums. There’s often a way to pull your software interface a little closer to a familiar object from the real world, and increase engagement with the user.

  • Make your application a real object if at all possible.
  • Alternatively, make it a surface for real objects.

Our graphic design budget must surely increase, but I think you’ll find the pay-off is more than worth it.

Key Questions

In summary, when approaching iPad app design, do so in a way that acknowledges the strengths and unique advantages of the device and platform. Ask yourself these questions:

  • What are the core features? How can I remove some of them?
  • How can I make this work on a touchscreen device?
  • How do I create an emotional connection?
  • How can I make my app uniquely suited to iPad?

Don’t ship before testing on an actual device, and remember that first impressions last - take the time to get it right. Don’t assume that what works on iPhone will be equally suited to iPad, and certainly don’t generalise from desktop software.

There’s a unique and exciting opportunity here, and just possibly the beginning of the next major stage in software design and user experience. You’re getting in on the ground floor, and there’s every reason to be optimistic. Good luck.

If you enjoyed this article, you might be interested in following me on Twitter, enquiring about my iPad (and iPhone and Mac) development services, or listening to my thoughts on software design on The MDN Show podcast. I'll also quite shamelessly link you to my Amazon wishlist.