Google’s Upcoming Android Q Gestures are a Mess
In 2019 it seems every Android device has to at least have the option for gestural navigation. Samsung, OnePlus, Huawei, and many other Chinese manufacturers come out of the box with a gesture control option now. In an attempt to perhaps get ahead of the problem before true fragmentation really takes hold, Google has also been working to come up with a suite of gestures. Google’s latest Android Q Beta brought with it a new set of system navigation gestures. These gestures have been tweaked and changed through Android Q’s entire beta process. Unfortunately, Google’s latest crack at gesture navigation comes up short for me and winds up feeling like something bolted on to Android, rather than an intuitive, clever, helpful system for moving around a device. Let’s take a look at why they’re sort of a mess right now.
A Brief Navigation History
To properly talk about Google’s gesture navigation in 2019, I think we have to start at the beginning. In September 2008, HTC released the G1, the first commercially available Android phone. While almost everything has changed with Android since then, the G1 came equipped with two buttons that have stayed with Android more or less in their current form: Back and Home. In fact, a system-level Back button has been a defining feature and differentiator of Android since inception.
For several years, Android devices, like my beloved Nexus One, came equipped with a four-button layout: Home, Back, Menu, Search.
While many manufacturers shuffled the order around, with few exceptions this was the Android layout at the time. In 2012, Android 3.0, began the depreciation of the menu button (the search button had already been dropped). While at the time this was a controversial change, Google’s reasoning was sound. Menus themselves were always a question mark. A hidden menu that may or may not have the option you’re looking for that is only discoverable by pushing a button to check isn’t a clear and communicative user experience. Applications adapted to this change and started including a menu button in their toolbars.
Starting with Android 4 in 2013, “vanilla” devices came equipped with the now-familiar navigation layout of back-home-recent apps. We’ve mostly held to this layout and button arrangement for years now. However, with the post-Nexus Pixel line, Google has begun to experiment a bit.
The original Google Pixel and Pixel 2 came equipped with a standard back-home-recent layout, but the Pixel 3 (and Android Pie) launched with a new two-button “gesture” control scheme. The home button remained, as did the system-wide back button, but Recent Apps was now replaced with a swipe-up gesture. Much like the removal of the menu button, such a big system-level change was met with criticism and confusion. Unlike the Menu button removal however, this change didn’t actually provide user benefit. The navigation bar remained the same height, and it was arguably slower to use than a simple button tap. It’s possible these gestures were a response to the iPhone X which brought full system-wide navigation gestures, but it felt a lot like change for the sake of change.
Android Q Gestures – An Attempted Revamp
Now, many Android OEMs have come up with their own gesture systems. Many of them are similar to the iPhone X, particularly in the Home gesture. With the Pixel 4 launch (and Android Q) looming, Google is set to release yet another system navigation method, one that embraces gestures even more. We’ve seen these gestures evolve throughout the Android Q betas, but now that we’re on beta 5 and nearing Q’s final release, the likely “final version” of these gestures is starting to take shape. To be frank, the gestures are bad.
To start, let’s look at how these new gestures work. Once full-screen navigation is selected, the Navigation bar mostly goes away and is replaced by a small horizontal line across the bottom. This bar looks very similar to the home bar on iOS, only smaller. The gestures also function in a very similar way to iOS. Swiping up from the bar, while in an application, will go to the home screen (a neat bouncy effect on the adaptive icons helps sell the motion). Swiping up and holding will bring up the recent apps switcher. Swiping horizontally along the bottom bar will scroll through recent apps, again, much like in iOS.
Here’s where things get messy. The ever-important Back button, which is still a critical component of Android navigation, has been moved to a swipe from either side of the screen. A swipe from outside the display inward activates the back button on either side.
The back gesture can be activated from the entire height of the display unless the keyboard is open. If the keyboard is open you have to swipe above the keyboard or close the keyboard from the navigation bar. Lastly, with Beta 5, Google added these little half-circle indicators in the bottom corner on either side for the Assistant gesture, which is swiping in from either bottom corner.
Most of the Android Q gestures are fine; Apple and other manufacturers have already introduced people to these and while I wouldn’t call them intuitive, they mostly work well enough. There are, however, some big problems with the Back gesture, and I really wish Google would rethink the entire system.
Issues and Confusion
My first and main problem is with using applications. To start with, the majority of Android applications have a Navigation Drawer. This handy slide-out panel is present in lots of applications, and many years of Android use have trained me to swipe in from the edge to open it. One can press the Hamburger menu up top to open the drawer, but with phones getting ever larger and taller, this is problematic. With both the Back and Navigation Drawer opening gestures being functionally identical, it’s incredibly finicky, difficult, and annoying to do one without activating or stumbling over the other. In Android Q Beta 5, Google attempts to fix this with a sort of “start to swipe in and pause” method for opening the drawer rather than Back, but in my experience, it is incredibly unreliable.
🚧 The drawer behavior is changing. Users will be able to open the drawer by peeking the drawer, and then swiping. Big benefit is that this works with existing apps with “old” DrawerLayout versions. pic.twitter.com/WVyOzQFzHO
— Chris Banes (@chrisbanes) July 2, 2019
Forcing myself to use Google’s gestures since the Beta 5 release has shown me just how many applications I frequently swipe open the navigation drawer in. Here’s a (by no means exhaustive) list of applications that are now quite a bit more cumbersome to use with gestures:
- Play Store
- Literally any Reddit client
- Keep Notes
Of course, this isn’t an insurmountable issue, but it feels like an unnecessary one. We have years of developer inertia here that the new Android Q gesture is fighting against.
Another issue I have with the Back gesture is that it just isn’t coherent or communicative. Admittedly, Android’s system-wide back behavior has always been a little odd. In some applications, it will close the app, while in some situations it can take you between apps and then ultimately back home. A common situation is opening an Application from the launcher and then hitting the back button (at least one time) to go back to the launcher.
On iOS, where many claim Google lifted its gestures from, this isn’t possible. Apple’s operating system is more “app-centric,” and there is no gesture except for Home to go from an application back to the home screen. While inside most applications in iOS, swiping from (only) the left edge is treated as a back gesture. This is communicated to the user through a subtle animation of the new view sliding in from the right edge. So naturally and intuitively, sliding the opposite way will go “back.”
This sort of flow and animation simply doesn’t work with Android’s back UX. If I launch an application from my dock, it “zooms” into view from the Icon. Nothing about the animation communicates that “going back” via swiping from either edge will take the user to the home screen. Again, this isn’t a showstopper, but we’re more than a decade into these mobile operating systems, and this feels like a step back in terms of working intuitively with the user.
Lastly, I have a couple more minor problems with the Android Q back gesture. When the keyboard is open, you lose the ability to swipe back on the edges for however tall the keyboard is. If one wants to use the back gesture to close the keyboard, they’d have to shimmy the phone up and swipe above the keyboard.
For now, there remains a “close keyboard” button in the old back button location to help. To me, this feels pretty discombobulated. Lastly, and I’m fully willing to admit this may simply be something I do with a gesture rather than a button, there’s no ability to repeatedly press the button to go back several layers. It’s not uncommon for me to be chatting in Hangouts (I’m still mad at you Google) and just sort of “rapid-fire” the back button to get back to the home screen. Alternatively, sometimes you’re a few layers deep in Twitter or Reddit browsing and want to press the back button a few times to get back to the main feed. Pressing a button repeatedly will always be easier than the equivalent number of swipes.
Please fix Android Q’s Gestures, Google
To be totally frank, I’ve been on Android Q Beta 5 since release, and it’s the first time I’ve forced myself to use gestures when I’m using my Pixel 3 XL. I still don’t enjoy it, and I constantly have to fight the urge to switch back to either 2 or 3 button navigation. So much of Android Q gestures just feels like Google playing catch up or simply duplicating what iOS and EMUI already do. It doesn’t feel like a deeply thought out and coherent experience. It also feels slower in almost every way than the 3 button layout from almost a decade ago. I know we are very close to release with Android Q, and it’s likely that a lot of what we see in Beta 5 will make its way into Q’s stable launch. However, I just truly hope that they can come up with something better sooner rather than later. For now, at least I can still switch back to the 3 button layout or the Pill.