Shared publicly  - 
This is part 2 in a series. You can read part 1 here:

One of the first decisions we made around navigation drawers was to leave the action bar fixed and we published this stipulation in the Design Guide very early. This was for a couple of reasons.

First, the action bar is part of what we call the window decor. A window’s decor is extra decoration around the window’s primary content that is owned and controlled by the framework. Nothing actually guarantees than an app can walk up the view hierarchy and see something consistent from version to version or that inserting a new, arbitrary parent view above the action bar in order to move it and the rest of the content around is going to actually work without crashing on later platform versions.

Second, the action bar forms an important structural anchor for the activity. It’s always contextually relevant and provides a well-known place for navigation and actions. Making it inaccessible when a navigation drawer is open would be counterproductive in many situations and make the drawer feel more modal than it needs to. Apps that do this often end up creating secondary bars for actions within their drawers to compensate.

We always prefer direct manipulation when it comes to touch. If the main window content moves to reveal a drawer the user should always be able to grab it and drag it to one side to make the drawer visible. In the general case this has issues with the window’s gesture space.

A navigation drawer that is revealed by swiping the main activity content to one side means the horizontal swipe gesture space is now occupied. In effect, a navigation drawer in this style would mean you couldn’t have ViewPagers, swipe to dismiss, MapViews, WebViews, etc. in the main content without a conflict. That’s awfully limiting for a major UI pattern.

An overlay drawer with an edge swipe solved many of our requirements all at once. It retains direct manipulation and feels particularly nice on Nexus 4’s curved glass edges. It keeps the gesture space open over the main window content. It can be implemented as a simple ViewGroup that you can drop in at the top level of your layout with one view becoming the drawer itself. was born and met our goals of consistency, suitability across diverse apps and ease of development.

The next issue to tackle was discoverability. Thanks to work already done by the developer community users were already accustomed to reading a three horizontal line icon at the left side of the action bar as a menu/drawer button. (During user testing one user referred to it as “the hamburger” and the name stuck.) We knew this approach was a sure thing for discoverability but it didn’t quite sit right. Replacing the app icon meant potentially losing a big part of the app’s identity.

Tomorrow we’ll look further into our efforts to make sure the drawer didn’t become a Menu button by another name: a dumping ground for app navigation that users had trouble remembering was even there.

Qualcomm Developer Network's profile photoTim Russell's profile photoIvan Tarasovych's profile photoChristine Daunique's profile photo
Can you expand on the decisions surrounding the Contextual Action Bar's interaction with the Navigation Drawer? While the hiding/re-displaying makes sense for a developer controlled CAB, system controlled CABs (like text selection) don't know anything about the drawer being open or closed and hence stay open (not to mention the text selector drag handles gets drawn on top of the drawer even if the text is behind the drawer).
+Ian Lake At the moment they don't interact. There will likely be more handling around this down the road.
+Jim Avila It reflects the action that will be taken when you click it. When the drawer is currently closed it will be opened, when it is opened it will be closed.
I noticed the following behaviour when a drawer is opened. Is it by design, or should it be reported as bugs?

1. focus can still go through the content view when navigating with the dpad or explore by touch. I have had to subclass and override addFocusables and onRequestFocusInDescendants to scope focus only to opened folders, as well as make sure to transfer the focus from the content to the drawer when opening, and back to the content when closing.

2. similarly, it seems that dispatchPopulateAccessibilityEvent should ignore the content view when a drawer is opened.

3. if a drawer has an area that does not capture clicks (for example a header that is just a plain textview), the click goes through to the content view behind the drawer. I have had to add a OnTouchListener to my drawer (a LinearLayout) that captures all onTouch events.
+Nicolas Pombourcq  1 and 2 may already be fixed for the next release of the support lib if I recall but please keep an eye out for any repro cases after that.

3 is a matter of some contention. Strictly speaking it's following the usual rules of touch interaction and dispatch. Normally the drawer view is a ListView which will always consume the touch events anyway, but there are always other cases that arise. If there's a lot of feedback that this is causing issues we may have DrawerLayout eat those on the app's behalf.
The drawer is revealed when performing an edge swipe.
Is it perfectly fine to use a ViewPager for the main content, when also using the edge swipe to reveal the drawer? Since both are horizontal swipes, could this lead to confusion?
+Christian Göllner Yes, though I would avoid nesting any deeper than that if you can help it. (ViewPager will also accept edge swipes if the content of a single page scrolls horizontally.)

The overlay drawer style helps with this by maintaining more stable spatial relationships between the drawer and pages of the ViewPager - the drawer is always on top with the pager's content sliding below.
+Adam Powell thanks, got it :)

By the way, is there some guideline or standard regarding screen sizes and the switch from navigation drawer to multi-pane layout (Like the YouTube  app does)?
More to come on that in a later post. :)
They're SUBscribing to the thread. By adding a comment they're causing G+ to send them notifications when other new comments are added. Effective, but if too many people do the same it can get spammy. :)
Add a comment...