One of Android Q’s biggest improvements is the implementation of new gesture navigation. In conclusion, users can now travel back (left/right edge swipe) to the home screen using gestures rather than buttons (swipe up from the bottom).
By transitioning to a gesture approach for system navigation, we could grant apps access to a larger portion of the screen to provide a more immersive experience.
We wanted to provide readers a behind-the-scenes look at how we approached this task, including our thoughts, our plan, and some of the trade-offs we had to make. There will be some geeking out about gesture design, but maybe that will help you understand how we operate.
why do gestures?
One of the truly amazing aspects of Android is the capability for app developers and Android partners to test out unique, cutting-edge techniques on the phone.
Despite the fact that gestures have been around since 2009, mobile device users have started to use them more frequently during the past three years.
At the forefront of this movement were creative Android partners and Android apps rolling out some pretty intriguing concepts (for example: Fluid NG, XDA).
When we looked into this deeper, we concentrated on the advantages for the user:
1. Gestures can be speedier, more ergonomic, and more natural ways to operate your phone.
2. Gestures are more purposeful than software buttons that you might press by casually grabbing your phone.
3. Gestures enable a more immersive experience for apps, especially as hardware progresses toward larger displays and narrower bezels. Gestures also reduce the amount of system drawing over app content. Such as HOME/BACK buttons and the bar they sit on.
But not everything went perfectly; we had issues with a few of the gesture modes.
- Not every user can use gestures.
- It can be difficult to learn gestures, and they take some getting used to.
- Gestures may interfere with how an app navigates.
Over the past year, we worked with partners including Samsung, Xiaomi, HMD Global, OPPO, OnePlus, LG, Motorola, and many more to standardise gesture navigation going forward. To ensure a consistent user and developer experience, the Android Q gestures will act as the default gesture navigation for future Q+ devices.
So why are they acting in this way?
to comprehend how individuals used their phones. We initially did research on what a typical reach looked like and which parts of the phone they used the most. From there, we built a tonne of prototypes and evaluated them on a range of criteria, such as desirability, usability, ergonomics, and others. In order to find out how soon consumers accepted our final design, we also ran a number of research on it. How soon they adjusted to it and their feelings toward it.
A distinguishing element of Android navigation has always been the Back button. notwithstanding several disputes on what behaviour is “appropriate”. Many people appreciate it since they find Android to be easier to use and learn, and it is extensively used! Actually, it was 50% more than Home. As a result, we gave this goal precedence over less popular navigation options like drawers and recents. And one of our design objectives was to make the return gesture reliable, simple, and ergonomic.
using the graphs of reachability below as a reference. The Back and Home gestures were designed to match with the thumbs’ most convenient and reachable positions.
In comparison to using buttons, users completed tasks involving Home and Back on average faster than they did with most other models. The strategy did compromise people’s ability to quickly access Overview/Recent apps, which they use less frequently than the Home screen.
The Q model was viewed by users as being more straightforward and qualitatively attainable. Even if more users continued to consider buttons to be more ergonomic.
App Drawers and Additional App Swipes
We ultimately came to the conclusion that the side swipe was the back gesture that best balanced the trade-offs. It is significant to highlight that there were challenging decisions, particularly in light of how that motion might impact apps.
For instance, we found that, depending on the Google app, just 3–7% of users swipe to activate. The remaining users have to select the hamburger menu from the app’s navigation drawer. Since the drawer swipe gesture is now dominated by the back button. The hamburger menu will require some users to get used to it. We optimised for what functioned best there given the broad use of back, even though it was a difficult choice.
Because it is never our objective to change users’ behaviour, we tried a variety of methods to help them distinguish between the drawer action and the back gesture. But with each of these options, consumers began to doubt the Back button and pull in the drawer instead when wanting to go back.
Beyond drawers, gestures represent a substantial adjustment for people, and it frequently takes them 1-3 days to adjust. Swiping right or left on a carousel or hitting the Back button were two motions that users had a hard time adapting to.
Users were able to accurately distinguish between these two movements after a 1-3 day break-in time, according to qualitative testing.
What Impact Does This Have on Developers?
With gesture navigation, we hope to improve and standardise the Android user experience. The majority of users will benefit most from the paradigm we selected. Some of the gestures, nevertheless, are incompatible with those employed by programmes that already exist. Requiring developers to make adjustments to the way people use your programmes. We take our responsibility to Android developers seriously and want to help you through this process.
The following three critical phases are involved in gesture navigation support:
Move to the edge so your programme may draw across the entire screen.
It is important to address any visual conflicts with the system’s user interface (such as the navigation bar) and gesture inconsistencies with its gestures.
We value your input.