Friday, March 29, 2024

Android Q’s back gesture breaks just about every app’s primary navigation

Share

gmail-side-drawer-android-q-pixel-3.jpg?

The new gestures are great, but they aren’t worth losing slide-in drawers in every app for.

Android Q’s new gesture navigation system is a clear upgrade over what Google tried with Android 9 Pie. Multitasking is easier, and each of the core gestures is easier to use with more fluidity. But one core part of the navigation paradigm that’s still up in the air is the new back gesture.

We’ve seen several phone makers create their own back gestures, but not in the way Google is standardizing on with Android Q: swipe in from the edge of the screen, on either the left or right, at any time to perform the same action previously handled by the back button. This difference from the rest of the back gestures on other Android phones is extremely important because it interferes with one of the most fundamental in-app navigation systems used today: the slide-in drawer.

The slide-in drawer has been a fundamental app interface component for a decade.

The hidden slide-in drawer has been a fundamental app navigation mechanism for nearly a decade, and it’s propagated beyond Android to just about every other platform in some way. Apps that don’t use a slide-in drawer are few and far between, and many (including some of Google’s own) rely on it as their primary system for moving through sections of the app. Even those that surface most-used functions to a bottom navigation bar still use the slide-in drawer as a dumping ground for further options.

(The only category of apps that doesn’t regularly use a slide-in drawer are games, which have their own struggles with edge-based gestures.)

screenshot_20190610-145724.jpg?itok=Vu19screenshot_20190610-145747-2.jpg?itok=Q9screenshot_20190610-145808-2.jpg?itok=v4

Using Android Q with gesture nav, every single app will lose its slide-in drawer until the developer updates.

When you’re using Android Q with gesture navigation enabled, every single one of those apps loses its slide-in drawer. You simply cannot swipe in from the edge, at any place or in any way, to reveal it. The only way to show the drawer will be to tap whatever button is associated with it — typically a hamburger menu button in the top corner, which is increasingly tough to reach on large (and tall) phones. That’s a massive pain that requires a change in muscle memory at the very least and dramatically reduces the speed at which you can navigate apps.

Google knows that the back gesture is going to create headaches for everyone who has come to rely on the slide-in drawer (among other near-edge taps and swipes), and is making it very clear to developers that they need to plan for this change:

If the user swipes in from the edge of the screen, the system interprets that gesture as a Back navigation, unless an app specifically overrides that gesture for portions of the screen. To make your app compatible with gestural navigation, you’ll want to extend the app content from edge to edge, and handle conflicting gestures appropriately.

Android developer documentation lays out the process by which developers can define areas of their apps that are excluded from the back gesture, and will instead perform other actions — whether that’s to pull in a slide-in drawer, or simply have guaranteed touch input all the way to the edge for some other interaction. As an example, Google has already updated the Play Store app to completely remove the back gesture on the entire left side, leaving it for the slide-in drawer only.

Gesture exclusion areas will be different for each app — if they have them at all.

That’s all fine and good, but it requires that developers actually do what Google is asking. And even if we take that as a given (which we obviously can’t), and every app with a slide-in drawer magically has an exclusion area overnight, there are still big usability hurdles. Gesture exclusion areas only work if you can count on them being there — not knowing where that area is, which side it’s on, how large it is, and having it be different for each and every app on your phone introduces a new set of issues altogether. It’s going to be a very, very frustrating transition.

android-q-pixel-3-gesture-nav-bottom.jpg

Unfortunately for us, developers don’t have that much incentive to create these exclusion areas. The new gestures are mandatory to include on new phones shipping with Android Q, but they don’t have to be the default nor the exclusive navigation choice. It’s a pretty safe bet that most companies that already make their own gesture navigation systems, or stick with three-button navigation, will continue doing so with Android Q — and for this vast majority of phones out there, developers won’t hear any complaints.

This is one of those situations where we can actually take the slow rollout of Android updates as a positive thing because developers as a whole are not going to have their apps up to date with considerations for the new Android Q back gestures for some time to come. And in the case of anyone who updates their non-Pixel phone to Android Q, it gives even more weight to the decision between enabling the new gestures and sticking with the other available system(s) — the Android Q gestures may be great and intuitive, but are they worth losing slide-in drawers in most apps you use every day? I don’t think anyone would say they are.

Android Q: Everything you need to know!

Read more

More News