Voices that Matter iPhone: Five iPhone app design mistakes, and how to fix them

TUAW is at the Voices that Matter iPhone developers' conference this weekend, talking to iPhone OS developers of all walks of life. All weekend long, devs are here learning about how to code and design better iPhone applications from some of the best minds and artists on the App Store.

We've gathered some wisdom from the hallways and discussions here at the conference, and boiled them down into five different design mistakes that developers need to address before moving into the iPad arena. Hit the link below to see what's going wrong with typical iPhone practices when they are applied to iPad development, and how to do it right.

1. Stop designing too small. All too often, iPhone devs have designed to exact pixel dimensions. They've accepted art that was, at its largest, 320 by 480 pixels in size. As the iPad has shown, and the next generation iPhone leaks hint out, that's a development strategy that has to stop. New device families and ever-improving display technology show that practical real world pixel dimensions are on their way up. Building higher resolution source art -- or even better, using resolution independent vector sources -- help ensure that your art will keep working in shipping software as new devices debut.

Solution: Start big; scale down.

2. That Documents folder is not yours. For a few years now, developers have been getting away with using the sandbox Documents folder as an extension of their application. Got a core database that ships in your app bundle? Chances are pretty good that at least some of you have copied it out to the Documents folder, and allowed the application to customize it from there. (You cannot modify files in the application bundle, but there is no other way to include files with your app other than to store it in the bundle.) This is a Bad Move.

As of the 3.2 SDK, the Documents folder has opened itself up to the user. When you enable sharing, users can then manage the contents of the folder through iTunes. They can add files, delete files, and even overwrite them -- all by using a simple iTunes feature in the Apps tab.

Its time for the Documents folder to be used the way it is meant to be, the Apple way. Application support files belong in the Library folder, not in the Documents folder. The Documents folder is meant for Documents, which can be created, read, or edited by your application. All materials that support your application that are not user documents belong in the Library, preferably in an Application Support folder that you create yourself.

Solution: Keep your files in the Library folder. Surrender the Documents folder to the user..

3. Your model doesn't belong in your View Controller. If you've studied Computer Science, you've likely encountered Model View Controller, the design paradigm that separates "orthogonal" (functionally non-intertwined) development elements into distinct programming units. For far too long, iPhone developers have gone the lazy route of adding programming functionality into their UIViewController applications. With the iPad introduction, that cannot continue.

In order to ship applications that truly work on multiple devices, your application needs to create separate interface components for each interaction style you'll support. Don't just think separate XIB files; consider completely separate controller classes, united by a single underlying model. You can't accomplish that until your model is decoupled.

Solution: Pry your Model out of your View Controller.

4. Your iPad is not an iPhone. As author and developer August Trometer points out, an iPad is not an iPhone. From physical device differences to screen resolution, the iPad has a new set of interaction challenges that you must meet as a developer. People hold the iPad differently. There's far more space to work with -- you don't have to fold your interfaces the way you do on the iPhone, using technologies like tab bars and navigation controllers.

Your designs need to expand into the whole iPad space. The interaction ideal is a single, focused, full application without intermediate windows. If you need to reference transitory information, popovers now make more sense than full screen modal presentations. Apple has thought about these things, long before they released the iPad to the public or the iPad SDK to developers. And they encapsulated their development ideals in the human interface guidelines that they wrote specific to the iPad device.

As a developer, it is your job to get the HIGs, read the HIGs, and live the HIGs. And you have got to be aware that the iPhone HIGs are not the same as the iPad HIGs. Your applications will not succeed until you recognize and celebrate the iPad differences as a device of its own type, own features, and own limitations.

Solution: Design to the iPad HIG.

5.. Every orientation matters. Even face up. Apple insists that your application fully express at least one orientation, whether landscape or portrait. A portrait app, for example, must work properly when the Home button is down and when it is up. They, of course, prefer that your app work meaningfully in all four orientations, although at this time that is not a hard requirement. But there is one kind of use that the iPad excels in that is mostly missing from the iPhone oeuvre.

Don't overlook the flat, face-up iPad orientation. It's great for reading ,for playing air hockey, for engaging in cooperative drawing, and more. Consider designing for face up use, and allow users to control that use without having to pick up the device to get it to re-orient every few minutes.

Instead, consider adding non-accelerometer orientation control for face-up interaction. Add a software lock, and a reorientation control directly into your interface to support that (literal) desktop interaction mode. If you can use a flat interaction style, make sure you design that style into your app.

Solution: Design for all physical orientation realities..