I’ve spent the last 12 months working on an native app for both iOS and Android. But I’m embarrassed to say that except for reviewing builds on a test phone I’ve never really used an Android device before.
The Android build is in good shape thanks to talented designers and developers, but it makes me sad to see one platform get a lot of love while another is mostly designed as an afterthought.
So following @zacsnider, I made the switch to Android last week so that I can become a more well-rounded designer and make better design decisions for Android.
Here are my observations of Android after one week…
The first big difference between Apple and Android is the sheer variety of options. Searching on Amazon there are literally thousands of results for “unlocked android phone”.
And unlike buying an iPhone with Apples tight control of hardware and software, when you buy an Android phone your end experience may differ dramatically depending on which manufacturer built the hardware, and which carrier you buy the phone with since they may both add their own enhancements to the device, either directly to the operating system, or by including adding stock apps which can not be deleted.
To avoid this, I ordered an unlocked Moto G GPE directly from Google meaning that the phone ships with ’stock Android’ (with no extra apps or additions to the OS) and promises quick updates to future versions of Android1 including the promise that the Moto G will receive an update to Android L2.
I was a little surprised that despite purchasing directly from Google that I still needed to sign in with a Google account. In retrospect I’m actually happy that it didn’t make that assumption for me, and since I’m treating this as a bit of an experiment I decided to create a brand new account just for this phone.
Unlike Apple where people are expected to have a single Apple ID, Google are pretty flexible and allow you to have many accounts one one device. For instance I connected hangouts to both my primary gmail account and the new account I created for the device, but kept just the new account to sync other data like my photos and map locations.
There are two huge differences between Android and iOS.
The first is that as well as downloading apps that you can add and launch from your home screen, you can also add widgets to both your home screen and your lock screen. Often people choose to add an analog clock, but app publishers can create a bunch of mini apps that run directly embedded within the home screen.
The second is that you have the choice to choose what app to use by default for a bunch of set intents. For example you can set the default app that’s used to make a call, take a photo, view images, set as the default browser, and the keyboard to use for any text input3.
The most significant app to change is the ‘launcher’ which is the UI that you use to pick apps from your home screen.
I replaced the stock launcher with Google’s Google Now Launcher which allows a single swipe left to open up the Google Now app.
In iOS any app that you have installed on your phone can be located either directly on one of your home screen pages, or within a folder.
Android takes a different approach where all installed apps & widgets appear in an alphabetical index that’s launched from the home screen.
Lock screens and notification list
Home screen, app index, and recently used apps
You can then choose which apps and widgets you want to include for quick access by pinning them to your home screen. As an extreme you can even choose to have no apps or widgets at all pinned to your home screen.
I choose a middle ground where some favorite apps were added to my home screen, and at least for now I’m really happy with the simplicity of this approach.
Android allows app creators to choose any icon shape they want for their app or widget. A monochrome mini version of that icon is then also used in the status bar as part of Androids’ notification model.
It’s an interesting idea and a distinction from Apple, Windows and Firefox who all have either requirements or guidelines for icon shapes. I like the visual variety it allows but at the same time the designer in me wishes that there were some more specific guidelines around how shapes are used4.
In addition app icons in Android can’t show a badge (the red bubble in iOS with some number). I don’t know if this was an intentional design decision, or an artifact of variable icon shapes but the end outcome is a much cleaner launch screen, and I like it a lot.
I started this experiment with an expectation of finding a lot of poorly designed apps, and while I did find some disappointing examples, nearly every app that I use on iOS has a well designed Android equivalent5.
Tumblr lacks some design details compared to the iOS app, but still looks great and even feels more stable than iOS.
Threes already had a platform-agnostic design and feels just as happy on my Android as it does on my iPhone.
Then there are some apps that are in many ways superior. OKCupid for Android looks like someone took a keen editing eye and parred it down to a much cleaner and faster experience.
Threes!, Tumblr, Monument Valley, and Etsy
Another area I was impressed was the Google Play store. Instead of having a desktop app like iTunes as the preferred way to manage apps Google stuck with a well designed website, and it works!
The search feels more robust and creating or updating a review is fast and easy on both device and web.
It’s interesting to compare the number of reviews from Monument Valley on Google Play store and iTunes App Store. Although Monument Valley had a big head start on iOS, iTunes has 6,580 reviews compared to 29,718 reviews on Google Play.
Another important difference for Android is that app permissions are granted in the app store before the app even starts to download.
The level of granularity for permissions is also a lot higher in Android compared to iOS and there isn’t a way to opt-out if for instance you’d prefer the app not to have access to your location.
I’ve got mixed feelings about this approach and still trying to decide which model I like better.
My biggest surprise and letdown is that headphones are not well supported on Android devices.
Apple has some patents on how signals are sent from a three-button headphone remote which Android device manufacturers don’t seem to have found an agreement on and it does’t seem to be a priority for Google to enforce.
I’ve not noticed it in many non-Google apps, but it’s nice to see apps use a subtle toast at the bottom of the screen to confirm actions, and in some cases provide an option to undo the action. I’ve already found this useful when accidentally closing too many tabs in Chrome at once, and would love to see more apps support this.
I’m not going to go deep into specifics since with the upcoming launch of Android L, Google are pushing for an updated design language they’re calling Material Design but here are some tips that should still apply in Android L.
In iOS there are concepts of navigation bar, tab bar and toolbars. All of these concepts are bundled in Android into a multipurpose Action Bar.
It’s possible to position an action bar at the bottom of the screen, but it would interfere with Androids built in soft buttons I’ve not seen it occur much in practice.
Buttons within the action bar are called Action Buttons, and action buttons that don’t fit within the space are pushed into the action overflow button which is shown as three dots stacked on top of each other6 .
In apps like Gmail I think it’s particularly interesting to see nesting of the action overflow button.
With the virtual buttons at the bottom of the screen it’s more common to see tab-based navigation app with the tabs at the top of the screen.
Tabs come in two versions: Fixed and scrolling. Fixed work as you’d expect, and scrolling allows you to swipe horizontally across the screen to switch between tabs.
Sometimes an app will so many sections in a scrolling tab that they’re not all visible at the same time. But I found this approach very disorienting and wouldn’t recommend it unless there were no other alternatives.
Unfortunately, I’ve not noticed any convention set to visually distinguish fixed tabs from scrolling tabs so people simply have to swipe to see if its enabled.
In Android, an inline drop down menu is called a spinner. These objects have a little triangle on the bottom right to indicate that a selection from multiple options can be made.
These aren’t my favorite choice for a primary navigation since they’re slower to use and you need to tap to view possible options so they’re best for when you think people won’t need to make the selection very often and it’s not important to show the options by default for example switching inboxes to different email accounts.
In general, I don’t like hidden navigation, and so in general I don’t navigation drawers because I think they are an easy way to make last decisions about what’s important enough to be top-level navigation.
However, Android offers a navigation drawer as part of their SDK, which when implemented at least offers consistent behavior between different apps.
When choosing a navigation model my favorite are in order of tabs, then navigation drawer, then spinner. But it all depends on the size and content of your app. The most important thing to remember is to stick with one main way to navigate and not mix and match all three together.
When drilling down into content Android asks us not to show a caret (or disclosure indicator in iOS terminology). Instead it’s assumed that doesn’t is tappable unless it’s ether obviously content, or if there is an actionable object (like a switch or checkbox) on the option.
When you navigate within the app you’re building up a history of screens visited. Tapping the virtual back button at the bottom of the screen allows you navigate back into that chain of screens.
In the action bar there is also an up button which is normally presented with a back symbol and the app icon. This action represents moving to the next screen ‘up’ in whatever the hierarchy the app uses for it’s navigation model.
Most of the time as you navigate apps you’re drilling down into some navigation hierarchy anyway so the virtual ‘back’ and the action bar ‘up’ have the same consequence although consider this flow of some app like Twitter:
A) Start on Latest tweets, tap on a retweet from the BBC B) View the BBC tweet and it’s replies
On screen (B) tapping the system back will take you to (A), but tapping on the action bar up button should technically take you to (C) the profile screen for the BBC account.
This is a smart idea, but at the same time I think it’s too complex and will only potentially cause confusion. Google describe it more in their navigation design guidelines but I’ve not noticed it implemented in many apps.
Unlike Apple where an iOS update is available to anyone at the same time, Android updates will roll out to devices on different timelines that rely on the carrier or manufacturer so that they can test their devices (and presumably add in their enhancements). ↩
Although the Moto G GPE is only $199, I really love this handset since it references back to the phone I had when the original iPhone first launched: the Moto PEBL. Not a side effect of Android, but because Motorola wanted to keep manufacturing costs low, it seems that Motorola choose to build a multiple versions of the handset with different radios (e.g. one for US, one for Worldwide). The Google Play Edition in particular ships with a cellular radio that doesn’t play nice with T-mobiles legacy 3G network so I ended up returning the GPE and buying the Moto G LTE. ↩
Interestingly, this is the direction that Apple is also moving towards with iOS 8. ↩
For example my online banking app, chrome and hangouts are all based off a circle for no particular reason other than branding. ↩
The only exception being Dark Sky, which sadly has no future plans to create an Android version. ↩