This article first appeared on Smashing Magazine, June 30, 2011.
For designers, Android is the elephant in the room when it comes to app design. As much as designers would like to think it’s an iOS world where all anyone cares about are iPhones, iPads and the App Store, nobody can ignore the fact Android currently makes up the majority of the smartphone market share and is being used on everything from tablets to e-readers . In short, the Google Android platform is quickly becoming ubiquitous and brands are starting to notice.
But let’s face it, Android’s multiple devices and form factors make it feel like an uphill battle to design for, and its cryptic documentation is hardly a launchpad for designing and producing great apps. Surf the Web for resources on Android design and there’s little there to guide you.
If all this feels discouraging (and maybe the reason you’re not designing apps for Android), you’re not alone. Fortunately, Android is beginning to address the multiple device and screen size issues, and device makers are slowly arriving at standards that will eventually reduce any complexity.
The following article will help designers become familiar with what they need to know to get started with Android and delivering the right assets for development. Topics include:
- Demystifying Android screen densities
- Learning the fundamentals of Android design via design patterns
- Design assets your developer needs
- How to get screen shots
- What Android 3 is about and what’s next on the horizon
Android Smartphones and Display Sizes
When starting any digital design project, it’s a good idea to have an understanding of the hardware first. For iPhone apps, it’s either the iPhone or iPod Touch. For Android, it spans dozens of devices and makers. So, where to begin?
The old baseline for Android smartphone devices was the T-Mobile G1, the first commercially available Android-powered device which has an HVGA screen measuring 320 x 480 pixels.
HVGA stands for Half-size Video Graphics Array and is the display size for many of today’s smartphones (the iPhone 3GS, 3G and 2G use this configuration).
To make things simple, Android divides physical screen sizes (measured as the screen’s diagonal from top left corner to bottom right corner) into four general sizes: small, normal, large, and xlarge.
320 x 480 is considered a normal screen size by Android and for xlarge, think tablets . However, the most popular Android smartphones out today have WVGA (Wide VGA) 800+ x 480 displays. So, what’s “normal” has changed. For now, we’ll say that most Android smartphones have large screens.
The variety of display sizes can be challenging for designers trying to create one-size-fits-all screen layouts. I’ve found the best approach is to design one set of layouts for 320 x 533 physical pixels and then introduce custom layouts for the other screen sizes.
What You Need to Know About Screen Densities
But screen sizes are only half the picture! Developers don’t refer to a screen’s resolution but instead, its density. Here’s how Android defines the terms in its Developers Guide:
The total number of physical pixels on a screen.
The quantity of pixels within a physical area of the screen; usually referred to as dpi (dots per inch).
Density-independent pixel (dp)
A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way. The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a “medium” density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application’s UI, to ensure proper display of your UI on screens with different densities.
It’s a bit confusing, but this is what you need to know: Like screen sizes, Android divides screen densities into four basic densities: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high). This is important because you’ll need to deliver all graphical assets (bitmaps) in sets of different densities. At the very least, you’ll need to deliver mdpi and hdpi sets for any smartphone apps.
What this means is all bitmap graphics need to be scaled up or down from your baseline (320 x 533) screen layouts (note: there is also a method for parsing SVG files that provides a way to scale vector art on different screens sizes and densities without loss of image quality).
The bitmap requirement is similar to preparing graphics for print vs. the Web. If you have any experience with print, you know that a 72 ppi image is going to look very pixelated and blurry scaled up and printed. Instead, you need to rescale the image as a vector image or use a hi-resolution photo and then set the file’s resolution at around 300 ppi in order for it to print without any loss of image quality. Screen density for Android works similar except that we’re not changing the file resolution, only the image size (standard 72 ppi is fine).
Let’s say you have a bitmap icon 100 x 100 pixels taken from one of the screens of your baseline app design. Placing that same 100 x 100 icon on a device with an ldpi screen will make the icon appear big and blurry. Likewise, placing it on a device with an hdpi screen will make it appear too small (due to the device having more dots/inch than the mdpi screen).
To adjust for the different device screen densities we need to follow a 3:4:6:8 scaling ratio between the four density sizes (for the iPhone it’s easy–it’s just a 2:1 ratio between iPhone 4 and 3GS). Using our ratios and some simple math, we create four different versions of our bitmap to hand-off to our developer for production:
- 75 x 75 for low-density screens (0.75x)
- 100 x 100 for medium-density screens (our baseline)
- 150 x 150 for high-density screens (1.5x)
- 200 x 200 for extra high-density screens (2.0x)*
*We’re concerned with only ldpi, mdpi and hdpi for Android smartphone apps
After you’ve produced all your graphics, you might choose to organize your graphics library as follows:
Note: There may be some confusion about what ppi (pixels per inch) you set your deliverables at. Just leave them at the standard 72 ppi and scale the image accordingly.
Using Android Design Patterns
Clients often ask whether or not they can use the same iPhone app design for Android. If you’re looking for shortcuts, maybe building an app for mobile web browsers using something like WebKit and HTML5 is a better choice. But for producing native Android apps, the answer is “no”. Why? Because Android UI conventions are different from iPhone.
The big difference with Android when compared to iOS devices is the use of the Back Key to navigate to a previously visited screen. The Back Key on Android devices is always present and available to the user apart from the app. It’s either a part of the physical device or digitally fixed to the bottom of the screen independent of any app (like what we see in the recently released Android 3.0 for tablets — more about this later).
The use of a Back Key other than within the app itself, leaves space for other elements at the top of the screen such as a logo, screen title or menu. While this navigational convention differentiates greatly from iOS, there are also other differentiators that Android calls design patterns. According to Android, a design pattern is a “general solution to a recurring problem”. Here are the main Android design patterns that were introduced with Android version 2.0:
This pattern solves the problem of having to navigate to several layers within an app. It provides a launch pad solution for rich apps like Facebook, LinkedIn and Evernote.
The Action Bar is one of Android’s most important design patterns and differentiators. It works very similar to the conventional Web site’s banner with a logo or screen title linking to a ‘home’ page typically placed on the left and common actions buttons on the right. The Action Bar design is flexible with the ability to include hovering menus and expanding search boxes. It’s generally used as a global feature rather than a contextual one. Here’s an example of the Action Bar used by Twitter:
Allows a simple way to search by category and provide search suggestions.
This design pattern acts similar to the iOS popover providing the user with additional contextual actions. For example, tapping a photo within an app might trigger a Quick Action bar to appear for sharing the photo.
Widgets allow an app to publish notifications to the user’s launch screen. Unlike push notifications with iOS that act as temporary modals, Companion Widgets remain on the launch screen (tip: to select a widget for your Android device, simply tap and hold any empty space on one of the launch screens).
Using established design patterns are important for keeping your user experience intuitive and familiar to your Android users. Your users don’t want to have an iPhone experience on their Android device any more than a Mac user wants to have a Microsoft one within their Mac OS environment. So, understanding the design patterns is the first step toward learning to speak Android and designing an optimal experience for Android users. Your developer will also thank you!
Android design deliverables
OK, so I’ve designed my Android app and am ready to make it a reality. What do I need to hand-off to my developer? Here’s a quick list of deliverables:
1. Annotated wireframes of the user experience based on the baseline large screen size of 320 x 533 physical pixels. Include any additional screens for instances where a larger or smaller (320 x 480) screen size requires a modified layout or a landscape version is required.
2. Visual design mockups of key screens for WVGA large size (320 x 533) screens (based on a WVGA 800 x 480 hdpi physical pixel screen size) in addition to any custom layouts needed for other screen sizes.
3. Specifications for spacing, font sizes , colors and indication of any bitmaps.
4. Graphics library with ldpi, mdpi and hdpi versions of all bitmaps as transparent PNG files.
5. Density-specific app icons including the app launch icon as transparent PNG files. Android already provides excellent tips for designers on this topic along with some downloads including graphic PSD templates and other goodies.
How to Take Screen Shots
My product manager just asked for screen shots of the developer’s build. The dev is busy and can’t get them to me until tomorrow. Now what do I do? As of publication of this article, Android has no built-in way to take screen shots (bummer, I know). The only way is to just deal with it and that means pretending to be a developer for a while and downloading some really scary software. Let’s get started!
The following software must be downloaded:
1. All USB drivers for your Android device
Next, on your computer:
1. Extract the USB drivers to a folder on your desktop
2. Extract the Android SDK to a folder on your desktop
3. Install the Java SE SDK
On your Android device:
1. Open Settings (you’ll find it in the apps menu)
2. Tap on Applications
3. Tap on Development
4. Check the box for USB debugging
Now, for the fun part:
1. Connect your Android device to your computer via USB. Windows users: allow Windows to install all drivers. One of the drivers may not be found and will require you to go to the Window’s Device Manager under the Control Panel. There, you can locate the device (having a yellow warning icon next to it) and right-click on it.
2. If necessary, choose to update/install the driver for your device
3. Go to your desktop, open the Android SDK folder and select SDK Setup.exe
4. Allow it to automatically refresh its list of operating system SDKs available and select to install all packages
5. Once finished, exit the application
6. Go back to the opened Android SDK folder on your desktop and open the tools folder
7. Click on the file, ddms to open the Dalvik Debug Monitor
8. Select your device listed in the Name pane
9. In the application’s top menu, open the Device menu and choose Screen capture…. A Device Screen Capture window will open and you should see the launch screen of your Android device.
1. Grab your Android device and navigate to a screen of your liking. Go back to your computer and select Refresh in the Device Screen Capture window and the current screen from your Android device will appear.
2. If you’re on a Mac, you can just do the old shift-command-4 trick to take a screen grab or you can choose to copy it in Windows and paste it into one of the Windows media applications.
About Android Tablets
At CES 2011, companies launched a downpour of Android tablets with an array of screen sizes. However, after a quick review of the most popular Android tablets we can conclude that the most important screen size to focus on in physical pixels is 1280 x 800.
With the Android 3.0 “Honeycomb” release, Google provided device makers with an Android UI made for tablets. Gone is the use of a hard Back Key which was replaced by an anchored software-generated navigation and system status bar at the bottom of the screen.
Android 3.0 received an updated visual design and incorporates all the design patterns introduced with Android 2.0. One of the major differences with 3.0 is the Action Bar which has been updated to include tabs, drop-down menus or breadcrumbs. The Action Bar can also change its appearance to show contextual actions when selecting single or multiple elements on a screen.
Another new feature added to the Android framework with 3.0 is a mechanism called Fragments. A Fragment is a self-containing component within a layout that can change size or layout position depending on the screen orientation or size. This further addresses the problem of designing for multiple form factors by providing designers and developers a way to make their screen layout components elastic and stackable depending on what screen restraints the app is working with. Screen components can be stretched, stacked, expanded/collapsed and shown/hidden.
The next Android release scrumptiously dubbed “Ice Cream Sandwich” promises to bring this functionality to Android smartphones as well, giving designers and developers the option of building an app using a one-size-fits-all strategy. This could be a paradigm shift for designers and developers who will need to learn to think of app design in terms of puzzle pieces that can be either stretched, stacked, expanded or hidden to fit the appropriate form factor. In short, this will allow one Android OS to run anywhere (with infinite possibilities!).
A Word of Advice
Do get your hands on an Android phone and tablet and spend some time downloading apps and exploring their interfaces. In order to design for Android you have to immerse yourself in the environment and know it intimately. This seems obvious, but it’s always surprising to learn even the product manager doesn’t have an Android device.
Here are some links to online resources I found especially useful:
Comparison of Android Devices