Bottom Navigation on Android — FAQs & suggested practices
It’s only been a few hours since Google updated the Material Design spec and finally made the bottom navigation tabs an official thing. Bottom tabs are understandably controversial: Android design always recommended having tabs at the top of the screen, and usage of tabs at the bottom was looked at as lazy mimicking of iOS design. Yet Google themselves began using the pattern last year with Google+, and then followed it up with Google Photos earlier this year.
I wasn’t a fan of bottom navigation tabs for the longest time. Yet having used Photos regularly over the past few weeks, and having read the documentation thoroughly, I can see some of the reasoning behind it. I’ve had the opportunity to discuss the pattern in a few groups already, and wanted to share answers to some of the key questions being asked.
What is the purpose for bottom navigation?
For the past 18–24 months, the most commonly used pattern for key navigation was to place items in a drawer. The drawer’s popularity on mobile is understandable: limited screen real estate made it difficult to show all the navigation options inside a complex application, but the tradeoff was the lack of visibility of key navigation elements.
This led to the rise in usage of tabs, with most apps going for tabs on the top. The problem with tabs on the top of the screen, however, is they need to be “swipeable”, which comes with a performance hit. The experience isn’t quite right as well if the content in different pages of the tabs don’t feel like a continuation of each other.
For example, tabs on the top work really well in a music app where each tabs allows you to see the same (or similar) content organised either by playlists, or artists, or albums, etc. They don’t work well, however, if one tab shows you a map view, another a feed, and third some different collection.
The alternative is not to allow tabs on the top to swipe, but that creates a problem for users who may not be able to reach there. They also struggle to then understand the swipe pattern itself and are left frustrated when a collection of tabs they expect to swipe can’t be swiped.
When should I and when should I not use bottom navigation?
You should use the bottom navigation only if you have between 3 and 5 key top level views. As mentioned in the previous section, these elements contain content that aren’t directly related to each other and hence swiping between tabs doesn’t fit in well. These views also need to be accessible from most screens in your app, and hence are very much a means to bring your key navigation out of the drawer.
Bottom navigation is only meant for mobile experiences. Larger displays should look at using side navigation instead. Do not use bottom navigation if you have more than 5 views, and do not make the navigation elements scrollable.
Some recommendations on usage
Firstly, I highly advise against using bottom navigation in conjunction with tabs on the top of the screen. Overloading the screen with navigation options can lead to significant confusion for the user.
Secondly, if you are using a Floating Action Button towards the bottom of your screen, understand that the presence of the bottom navigation could hamper it’s prominence, and hence performance. The purpose of the Floating Action Button is to promote your key action, and the button would now only be 16dp away from a prominent navigational element.
You can leave the FAB where it is if you are OK with it (such as Google Photos). You could also remove the FAB and replace it with a Toolbar menu option, but that’s admitting defeat and removing all prominence. Alternatively, if you really need the FAB to maintain higher prominence, consider moving the FAB to partially overlay the Toolbar on the top of your screen, where the contrast of the accent color against your primary color might draw attention.
Thirdly, with a Z-index of 8dp, the bottom navigation drawer is going to be above the Floating Action Button and the Snackbar. This also means that the snacker, when shown, needs to come above the bottom navigation. The Floating Action Button, if present, will move up to make space as before. This is understandable when you consider that the bottom navigation must stay in place, and that the snackbar is related to the content of the active view itself.
Lastly, use the pattern only if it makes sense for your experience. Do not use the excuse of having a new pattern for navigating between multiple key top level views as a reason to have multiple key top level views: the user is going to continue to spend time on only one of them. Any addition of navigational options brings a bit of confusion, and the removal brings a sense of great simplicity that the users enjoy.
As an example, since about last April, we had multiple tabs in the Haptik Android app. We believed offering these additional views (inbox, tasks and profile) would benefit the user. When we were rethinking our product for 3.x, which launched in August 2015, one of our key focus was to fix issues that the users had with regards to navigation. The simplicity of just an inbox worked tremendously well for them, and we instead chose to make changes in behavior of existing elements inside the conversation view to more than make up for the loss in prominence of tasks.
I highly recommend reading the guidelines with the dos and don’ts as a follow up to this post.