Android P navigation: The best way to do swipe-left-to-go-back (concept)

It could be more simple

Some lovely person shared my previous concept post Android P navigation over on Reddit (here) and it got a bit of traction. Forgive me, I don't really use Reddit - but I'm happy to kid myself than 200 comments and 30,000 views in 10 hours overnight is OK.

The thing is, I came up with that concept over my lunch break - and I've had a little longer to think about it now and I've realised it's needlessly complicated.

And navigation should be simple.

It stems from my stupid idea to do a 'swipe-right-to-go-forward'. What was I thinking? When does anyone even use to forward button on their web browser, let alone feel any need for such a feature to be introduced on Android?

Nope: that idea needs to die.

Instead, I realised that Google was totally right with its swipe-right-to-quick-switch-app approach.
If a swipe-left-to-go-back move makes sense because it seems to 'push' the active app layer away, then a swipe-right-to-quick-switch-app also feels right to 'pull' the entire app away and drag in a new one. There's no need for any of those quick-switch swipes at the ends of the screen - they aren't even coherent with the rest of the concept.

Google was right; I was wrong.

HOWEVER, the swipe-left-to-go-back still makes sense for all the reasons as before - and there's one thing we're gonna need to accept to make it happen: the pill has to move up when the keyboard's on screen.

Yup, I know: it's dangerous to move a core navigation component around the screen. But, as you'll see, in this situation it totally makes sense.

In fact, it's probably the best way to clean up that UI and make swipe-to-go-back a reality.

Here's my Android P concept 2.0 after 24 hours to think about it:

Yup, it’s still all about that damn back button on the left. Look at it there, pushing the whole thing off balance. Sure, it disappears on the home screen, but for the rest of the time, you’re stuck with a lopsided navigation system.


I still swear, I could do better than that... again.

How to make it better:
It still starts with how the back button needs to work inside apps. This is exactly the same as my previous idea. If we are going to go with swipes on the pill-shaped home button (which I’ll call the ‘pill’ from here on in), then we should notice the similarity between a swipe and a push. If we are going to swipe to go back, it needs to feel as though we are pushing something away. Now, the direction of the push comes from the presence of that slide-in menu thing that we normally get on the left of the screen within apps. To get rid of it, we already swipe the thing to the left and off the screen. Hitting the old-school back button does the same thing, so it makes sense for the ‘back’ function to swipe in the same direction.
So, this swipe left to back up should also be used to move back through different screens within an app. For this, I imagine the difference screens within an app as layers. As you click on icons within an app you go ‘deeper’ into the app.

Swiping left on the pill should ‘back up’ out of that layer and out to the previous. The animation can have the zoom out slightly off centre towards the lower left quadrant of the screen to reinforce the feeling that the user is ‘pushing away’ layer 3 to return to layer 2.
If we imagine the overview screen acts as an example of where our apps are in space in relation to each other (ok, virtual space. Whatever), then we can see overview presents them as being laid out next to each other with all the home screens off to the right.
Scrolling within an app normally moves along the y axis; moving between layers within an app is simulated along the z axis - which leaves us movement along the x axis for switching between apps. The active app should always move to the App 1 position. A quick flick right on the pill should quick-switch apps by dragging the app in the App 2 position into focus. Another swipe brings the app in the App 3 position into focus. The user can swipe back from App 3 to App 2 by swiping left on the pill to 'go back'. The app takes up the App 1 position once the user starts interacting with it.
In this way, swipe left normally interacts with the z axis and swipe right interacts with the x axis.
In old school Android versions, pressing the back button again when on the top layer of an app normally closes the app. In this concept, it does the same thing - we imagine the active app always takes the App 1 position on the x axis but instead of the app dropping down to reveal the home screen behind it, the app swipes left along with the user’s gesture to reveal the home screen waiting there to the right. Move between home screens as you would do normally, but swiping right on home screen 1 would bring you into the overview screen, same as a swipe up might do, to let you quickly move back into the app you might have just swiped out of by accident.
So, we are left with one little pill on screen to do all the work.

But there’s one problem: the keyboard.
When the keyboard pops up on old school Android versions, the back button transforms itself into a down button that tucks the keyboard away below the bottom of the screen. 
from Stackoverview: 

In every other concept out there, this issue of needing to drop the keyboard makes them unworkable: swipe-left-to-drop-the-keyboard just doesn't make any sense - the direction of the movement is different to the direction of the swipe. And pretending we can tuck the keyboard off to the left of the screen doesn't work either, because that's the place the most recent apps slide in from. Sure, we could have the down arrow reappear when the keyboard is up, but that's just another example of a lopsided interface and I hate it.

What I’d like to do here is a little bit more daring and probably the most risky change I’m proposing due to how different it is. Yet I've come to realise it is the most important change and THE BEST WAY for swipe-left-to-go-back to work. In fact, EVERYTHING HINGES ON THIS ONE CHANGE:

When the keyboard pops up in this concept version of Android, I want the pill to move up with it.

Now, while this does mean that the home button is now in the middle of the screen rather than at a nice secure place at the bottom, I still think it’s the best option. All the normal swipe gestures on the pill would still work from this raised position AND it has the advantage of actually making a little more of the app visible to the user because there is no longer any need for any wasted space below the keyboard for the navigation bar or a strip of unused space for the pill to sit.

And if you're gonna start complaining about moving such a key navigational feature around the screen, then just remember that the home button already moves around when we go full screen AND when we move into landscape position.

Moreover, the way to drop and close the keyboard becomes so obvious that it's beautiful: you just drag down the pill to its normal position at the bottom of the screen.
Keyboard closed.

So that’s it. We get a balanced display, full functionality AND an interface that improves the user experience without simply copying the iPhone X.

And that’s how a dumb-ass high school Literature teacher reimagined Android navigation controls over lunch and an evening learning to use Google Drawings and Blogger (and then ripped that idea apart to come up with something far more simple).

What do you think?

(Disclaimer: ideas are cheap; execution is everything)


  1. Hi Ollie. I edit a tech news website and Youtube channel. We wanted to get in touch to speak a little more about your concept. Would you be able to drop me a line (, so we can talk on email?

  2. I took your concept one step further.

    Here's the summary.

    Swipe Gestures
    - Swipe Up -- Current Android P Behavior
    - Swipe Down -- Expand notification
    - Swipe Left -- Back
    - Swipe Right -- Current Android P Behavior

    Tap Actions
    - Single Tap -- Home
    - Tap and Hold -- Google Assistant
    - Double Tap (Option1) -- Activates context-aware search action (Google, Omnibar in Chrome, Search in apps)
    - Double Tap (Option 2) -- Quickly switch between 2 apps.

  3. I haven't yet used Android P but I'll point out two things I don't like bssed on your concept:

    - Swiping up partially vs swiping up fully. I don't think this is a good idea. Novice users will get frustrated when trying to figure out how much to pull up to swipe 'fully'. Not sure what 'overview' displays but giving any directional swipe multiple actions will be messy, hence nobody has done this successfully yet. Look at the notification bar vs quick tiles (two finger pull for tiles instead of long/short pull). The last thing the user should be doing is trying to figure out how much to pull to get to something.

    - Moving the pill up with the keyboard, terrible idea imo. Why? First off, you won't be seeing more of the app like you claim. Instead you'll be blocking the text box with a pill in most messaging apps where the keyboard is most used. I wouldn't mind a down arrow beside the pill, not sure why that frustrates you so much. Why have all that wasted space with just the pill at the bottom? The other option is to still have the swipe down feature with the pill at the bottom.

    You stated the navigation bar moves when we go full screen or landscape but you forget it still stays by the edge, there's consistency in the position. I find your choice of mvoing the pill ironic since you're not a fan of lopsided interface because that's exactly what happens when you start moving core interface components around.


Post a comment

Popular posts