9

We want to have users navigate our app using a side menu.

Once a user leaves main app pages, the menu button (in top left corner of nav) would change to a back button.

However, the content of our app is prolific enough that I think we also need a constantly present menu button in top nav to get back home, or to a main page. Users could end up tapping "back" forever without a global menu button. But we definitely need a back button as well.

Can anyone think of a viable solution? Has anyone seen alternative nav options, possibly like this:enter image description here

Thank you for any help you might have!

Improve this question
2
  • 1
    Personally I would put the back button at the farthest to the left as possible, meaning switch it and the menu button. Right now it looks a lot more like it's pointing at the menu button instead of "back".
    – Andrew Gies
    Commented Jan 20, 2014 at 21:44
  • 1
    By the way if any of these answers were helpful, it would be really nice if you could choose one as the best answer.
    – VAlexander
    Commented Feb 17, 2014 at 23:14

4 Answers 4

Reset to default
2

The "back" next to the "menu" button is not the most conventional approach to this. I have however, seen the search next to other actions such as the compose in which Twitter implements, but nothing ever next to the primary menu action.

An approach could be to use a secondary navigation underneath the nav bar that allows the user to swipe through secondary screens. This still allows you to access the menu from anywhere in the app, unless there is an action that requires a push segue/modal in the content, in which that would usually require a close or back button. There's no issue with that approach given that user's usually will expect that. enter image description here

Improve this answer
4
  • This solution assumes a linear navigation pattern (where each screen has unique before and after). But it wouldn't work for hierarchical navigation, where users have to choose where to go to from a multitude of options (which I believe is the case in the question).
    – Izhaki
    Commented Jan 21, 2014 at 0:39
  • Given the limited vertical space on some mobile devices, e.g iPhone 3-4, I don't think it's practical to implement secondary navigation. And I agree with @Izhaki that it will actually confuse the users when you give them too many options to choose from.
    – donysukardi
    Commented Jan 21, 2014 at 1:46
  • @donysukardi That's assuming that there is a substantial amount of content that would require the user to scroll. It's also another assumption (in terms of this layout) that users will be confused when they are given too many options. I understand in regards to Hicks law that when given too many options they would likely not choose anything at all, but I don't think that three nav items is confusing. This app does this pattern well with a substantial amount of content : itunes.apple.com/us/app/city-guides-by-national-geographic/…
    – jnmnrd
    Commented Jan 21, 2014 at 2:15
  • 1
    Secondary navigation isn't a huge problem since you can hide it as a user scrolls down if warranted by content length (ie instagram). This does not solve my problem however because my content is not linear as lzhaki stated. The content is very interconnected and needs back functionality as well as a menu of "home pages" (kind of like facebook).
    – emily
    Commented Jan 21, 2014 at 4:17
1

The (Hamburger) menu in question supports back navigation to the hub in the hub-and-spokes navigation pattern:

An illustration showing the hub and spokes pattern

Unlike back buttons (which simply take you to the previous level), it has the useful feature of allowing users to not make a menu selection and return to the screen they came from (where they click on the menu icon).

Consider the following:

  • What you are proposing is really a home button; it does not follow the convention of the hamburger button.
  • If presented on each screen, its function may be confusing - some users may assume the button will show the previous level options, not those of the hub.
  • Some screens (like functional ones) may require a simple save or cancel options only (modal/dead-end/toilet screen - once you enter it, you have to go back to where you came from). In other words, in some applications you want to disallow users returning home.
  • You are curing symptoms rather then treating the root of the problem, which is that you have a hierarchy too deep in your application. Just think of Spotify, where currently you can go down the hierarchy many levels (6 if I'm not mistaken) and then have to press the back button these many times. Whereas Apple, to combat such deep hierarchy, instead of showing a navigation screen with all artist's albums, put all albums and songs on the same screen and rely on scroll instead of depth navigation.

All of this is to argue that such a proposal is not ideal.

Improve this answer
1
  • Thanks for the feedback! I actually was proposing a conventional hamburger button. The structure of our app is like your diagram above except each end hub connects to the other end hubs. In order to cure the problem of this hierarchy, I do need a solution similar to Apple's. Itunes relies on the bottom navigation tabs to help a user get back to a basic level. I would prefer having these tabs within a side menu to conserve real estate. But if the idea of two buttons (a back button and hamburger button) in the top left nav is too obscure, my only other solution will be a bottom nav.
    – emily
    Commented Jan 21, 2014 at 4:11
1

Although the other answers are different ways to combat the problem, they might not be the best. Due to screen real estate, implementing a secondary navigation bar would actually hurt the user experience.

Have you considered the reasons why you want a side menu over any other type of menu, the reason I ask this is because, it might be much more useful and simple if you had a drop down menu similar to that of vine. What you could do is display a small arrow next to the title label and when a user taps it the arrow rotates down, and a menu slides down beneath the navigation bar. Here are two great third party libraries that can help you get started:

1) https://www.cocoacontrols.com/controls/navigation-menu

2) https://github.com/romaonthego/REMenu

However if you really need a side menu, I'd like to recommend using gestures. If the user wants to access the menu they can do a long hold / press gesture anywhere on the navigation bar and slide to the right revealing the side menu. You can explain this when they first download the app.

Improve this answer
0

What I don't like about the first image is that the back button is next to the menu button. I could see users accidentally hitting the menu button when they meant to hit back or vice versa.

What about moving your search inside the side menu and moving your back button the right side of the top navigation bar?

Menu

This is a similar approach to what I see with the Facebook application: Facebook

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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