Recap: Homegrown | App Design: Designing for Android

Adit is the Director of Creative Strategy and lead designer at the mobile app development firm Two Toasters. Acting as Director of Creative Strategy Adit has worked with a number of clients to build critically acclaimed iOS and Android applications. Most recently, he worked with Simple on the design of their well received android application. In his spare time Adit is an avid cook with an affinity for testing the level of spiciness he can manage.

For those unfamiliar with the Android platform, the process for reinterpreting an iOS or web application for native use is beset by a number of pitfalls and constraints. After all, like designing for native experiences on any other platform, there are many eccentricities and idioms on Android that must be considered in order to craft a consistent and satisfying application. In this talk, Adit walked through the steps for reimagining common iOS usage paradigms, some uniquely Android usage metaphors, best styling practices, designing for multiple form factors and processes for supporting developers to execute designs.

Why Design Natively?

Users speak in Android: without Android paradigms you must teach the user or risk losing them
Using an element from another platform is like forcing a toilet to flush in a different direction, i.e. not idiomatically

How To Start Designing Idiomatically

Screen Densities & Measurement

LDPI (0.75x)
MDPI (1x)
HDPI (approx. 1.5x)
XHDPI (2x)

LDPI is almost completely deprecated while HDPI and XHDPI are the most common. Measurements on Android are specified in units called DP, which stands for Density Independent Pixels. So an on-screen element measured at 8dp works out to the following approximate measurements in pixels:

LDPI = 6px
MDPI = 8px
HDPI = 12px
XHDPI = 16px

In this way, user interface elements correspond to an easy to remember ratio, 3:4:6:8.

Navigation

Back Button

Always takes the user to the previous screen or view
Can navigate outside the app
Found in both hardware and software (on-screen) versions depending on which handset is used

Up Button

Always takes the user to the next level up in an app’s screen hierarchy
Can only navigate inside the app
Found on the action bar, to the left of the app icon

Action Bar

The action bar sits at the top of any app, just below the system status bar. It is and should be used for all major persistent interactions. In portrait mode it is 48dp tall. From left to right we can see the following:

the “Up” action icon
an icon, usually the app icon, combined with the “Up” icon creates the button to invoke the “Up” action
the title of the currently displayed screen, in this case as part of a view control
a group of two action icons, representing the most likely used actions
the overflow icon, representing other, more secondary actions

Tab Navigation

The tabbed navigation bar fills 48dp below the action bar in fixed mode. This bar integrates with the action bar on tablets. There is a scrollable version which is shorter and offers more available space on-screen. However, it obscures the total number of tabs.

View Control

Also known as a Spinner in Android parlance, it offers an alternative to tabs where each selection in the list modifies or replaces the view below the action bar.

Side/Navigation Drawer

Until recently only available via third party libraries, the navigation drawer is most often used to display an app’s main navigation options. As of May 2013, this user interface pattern is now officially supported by the standard Android distribution. This updated interaction replaces the previously used “<” icon as part of the “Up” button with three vertical lines aligned to the left side of the screen. It can also be accessed via swipe. Most third party versions of this UI pattern often require that an action bar is present to use.

Pitfalls

Designing natively and idiomatically for Android involves avoiding UI patterns, graphical styles, and so on that might be found on other platforms like iOS and Windows Phone 7. These are a few highlights:

chevrons, right-facing carets, greater-than signs in list views. These are common on iOS but don’t belong on Android. Instead apps should be designed so that tap behavior is obvious.
labeled back buttons. Instead rely on Android’s native “Up”/“Back” functionality to help users both know where they are in an app and to move around its hierarchy.
text action buttons. Action bar buttons for common/frequently used actions should be represented by icons. Actions like Save/Done/Cancel/etc. should be relegated to a contextual action bar, separately located from the main action bar at the top of the screen.
rounded app launcher icons Android affords an opportunity for designers to create uniquely shaped icons since transparent PNGs can be used.

Where to Begin

Setup

your app and its associated platforms speak in pixels and so should your designs. Photoshop is the best tool for pushing pixels.
keep designs for each app in a single PSD file. Use layer comps for each screen or view and smart objects for frequently used items.
design everything at XHDPI (usually 768x1280px for phones) so you only have to scale assets down for optimisation and export
to avoid doing sp math (Android’s device independent measurement for type, corresponds to the same ratio scale as DPs) set the pixel density of the PSD to 144dpi (2x), so that the pt measurement in the character palette equals the sp measurement. So a 12pt font in a 144dpi PSD is approximately equal on-screen to a 12sp font
Apps like Android Design Preview and Skala Preview (the latter is Mac only, companion iOS and Android app required) allow you to preview your designs on any device that’s plugged in to your computer, much like many similar tools for iOS.
Two Toasters recommends InVision for prototyping

Design for Multiple Resolutions

XHDPI, HDPI & MDPI represent 88% or more of users covered
use fluid layouts to ensure your app looks good on most devices
use fewer patterns & textures. Avoid full screen patterns and textures, using only tile-able images for backgrounds and so on.
use 9-patch images (stretchable assets)
landscape layouts are both necessary and expected, especially on hardware with slide-out keyboards

Tablets

use compound layouts for larger screen sizes
for smaller tablet screens, scale up HDPI and XHDPI assets
planning for landscape mode goes a long way toward helping your app look great on tablets
if an app is specific to tablets, target its design to this size

9-patch Images

let you compress an asset to scale without on-screen artifacts
reduce asset to smallest possible size
use Android’s Draw 9-patch utility: draw outlines outside of an asset’s borders to indicate areas to stretch (top & left) and for content padding (right & bottom)
in many cases assets with simple linear gradients are good candidates for 9-patching, assets with patterns or textures are not

Conclusion

An idiomatic, native approach to designing Android apps is important because it simplifies interactions.

Q & A

After the talk, Adit took questions from attendees.

Strategies for Multiple Platform Apps?. If an app will exist on iOS, Android, and so on, it’s best to pick a lead platform but don’t equate controls between platforms. An app’s design should be native to each platform it’s found on.
App Design: All At Once or A La Carte?. Designing an entire app all at once makes it cheaper to develop than designing an app in a more piecemeal fashion. A set of basic screens representing an app’s design might seem cheaper to a client, but will be more expensive in the long run since not every edge case and user interaction is present and accounted for.
What about Kindle Fire?. Presently, no additional design work is required for Amazon’s own Android tablet.
Giving Specs to Developers?. Two Toasters employs a technique called redlining (link shows a web design example) for specifying screen layouts for their developers. Xscope is used by both designers and developers to check sizes of UI elements and to keep everything crisp.
Documenting User Flow?. Two Toasters also uses InVision for documenting user flows through an app in addition to its prototyping abilities. User flows get printed out big and put up on the wall for the duration of a project.
Specifying Animations?. Animation is important and adds a nice level of polish to an app. Discuss animation possibilities with your developers to find out both what’s possible and what’s practical.