This is part 2 in a series. You can read part 1 here: https://plus.google.com/+AdamWPowell/posts/2zi4DXd3jkm

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. android.support.v4.widget.DrawerLayout 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.

#androiddev  
Shared publiclyView activity