Material Design Navigation Drawer III: Navigating
A series of articles digging on the Material Design Navigation Drawer.
Intro
It seems that the Navigation Drawer is here to stay. I like the pattern besides some criticism, so I decided to implement it on a couple of apps I'm working on. What you can read here are just my thoughts about what I found interesting about it, hoping to help and learn from others.
This is the last of 3 publications. Check out the two first here:
Inception
The drawer was always a hot topic. When the Material Design concepts started to appear, there was some confusion and even after the guidelines came out things weren't completely clear.
Nowadays you have awesome libraries out there and even the some Google code to take a look at… but if you are here is probably because you like coding for fun.
In this publication I’m gonna talk about how the drawer affects your app hierarchy, structure and navigation. I’m reflecting here just those points with something to point out from my point of view.
Navigation is the essential backbone of any well design experience. Is what makes everything make sense. It´s what gives people a sense of place and keep them grounded
- Matias Duarte at Google IO 2012 (Matias Duarte)
A well-structured app makes it easy and efficient to get things done
- Richard Fulcher at Google IO 2013
Navigation
One of the most important things to understand about the Navigation Drawer within its name: Navigation. Even if it has evolved and has more functionality over time, the main purpose and core functionality is Navigation.
The problem
Five years ago, a typical Android main menu looked very different than nowadays. It was called the Dashboard (aka six pack) and was an Android design pattern with its peak between 2010 and 2013.
In the next video you can see between 34:15 and 41:50 the Twitter app demo showcasing all the best in Android design patterns in mid 2010.
Even the best UI design patterns for Android in 2010 look confusing to navigate and difficult to understand from a nowadays average app expectations. The navigation was specially complicated to understand and was mixed between the dashboard, the menu button, contextual menus, split action bars…
As apps are evolving and growing in complexity, some design patterns appear and others are not relevant anymore. As the navigation patterns appear to solve existing problems, looks like they are always behind and never catching up with navigation problems.
In 2010 the dashboard and the action bar tried to give every android app a structure. In 2011 the up navigation was added to complement the back navigation, and tabs appeared as well as a new navigation pattern. In 2013 the app structure was a needed talk at Google IO because of the growing complexity of the apps, and was the first moment when the dashboard (aka six pack) started to be perceived as a problem instead of a solution. You had to navigate back and forth, you needed to have an entire screen for navigation purposes, was good only up to 6 options and it wasn’t a pleasant place to look at.
The Solution
Just after pointing out the problems of the dashboard, the Navigation Drawer was introduced officially at Google IO 2013. We had previously seen the pattern as a community driven design but Google embracing the pattern was a huge drive for it.
The Navigation Drawer appeared as a community driven pattern to solve structural and navigation problems. It provides hierarchy and structure, and helps to build mental model that helps users get things done.
The era of the Navigation Drawer started in 2013. In the previous 3 years, the dashboard, tabs, spinners, up affordance, back button, contextual menus, iOS ported bottom navigation bar and a lot of different solutions were trying to exceed its responsibilities and were sometimes acting like a main navigation menu. It’s not that the Navigation Drawer replaces all of them (it’s interesting to point out that actually only replaced the dashboard), is that it is a Navigation hub that allow other components stop pretending they can be it.
The biggest Nav Drawer’s win in 2013 was to allow other components stop pretending they could be a good navigation hub and start shining filling the gaps where Navigation Drawer couldn’t reach.
Hierarchy
One of the best things going from Dashboard to Navigation Drawer is the drawer doesn't take any space from the screen. It is planning the navigation hierarchy.
- Dashboard hierarchy:
- Nav Drawer hierarchy:
It’s important to note the second image shows a deeper hierarchy than the first one.
- The first scheme: Dashboard plus two deeper levels.
- The second scheme: Drawer (appears hidden on each of the three top levels and doesn’t take any screen) plus three deeper levels.
In other words, the B1/B2 level in the first scheme are the same than the Top Level in the second scheme.
The other quick win here is with the dashboard you have no fast way to go from B1 to B2. You have to go thru A. With the Nav Drawer you can go to any sibling Top Level screen really fast. Theoretically, you are not limited to the Top Level screens in the Drawer but any level or endpoint that makes sense to appear in there, but you should only do that for a good reason.
Mental model
One of the cool things about the Navigation Drawer is that it does not take any space on the screen. It is one swipe away but it does not interfere with our content. If the goal of the Nav Drawer is to provide us with easy and fast Navigation, probably some people are thinking about placing the Nav Drawer on every possible screen on the app.
The Navigation Drawer provides not only navigation affordances but an structure and hierarchy that help us to shape the user’s mental model
A mental model represents a person’s thought process for how an app works, helps users to understand how the app works, how it flows, knowing and understanding its boundaries, guides their attention and increases predictability. A good design is out of the way meaning users are driven unconsciously by visual clues, affordances, past experiences and expectations.
I've commented a couple of times before the Nav Drawer does not take any space on the screen. Almost. There is a clue telling users the Nav Drawer is there.
Those three lines have become more present over time, but the functionality is the same: It offers an affordance and visual clue.
It’s located in the same place where we usually find another navigation affordance: Up navigation.
As we learnt from Google Io 2012 talk, the up navigation is a really powerful and useful navigation pattern. It allows to go up in the hierarchy. Up and back can behave the same when the previous activity is as well the upper activity in the hierarchy, but understanding the difference is essential to a powerful in-app navigation.
Back is a system-wide navigation pattern controlled by the operative system. Up is app hierarchy navigation. Understanding the difference is essential to achieve a powerful navigation in complex applications
The top left corner affordances (the three lines and the back arrow) are sending messages to the user.
Nav drawer affordance:
- There is a Navigation Drawer
- The current screen has sibling screens
- You are in one of the top level screens in the app hierarchy
Up nav affordance:
- You can go to a parent/upper level from this screen
- You are not in the top level screen in the app hierarchy
- There’s not necessarily sibling screens and this might be an endpoint.
Is fast to know where I am and where I can go with just those two small details added to the user past experiences. They provide relevant navigation information and hierarchy context. Another subtle message is all elements that are reachable from the Nav Drawer lead to screens that offers the Drawer as well.
In most apps, the Nav Drawer should only be shown in the top level sibling screens, and the Drawer should only list those screens as navigation hubs.
Navigation is not easy
Event with Navigation Drawer, back and up affordances, tabs, spinners and contextual menus, providing an easy, intuitive and fast navigation can be difficult. Android applications are growing in complexity minute by minute, and navigation is becoming more difficult.
Having a bad navigation in 2010 was something to improve, having a bad navigation in 2015 can make an app unusable
Deep hierarchies
If you have a hierarchy of 3 levels and you are in the deeper level, to reach the Nav Drawer you have to tap 2 times in the up navigation.
Three or four levels or hierarchy is easy to achieve nowadays and you'll have to click 3 times in a row to reach the Nav Drawer. Remember that we are using up because is the most straightforward way of reaching the top level. Using back could lead us to much more longer paths.
So we do have a little problem when the hierarchy is deep: Nav Drawer reachability is difficult.
One possible solution here is the one Google is using in apps like Google Music, Play Store and others: Offering the Nav Drawer in intermediate levels as a power user feature.
It’s strange to see the up affordance and the Nav Drawer at the same time tho. You don't have a clue the Nav Drawer is there, but it’s there.
Circular/Infinite Navigation
Sometimes we can have circular navigation which is a problem because this makes the back button a really bad option for going back to the top levels. Think about circular navigation as not going exactly to the same place but the same category. Something like artist to artist to artist to artist. Or for example in a football app you can go from match to team, from team to match, from match to another team and so on.
Here is when up navigation makes a lot of sense. What I recommend to do here is the recommended use of back and up affordances. With back you can go all the way back through the circular navigation. With up you can break the circle and start going up. If the hierarchy is too deep just apply the rule mentioned previously. If you don't have a defined hierarchy try to apply the rule mentioned after this one.
Lack of hierarchy
Sometimes you can just have linear navigation that does not follow a top down hierarchy. In other words you can not identify the logical parent of an activity.
I'll recommend two options here:
- Point the up navigation to one of the top screens (recommended if the activity is deep in the hierarchy and it’s difficult to reach the drawer from there)
- Up behaves like back.
I do not recommend to hide the up navigation affordance for navigation consistency.
Now think that problems like deep hierarchies, lack of hierarchy and circular/infinite navigation can be mixed and can happen simultaneously and you'll see this is not a trivial problem.
Showing the Nav Drawer in all screens is an easy solution that might lead to greater problems. Think your navigation and measure the impact it has on user’s mental model
Criticism
I've said before one of the best things about the Nav Drawer is that it doesn't take any space on screen. If you are into UX design you've probably heard before if you can't see it, it doesn’t exist, or obvious always wins.
In other words, a lot of people advocate against the Nav Drawer saying it is not obvious and decrease the users engage.
You can read more on that here or here or here and so on.
Google was making some A/B testing on this with the Youtube app for a while before finally started to roll it out without the Nav Drawer on late July 2015.
The above image belongs to the tests Google made in early 2015. The below images are the interface Youtube for Android started to rolling out on late July 2015.
It looks to me that is a server side decision which interface to show because when I cleaned the app cache, the Nav Drawer was back.
Besides all the criticism I wouldn't say the Nav Drawer is near disappearing, and is a strong pattern in Material Design.
I would argue as well the idea that more time spent on the app is always better. I can see obvious cases where less time is better, but that’s a different discussion.
Summary
This third chapter on the Material Design Navigation Drawer is from my point of view the most important. A lot of misunderstandings about the history and purpose of the Navigation Drawer can lead to gross mistakes. Even if you have a perfectly sized and styled Nav Drawer, remember that the Nav Drawer is a tool and not an end.
Form follows function and it’s not different in the Drawer. Styling is important but navigation is the key and the most difficult point to get right.
Update — June 2015
In the Google IO 2015, Google released the Android Design Support Library. It’s the recommended and easy way to add a Nav Drawer to your apps.
In the Github project down below, there are two branches: with and without the Android Design Support Library. Check them out.
Resources
- Navigation Drawer pattern
- Material Design metrics and keylines
- Toolbar metrics
- Google IO 2010: Android UI design patterns
- Google IO 2011: Designing and Implementing Android UIs for Phones and Tablets
- Google IO 2012: Navigation in Android
- Google IO 2013: Structure in Android App Design
- Google IO 2013: Android Design for UI developers
- Obvious always win
- UX designers: Side drawer navigation could be costing you half your user engagement
- Kill the burger button
