Designing for the iPad

Working on my first iPad app has really forced me to think about design, usability, and user experience issues that creep up that are unlike any platform I have ever worked on. The iPad is not like a desktop app. Having only briefly worked on an iPhone app before, I think that it’s not all too dissimilar but there are even more issues to think about.

No it’s not a laptop! (in your best Arnold impersonation).
Because of the size, people might be inclined to think that this device is like a laptop or a netbook. Nothing could be further from the truth. If you are used to building rich desktop apps (like I am), you will be used to many conventions.

Come on puppy, Rollover
One convention is hover states or rollover states. The iPad being a touch device does not support the concept of hover or rollover states. You either touch a button or you don’t. You can not interact with a user interface (UI) control such as a button, a list, or textbox without activating or taking action on it.

I’m all thumbs.
Another convention of Web 2.0 app is to cram tons of functionality in the form of small buttons or icons. This doesn’t work all that well on a 10″ screen when your index finger is about half an inch in diameter. You just don’t have the accuracy that you get with a mouse pointer. Thus apps need to think about negative space and larger surface area for buttons and icons.

What’s Your Orientation?
For most people interacting with computers/laptops nowadays, it’s taken for granted that you have a widescreen monitor. Many web apps are still designed to fit 1024×768 resolution but more and more sites resize the content and layout dynamically to handle the extra real estate. Not much thought however is given to the orientation of the screen because it never changes. The situation is a bit different on the iPad since the screen size is a fixed 1024×768 which isn’t all that much nowadays. Well designed iPad apps commonly use a split view UI when presenting information in landscape mode and switch to a single detail view in portrait mode because of the smaller horizontal space. Which brings me to my next point.

No it’s not a giant iPhone.
Many people dismiss the iPad as a giant iPhone. While it certainly looks like a iPhone with a pituitary gland problem, it doesn’t have to act like one. The iPhone screen is cramped. 480×320 means you can really only show and thus focus on one task at a time. Most iPhone apps revolve around the concept of viewstacks. If you want to see a list, that’s a view. If you drill down into that list, you get to see the details of that list but you can no longer see the original list. For that you have to hit the back button. The simple reason is because there’s just not enough room. The iPad doesn’t have the same limitation. The extra space lets you display both the list items and the detail view at once.

Input Overload
Your webapp or RIA probably never had to worry about what happens when users click on multiple things simultaneously. A mouse is a single input device. You can only do one thing at a time with it be it opening a dialog, clicking on a listbox or pushing a button. A device like an iPad can handle multiple touch points at once. That also means your app could potentially get into a state you never anticipated. Take for instance this wonderful fish pond app Pocket Pond. Touching the water makes the surface ripple. Touching the water with 2 fingers makes the water ripple from two points. Now try it with 10 fingers, and really shake the water.

These are just some of the considerations when designing for the iPad which I’m sure will apply to other tablet devices.