By the numbers Android and iOS are the two leading mobile platforms, together accounting for nearly 98% of mobile traffic on UW web services. With the successful launch of SpaceScout for iOS we felt it was time to start looking into designing for the Android platform.
I wanted to avoid the common pitfall of designing from a previously existing iOS app and simply porting the iOS experience to the Android platform, such as the epicurious app shown above. While Android and iOS share many of the same basic UI elements, gestural controls, and navigation patterns there are differences that must be considered. Most Android users will notice when an app isn’t designed specifically for Android, usually due to the presence of styles and interactions borrowed from other platforms. Based on an analysis and comparison of the Android Design Guide and the iOS Human Interface Guide here is a list of the main differences and unique elements of Android. Hopefully by the end of this post you should be able to spot the errors in the epicurious design.
iOS users are familiar with seeing a distinct back button on the upper left of the navigation bar. It appears when users proceed past the first level hierarchy of the app and serves as a way to get back to the main or previous view. It normally appears as a standard rectangular button, with the left edge shaped into an arrow pointing left.
Android devices have two built in methods for accomplishing this sort of navigation: the “Up” button and the system “back” button. The Up button appears in the upper left of the main action bar where the app icon is located. When a user navigates out of the main view of an app, the Up button appears allowing them to easily go back one level in the app.
The Back button, a system button persistent on all screens, accomplishes a similar but slightly different navigation. The Back button is used to navigate through the history of screens the user has recently navigated through, even outside of the current app. So it may at times take the user to the same screen as the Up button, but is not limited to the app hierarchy. This can be confusing and is explained in great detail in the navigation section of the Android guidelines. This image from the guide illustrates the basic idea:
A spinner is an Android UI element designed to allow an item to be selected from a set. Spinners are a versatile and can be used in many different situations.
One common usage is for data selection in forms, allowing the user to select a single item from a list. This is typically used to label data, such as setting a new contact to either “Home” or “Work” in the standard contacts app. This functionality is closely related to the iOS picker.
Spinners can also allow for action selection from a list. This resembles the iOS action sheet method for selecting an action. A good example of this can be seen in “reply” selection in gmail.
Yet another usage for Spinners is to switch views on a set of data. A spinner being used for this purpose is in the calendar app where a spinner allows for easy switching between day, week, and monthly views. This behavior of spinners is more closely related to segmented control element on iOS.
Tabs in Android are quite similar to the iOS counterpart with the notable difference being placement. It is recommended that they appear at the top of the screen as part of the top bar, rather than the bottom as in iOS. This is mainly to avoid tap conflicts with the system buttons.
A second unique quality of Android tabs is the ability to use scrollable tabs. This modified version of the standard tab bar enables for 4 or more tabs to be comfortably used in an app. iOS guidelines recommend up to 5 tabs, or when 5+ are required 4 plus a “more” tab to see the remaining options. An example of scrollable tabs in action can be seen in the Play store app.
A final area where Android has a significant divergence from iOS is with screen size and resolution. Due to the Android’s open nature, many mobile phone manufacturers have adopted Android as their OS of choice. Android device manufacturers put out dozens of phones to target different needs and niches, resulting in a huge fragmentation of device capability and specifications. There is no standard Android screen size or resolution. The fragmentation of screen size and resolution is discussed in detail in this blog post from Open Signal last year. This is quite different from iOS devices, which are heavily standardized and therefore easy to predict the users screen size and resolution.
This means that extra consideration is needed when laying out app views. You must ensure app layouts are both fluid and flexible enough to work on different devices ranging from 3” screens of older dives to 5”+ inch HD displays of newer devices like the Note II.
Designing for Android is of course no different than designing for any other platform. It has its own unique qualities and quirks, but with a solid understanding of the unique elements and interaction guidelines you can begin to create great experiences. There are always exceptions to the rules, even those listed above, but generally the one guideline to follow is to avoid mimicking other platforms. This is an easy mistake to make, especially when designing with an iOS app already released and in use. Android apps have the potential to provide as great of an experience as any other platform and the key to this is fully utilizing the unique qualities Android has to offer.
If you need further Android inspiration in either UX or visual design here are some great resources:
- Android Niceties – A collection of screenshots encompassing some of the most beautiful looking Android apps.
- Android UX – A collection of Android UX examples grouped by task/interaction.
- Android App Patterns – Categorized Android interaction patterns