Archive | December, 2010

What’s wrong with Android UI and what to do about it

7 Dec

After a few months of using Android, I think I can now articulate my displeasure with the UI and what should be done about it. The prescription comes down to this:

  • First, Android needs a different paradigm for navigating between applications and within them, one which doesn’t rely upon a Back button.
  • Second, the Menu button, Search button, and long pressing can and should be removed.

Before getting into the details of how this would work, here’s why the current UI is a problem:

Web-style navigation

Much like the paradigm of the Web is a collection of pages navigated page-to-page, the paradigm of the Android UI is a collection of screens navigated screen-to-screen. On the Web, this style of navigation is necessary because there are simply too many pages to be centrally organized, so the only structure that emerges is the ad hoc graph of links. To compensate, however, most sites impose a structure on their own pages, usually via a navigation banner and side menus. On Android, link-based navigation has been adopted not because of a preponderance of screens (the total number of screens in all apps installed on an Android phone is decidely finite) but because the small screens don’t afford catch-all structuring mechanisms like navigation banners or a Windows-style taskbar. In practice, then, each Android screen offers the user a very limited set of links to navigate to other screens, and so designers must very carefully choose for each screen the few links most helpful to the user.

When this pattern works well, each screen seems to magically anticipate the user’s next immediate need. When the pattern fails, the user puzzles over how to get back to that one screen they know exists but can’t get to directly from their current screen.

Things can get especially confusing when the user is linked from one app to another because this blurs the distinction between apps. Even worse, sometimes a link doesn’t take the user to another app but rather to a screen “borrowed” from another app (a screen used as an embedable widget, effectively), which may mistakenly lead the user to belive they’ve been warped to another app when they haven’t. This distinction between warping to a screen and “borrowing” a screen is way too subtle for most users.

Back button

To help the user cope when they get lost, Android has a hardware Back button which is meant to always take the user back through their history of screens. Confusingly, though, Back has four meanings depending upon context:

  • Go back to what I was just looking at.
  • Go up to the parent screen.
  • Dismiss the popup.
  • Go to the previous URL in this browser window.

Sure the guidelines say Back is always supposed to mean ‘go back’, not ‘go up’, but even stock apps violate this rule.

Even when the Back button works properly to mean ‘back’, it can still be confusing, for people tend to quickly forget what they were just looking at beyond two or three screens before. So there are two ways users actually use the Back button to go ‘back’:

  • the user knows what they’ll get when they hit Back
  • the user suspects what they’re looking for is there somewhere, and they’ll stop hitting Back when they see it

This first scenario probably plays out only when the user is taken to a screen and quickly realizes it’s the wrong screen. The second scenario can be an effective strategy for users, but it’s a very displeasing form of navigation. Imagine working at a workbench where the tools are kept not in their proper spots but in a mystery bag which you must go through one item at a time every time you wish to grab a tool. Sure it helps that the most recently used items are always at the top, but it still gets tiresome quick.

Home button

When users get stuck in a navigation deadend or simply get lost, they can always reorient themselves by escaping to the home screen with the Home button. Unfortunately, this doesn’t always fix the user’s disorientation because many apps don’t take the user back to the same screen every time the app is selected in the home screen, so the user can’t reliably reorient themselves within an app by leaving the application and re-entering.

Search button

The hardware Search button is meant to provide quick access to a common task, but it often goes untouched because it’s redundant (most apps provide a search button on screen) and unreliable (the user can’t always know what they’ll get when they press it). Sure, the Search button always takes the user to search, but search of what? Depending upon the current screen, it might take you to a search of the web, or it might take you to a context-specific search of your mail. (Even worse, in some dialogs, Search actually doubles as a Back button to back out of dialogs.)

I’m also skeptical that search is such a pressing use case for most users to deserve its own hardware button. It seems like the hardware Search button was included just as a sop to Google’s self-identify.

Menu button and context clicking

The core design challenge with the touchscreen phone form factor is the lack of screen space. Even when the screen is very high-res like on most recent Android devices, the text and buttons can only get so small before they are too small to read or click.

To mitigate this problem, Android punts many buttons into popups that only appear when the user presses the hardware Menu button or when the user “context clicks” with a long press. The primary problem here is that hiding functionality in hidden menus and popups makes many functions less discoverable and harder to recall where to find. These troubles are amplified by the bothersome way in which these menus and popups are activated and dismissed:

  • the Menu button is difficult to push with one hand (especially on the Droid X)
  • context clicking requires waiting nearly a full second
  • dismissing the menu requires clicking somewhere off the menu or by hitting the Menu button or Back button
  • dismissing most context popups requires hitting the Back button (which, again, is especially tricky on the Droid X with one hand)

The hope is that users will learn to look in the menu and try context-clicking things, but even when users do learn, the slowness and awkwardness of activating and dismissing the hidden popups makes browsing for functionality bothersome. Many users simply fail to catch on to these conventions, and even those who do may be slow to find hidden functions and work them into habitual use. Consequently, many apps place some buttons redundantly both on screen and in the menu.

So while hiding buttons in popups can result in a very aesthetically pleasing chromeless UI and also leave more room for displaying data on a very small screen, I don’t believe the benefits outweigh the cost in navigation ease and obviousness and annoying dialog modality.

Fixing it

So now, here in detail is how these issues could be addressed:

Rules for screens

To get a handle on navigation, we need a handle on the set of places the user can visit and how they can move between them. In Android, we’ll call these places “screens”. The rules are:

  • The Home screen is a single screen.
  • Each application, as represented by an icon on the Home screen, consists of some finite, fixed number of screens (two or three on average, five or six on the high end).[1]
  • No other screens exist. Application screens and the Home screen are it.
  • Clicking an app icon in Home takes you back to the screen in that application which you last viewed.
  • User actions in one screen can warp the user to another screen within the same application or to a screen within another application.
  • User actions in one screen can also modify the state of other screens.
  • Clicking an item in the notification list warps the user to a screen within an application.
  • Within an application, the screens are organized strictly left-to-right. Content within a screen is always scrolled vertically rather than horizontally. Users navigate between screens within an app by swiping left and right.[2]

A major goal of these rules is to establish and maintain spatial coherence for the user. The user needs to feel like the screen they are looking at fits somewhere. When the user has a destination screen in mind, they want to picture that destination in space relative to their current position. The way Android currently works, when users mentally construct a path from their current position to their destination, the path is a chain of links that lack spatial coherence. A lack of spatial coherence works well enough on the Web because users of the Web constantly visit new territory rather than familiar places: when you go somewhere new, you don’t know your way around anyway, so navigation that foils spatial expectations is not really any worse. But when the user is in frequently visited territory, it’s disconcerting when the territory lacks a defineable shape.

To maintain a sense of spatial coherence in Android, users need strong cues of where they are currently located, especially when they are warped to a different screen. So on the far left of the notification bar, the user always sees two icons: one representing the current application, the other representing the previously viewed application. When the user is warped from one application to another, these icons flash to indicate the move. To the right of these two icons, the user sees a row of dots wherein each dot represents the screens of the current application in order from left-to-right, and the dot representing the currently viewed screen is highlighted. When the user pans between screens, the dot of the new current screen faintly blinks.

When user actions modify the state of other applications, it’s generally a good idea if the state modification adds to the state rather than changes existing state. For example, when the user is taken from an app to a new URL in the Browser, the new URL should be added as a new browser window and leave all other open windows unaffected.

Grouping screens with tabs

To keep the number of screens down to a sensible few, many applications might simply cheat by stuffing multiple screens into the space of one using tabs at the top. This makes sense in many cases, particularly when the tabs represent different views of related data. For example, in the Music app, the Artist, Album, Song, Playlist tabs are more or less different views of the same collection of tracks.

When apps use this strategy, they should attempt to only group tabs which logically go together. In general, the number of tabs per screen should not exceed five. When you really need more than five, use an arrangement where two or three tabs are fixed in place, but the rightmost tab is actually a pulldown that includes all the remaining tabs.

Navigating with “Home” and “Swap”

Android should have just two hardware buttons: “Home” and “Swap”.

The Home button, of course, takes the user to the Home screen, just as it does currently.

The Swap button replaces the Back button and simply takes the user to the previously viewed application. Pressing it repeatedly toggles the user back and forth between the current and last application. (Recall that the notification bar always displays the icon of the current and last app.) When swaping to an application, the user is always taken to the screen within that application which they last viewed.

Pressing Swap at the Home screen takes you back to the current app (the app you were at before pressing Home).

On-screen Menu

If the Menu button is to be gotten rid of, the buttons of the menu need to appear on screen permanantly. The simplest solution is to simply put the buttons in a menu bar, a row at the bottom much like they appear in the current design when the user pushes the Menu button. However, to minimize use of screen space, the menu bar should consist of only a single row of buttons, never two, and less common buttons should get punted into a pullup revealed by a right-side ‘more’ button. (To make it even smaller, perhaps the buttons should only have a text label without an icon so they can be much shorter, or perhaps the icon can be placed next to the label rather than on top.) The number of buttons should not exceed four, so to fit five or more will require punting into a pullup menu.

In many cases, buttons currently seen in menus can be gotten rid of because they would no longer be necessary. For example, settings, by convention, should be placed on the rightmost screen of an app, so users shouldn’t need menu buttons that warp them to the settings screen. In general, menu buttons that warp the user to other screens should no longer be necessary. This would have the nice benefit of removing the redundant appearance of many menu buttons on multiple screens.

For screens with a need for fewer than three buttons or which simply wish to minimze the visual footprint of the menu bar, the menu bar may consist of just a single ‘more’ button that doesn’t span the whole screen width.

Of course, some apps way wish to have additional always visible buttons. In these cases, the most important buttons should generally appear in a larger size at the top of the screen rather than as a second row. The menu bar is meant to hug the edge of the bottom as much as possible; adding other rows on top would require the buttons to be much taller for easy clicking.

Rules for popup menus

For the purposes of this discussion, a popup is a modal overlay which covers the underlying screen area. While some popups are simply centered in the middle of the screen and block all other interactions, others may be ‘attached’ to an element on screen (so as to move with the screen when it’s scrolled) and which may or may not block other interactions. These latter kind are typically small, containing a few buttons. These ‘attached’ popups should be generally favored, as they maintain a stronger sense of space: when a popup floats freely, it’s much harder to remember where it comes from and so recall how to get back to later.

To give popups a consistant, distinct look so that they can be discerned from regular screen elements, popups should be given a strong border with a drop shadow effect to visually convey that they overlay the regular screen area. Also, every popup needs an on-screen dismissal button, a distinct X for close. (In OK / Cancel dialogs, the X can go on the Cancel button.)

Rather than integrating the keyboard into screens, it should always appear as a popup, with the standard dismissal button and the other visual cues that indicate it is a popup.

Generally, context popups should appear below the item as a row of small buttons, similar in appearance to the menu (though with somewhat smaller buttons.) If the number of buttons exceed four, four more buttons can appear on a second row. If the number of buttons exceed eight, the rows scroll vertically to reveal additional rows. When a popup is revealed that runs off the bottom of the screen, the screen should scroll down a bit, then scroll back when the popup is dismissed.

The dismissal button for these context popups should appear in the same place where the user clicked to make it appear.

Popups without long pressing

Currently, some items can be long pressed to present a context popup or regular tapped to perform a default action. Most commonly, the default action displays the tapped item in full.

To get rid of long pressing, one solution is to simply get rid of the context popup, and if the actions presented in the context popup are really necessary, they can be presented as buttons when the full item is displayed.

Another solution is to make single-tapping present the context menu. This would make the default action require two taps, but this downside is often acceptable.

Another solution is to attach a ‘more’ button to each item. Tapping the item would perform the default action, but tapping the ‘more’ button would present the context popup. This solution, of course, only really works for items of a sufficient size, such as full-width items in a vertical scroll.

One special case is the Maps app, where the user needs to perform actions on points on the map. It might be annoying if the user gets a context menu every place they tap, so one solution could be to place a marker where the user taps, and then buttons at the top or bottom of the screen perform actions on the spot under the marker.

Another special case is how to do text selection and cut-copy-paste without long presses. Single tapping and dragging on text places the text cursor, so long presses are currently used to enter a selection mode. To get rid of the long presses, a solution is to place these functions in a ‘more’ button on the text box or on the keyboard popup. For example, to highlight text, the user places their cursor on a word, taps ‘select text’ under ‘more’ to highlight the word, then drags the triangles to modify their selection. The user can then cut or copy the text from the ‘more’ button.

Single-screen Home

Sometimes the Swap button will not serve the user’s multitasking needs when the user needs to switch quickly between more than just two applications. Consequently, we should tweak the Home screen to better accommodate cases where the user is switching often between more than their last two apps.

First, the Home screen should consist of a single vertically-scrolling screen, not multiple screens swiped left and right. The scroll area is divided into a top customized area and an alphabatized area below it. If the user moves an app icon into the customized area, it doesn’t appear in the alphabatized area.

When the user presses Home from within an application, they are always taken to the top of the Home screen. When at the home screen, pressing Home will scroll to the top of the page.

To make navigation within a long Home scroll quick and easy, the scroll bar is always visible on the right, so users can simply tap a position on the scroll bar to scroll faster. On the scroll bar, dots indicate the position of the last five-or-so used applications (much like errors and warnings are highlighted on the scrollbar in Eclipse and other IDE’s). (These dots should probably vary in intensity so that the most recent app is indicated with a stronger color than the least recent.) So if the user needs to switch quickly to a recently used application from the bottom of their Home screen, they can press Home, look for the dot in the scrollbar and click that part of the scroll bar to quickly get to the icon of that recently used app.

Pressing Home while at the Home screen scrolls the Home screen back to the top.

The dialer icon is treated just like that of any other app. While most phones will come by default with the dialer app icon at the top of the home screen, it can be moved or removed just like any other.


[1] A few odd applications, like some games, may get away with breaking this paradigm, but generally as many apps as possible should fit the mold.

[2] In applications where the content view is dragged both veritcally and horizontally (such as the Browser or Maps), translucent tabs appear on the sides for the user to drag to navigate to the adjacent screens. Having the special case is less than ideal, but I believe probably worth the cost. If left-right swiping on the application screen doesn’t work well, perhaps swiping left-right on the navigation bar or perhaps dedicated hardware buttons are a better solution. Or maybe a special left-right swiping area always at the bottom of the screen, one that is translucent and doesn’t block regular clicks or vertical swiping; this would make the left-right swiping behavior consistant for all screens.