Less than one year ago, most of my clients were requesting iPhone app design. Today they are still asking for iPhone app design but many also say, “Do you do Android, too?” Most of them plan to start with one platform, see how things go, and then decide whether to invest in the second platform. This roll-out strategy is often tied into engineering costs. Since few developers possess the coding skills required for each platform—Objective C for iPhone and Java for Android—it’s often necessary to hire two development teams. But what about design?
Would I, too, have to do twice the work when designing for the iPhone and Android? And what will happen if the Windows, Palm, and Blackberry app stores take off? Would I have to do five times the work? This dilemma reminded of the “browser wars” back in 1996, when Netscape and Microsoft used to hire evangelists to teach design and coding for their respective browsers. Eventually these proprietary standards were replaced with industry-wide standards but it didn’t happen overnight.
Many say the same will be true of the different smartphone platforms, that they’ll eventually be replaced with something like HTML 5. This could happen at some point, but we’re not there yet. HTML 5 works well for “web apps” and “hybrid apps.” “Web apps” look very much like native apps but they can’t access device data and hardware such as the user’s contacts, the photo library, voice recording, and device movement. In contrast, “hybrid apps,” which provide access to web content through a web viewing area, can access the device hardware and include native user interface elements. Companies like PhoneGap provide tools to simplify cross-platform development for hybrid apps. Using these tools, developers can create apps that are nearly identical across platforms. This may be effective for certain apps, e.g., games, but productivity apps, e.g., email, may want to customize the UI for each platform.
So we’re back to the dilemma: do designers have to do twice the work to create native apps for the iPhone and Android? Based on my recent analysis, I came to this conclusion: the app definition and concept phases would be very similar regardless of platform, but the app refinement and production phases would require adaptions to create full-fledged native apps for each platform. The remainder of this article discusses these differences based on these four phases: Definition, Exploration, Refinement, Production.
Definition
In the definition phase user research can help you acquire a deep understanding of your users’ needs and how these needs are currently being met. With this research foundation, you may uncover opportunities for new apps and develop innovative solutions that improve upon existing apps. Your user research methods in the Definition phase—diary studies, user interviews, shadowing— will be similar regardless of platform. To learn more about these methods, consider reading Jan Chipchase’s Methods Blog.
In the Definition phase, you’ll also want to read each device’s technical specifications and UI guidelines (e.g., iPhone Human Interface Guidelines, Android’s User Interface Guidelines, Android UI Tips) Knowing what’s possible will help when you get into concept development. App designers should also learn about multi-touch gestures which are well-documented in the followingTouch Gesture Reference Guide. The iPhone and Android have significant overlap but there are a few exceptions.
Exploration
Armed with your upfront research, you’ll want to start brainstorming and sketching app ideas. Try to be as platform agnostic as possible since it will allow you to freely explore a variety of concepts without getting bogged down by platform differences. This can be challenging if you have more experience with one platform since you’ll naturally gravitate to what’s familiar. For example, given my knowledge of the iPhone, I instinctively include Back buttons in my sketches, but Android doesn’t use Back buttons. On Android, users must tap the Arrow button on the device to go back. As an alternative, a platform agnostic sketch could include arrows to illustrate navigation between screens. Similarly, storyboards can work well if they highlight the user and context and place less emphasis on screen designs.
Once you start prototyping and testing your app concepts, it will become increasingly difficult to remain platform agnostic, though this may depend on the app. For example, gaming apps tend to be self-contained so your prototypes may be very similar across platforms. But apps like Facebook and Yelp have different navigation styles for the iPhone and Android. If you test prototypes with users, they may be confused if the apps don’t follow platform conventions. Notable differences between iPhone and Android navigation are summarized below.
iPhone and Android navigation differences
To illustrate these navigation differences, let’s compare Facebook’s iPhone and Android apps (see images below). Notice how the iPhone app has one button that goes Home/Back whereas the Android app uses the Facebook logo to go Home and the Arrow button on the device to go back. Tasks are also treated differently. On the iPhone primary tasks (status update and commenting) are accessed directly on the page; secondary tasks (load new posts) are accessed by “pulling down” the screen. On Android, status updates are treated the same way as the iPhone, however, other tasks are accessed through the Menu or by tapping and holding table rows.
Refine
Once you get into your app refinements, it will become increasingly difficult to incorporate abstract design elements. Even if you have an app that’s self-contained, such as a game, you may have a sign up process, settings, or other features that require you to follow platform conventions. In some cases, you may be able to embed HTML within your native app but these controls may be less ideal than their native counterparts. For example, Android and iPhone have created widgets to make it easier to choose dates in the mobile context. Native apps can easily incorporate such widgets but embedded HTML pages can not. Below is a partial list of common UI controls for the iPhone and Android. For a complete list of iPhone UI controls, please see theApplication Controls section in the iPhone HIG. Unfortunately, the Android UI Guidelines do not include UI controls. You may need to dig into the Android Developer Docs.
Production
When you reach the production phase of your app design process, you’ll want to make sure your images are the correct resolution for each platform. Unfortunately, not only are there differences between platforms but there are differences withinplatforms. For the iPhone 4, the new Retina Display is at 640 x 960 whereas the earlier phones were at 320 x 480. And with Android, the latest Droid X is at 480 x 854 which they call HDPI, but older phones are lower resolution and called MDPI. Both operating systems will auto-scale high resolution images down, though some developers I spoke with don’t trust the quality.
To minimize the work involved with multiple platforms and resolutions, make sure all of your custom assets are absolutely necessary. Aside from your company logo and/or symbol you may not have to create many assets. Both platforms provide icons for common app tasks (take a look at the iPhone icons and Android icons) and there are a number of services that sell icons at a reasonable cost. If neither of these options meet your needs, consider hiring a skilled illustrator for the work.
Summary
iPhone and Android are the current market leaders in the smartphone space but things are likely to evolve in the years to come. We may see Windows, Blackberry, Palm or another competitor edge into first or second place. Whatever happens, more and more designers are going to be confronted with the question: Will I have to do twice the work? Five times the work? Part of me would like to see standards evolve, mostly from a user experience standpoint but also from a business perspective. Standards will make it easier for companies to provide smartphone apps on multiple devices. As it stands now, they need to prioritize devices because of the costs involved. At the same time standards could slow down the rapid pace of smartphone innovation, which would negatively impact everyone. And of course HTML 5 holds great promise but it’s too soon to tell if it will eventually replace the native app platforms. For now, I hope this articles helps you in your endeavors and perhaps you’ll only need to do less than 1.5 times the work.
Acknowledgements
Thanks to Omar Younis, Marty Picco, Jonathan Stark, Michael Mayo, and Emmanuel Carraud for sharing their insights on this topic.
Further Reading
- iPhone Human Interface Guidelines:http://developer.apple.com/iphone/library/documentation/userexperience/conceptual/mobilehig/Introduction/Introduction.html
- Android User Interface Guidelines: http://developer.android.com/guide/practices/ui_guidelines/index.html
- Android UI Tips: http://www.slideshare.net/AndroidDev/android-ui-design-tips
- iOS Icons Made in Pure CSS: http://blog.graphicpeel.com/post/740928981/ios-icons-made-in-pure-css
aa peekinav tee..
ReplyDelete