Android: On Context Buttons

Capacitative

David Barnard complains about the capacitative buttons below the Nexus One screen. As I have done in my Motorola Milestone review. But it gets both more interesting and, unfortunately, worse, in the story of these buttons.

There are four buttons1:

  • Back
  • Context menu
  • Home
  • Search

While programmable, the back button mostly works as you’d expect. When in the browser, “back” goes back in history as any browser worth its salt should. When you’ve just started an app, “back” goes to your homescreen. If you’re in an app, browsing menus, back goes to the parent menu. If you’re playing “Solitaire”, the back button has been programmed to undo the last move. This is a very useful button, as useful on an Android handset as in a browser where “back” takes up the prime real estate.

The context menu is an intriguing design. It’s most comparable to what happens when you right-click on a PC: same as if you right-click on your desktop, if you context-press on your homescreen, you get to change the wallpaper. If you’re in an app, context-press invokes the options menu. In both cases, when you press the button, a menu pops out with a context menu: “Wallpaper”, “Share Image”, “Options” and so on. I’ll get to the usefulness of this in a second.

The home button works as the iPhone home button does. It takes you to your homescreen. More than that, if you press and hold the home button, an Alt-Tab like menu showing recent apps is invoked, which is useful if not completely necessary for multitasking. Similarly, the search button when single pressed opens a Google search, whereas a long-press invokes “search by voice”2.

Useful On A Whiteboard

So, while the first three of these buttons are indeed useful (and I do honest to goodness use them all the time), I would argue that they shouldn’t exist. As compared to David Barnards piece, not for one but for two reasons:

  1. They encourage lazy app design
  2. Like Barnard says: you’ll sometimes hit these buttons when you don’t want to

To elaborate on #1, this is mostly related to the “back” and “context menu” buttons, which you’ll have to deal with if you’re an Android app writer. Obviously, the iPhone does well without these buttons. The back button on an iPhone app is usually an arrow-elongated pill button in the upper left corner (like a browser), and option menus are also usually available from aptly titled buttons. So essentially there’s no reason why an Android app couldn’t work like this. The whole idea of adding these buttons, however, is to save space. On a tiny screen, I hear the initial Android handset designers argue, you shouldn’t have to make space for back and options buttons. Which in theory may be valid, but in actual practice isn’t a problem at all since these screens scroll. The net result is that at least the back and context menu buttons become mystery meat navigation: you won’t know what happens until you press. Potentially disruptive.

Lastly, the fact that these buttons are usually capacitative buttons (as opposed to tactile, pushable buttons) that are placed in immediate extension of the screen, sharing the same glass, means you’ll accidentally hit it once in a while; whether it be in a browser and you accidentally scroll down on the home button, or as in Barnards example, when you press space on the keyboard. Gruber argues, and this is apt, that if you could compare a touch screen to a computer screen, the capacitative buttons on the Nexus One are right in the prime real estate area: the screen edges. Which means they’re easy to hit, even when you don’t want to.

The worst problem with these buttons is that now they exist, both Android and Android apps rely on them. An Android handset without these buttons would be less than useless. That is, unless Google decides to do what’s right as soon as possible and deprecate these buttons, thereby pushing developers to design UI that works without them.


  1. On some systems, there are only three, the Search button being omitted.  

  2. Which doesn’t work nearly as well as you want it to, but that’s another story.  

4 thoughts on “Android: On Context Buttons”

  1. shonangreg says:

    Yes, these buttons are a problem. They are especially problematical for lefties using a tablet with a stylus. I have to float my hand over the bottom left to avoid hitting them while writing (or use a handkerchief as a palm rest).

    Putting the buttons on top would eliminate this particular problem (an auto-hide feature would be nice too…) And my tablet, the ThinkPad Tablet, actually has hardware buttons so I don’t need the capacitive buttons at all. I know if I could root my tablet I could hide them. But I’m not rooting any time soon, and google shouldn’t want me to root to overcome their design problem here.

    Is there any way around this short of rooting?

    One suggestion I had was that drawing app developers could put an “upside-down mode” in their apps. Launch the app in landscape mode, invert the tablet with the bottom (and any hardware buttons) at the top, lock the screen orientation in this upside-down mode, rotate the tablet back correctly so that everything on screen s now upside-down, including the capacitive buttons, then click the “invert app” button. Now your app is all OK and there are no buttons at the bottom to accidentally brush against.

    1. shonangreg says:

      Oops. I meant, “Launch the app in normal PORTRAIT mode…”

Comments are closed.