Android: On Context Buttons
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:
- They encourage lazy app design
- 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.