Is a bottom sheet dialog "unfitting" for navigation?

Question

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:

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:

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?

Answer 1

Material design has a bottom navigation drawer:

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

Answer 2

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!

Answer 3

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.

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.

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.

Answer 4

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:

Answer 5

You could use an ellipse button like this:

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.

Answer 6

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!

Answer 7

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.