7

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.

  • but back button means going back to previous page, why would user expect back to take him/her multi-step back? – gurvinder372 Jan 6 '16 at 11:11
  • There is a post that provides additional inputs on this topic ux.stackexchange.com/questions/74934/… – Vjay Jan 6 '16 at 15:00
  • Brand, spanking, new article from Jan 4, 2016: usabilitygeek.com/making-case-for-desktop-hamburger-menu – user77806 Jan 6 '16 at 15:56
  • had the same discussion with my colleague a while back. I agreed with you for our particular scenario. depends on your nav structure, going into settings or similar page only offering a back button meant later down the line if they used the back button they wouldn't get to that settings page in the stack. – Dave Haigh Feb 5 '16 at 16:38
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:

Android Navigation

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.

Gmail app example of navigation

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!

  • In iOS you could swipe right on the screen and you will go back the previous screen, you get the same effect as you tap in hardware back button in Android phones. – steppenwolf Dec 7 '15 at 10:05
0

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.

Twitter Screenshot enter image description here

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.

Android N Settings

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.

material design 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.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.