Note (added 2016-03-21): The original post has been updated with clarifications in the intro and a link about accidental touches.
A little while back, Google updated their design guidelines to include tabs as an option at the bottom of an app on a mobile device. They refer to this as bottom navigation, citing a few times when you might consider this pattern. Given that Android already has a pattern of displaying tabs at the top of the app, two obvious reasons to shift those to the bottom stand out:
- The bottom of the screen is often easier to reach on a large phone.
- Putting tabs at the bottom gives the design visual balance.
Google seems to consider this a supplement to the navigation drawer as opposed to a change to traditional tabs, which is probably the reason they’re calling this bottom navigation. Of course, the average user will see this as tabs.
A lot of the cries against bottom tabs come from people who have associated that navigation pattern with iOS, but we shouldn’t disregard a pattern just because it comes from iOS. In fact, being able to create consistency across operating systems when it makes sense is a good thing; however, analyzing this pattern reveals several problems.
We generally examine content from top to bottom when specific triggers don’t interfere. That means the bottom navigation is the last thing the user will see, but that assumes they even scan that far down. I’ve lost track of how many times I’ve seen an Excel spreadsheet that included three sheets, only one of which was used. That happens because the navigation among sheets is at the bottom (and poorly designed), so users often never look that far down. They begin filling out content from the top, so there isn’t a natural reason to explore the rest of the UI. Including a default of three sheets when creating a new app was probably to highlight the fact that you can have multiple sheets but a better solution would have been to improve the UI and include the sheet navigation above.
Worse, the bottom of apps has often been used for advertisements, which means many users will have built up the natural ability to ignore content at the bottom of an app.
##Excessive Work for Grounding##
Even once users have learned to look at the bottom for navigation, there is another problem. Whenever you return to an app, your eyes look for quick indicators as to where you are in that app. Prior to the bottom navigation pattern, your means of doing this in Android was very simple: You start at the app bar and look down from there. This linear path for your eyes is very quick and even scales with content subsections. With bottom tabs, your eyes have to jump from the top of the screen to the bottom back up to nearly the top and then scan downward. It might not seem like much, but eliminating these types of extra work is a big part of good UX.
By promoting bottom navigation, the Material Design guidelines are giving weight to the option of putting tabs at the bottom. That means more apps are going to do this and you’ll have a mix of apps that have tabs at the bottom and apps with tabs at the top. This is exactly the kind of inconsistency the design guidelines should be fighting against.
Another consideration is how this affects tablets. If the navigation stays at the bottom on tablets, that’s a substantial amount of screen space the eye has to travel. If they stay at the top, additional inconsistency shows up in the app between devices.
##Maximizing Content Visibility##
When you have bottom navigation, scrolling the navigation out of view becomes awkward. If tabs are at the top, they can scroll up and off the screen while the user scrolls down. If tabs are on the bottom, they’d have to scroll down to hide themselves, which would be inconsistent with the rest of the app (Google+ does this). You can get around this by choosing another transition, such as fading out, but that causes new problems. The user has to associate meaning with an unexpected transition and it isn’t obvious how to make the tabs reappear.
I think users can adjust fairly quickly to the awkwardness of bottom tabs scrolling in the opposite direction of everything else, but you also lose the ability of minimizing the system navigation by allowing it to overlay the content.
Any time you have elements near each other, you have to consider how that effects the UX. For instance, if you have a rename option and a delete option directly touching, you substantially increase the chance that users will accidentally delete content that was so important they wanted to give it a more meaningful name (another good reason for the undo pattern). With tabs at the bottom, you now have app-specific navigation touching the system-level navigation. That means a slip of the finger can easily cause the user to press the back button when trying to change tabs.
Note (added 2016-03-21): Ian Lake (an Android Developer Advocate at Google) kindly pointed out a tweet from Mike Denny (a designer at Google) that says user testing didn’t show any issue with accidental taps.
##My Own Experience##
Interestingly enough, I didn’t consciously realize that the Photos app had bottom navigation until I started to write this article. This is an app I use daily, so I’ve certainly used it several times with the bottom navigation in place, but my brain simply didn’t process it being there. I noticed something was there because the floating action button had moved up, but I scan content at the top of the app while my thumb covers a portion of the bottom to scroll. I rarely look at the bottom portion of an app, which is one of the reasons I think using vibrant colors for the floating action button was a good idea.
An additional curiosity is that Google+ has had bottom navigation for quite a while now, but I couldn’t even tell you what the tabs are without opening the app. I’m not sure if that’s because the other tabs are less important than the main one or if it’s because of the positioning of the tabs, which causes me to never look at them, but that seems like an issue.
Bottom navigation for an app essentially makes it more convenient to touch at the expense of the above issues. One of the ways top navigation got around the reach problem was with the ability to swipe across the content to change tabs; although that solution wasn’t ideal, it helped mitigate the problem. Ultimately, I think putting app tabs at the bottom is not a great solution.
To comment on this issue, please see the Google+ post.