CONTENT INDEX DEVELOPER PROTIPS: DESIGNING APPS FOR iOS AND ANDROID PREFACE. SUMMARY AND ACTION ITEMS 2 I. THE PURPOSE OF THIS DOCUMENT 2 II. GENERAL SUGGESTIONS 3 A. DESIGN PHASE 3 B. ASSET DELIVERY 5 III. iOS- SPECIFIC TIPS 6 IV. ANDROID- SPECIFIC TIPS 7 V. HELPFUL ADDITIONAL READING 9 PREFACE. SUMMARY AND ACTION ITEMS NOTES While each of these items is explained in greater detail throughout this document, here is a list of a few simple things you can do to make your design and development experience for native mobile development better. ▪▪ R ead the UI guidelines for the platform(s) you are supporting. In particular, consult Apple’s iOS Human Interface Guidelines1 and the Android Design2 page at Google. Pay particular attention to differences in expected navigation patterns, as these can significantly change design across platforms, and even across versions of a platform. ▪▪ L earn what functionality is available on the platforms, versions, and devices you want to support. Take advantage of cool technology, but be careful to ensure that you know what its limits are and can provide fallbacks when certain items aren’t supported. ▪▪ F igure out how you’re going to support different screen sizes. An Application Style Guide is a great way to make this clear, but providing guidance on this is an absolute necessity. ▪▪ M ake sure your PSDs are clear and platform-appropriate. Make sure you’re not giving iOS designs to Android developers, or vice-versa. Show your hit states, keep related items in folders, and use layer comps wherever possible. ▪▪ T alk to developers before finalizing your designs. Developers for each platform can give you feedback that can save you tons of time in implementation, particularly if you are targeting an unfamiliar operating system or a version of an operating system still under development. I. THE PURPOSE OF THIS DOCUMENT Designing for native mobile development, particularly when working crossplatform, can be extremely challenging. While some issues present themselves across all platforms, every mobile platform has different design conventions, screen size handling, and built-in controls. Attempting to build a single set of designs that will be easy to implement on every platform is impossible. We’ve created this document based on our experiences when working with native mobile designs provided by clients. We want to help you limit the time spent recreating native controls from a different platform, figuring out color schemes, and requesting assets that meet the needs of the platform and application. The goal is to give you more time to focus on the really cool stuff. We want, in short, to provide guidelines that will help you during your design process to create the best experience for your users in every application, while keeping your costs and timeline for development as reasonable as possible. 1. Apple HIG, including iOS 7: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/ index.html - Consult your development partner for prerelease documentation for new versions of iOS. 2. Android Design site: http://developer.android.com/design/index.html 2 II. GENERAL SUGGESTIONS NOTES Some elements of mobile design and development apply no matter what the platform. We’ve broken these out into things to take into consideration during the initial Design Phase, when you are coming up with the ideas for your User Interface, and the Asset Delivery Phase, when you are preparing to deliver Photoshop documents to developers. These tips apply to any mobile development platform, though we will be primarily contrasting iOS and Android, as they are presently the most popular platforms at the time of this writing.3 A. DESIGN PHASE ▪▪ H aving a mobile device gives you both less and more flexibility in terms of how users interact with your application: The bad news is that your hit targets will need to be bigger than on a website in order for users to actually be able to select the items they’re trying to hit. The good news is that swiping between screens becomes a much more viable option for navigation, and on some devices multi-touch gestures, accelerometers, gyroscopes compasses, cameras, GPS integration, and other advanced technologies can help create very unique experiences. While all devices support tapping and swiping, ensure that if you want to use any advanced technologies, you are aware of the limitations of each technology, which devices support each option, and can provide some sort of fallback for devices which do not support a particular technology. ▪▪ C onsider making an Application Style Guide, similar to one you would make for a website. Answer some of the questions your designers will need to know as they come up with the designs, and some of the questions your developers will have as they implement those designs. For example: ▪▪ W hat are the hexadecimal colors that will be used within the application for backgrounds, buttons, text, or other repeated elements? ▪▪ Are there standard hit states for buttons? ▪▪ Are there standard sizes for rows in a list of items? ▪▪ H ow should the app handle text that is longer than the designs permit for should it scroll? Should it truncate? Should it ellipsize? ▪▪ O n different screen sizes, should elements grow to fit the height of the screen, or should they stick to the top of the screen, remaining the same height and/or width? Even if you’re only starting with one platform, having this style guide built out can help immensely when transitioning designs to a future platform. Designers and developers can clearly see what you intended during the original design phase just by looking at the style guide. Without a style guide, they might need to 3. U S Smartphone Subscriber Market Share, July 2013. http://www.comscore.com/Insights/Press_Releases/2013/9/comScore_ Reports_July_2013_U.S._Smartphone_Subscriber_Market_Share 3 make assumptions (which introduce additional risk) or seek clarification (which requires additional time) for designs and implementations for a new platform based on designs and implementations for the original platform. NOTES ▪▪ D uring your design phase, look at your designs on a device. Export your PSD or Illustrator document as an image at the size it will appear on a screen (on multiple screens if you are working with Android), and open it on the target device. This is a really easy way to tell if elements that look great on your computer will be too small (or large) for a mobile device. There are a few tools of varying price and sophistication available to facilitate this: ▪▪ F or iOS only, there is an app called Briefs4 that allows fast prototyping and display on an iPhone with a companion app. The iOS companion app is free, the Mac app that facilitates it is currently $199. ▪▪ F or iOS and Android, there is an app called Prototyping On Paper5 that you can use to create quick, tappable prototypes on a device with either pictures you take within the app or images imported from the Camera Roll. Pricing is based on how many prototypes you are currently using. ▪▪ F or a free solution, you can export your comps at the appropriate size to a Dropbox folder, then using the Dropbox app on the appropriate platform, open the comp on a device. It won’t be tappable, but it can quickly give you a good idea of whether your controls are appropriately sized. ▪▪ M ake sure you are aware of what controls various devices provide you as part of the operating system and hardware. For example, iOS only provides the Home button, which developers programmatically have no access to. Android provides a system back button either through hardware or software, and Android developers can intercept taps for this button if they wish to do so. In this example, your designs need to account for a way for users to navigate backwards through the app in iOS, but you may not necessarily need to do so on Android. Android also offers developers access to other hardware buttons not easily accessible in iOS, such as the volume keys. ▪▪ L earn and understand the design conventions for each platform, and on Android, what is available in the version you are targeting. Due to wildly different screen sizes, pixel densities, and aspect ratios, you cannot use iOS assets for Android or vice versa. There are also dozens of differences in the user interface elements each system provides developers. It is significantly less time-consuming for developers to re-skin a system-provided item rather than try to implement one designed for a different system from scratch. ▪▪ If you have custom animations within your application, please provide animatics or similar animations in other applications your developers can use for reference. This will help eliminate guesswork in implementation and can help your developers call out any potential pitfalls of implementing your desired custom animations. 4. Briefs App: http://giveabrief.com/ 5. Prototyping On Paper: http://popapp.in/ 4 ▪▪ S eek feedback from developers before finalizing your designs. We can often point out areas where a small amount of additional work in the design phase can save dozens to hundreds of hours during the implementation phase, or where you’re unnecessarily departing from an accepted convention of a platform. This can be especially helpful if the platform you are designing for is not the platform of the device you use on a daily basis, or if you are targeting a version of a platform which has not yet been released to the public. NOTES B. ASSET DELIVERY ▪▪ P articularly if you have not provided a Style Guide or have hit states that fall outside its bounds, make sure that you use Layer Comps instead of multiple PSD files to show hit states. This helps ensure during the design process that hit-state buttons are all the same size as standard buttons, and helps us slice your elements accurately during development. ▪▪ P ut related interface elements in folders in your Photoshop document - this makes them much easier for the devs doing the slicing to find and saves time during this process. ▪▪ Make sure you are using the correct Color settings for your PSD: ▪▪ Color Mode is set to RGB ▪▪ D ocument is using Photoshop’s default “North American Web/Internet” Color Settings ▪▪ RGB Working Space must be “sRGB IEC61966-2.1”. ▪▪ RGB Color Management Policy must be set to Convert to Working RGB. ▪▪ P SDs without these color settings will result in inaccurate colors when implemented. ▪▪ M ake sure that if you have text with layers of effects on top of them, the layers are separated out rather than blended together - otherwise we will not be able to slice them properly. In short, do not use layer effects unless they can be flattened. Blending-based layer effects are particularly troublesome to implement, and should generally be avoided. ▪▪ M ake sure every folder with new versions of PSDs is labeled with the date delivered. Please let your development team know exactly what has changed in the PSD when delivering changes, particularly if development has already commenced. This helps us focus on implementing changes rather than figuring out what has changed. ▪▪ I f you choose to use any font other than those included with the system (iOS encourages the use of Dynamic Type, which is optimized around Helvetica Neue6, while Roboto7 is the only font included on Android as of 4.0 Ice 6. Apple HIG section on Typography: https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/ColorImagesText.html 7. Android Typogrophy including all about Roboto: http://developer.android.com/design/style/typography.html 5 Cream Sandwich), make sure your custom fonts are properly licensed for use in mobile applications and are provided to the developer in the proper format for each platform. TrueType (.ttf) or OpenType (.otf) files will work for iOS and Android - consult your development team directly for confirmation for other platforms. NOTES III. iOS- SPECIFIC SUGGESTIONS iOS design has, until recently, been somewhat easier than Android design, largely due to the dramatically smaller number of devices that need to be supported. Right now, there are only three screen dimension types to support. At Retina resolution (all devices supported by iOS 6 except the iPad 2, iPad Mini and the iPhone 3GS), these are iPad 2048x1536, 640x960 iPhone/iPod Touch, and 640x1136 iPhone/iPod Touch. Final PSD comps should be provided at these sizes. The biggest opportunity and danger in iOS design at this moment both lie in the significant changes in User Interface and Interaction which Apple introduced with the announcement of iOS 7. Apple has fundamentally rethought much of the philosophy behind their User Interface and User Experience, leading to a look and feel that departs dramatically from iOS 6. There are several things that you can do to help keep implementation of your iOS designs as smooth as possible: ▪▪ R ead the Human Interface Guidelines8 for both their overall theory and for notes on the individual elements you are designing. They can be very helpful in terms of keeping you away from common pitfalls. Apple has made significant clarifications and revisions to this document for iOS 7, building on their decade of mobile User Experience research - take advantage of it to the fullest extent possible. In addition, if you are transitioning an existing app to iOS 7, Apple has put together a fairly thorough guide9 for this. ▪▪ W hen designing, make sure that you facilitate supporting non-retina devices by placing all your elements on even pixel numbers and making them even pixel heights and widths. This facilitates resizing these elements appropriately for non-retina devices - non-retina is exactly half the size of retina, so all pixel measurements should be divisible by 2. If they are not, you’ll wind up with assets that cause sub-pixel rendering, which both creates a surprisingly large performance hit and looks blurry. ▪▪ M ake sure you’re aware of the standard sizes for iOS UI elements. Going outside this size range can be done, but it may add a significant amount of time to development depending on the element. Apple, frustratingly, does not provide a list of these sizes, but graphic designer Ivo Mynttinen put together an excellent Cheat Sheet with several of these listed.10 8. Apple Human Interface Guidelines: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/index.html Consult your development partner for prerelease documentation for new versions of iOS. 9. iOS 7 UI Transition Guide: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/TransitionGuide/index.html 10. iOS 7 Design Cheat Sheet: http://ivomynttinen.com/blog/the-ios-7-design-cheat-sheet/ 6 ▪▪ A pple recommends all hit targets be 44x44 points (a point is 1 pixel in nonretina devices and 2 pixels in each direction in Retina devices). On iOS, it’s relatively easy to make hit targets larger than the images themselves, but you may wish to have the full image you’re going to use as a target be that size so the user can see the full extent of the tappable area. NOTES ▪▪ F or pre-release/newly released versions of iOS, recall that Apple likes to give the developers the tools to create many of the same interactions that they use in their stock applications. They also expect developers to follow many of the same design guidelines they have created for any new version. Always carefully examine any updates to existing stock applications for guidance towards new direction for your own applications. Note that in the future, you should engage your development partners early whenever any major changes are announced in conjunction with a Non-Disclosure Agreement. This will help you make sure you are aware of both new tools and tricks Apple has provided to improve your application and any new pitfalls that might affect your existing UI or functionality adversely. IV. ANDROID- SPECIFIC SUGGESTIONS Android design can be a real challenge. The myriad of screen sizes and the fragmentation both among operating system versions (named for various candies and desserts) and among manufacturer modifications to each of those versions can lead to all sorts of weird quirks in design support. In addition, we’ve found in practice that many designers do not use an Android device as their primary mobile device, so they are generally less familiar with the conventions of the platform than they are with a platform they interact with on a daily basis. Because of those factors, we’ve got a somewhat larger number of suggestions to help you make your design process successful with Android: ▪▪ T ake a read through the Design Guidelines11 that the Android team has put together since wholly revamping the User Interface in v4.0 (Ice Cream Sandwich). This contains a myriad of examples of interface elements and design patterns that are now commonly available for Android. Three in particular to pay attention to, and all of which have been back-ported as far back as v2.3.3 (Gingerbread) are: ▪▪ T he Action Bar design pattern12. It looks somewhat similar at first glance to the UINavigationBar in iOS, but is philosophically and programmatically very different. ▪▪ T he Navigation Drawer13. Note that Google’s implementation of this is a bit different than the version seen in many existing iOS andAndroid apps, particularly the older versions of the Facebook app: Bringing out a navigation drawer overlays your content rather than pushing your content over to one side. 11.Android Design site: http://developer.android.com/design/index.html 12. Action Bar Design Pattern: http://developer.android.com/design/patterns/actionbar.html 13. Navigation Drawer design pattern: http://developer.android.com/design/patterns/navigation-drawer.html 7 ▪▪ Navigation patterns, in particular the Up vs. Back pattern as it relates to the Action Bar. Google’s page on this14 has several excellent examples with clear diagrams of the differing actions that can happen when the user presses the system back button vs. pressing the Up button on the Action Bar. NOTES ▪▪ S upporting sophisticated user interfaces has become significantly easier since Android v4.0 (aka Ice Cream Sandwich, or ICS). Unfortunately, only a small subset of the changes have been added to the Support library that allows some elements to be usable on Android v2.3 (a.k.a Gingerbread), which as of this writing, was still on 30.7% of currently active Android devices. You can view the overall Android install base at any time by on the Dashboards Page at the Android Developer site15, but you should also consider whether your user base might be one that is more likely to have a newer phone before deciding to support Gingerbread. Most sophisticated UI elements and animations *can* be supported on Gingerbread, but it can take anywhere from dozens to thousands of lines of additional code (and therefore significantly more time) to do so. The decision to support Gingerbread devices should be akin to deciding to support a legacy browser: Consider realistically how much of your user base will be using the older technology, and whether serving that audience until they upgrade is worth the additional cost of development. ▪▪ D ecide what screen sizes and pixel densities you wish to primarily target up front, and provide appropriately sized assets for each. If you are only targeting phone-sized devices, we have seen solid results with 480x800 hdpi and/or 720x1280 xhdpi as baseline screen sizes/resolutions. The Android Cheat Sheet for Graphic Designers16 can help you figure out how to scale your assets appropriately. ▪▪ N ote that social sharing in Android is significantly different than in iOS. For Android, a system called “Intents” allows applications to register for sharing links and other items, and users can easily use their social network of choice to share a link. There’s a great post summarizing this at the Google Developers blog17 - the “Intents over Integration” and “Avoid One-Off Integrations” sections are a concise summary of why using system-level sharing rather than individual share buttons is the superior approach. There’s also an example at the bottom of the post of what sharing from the ActionBar looks like in modern versions of Android. ▪▪ B e aware that design changes can take longer to implement on Android than iOS. Android assets have to be sliced *very* precisely to allow for proper layout on multiple screen dimensions when views are complex, so having custom assets finalized at the beginning of development is particularly desirable for Android. 14. Android Navigation Patterns: http://developer.android.com/design/patterns/navigation.html 15. Android Dashboards page: http://developer.android.com/about/dashboards/index.html 16. Android Cheat Sheet For Graphic Designers: http://petrnohejl.github.io/Android-Cheatsheet-For-Graphic-Designers/ 17. Android Sharing With Intents: http://android-developers.blogspot.com/2012/02/share-with-intents.html 8 V. HELPFUL ADDITIONAL READING NOTES Beyond the links already referenced in the footnotes of this document, Here are a few additional links we’ve found to be very helpful. MULTIPLE PLATFORMS ▪▪ M att Gemmell’s How Designers Can Help Developers and its companion piece, How Developers Can Help Designers. Primarily targeted at iOS devs, but helpful guidance for all platforms. Designers Helping Devs: http://mattgemmell.com/2012/02/02/how-designers-can-help-developers/ Devs helping designers: http://mattgemmell.com/2012/02/06/howdevelopers-can-help-designers/ ▪▪ F lat Design - A blog covering well-done iterations of the popular flat design for multiple mobile platforms and the web- there’s no direct link, but click the “App” button to see examples of iOS and Android apps. http://fltdsgn.com/ ANDROID ▪▪ M obile Design Tips For Android - Designer favorite Smashing Magazine’s comprehensive list of tips: http://mobile.smashingmagazine. com/2012/07/26/android-design-tips/ ▪▪ D on’ts Of Android Design - A solid reference of pitfalls to avoid, particularly when transitioning your application from iOS to Android: http:// www.androiduipatterns.com/2013/06/donts-of-android-design.html ▪▪ A ndroid Design Protips - A nice little set of Android Design protips from Android UI guru Roman Nurik, including a great calculator for converting Device-Independent Pixels to pixels for design purposes: https://plus.google. com/+RomanNurik/posts/9FhozUbg2i2 ▪▪ A ndroid Design in Action - A YouTube talk show with several high-level Android designers going through the best practices and common pitfalls of design for Android. https://www.youtube.com/playlist?list=PLWz5rJ2EKK c8j2B95zGMb8muZvrIy-wcF ▪▪ A ndroid Notification Icon Design Guidelines - For icons that show in the status bar when the user receives a notification. Note that these are different based on what operating system your user is running: 2.2 (Froyo) and below, 2.3 (Gingerbread), or 3.0 (Honeycomb) and above. http://developer.android. com/guide/practices/ui_guidelines/icon_design_status_bar.html ▪▪ A ndroid Niceties - A good collection of modern Android user interface design. Particularly useful for seeing how people are taking advantage of the Action Bar. http://androidniceties.tumblr.com/ 9 ▪▪ T ips For Android Tabs - Android handles tabbed interfaces very differently than iOS, and this is a good summary of the Android conventions. http:// www.androiduipatterns.com/2012/08/tips-for-android-tabs.html NOTES ▪▪ S upporting Multiple Screens - The extensive, official, slightly overwhelming guide to supporting multiple screens (ie, both phones and Tablets) in the same application. https://developer.android.com/guide/practices/screens_ support.html ▪▪ A ndroid Asset Studio - An open-source method to help you create appropriately sized assets for various screen sizes and pixel densities. https:// android-ui-utils.googlecode.com/hg/asset-studio/dist/index.html ▪▪ A ction Bar Style Generator - An open-source tool to help quickly and easily preview potential styles and generate appropriate resource files for your ActionBars. http://actionbarstylegenerator.com ▪▪ A ndroid Holo Colors - An open-source tool to help quickly and easily generate the appropriate Android native-control-friendly colors and icons for your application. http://android-holo-colors.com/ ▪▪ E nchant, Simplify, Amaze: Android’s Design Principles - A ~40 minute talk from the 2013 Google I/O conference about UI principles for Android: http://www.youtube.com/watch?v=s0HIP8EdlnE iOS ▪▪ A pp Design Workflow - A great article from the prinicipal designer at Bjango who detailed his entire workflow very thoroughly: http://bjango. com/articles/appdesignworkflow/ ▪▪ T eehan + Lax’s GUI PSDs - PSDs representing the GUI of iOS and giving you an outline for the phone. Note that as of this writing, they have not updated for iOS 7, but these can give you a running start if you need http:// www.teehanlax.com/blog/?s=gui+psd ▪▪ D esigning for Retina Display - A two part article from Bjango highlighting some tips and techniques for effective Retina display design. Part one, with basic tips: http://bjango.com/articles/designingforretina/ Part two, with lots of good questions and answers: http://bjango.com/articles/designingforretina2/ ▪▪ B eautiful Pixels - A good design blog covering highlights of recent iOS applications. Also covers the occasional Android app. http:// beautifulpixels.com/ ▪▪ P ttrns - A site with a collection of various design patterns easily sortable by type - Activity feeds, calculators, popovers, etc. http://pttrns.com/ 10 NOTES 11