Android UX - When to use navigation drawer

Question

A friend and I were discussing the use of navigation drawers in an app and had a disagreement about when there should be one.

Basically, my point was that if there is a back arrow in the toolbar, then you generally shouldn't have a navigation drawer in that view. My reasoning is that you introduce unintentional paths of navigation, and it can lead to unexpected back behavior. For instance, if I went from:

Home -> Settings -> "Some main view"

If the user now hits back, they could have 1 of 2 expectations:

1. Go back to Settings
2. Go back to the home view

which I think is incorrect. If the navigation drawer isn't present in the Settings, then you don't run into this issue because the navigation path is much clearer because they would first go back on the Settings page, and then go to "Some main view".

However, my friend's point was that the user should have the freedom to choose where they want to go from wherever.

Just wanted to get some more thoughts on the matter.

Answer 1

Sounds like a good discussion, but if you really look into this the question would be looking at the design choices: Going native or designing for all devices. The arrow navigation you describe is typically something you would see for iOS, since they don't have the option buttons on the bottom of the screen like Android devices have:

With these buttons a user is always able to navigate back the the screen he/she came from, where iOS users really rely on the toolbar back button.

Of course Android has back buttons as well in the toolbar, check for example the Gmail App below. Clicking on a email will change the "Hamburger icon" to an "Arrow" icon, but still keeping the possibility to access the "Navigation drawer when swiping from the left edge of the screen to the right.

So my answer would to to incorporate BOTH methods if you are designing purely for Android. Looking at iOS, leave the drawer out as they are unfamiliar with this, see for example the iOS Human Interface guidelines on how the native navigation is described (Can't include them, link restriction.. :-/ But Google is your friend)

Hope this makes any sense, good luck with the discussion!

Answer 2

Great question, Adam!

No, it is not necessary to have a Back button in the Toolbar if you have a Navigation bar in the Activity.

A rule of thumb to follow is that you can substitute Tabs instead of Navigation Drawer if the tabs are limited i.e. 3-4 or else have scrollable tabs.

Considering the fact that you are in the Secondary Activity of an App, it need not have a lot of navigation going on in it. So, in most cases you could find a work around with tabs.

Here are two Twitter examples of Secondary page activities along with a Back button with Tabs.

However, there can be complex hierarchy present in your application due to which you might require a Navigation Drawer.

So, I looked into the Settings app of Android N Developer Preview 3.

The way settings has been implemented here is quite interesting.

Since the Settings app consists of a lot of settings and each having various options. It can get a little overwhelming. So, vividly, Google has basically given the app no Navigation bar in its primary activity. But, instead of a Back button like on Settings in Marshmallow, it made it simpler to navigate by replacing it with a Hamburger Menu/ Navigation Drawer.

As far as your question goes, since in Material Design, the Navigation bar is above the Toolbar, it is sensible to not have a Back button in the Toolbar itself because the Hardware button does the same job, and it'll be covered by the drawer anyway otherwise.

Answer 3

It mostly depends on how many secondary screens the user can access from your main menu. If the user can access to 4 or more screens from it (and take into account that the access to the settings screen should be into the overflow menu in the action bar OR in the navigation drawer, so don't count it by now) go with the navigation drawer. If the accesses to the screens should be grouped in some way to clarify the navigation, go with the navigation drawer. In other case (3 or less screens from the main screen) go with a tabbed navigation, which is more agile and clear.

About the back navigation, make it easy, go with the default behavior: https://developer.android.com/training/implementing-navigation/temporal.html

When the user clicks back, you should show him the last fragment he was in. Going to the main screen should be the UP navigation: https://developer.android.com/training/implementing-navigation/ancestral.html