Let’s discuss, for the moment, the Home button. It’s the quintessential interface on smartphones.
As pioneered by the iPhone, its behavior arguably defined the user experience of the rest of the operating system. It suggested apps were a modal experience, and that a press of the button would always exit the app and take you home. In-app navigation would have to happen elsewhere. The home button conveyed a simplicity of interface that immediately resonated. Despite doing only a single thing, it was worth spending an entire physical button on it.
Since then, the button has taken on many new behaviors. First off, the double-click happened as something you could tie to a custom shortcut. Eventually that would open the multi-tasking tray. We got a long-press that would fire up Siri. When the form factor grew beyond 4 inches, we received an optional “reachability” feature that would require a double-tap (not click). Tripple click could be mapped to an accessability feature.
Before we go into the feasibility of adding more gestures to the previously single-purpose iPhone home-button, let’s look at what Android did. In the early days, it wasn’t pretty. There would be physical buttons for Back, Menu, Home, and Search. Home and Back buttons worked (pretty much) like you’d expect, but Menu and Search were problematic. The former, in particular, meant that apps had no visible UI for extra features. You’d open an app, and some aspects would be buried in an invisible menu you had to click the menu button to see. It was classic mystery meat navigation, and search was almost as bad. Search would open an apps contextual search feature, if it existed. Otherwise it wouldn’t do anything. On the home screen, search would fire up Google. In the browser it would set focus on the addressbar. I may be misremembering bits here, can you blame me?
Oh, and most buttons had longpress. Longpress back, I believe, would open up history in the browser. Longpress home would access voice navigation, I think. Longpress search, for whatever reason, would invoke the multi tasking menu.
There were a lot of qualifiers there, suggesting I might be misremembering. That’s because invisible features are almost always a bad idea. Hiding possibly critical app features in an invisible menu reduced the discoverability to those willing to play whack-a-mole. Same with search, and frankly, longpress.
Before we get to that, though, Android 4.0 Ice Cream Sandwich (technically Android 3.0 Honeycomb, though I’m not sure anyone will recognize that version) improved things a fair bit and the Android systembar has been fairly stable ever since. Here’s the latest iteration:
For the purposes of this post, we’ll be discussing the Android “spec” version of the systembar, which features these three onscreen buttons in “back, home, overview” order. Some OEMs, like Samsung or HTC, would make the buttons physical, or flip around their order.
Android has a Back button, a Home button, and an “Overview” (multitasking) button. Initially, there were no longpress actions tied to any of the buttons. Instead, a vertical swipe would invoke Google Now, or Search, whatever your phone came installed with.
Redesigning an interface is like dancing a waltz. It’s usually two steps forward, one step back. In the case of the Android systembar, the swipe up to enter Google Now gesture was crazy making. I would accidentally invoke it every once and again, but my daughter playing with drawing apps would invoke it constantly and lose her place.
Eventually (5.0 Lollipop I believe) the swipe gesture would be replaced by a longpress, and in 6.0 Marshmallow you could even disable the longpress.
The Goldilocks Principle
The elephant in the room is the burning question: which is better? What’s the right amount of system buttons? Should buttons be physical or on-screen?
In the end I think that’s mostly a question of personal taste, preference, who’s using it, and what one is used to. However if the purpose of an interface design is finding a beautiful balance of usability and discoverability, we can probably extrapolate a few general guidelines.
First of all, basic usability favors visibility. Anything you bury under non-standard gestures such as double-click or longpress are going to go unnoticed by most people, and only utilized when such a gesture is learned to be necessary. Ever see someone doubleclicking a hyperlink in a web-browser? That’s arguably a bad user experience design resulting in the wrong lesson: double-click to make sure it works. Online stores are still paying the price for this, having to disable the buy button once pressed a single time, or verbosely spelling out: “only press once”.
The swipe gesture is a powerful gesture when used right. In older Androids it invoked search, which was a terrible decision — as mentioned it was too easy to invoke, and just not useful enough to warrant such an action. When used to swipe between homescreens, or scroll a page, however, there are few better gestures.
Which brings us to the Back action. On Android it’s a permanent systembutton. It mostly does what you expect it to do, except for a few cases where it doesn’t. It’s supposed to always take you back to the previous screen, but what if you just launched an app and accidentally hit back, should you exit out to the homescreen?
On iPhone, there isn’t a system back button. Instead, back-buttons are added by the developer to the top-most toolbar of an app, ensuring they are contextual and pretty predictable. They’re even labelled (most of the time), which is hard to beat from a usability perspective.
On the flipside, they can be far away from your thumb, especially on large screen phones like the Plus models. To alleviate that, there’s the side-swipe, for lack of a better term: you swipe right from the left edge of the screen to go back to the previous screen you were on. Not quite as predictable, perhaps, as swiping left and right inside a photo gallery, but certainly convenient. The main downside of the side-swipe is that it can limit what apps can do with the same gesture. Once a gesture is reserved by the system, you should probably be mindful to not interfere with it.
Incidentally the side-swipe gesture suggests when it might be appropriate to add multiple actions to systembuttons: poweruser features. If a feature is complementary but not required learning in order to use an interface, it can add a lot of value to the experience. The side-swipe seems to do that — you don’t have to learn it in order to use an iPhone, Back buttons are still there. Android 7.0 Nougat has a similar power-user feature that is absolutely not required learning: double-tap the multitasking button to quickly switch to your last used app. It’s like alt-tab for your smartphone.
I’m not finding it easy to defend mapping the multitasking feature to double-click on the iPhone, however. It seems like a feature so valuable you’d want to make it esaily discoverable.
Siri vs. Google Assistant
We come to it at last, the long-press features. On the iPhone, holding the home button opens Siri. Same with Android 5.0+ which would fire up Google Now, and with the upcoming Pixel phones, Google Assistant.
Pixel phones feature a little colored-dot animation as you press and hold, which seems to be an attempt at adding discoverability to the feature. I don’t buy it. The onscreen buttons are small already so you’re likely to cover the animation with your thumb, and nothing beats a label regardless.
The Google Assistant is available through other means, though. The homescreen — the launcher as it’s called — has a big Google logo tab in the top left corner, which also invokes it. You can also use the “OK Google” hotword. So while the home-button longpress isn’t very discoverable per se, the Assistant itself should be. That embraces the poweruser nature of adding longpress features to systembuttons.
Siri is less discoverable. You have to enable it first (otherwise you just get “voice control”). Then it’s there on the longpress. You can also enable a hotword detection, “Hey Siri”, to invoke it. There isn’t a widget you can add, or an app icon you can tap.
Perhaps that’s okay, though. Perhaps the assistants don’t have to be discoverable, yet. They pass the litmustest of can you use and enjoy the phone without it, and in both cases I’ve never used them for much other than setting timers and reminders.
I can’t help but feel like that’s about to change. Assistants, neural networks and AI seem to be evermore encroaching on the smart devices we use. Today it’s smart replies in Google Inbox and on smart watches. But what do the interfaces of tomorrow look like?
It feels like most of the design of the original iPhone sprung from the concept of having that singular home button. What would a phone look like if that button, instead of taking you home, was your assistant?