Shared publicly  - 
 
This is part 3 of a series on the new Android navigation drawer pattern. You can read the previous parts here:

Part 1: https://plus.google.com/+AdamWPowell/posts/2zi4DXd3jkm
Part 2: https://plus.google.com/+AdamWPowell/posts/VdgexsZeXHW

The apps that made the full-size three-line button icon in the upper left popular are themselves popular apps with strong branding throughout their UI. For other apps, using that full-size hamburger icon in place of the app’s own icon on the action bar meant losing a glanceable identifying characteristic. It ran the risk of apps looking too “samey.” We decided to play around with changing the Up chevron to the left of the icon as an alternative to a full hamburger.

A first draft of the small hamburger (affectionately called “the slider”) didn’t test well. Making it the same width as the Up chevron made it too easy for users to miss in a quick visual scan. Some of our visual design team got to work creating a number of alternatives for later review. In the meantime we added the long-edge touch “peek” to DrawerLayout’s behavior as a hint to a drawer’s presence, but we knew this wouldn’t be sufficient for discoverability on its own.

Meanwhile we were still looking into whether we could address adapting to multiple screen sizes with the same DrawerLayout pattern and we were running into a wall. Many apps like Gmail were already using fragments to great effect on larger screens by simply placing item list and item detail views side by side where those same views would represent deeper navigational hierarchy on handsets.

YouTube was already using a content-sliding drawer to handle this case and it worked quite well. The new Hangouts app wanted to do something similar, especially to handle the case of Nexus 7-sized tablets in portrait mode. They wanted to keep the conversation list partially visible as context even when there wasn’t space to show it fully, but to show the full list and current chatlog on large enough screens.

The further we looked at these use cases the more clear it became that DrawerLayout and what Hangouts wanted were distinct. The key difference was that our navigation drawer pattern was independent of screen size; in cases where we wanted a nav drawer we wanted it tucked away until summoned. A larger screen didn’t mean that there was some responsive design inflection point where the drawer became permanently visible.

android.support.v4.widget.SlidingPaneLayout now formed the basis for the new Hangouts app’s UI. We kept the bulldozing behavior here even though we rejected it for DrawerLayout. Its use case is more narrow than nav drawers and it wasn’t designed to be as strong of a prescription for this specific use case, merely another tool in the box. We were willing to concede the potential for gesture space conflict and leave that to apps choosing to use it.

This had some other implications for Up navigation. While we were settling on using the upper left corner as a toggle with a different glyph for navigation drawers using DrawerLayout, SlidingPaneLayout was becoming a different story. SPL’s primary purpose was fitting a large-screen layout onto a smaller screen. You could build something equivalent using fragments and list/detail activities, SlidingPaneLayout was just meant to give that flow a more engaging interaction.

With that in mind there was only one answer. SlidingPaneLayout would use normal Up navigation as if it were conceptually two different activities in the navigation hierarchy. The Up button should travel up from the detail pane to the item list, opening the pane, but never the reverse.

Making it easier and more satisfying for developers to handle multiple screen sizes: accomplished. The same code can be used on any device and SlidingPaneLayout will automatically lock open when enough horizontal space is available to fit both panes side by side.

Tomorrow this series concludes with a flash of inspiration from the visual design team and a solution for drawer navigation at deep levels of an app.

#androiddev  
75
15
Akash Ramani's profile photoAdam Powell's profile photoMatthew Townsend's profile photoBenjamin Weiss's profile photo
6 comments
 
Hmm, i'm not sure if this is the right behaviour but the slidingpanelayout always has a little bit of the content pane overlapping the master pane, when the master pane is in an "opened" state. Is it me or is that unexpected behavior??
 
There's a minimum amount of the right pane that remains visible along the side.
 
Is there a reason for that? Is that configurable?
 
It helps hint that something is there when open and it's large enough to invite touching. It's not configurable for consistency across apps.
 
how to change set icon instead of navigation drawer open and close strings along with appIcon.
Add a comment...