Bottom nav bars. Between the time of Gingerbread and Marshmallow, they seemed to become significantly less prevalent on Android (or maybe I was just able to avoid more of them), with many developers and designers going for other navigation models. But those other nav models - specifically the hamburger menu - aren't always ideal. Often, teams worry that items in the drawer are "hidden" from users. Sometimes immediate visibility and total obscurity seem like the only two realistic options.
To be fair, it's true that ensuring users see these options each and every time they open the app tends to increase usage. And while the situation isn't so dire, it makes sense to have official guidance on popular navigation patterns.
So in March of 2016, Google added bottom navigation to the material design guidelines, providing guidance for a pattern that had already seen success on iOS. The guidelines thoughtfully lay out when and how to use bottom navigation bars, with the great animations and spec examples we've come to expect. The bars laid out here fit snugly inside material design - the spec makes clear where the bar lives in an app's stack of paper, how the bar can animate, how it can move on or off canvas sensibly, and typography and iconography are well defined.
from the material design spec
Even given this thoughtful approach, though, it seems too tempting to simply acknowledge that bottom bars are a thing on Android and directly bring over the bar a product uses on iOS. In this post I want to lay out - again - why being aware of and sensitive to Android as a platform is both necessary and beneficial, specifically in the context of bottom navigation.
But first, a few thoughts about bottom navigation in general.
The usage Google offers in the material spec is generally good guidance for bottom navigation. The bar is meant for an app that has 3 to 5 top level destinations. Specifically, 3 to 5 top level destinations that must be immediately accessible from one another. Narrowing it down further, these destinations should be of equal importance.
If you draw out all the screens in a given app and arrange them in a hierarchy, the screens represented in the bottom nav bar should be the ones at the top, from which the most important user flows originate.
For simple apps, the bottom nav bar can be a big help, keeping destinations out of the toolbar or eliminating the need for some other UI components altogether, resulting in an even more svelte UI. More complex apps can get confusing fast, but it doesn't have to be this way.
The Google+ app, for example, does a decent job of mixing three navigation components - the hamburger menu, the bottom nav bar, and tabs - into one app, and if we consider all the features these represent hierarchically, the organization seems to make sense for Google+'s goals (ignoring for a moment the app links inside the hamburger menu).
What it's not for
The list of things bottom navigation is not for is obviously longer. In the interest of brevity, we'll stick to just a couple of salient examples.
The bottom nav bar is not for FOMO (fear of missing out). In other words, the bottom nav bar is not a catch-all solution for making sure users don't miss out on something. Call me optimistic, but I believe it's completely possible to craft a flow that leads users to organic discovery of important features, and this kind of discovery can even be helpful to the user's overall experience.
It is tempting to add destinations of lesser importance to the bottom nav bar because there are one or two empty slots you could fill up. After all, you want that feature to be immediately visible so people will use and love it. But this temptation should be avoided.
This isn't to say that the bottom nav bar design pattern can't serve your business goals. But there is (always) a balance between what's best for the user and what's best for what you're measuring. In my initial post about the addition of a bottom bar to Google+, I noted that the new design seemed largely outcome- or product-centered, treading over much of the experience in favor of the Communities and Collections features. Major facets of the interface (particularly search) were overtaken in favor of promoting the two features. The interface and experience were off-balance in favor of the product.
The app has been further refined since then, but Communities and Collections are still keeping the bottom nav bar alive in Google+. As I said in the post there's no way to know for sure, from the outside, whether those two destinations are equally important to the home stream from the user perspective, but the app is a good example of how the balance can shift with help from a bottom nav bar.
The bottom nav bar is also not for menus - occasionally, we see a bottom nav bar on Android with a "more" tab, a pattern carried over from some iOS implementations that puts other in-app destinations into what basically amounts to a full-canvas overflow menu. This itself doesn't count as a top level destination in the app, since it's not a destination at all. It's a list of secondary destinations. Similarly, the bottom nav bar is not for popups or popovers. A dialog, spinner, or popover menu is also not a top level destination. Popover menus suffer their own misuses even in more appropriate contexts, but that's a story for another day.
Bottom nav is not for lower-level destinations. In a recent update (the update that finally pushed me to publish this post), TripIt migrated its navigation to a bottom bar that not only includes a "more" page, but a "pro" page - a list - that has essentially two items that are actually useful out of the box - point tracker and seat tracker. The next two items are meant to onboard pro users into new programs with a $25 credit or a free trial, and the rest of the screen - five more items and a subhead - is occupied by a list of features. If you tap a feature you're taken to a static page explaining the feature, with maybe a link to the app's settings screen. This is not a top level destination. I hesitate to call it a destination at all, save for those first two items. It may serve business goals, but the first two items make sense embedded in more appropriate contexts, and the rest of the list could be a single screen branched out from settings.
Following the guidelines
This is something I've said more than a few times at this point, but there are considerable reasons to be interested in following the guidelines and patterns organic to the platform you're building or designing for.
Building for Android, iOS, Windows, Mac, or any other platform means being part of that platform, even if your contributions stop after publishing an app. This means a few things. First, it means a responsibility not to have a negative impact on the platform. When apps conform to the expectations of the platform, users build up confidence in that platform's interfaces. If a user has experience with standard, functional tabs in one app, they will expect the tabs in other apps to behave similarly.
Breaking a user expectation, especially with an element as crucial as the navigation components in your app, can be extremely off-putting to a user, and their negative experience will likely be directed at the platform as a whole, and at your product specifically, when that unexpected implementation leads to confusion or frustration.
But user expectations can be beneficial to a product, too. If your app's components conform to what users (really) expect, while finding organic and friendly ways to innovate on those patterns, the user will have a good experience, and that good feeling will likewise be directed at your product. The confidence the user has built up throughout the platform will automatically help them "know" your app faster, and that leads to users accomplishing more of their goals and yours.
Finally, the guidelines aren't prescriptive enough to excuse ignoring them. The material design spec sets out guidelines and best practices for common elements, interactions, and components that will help you fit in with the platform, but keeping the guiding principles in mind and staying mindful of the platform, there's plenty of room to explore and innovate.
In other words...
Essentially, all of this is to say that iOS (or other) implementations don't always work on Android. Bringing an app to a new platform is a process that requires new research and new design. Bottom nav bars have official guidance in the material spec, but this doesn't indicate that bringing an exact copy of a bottom nav bar from iOS is a good idea for the user, for the product, or for the people building it.
Ultimately the material guidelines, platform participation, and user expectations are important, and it's our job as designers and developers to determine what things we can push - and how far - to create a great experience for our Android users.