Edit: I posted an answer below containing various attempts based on the ideas provided here.

I am developing an application with a somewhat special main screen, from where the app is divided into two main parts. These parts are fairly independent and basically form a 50-50 relation of the content.

Now the thing is that besides the main content, I do have to bring in some very minor other screens, e.g. about page. I do not want to kind of "be forced" to use one of the common navigation patterns like a nav. drawer or a bottom tab bar just so I can display these minor pages.

So from my perspective, it would be cool to include those in a modal dialog that only comes up when needed:

Two screenshots showing original state and one with the dialog open

But the issue I'm concerned with here is that such bottom sheets seem to only be used for managing/editing actions, such as when selecting photos or files:

An example screenshot showing a bottom sheet in a file management app

The Material docs say

Modal bottom sheets are an alternative to inline menus or simple dialogs on mobile and provide room for additional items, longer descriptions, and iconography.

So it does not seem to be "against the rules", but maybe it is against user expectations?
What do you guys think, any better solutions to this?

  • the definition "some very minor other screens" sounds like links to those screens should be located only at the very bottom of home screen and should not be referenced in two main parts at all. Are "minor other screens" enough minor for that? :) – ADOConnection Jan 21 at 16:27
  • @ADOConnection Oh maybe I should clarify, the wireframe I have is the home screen. From there the user can press button 1 or 2 to navigate to the main content part 1 or 2. And that's basically all that 70-90% of the users need. These screens in the "more" section are basically very minor cases that people only need 5-10% of the time. That's why I do not see the importance of making them super prominent. People just have to know that they're there. – Big_Chair Jan 22 at 10:03
  • sorry, have read it wrong yesterday. The initial text is clear enough. So it is already decided that user can access those pags only from home screen. Can you please tell a little bit more about home screen: how "special" it is (like image rather than classic ui controls) and doest it have scroll? – ADOConnection Jan 22 at 10:28
  • @ADOConnection There really isn't much more to it, it is this screen and contains 2-3 buttons (the two on the image and one as a deep-dive shortcut into a frequently used functionality of content 1). And above that is a logo image. And the theme is rather dark, but that doesn't matter for the navigation logic. – Big_Chair Jan 22 at 10:45

Material design has a bottom navigation drawer:

Material design bottom sheet navigation drawer

I would combine this with a corner floating action button to reveal it:

Material design corner floating action button

| improve this answer | |
  • I saw the bottom drawer in the material guidelines, but missed the visual thingy with the corner, I like it! – Big_Chair Jan 21 at 15:50
  • 1
    Yeah I had trouble finding it again. Seems they are only used in the material studies (this is from the Owl study) and not actually mentioned in the guidelines anywhere. They come in handy for when you want to provide access to a UI component at all times but in the least intrusive way possible. – James Coyle Jan 21 at 15:53
  • 3
    this corner thing imo more sutable for primary action, like "Donate", but odd for "settings" or "about" – ADOConnection Jan 21 at 16:20
  • I completely disagree. Using this for a donation link would be terrible UX as it takes up screen space for a feature that doesn't directly benefit the user. It should only be used provide quick access to important app features. Moving the button to the corner demotes its significance with regards to the current page and makes it clearer to the user that it is part of the main app UI rather than the page content. I think it makes perfect sense to use for triggering app wide UI components such as a navigation menu, settings pane, or a shopping cart in apps where a full app bar is not needed. – James Coyle Jan 22 at 9:30
  • I evaluated different options based on your answer, see my answer below if you're interested :) – Big_Chair Jan 24 at 12:15

In terms of User expectations, when entering into and using any Android app Users will likely expect to be able to access important information quickly and easily.

It is unclear how Users will navigate between your two main pieces of content, but it seems that by pressing the More... button the Bottom Sheet will be displayed offering navigational menu items.

Generally and historically in Android, best-practices discourage the use of menu items for navigation, rather encouraging their use for actions. There has been plenty of divergence from that best-practice guideline - typically where you see one or a few navigational items intermixed with action items (e.g. an overflow menu item that navigates to an 'About' section). That said, I don't think there is anything alarming or surprising in your use of the Bottom Sheet for navigation, particularly since you hint that the use of each item pertains to navigation by including the "Go to..." text.

I do think that, in terms of your specific design, the use of a More... button to access navigation is misleading and strange. Typically that pattern suggests that there is more reading to be done regarding the main content in view, as per an article in a media app. Though, a User would quickly learn that this 'More...' actually leads to navigation options, so the ramifications of messing with User expectation isn't so bad in this scenario. While in Android the expected pattern to access more options is an overflow menu. But then you have a new problem: Point of opening bottom sheet when overflow menu was clicked?

An alternative approach would be to have the Bottom Sheet partially visible, replacing the More... button.

If you were to setup A/B testing around these approaches and generate some data, please feed that data back into this thread!

| improve this answer | |
  • "Though, a User would quickly learn that this 'More...' actually leads to navigation options" - I do not quite agree: If I use this particular app once a week, I might stumble across this unusual design every time I need to use it. – virtualnobi Jan 22 at 7:58
  • @virtualnobi that is true. Considering you quickly forget, then, each time you press it you will quickly learn that it doesn't do what you may have expected it to do. The danger is that Users may refrain from interacting with it purely because it suggests there is more of the mundane content presented on that screen. – straya Jan 23 at 0:44

So, drawing inspiration from James Coyle's and ADOConnection's ideas, I gave it multiple attempts and wanted to share my thoughts.

First, this is how I initially planned it:

Second, James' corner FAB. Not too sure about the color style yet, but since I wanted it to not be too prominent (since the options aren't that important) I couldn't use my accent color for the FAB as is usual. So I might just have to make it dark.

enter image description here

Third, ADOConnection's game inspired menu. I kinda went back and forth with this one, but it just didn't really feel good to me. The concept made sense in theory but it just wasn't good looking or "cool" for me.

enter image description here

But by stacking the icons on top of each other, I got the idea of using the FAB in a more traditional way. But I think this is the one that might go against the rules the most, as the revealed options here really have to be actions that you take, not navigation. So it looks cool but I don't feel comfortable using them.

All in all those are all interesting options. But I feel like the corner FAB in James' answer caught my attention the most.

| improve this answer | |
  • 1
    thanks for sharing result! Looking on these screens I would go with corner fab too, because it looks nice and 3 bottom classic icons looks odd when located near native Android navigation (good-to-remember for iphone users :) – ADOConnection Jan 24 at 16:31

From the info you provided I see correlation with mobile games UI:

  • custom-made home screen with few primary actions and some secondary actions
  • custom-made navigation

I think you can grab the same idea. Even if your UI is not that heavily drawn and does not look like cartoon frame, this pattern still applies and you dont need to use common navigation controls.

Here is worms 3 home screen: enter image description here enter image description here

enter image description here

| improve this answer | |
  • Good point! Maybe I don't need a whole different navigation concept if I only have 3 other points. I have enough space on the bottom to place 3 buttons. Hm, I will have to try your option vs. James' in Figma to see how they work in terms of look & feel. Thanks. – Big_Chair Jan 22 at 11:38
  • I evaluated different options based on your answer, see my answer below if you're interested :) – Big_Chair Jan 24 at 12:15

You could use an ellipse button like this:

enter image description here

It means the links are more contextual when placed with the second portion of content, if I understand the problem correctly anyway. It also acts as a secondary level CTA as you mentioned they are "less" important pages.

| improve this answer | |

I may have missed something, but if you’re thinking of using the space to pull up the sheet, why not just stick to the common navigation pattern that users are familiar with? If the main stage content of the app is sufficiently engaging, users won’t mind the presence of a UI element they have become accustomed to consuming precious pixels lol. Best of luck!

| improve this answer | |

I'm not sure why you would not want "to use one of the common navigation patterns" - users are familiar with them, they don't need to think about how they work, and they will feel in control of your app when the app behaves as the users expect them to do.

Would you buy a car where the car designer had decided she didn't want "to be forced to use one of the common [..] patterns" for, e.g., indicators or - Lord, behold - the brakes?

To deviate from the "common [..] patterns", you need very good reason, and a lot of user validation to make sure your invention is better than the existing ones.

| improve this answer | |
  • I absolutely agree with you in the context of general use cases. Please read my comment below my question, where I clarified some things. The main navi is already made "special", so to speak, as it is presented by simply two buttons. And since the other options in the "more" menu are not really that important, I do not desire to completely change the navigation structure for them. Because if I use a nav. drawer for example, I would have to put the main nav points in there as well. – Big_Chair Jan 22 at 10:06

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.