BlogmyQuery – BMQ

More than ever, designers are being asked to create experiences for a variety of mobile devices. As tablet adoption increases and we move into the post-PC world, companies will compete for users’ attention with the quality of their experience. Designing successful apps for Android tablets requires not only a great concept that will encourage downloads, usage and retention, but also an experience that Android users will find intuitive and native to the environment.

The following will help designers become familiar with Android tablet app design by understanding the differences between the iPad iOS user interface and Android 3.x “Honeycomb� UI conventions and elements. We will also look at Honeycomb design patterns and layout strategies, and then review some of the best Android tablet apps out there.

Note that while Android 2.x apps for smartphones can run on tablets, Android 3.0 Honeycomb was designed and launched specifically for tablets. Future updates promise to bring Honeycomb features to smartphone devices, as well as make it easier to design and build for multiple screen types.

For most of us, our first exposure to tablets was via the iPad. For this reason, it’s reasonable to begin comparing the two user interfaces. By comparing, we can align what we’ve learned about tablets and begin to focus on the key differences between the two, so that we can meet the unique UI needs of Android users. Not only will this help us get up to speed, but it becomes especially important when designing an Android tablet app from an existing iPad one.

It’s Just Like The iPad, Right?

While the Android tablet and iPad experience share many similarities (touch gestures, app launch icons, modals, etc.), designers should be aware of the many differences before making assumptions and drawing up screens.

Screen Size and Orientation

The biggest difference between the two platforms is the form factor. Layouts for the iPad are measured at 768 × 1024 physical pixels, and the iPad uses portrait mode as its default viewing orientation.

With Android tablets, it’s a bit more complicated, due to the multiple device makers. In general, there are 7- and 10-inch Android tablets screen sizes (measured diagonally from the top-left corner to the bottom-right), with sizes in between. However, most tablets are around 10 inches.

What does this mean in pixels? A good baseline for your layouts is 1280 × 752 pixels (excluding the system bar), based on a 10-inch screen size and using landscape (not portrait) as the default orientation. Like on the iPad, content on Android tablets can be viewed in both landscape or portrait view, but landscape mode is usually preferred.

The portrait view on a typical 10-inch Android tablet (left) and on the iPad (right).

The landscape view on a typical 10-inch Android tablet (left) and on the iPad (right).

However, with Android, screen size is only the half of it. Android tablets also come in different “screen densitiesâ€� — that is, the number of pixels within a given area of the screen. Without going into too much detail, designers have to prepare all production-ready bitmaps for three different screen densities, by scaling each bitmap to 1.5×and 2× its original size. So, a bitmap set to 100 × 100 pixels would also have copies at 150 × 150 and 200 × 200. By making three batches of graphics scaled at these sizes, you will be able to deliver your bitmaps to medium, high and extra-high density tablet screens without losing image quality.

For more information on screen densities and preparing graphics for Android devices, refer to my previous article on designing for Android.

System Bar

While iOS makes minimal use of the system bar, Android Honeycomb expands its size to include notifications and soft navigation buttons. There is a “Back� button, a home button and a “Recent apps� button.

The Android Honeycomb system bar.

Android Honeycomb’s system bar and buttons are always present and appear at the bottom of the screen regardless of which app is open. Think of it like a permanent UI fixture. The only exception is a “Lights out� mode, which dims the system bar to show immersive content, such as video and games.

“Back� Button

While the bulkiness and permanence of the Honeycomb system bar might seem an obstacle to designers, it does free up the real estate that is typically taken by the “Back� button in iPad apps. The “Back� button in Honeycomb’s system bar works globally across all apps.

The “Back� button in the system bar.

Action Bar

The bulk of the UI differences between platforms is found in the top action bar. Android suggests a specific arrangement of elements and a specific visual format for the action bar, including the placement of the icon or logo, the navigation (e.g. drop-down menu or tabs) and common actions. This is one of the most unifying design patterns across Android Honeycomb apps, and familiarizing yourself with it before attempting customizations or something iPad-like would be worthwhile. More on the pervasive action bar later.

The action bar.

Widgets

New to iPad users will be Android’s widgets. As the name implies, these are small notification and shortcuts tools that users can set to appear on their launch screen. Widgets can be designed to show stack views, grid views and list views, and with Android 3.1, they are now resizable.

Several widgets on a launch screen.

Notifications

While iOS’ notifications system pushes simple alerts to your launch screen, Honeycomb offers rich notifications that pop up (“toast� we used to call them) in the bottom-right area of the screen, much like Growl on Mac OS X. Custom layouts for notifications can be anything from icons to ticker text to actionable buttons.

A notification on Android.

Settings

Access to settings in an iPad app are usually presented in a pop-over, triggered by an “i� button; and settings categories are broken up into tables for easy visual identification. Honeycomb has a different convention. It looks more like the iOS’ “General Settings� screen, where the user navigates categories on the left and views details on the right. This is the preferred (and more elegant) way to present multiple settings in Honeycomb.

The settings design pattern in the Calendar app.

UI Elements

As you can imagine, Android goes to great lengths to do everything opposite from its competitor (that’s called differentiation!). Honeycomb has its own UI conventions, and it now has a new “holographic UI� visual language for such routine actions as picking a time and date, selecting an option, setting the volume, etc. Understanding this UI language is important to building screen flows and creating layouts.

A sampling of UI elements, taken from a slide in a Google I/O 2011 presentation.

Fonts

How many fonts does iPad 4.3 make available? The answer is fifty-seven.

How many does Android? Just three.

Yep, those three are Droid Sans, Droid Serif and Droid Sans Mono. But there is an upside. While only these three ship with the platform, developers are free to bundle any other fonts with their apps.

Anything the Same?

Luckily for designers who are already familiar with the iPad, the two platforms have some similarities.

Touch Gestures

Tap, double-tap, flick, drag, pinch, rotate and scroll at will.

Split View and Multi-Pane UI

The split view is one of the most common layouts for tablets. It consists of two side-by-side panes. Of course, you can add panes for more complex layouts.

Ustream’s split-view layout, with categories on the left and content on the right.

Embedded Multimedia

Both platforms allow embedded audio, video and maps.

The YouTube app, with an embedded video player.

Clipboard

For copying and pasting data into and out of applications.

Drag and Drop

Both platforms have drag-and-drop capabilities.

The drag-and-drop feature in the Gmail app.

Design Patterns

Honeycomb continues many of the design patterns introduced in Android 2.0 and expands on them. In case you’re not familiar with design patterns, they are, as defined in Android, a “general solution to a recurring problem.� Design patterns are key UI conventions designed by Android’s maintainers to help unify the user experience and to give designers and developers a template to work from. They are also customizable, so no need to fret!

As mentioned, the action bar is the most prominent Android UI component and is the one we’ll focus on here.

The action bar highlighted in the Calendar app.

Icon or Logo

The action bar starts with an icon or logo on the far left. It is actionable; by tapping on it, the user is directed to the app’s home screen.

The Calendar app icon.

Navigation

Next, we’ll typically find some form of navigation, in the form of a drop-down or tab menu. Honeycomb uses a triangle graphic to indicate a drop-down menu and a series of underlines for tabs, which typically take up most of the action bar’s real estate.

A left arrow button might also appear to the left of the icon or logo or the label, for navigating back or cancelling a primary action.

Three different kinds of action bar navigation.

Common Actions

Common actions, as the name implies, gives user such things as search, share and an overflow menu. They are always positioned to the right of the action bar, away from any tabs.

Common actions in the Calendar app.

Overflow Menu

The overflow menu is part of the common actions group and is sometimes separated by a vertical rule. It is a place for miscellaneous menu items, such settings, help and feedback.

An overflow menu.

Search

Search is also a part of the common actions group. Unique to search is its expand and collapse action. Tap on the search icon and a search box expands out, letting you enter a query. Tap the “x� to cancel, and it collapses to its single-button state. This is a space saver when many actions or tabs need to be shown.

The search function collapsed (top) and expanded (bottom). Tapping the magnifying glass opens the search box, while tapping the “x� closes it.

Contextual Actions

Contextual actions change the format of the action bar when an item is selected, revealing options unique to that item. For example, if a photo app is displaying thumbnails, the action bar might change once an image is selected, providing contextual actions for editing that particular image.

To exit the contextual action bar, users can tap either “Cancel� or “Done� at the far right of the bar.

The contextual action bar is triggered when tapping and holding an email in the Gmail app.

Tablet Layout Strategies

Using Fragments and Multi-Pane Views

The building blocks of Honeycomb design are “Fragments.� A Fragment is a self-contained layout component that can change size or layout position depending on the screen’s orientation and size. This further addresses the problem of designing for multiple form factors by giving designers and developers a way to make their screen layout components elastic and stackable, depending on the screen restraints of the device that is running the app. Screen components can be stretched, stacked, expanded or collapsed and shown or hidden.

The Fragments framework gives designers and developers several options for maintaining their layouts across screen sizes and orientation modes.

What makes Fragments so special? With a compatibility library, developers can bring this functionality to Android smartphones going back to version 1.6, allowing them to build apps using a one-size-fits-all strategy. In short, it enables designers and developers to build one app for everything.

While Fragments may be a term used more by developers, designers should still have a basic understanding of how capsules of content can be stretched, stacked, expanded and hidden at will.

The most common arrangement of Fragments is the split view. This layout is common in news apps and email clients, where a list is presented in a narrow column and a detailed view in a wider one.

The split view used by USA Today

Another way to present a split view is to turn it on its side. In this case, the sideways list Fragment becomes a carousel, navigating horizontally instead of vertically.

Orientation Strategies

While Fragments are great for applying one design to multiple screen sizes, they are also useful for setting orientation strategies. Your screen design might look great in landscape view, but what will you do with three columns in a narrow portrait view? Again, you have the option to stretch, stack or hide content. Think of Fragments like a bunch of stretchy puzzle pieces that you can move around, shape and eliminate as needed.

A Word About Animation

The Honeycomb framework allows designers and developers to use a variety of animation effects. According to the Android 3.0 Highlights page, “Animations can create fades or movement between states, loop an animated image or an existing animation, change colors, and much more.� Honeycomb also boasts high-performance mechanisms for presenting 2-D and 3-D graphics. For a good overview of what Honeycomb is capable of, check out this video.

Learning from Example

Android tablet apps are still a relatively new space, and some brands are only beginning to test the waters. Below is a list of apps for inspiration. You can download any of them from the Android Market or Amazon.

YouTube
Naturally, Google’s YouTube app for Honeycomb is exemplary, showcasing all of the design patterns and UI elements discussed above. To get a good feel for Honeycomb, download this app first and take it for a spin.

CNN
The CNN app makes good use of touch gestures (including flicking to view more content), the split view and fonts! A custom font (Rockwell) is used for news headlines.

CNBC
Another good news app, with animation (the stock ticker tape) and rich graphics and gradients. CNBC has one of the most visually compelling apps.

Plume
With its three-column layout, Plume is a good example of how layouts might need to be changed dramatically from landscape to portrait views.

FlightTrack
A data-heavy app done elegantly. Includes nice maps, subtle animation and standard Honeycomb UI elements.

Pulse
What else can you say: it’s Pulse for Android tablets! But comparing the Android and iPad versions, which are identical in almost every way, is still fun anyway.

WeatherBug
This was one of the first Honeycomb apps in the Android Market. It makes good use of maps and of the holographic UI for showing pictures from weather cams.

Kindle
Kindle pretty much sticks to the book in using design patterns and Honeycomb UI elements. The outcome is elegant, while staying true to Android’s best practices.

Honorable Mentions

• IMDb
• News360
• USA Today
• AccuWeather
• Ustream
• Google Earth
• Think Space

Online Resources

Video

• Designing and Implementing Android UIs for Phones and Tablets, Google I/O 2011
• Android 3.0 Honeycomb animation demo

Presentations

• Designing and Implementing Android UIs for Phones and Tablets, Google I/O 2011 (PDF)

Blogs

• Tablet UI Patterns

Android Developers

• Supporting Multiple Screens
• Icon Design
• Android 3.0 Platform Highlights

(al)

© Dan McKenzie for Smashing Magazine, 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 in which all anyones cares about are iPhones, iPads and the App Store, nobody can ignore that Android currently has the majority of smartphone market share and that it 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 designing for it is an uphill battle. And its cryptic documentation is hardly a starting point for designing and producing great apps. Surf the Web for resources on Android design and you’ll find little there to guide you.

If all this feels discouraging (and if it’s the reason you’re not designing apps for Android), you’re not alone. Fortunately, Android is beginning to address the issues with multiple devices and screen sizes, and device makers are slowly arriving at standards that will eventually reduce complexity.

This article will help designers become familiar with what they need to know to get started with Android and to deliver the right assets to the development team. The topics we’ll cover are:

• Demystifying Android screen densities,
• Learning the fundamentals of Android design via design patterns,
• Design assets your developer needs,
• How to get screenshots,
• What Android 3 is about, and what’s on the horizon.

Android Smartphones And Display Sizes

When starting any digital design project, understanding the hardware first is a good idea. For iOS apps, that would be the iPhone and iPod Touch. Android, meanwhile, spans dozens of devices and makers. Where to begin?

The old baseline for screens supported 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� (or half-size VGA) and is the standard display size for today’s smartphones. The iPhone 3GS, 3G and 2G use the same configuration.

T-Mobile G1, the first commercially available Android device and the baseline for Android screen specifications.

To keep things simple, Android breaks down physical screen sizes (measured as the screen’s diagonal length from the top-left corner to bottom-right corner) into four general sizes: small, normal, large and xlarge.

Two common Android screen sizes. (Image from Google I/O 2010)

320 × 480 is considered a “normalâ€� screen size by Android. As for “xlarge,â€� think tablets. However, the most popular Android smartphones today have WVGA (i.e. wide VGA) 800+ × 480-pixel HD displays. So, what’s “normalâ€� is quickly changing. For now, we’ll say that most Android smartphones have large screens.

Diagram of various screen configurations available from emulator skins in the Android SDK. (Image: Android Developers website)

The variety of display sizes can be challenging for designers who are trying to create one-size-fits-all 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.

While this creates more work for both the designer and developer, the larger physical screen size on bigger devices such as the Motorola Droid and HTC Evo might require changes to the baseline layouts that make better use of the extra real estate.

What You Need to Know About Screen Densities

Screen sizes are only half the picture! Developers don’t refer to a screen’s resolution, but rather its density. Here’s how Android defines the terms in its Developers Guide:

• Resolution
  The total number of physical pixels on a screen.
• Screen density
  The quantity of pixels within a physical area of the screen, usually referred to as DPI (dots per inch).
• Density-independent pixel (DP)
  This is a virtual pixel unit that you would use when defining a layout’s UI in order to express the layout’s 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 of 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: pixels = DP * (DPI / 160). For example, on a 240 DPI screen, 1 DP equals 1.5 physical pixels. Always use DP units when defining your application’s UI to ensure that the UI displays properly 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 way 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 production, you’ll know that a 72 PPI image will look very pixelated and blurry when scaled up and printed. Instead, you would need to redo the image as a vector image or use a high-resolution photo and then set the file’s resolution at around 300 PPI in order to print it without any loss of image quality. Screen density for Android works similar, except that we’re not changing the file’s resolution, only the image’s size (i.e. standard 72 PPI is fine).

Let’s say you took a bitmap icon measuring 100 × 100 pixels from one of the screens of your baseline designs (remember the “baseline� is a layout set at 320 × 480). Placing this same 100 × 100 icon on a device with an lDPI screen would make the icon appear big and blurry. Likewise, placing it on a device with an hDPI screen would make it appear too small (due to the device having more dots per inch than the mDPI screen).

An application without density support. (Image: Android Developers website)

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 the iPhone 4 and 3GS.) Using our ratios and some simple math, we can create four different versions of our bitmap to hand off to our developer for production:

• 75 × 75 for low-density screens (i.e. ×0.75);
• 100 × 100 for medium-density screens (our baseline);
• 150 × 150 for high-density screens (×1.5);
• 200 × 200 for extra high-density screens (×2.0). (We’re concerned with only lDPI, mDPI and hDPI for Android smartphone apps.)

The final graphic assets would appear like this using the four different screen densities.

After you’ve produced all of your graphics, you could organize your graphics library as follows:

The suggested organization and labeling of asset folders and files. In preparing our star graphic, all file prefixes could be preceded by the name ic_star, without changing the names of the respective densities.

You might be confused about what PPI (pixels per inch) to set your deliverables at. Just leave them at the standard 72 PPI, and scale the images accordingly.

Using Android Design Patterns

Clients often ask whether they can use their iPhone app design for Android. If you’re looking for shortcuts, building an app for mobile Web browsers using something like Webkit and HTML5 is perhaps a better choice. But to produce a native Android app, the answer is no. Why? Because Android’s UI conventions are different from iPhone’s.

The big difference is the “Back� key, for navigating to previous pages. The Back key on Android devices is fixed and always available to the user, regardless of the app. It’s either a physical part of the device or digitally fixed to the bottom of the screen, independent of any app, as in the recently released Android 3.0 for tablets (more on this later).

The hard “Back� key on a smartphone running Android 2.0.

The presence of a Back key outside of the app itself leaves space for other elements at the top of the screen, such as a logo, title or menu. While this navigational convention differs greatly from that of iOS, there are still other differentiators that Android calls “design patterns.� According to Android, a design pattern is a “general solution to a recurring problem.� Below are the main Android design patterns that were introduced with version 2.0.

Dashboard

This pattern solves the problem of having to navigate to several layers within an app. It provides a launch pad solution for rich apps such as Facebook, LinkedIn and Evernote.

The dashboard design pattern, as used by Facebook and LinkedIn.

Action Bar

The action bar is one of Android’s most important design patterns and differentiators. It works very similar to a conventional website’s banner, with the logo or title typically on the left and the navigation items on the right. The action bar’s design is flexible and allows for hovering menus and expanding search boxes. It’s generally used as a global feature rather than a contextual one.

The action bar design pattern as used by Twitter.

Search Bar

This gives the user a simple way to search by category, and it provides search suggestions.

The search bar design pattern as used in the Google Search app.

Quick Actions

This design pattern is similar to iOS’ pop-up behavior that gives the user additional contextual actions. For example, tapping a photo in an app might trigger a quick action bar that allows the user to share the photo.

The quick action design pattern as used by Twitter.

Companion Widget

Widgets allow an app to display notifications on the user’s launch screen. Unlike push notifications in iOS, which behave as temporary modal dialogs, 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.)

Companion widgets by Engadget, New York Times and Pandora.

Using established design patterns is important for keeping the experience intuitive and familiar for your users. Users don’t want an iPhone experience on their Android device any more than a Mac user wants a Microsoft experience in their Mac OS environment. Understanding design patterns is the first step to learning to speak Android and designing an optimal experience for its users. Your developers will also thank you!

Android Design Deliverables

OK, so you’ve designed your Android app and are ready to make it a reality. What do you need to hand off to the 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 and colors, and an indication of any bitmaps.
4. A graphics library with lDPI, mDPI and hDPI versions of all bitmaps saved as transparent PNG files.
5. Density-specific app icons, including the app’s 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 Screenshots

Your product manager has just asked for screenshots of the developer’s build. The developer is busy and can’t get them to you until tomorrow. What do you do?! As of this writing, Android has no built-in way to take screenshots (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,
2. Android software development kit (SDK),
3. Java SE SDK

Then, 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. 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 the operating system SDKs that are 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 from 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.

The Dalvik Debut Monitor.

To navigate:

1. Grab your Android device and navigate to any page. Go back to your computer and select “Refresh� in the Device Screen Capture window. The current screen from your Android device should appear.
2. If you’re on a Mac, you can just do the old Shift + Command + 4 trick to take a screenshot. In Windows, you can copy and paste it into one of the Windows media applications.

About Android Tablets

At CES 2011, companies rained down Android tablets, with an array of screen sizes. However, after a quick review of the most popular ones, we can conclude that the two important screen sizes to focus on in terms of physical pixels are 1280 × 800 and 800 × 480.

With the Android 3.0 Honeycomb release, Google provided device makers with an Android UI made for tablets. Gone is the hard “Back� button, replaced by an anchored software-generated navigation and system status bar at the bottom of the screen.

The anchored navigation and system bar in Android 3.0.

Android 3.0 got a visual refresh, while incorporating all of the design patterns introduced in Android 2.0. The only difference is that the action bar has been updated to include tabs, drop-down menus or breadcrumbs. The action bar can also change its appearance to show contextual actions when the user selects single or multiple elements on a screen.

The new action bar with tabs, introduced in Android 3.0.

Another new feature added to the Android framework with 3.0 is a mechanism called “fragments.� A fragment is a self-contained component in a layout that can change size and position depending on the screen’s orientation and size. This further addresses the problem of designing for multiple form factors by giving designers and developers a way to make their screen layout components elastic and stackable, depending on the screen limitations of the app. Screen components can be stretched, stacked, expanded and collapsed, and revealed and hidden.

Diagram showing examples of how fragments can be used.

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 to build 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 stretched, stacked, expanded or hidden to fit the 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 might sound obvious, but it’s always surprising to hear when even the product manager doesn’t have an Android device.

Online Resources

Here are some links to online resources I’ve found especially useful:

Presentations

• Android Design Patterns
• Android User Interface Design Tips

Videos

• Android UI Design Patterns (Google I/O 2010)
• Designing and Implementing Android UIs for Phones and Tablets (Google I/O 2011)

Documents

• Comparison of Android Devices

Blogs

• Designer’s Guide to Supporting Multiple Android Device Screens
• Android UI Design Patterns
• Android Patterns

Product Reviews

• Best Android Phones (CNET, May 2011)
• Best Android Tablets (CNET, May 2011)

Android Developers

• Supporting Multiple Screens
• Icon Design
• Android 3.0 Platform Highlights

Other

• Android App Developers GUI Kits, Icons, Fonts and Tools

(al) (il) (kw)

© Dan McKenzie for Smashing Magazine, 2011.