From Drawer to Bottom Nav Bar
The Junk Drawer
Almost everyone has a junk drawer in their homes that contain all kinds of random things. The Grubhub and Seamless native apps also had a junk drawer, our navigation drawer. The apps originally used a navigation drawer, where diners could find their favorite restaurants and past orders, provide feedback, and other things. However, as we added new features to the apps, this became the default location for every feature, which made it hard for diners to find important features. Our junk drawer was getting full and we were running out of room to put new features.
Bottom Navigation
Ultimately, we decided to switch to bottom navigation. This would help us present more important information to diners front and center. To a diner, the most important destinations in the app are search results to find food, my account to access orders and account information, and the bag to place an order. With bottom navigation, we can provide easy access to each of these destinations without the clutter of the navigation drawer.
Adding bottom navigation was especially challenging to introduce to the Android apps, as bottom navigation is a new concept for Android. Android apps typically use navigation drawers, which are well supported by the Android Support Library. Material Design only added guidelines for bottom navigation in 2016 and the support library introduced the BottomNavigationView widget in API 25, but this view is severely limited and difficult to customize. One of the biggest limitations with the BottomNavigationView is the inability to set notification badges on individual bottom navigation tabs. Due to product requirements, we needed this functionality and were unable to use the BottomNavigationView.
On the other hand, Apple provides excellent support and documentation for bottom navigation as a navigation pattern for iOS with their Tab Bar guidelines in their Human Interface Guidelines. This resource in addition to the Material Design guidelines allowed us to explore and understand bottom navigation.
Thinking Ahead
We reviewed all the documentation for bottom navigation patterns, which raised a number of questions we needed to think through across product, design and engineering. They largely fell into two categories: UI interactions and in-app navigation.
UI Interactions
How does Bottom Navigation interact with other UI components?
We explored how the bottom navigation bar would interact with other components, such as ViewPagers, actions within the ActionBar, and in-app notifications, which could be a variety of dialogs, bottom sheets, and snackbars. Some of our key takeaways mirrored suggestions highlighted in Material Design guidelines, such as avoiding tabs with bottom navigation and respecting component elevation, so that notifications would not unexpectedly block the bottom navigation bar.
When do we show the bottom navigation bar?
We decided to hide the bottom navigation bar on screens with very specific actions (such as adding a menu item to the bag) to avoid overloading the user with too many actions.
In-App Navigation
How many navigation tabs should we have today? How many could we potentially have?
For our initial release, we decided to break the app down into three navigation tabs, which could potentially increase to four tabs as we add new functionality to the apps. In dividing the app into these navigation tabs, we took a close look at where each screen truly belongs.
How do we handle up versus back navigation?
Though this sounds inconsequential, it is actually important since there are restrictions with up and back navigation and inter-tab navigation. The largest restriction being that at no point in time should a user be able to navigate to a different bottom navigation tab unless they explicitly tap on it. This ultimately means that neither the up button in the app nor the hardware back button on devices could allow the user to jump navigation tabs. Each navigation tab would also be responsible in handling its own backstack in order to retain state.
How do we navigate to and from various screens?
It’s important to note that in addition to up and back navigation, no interactions in the app should transition you to a different bottom navigation tab. A good example of this is going to an empty bag screen that prompts the diner with a link to explore restaurants in your area. Presumably, this link would take the diner to the different navigation tab, which is unnecessary because the diner can easily navigate using the bottom navigation tabs themselves. Additionally, we no longer have to assume what screen is the most appropriate for the diner in the event of empty or error states.
How do we handle network requests across navigation tabs?
Additionally, the app could potentially handle network requests across navigation tabs. For example, we could start a request in one navigation tab, but a user could attempt to tap on a different navigation tab during the request. Ultimately, we came up with a few solutions to handle this situation appropriately on a case by case basis:
- We can block the user from navigating away from the screen for the duration of the request with an appropriate timeout.
- We can cancel the request once the user exits the screen.
- We can continue to execute the request and, in the event of a failure, fail silently to avoid any dialogs or popups on the UI.
Re-architecting the Android Apps
We needed to understand how all the various user flows in the app would change with the switch to bottom navigation. Originally, with the navigation drawer, the app followed a linear flow: diners would search for a restaurant, view a menu, add some items to their bag, and proceed to checkout. If they wanted to navigate to a different screen, they would have to go back to the search results to get to the navigation drawer.
However, with bottom navigation, diners now have multiple entry points to get to a restaurant menu using any of the bottom navigation tabs. For example, I could view a menu on the Restaurants tab and potentially view my account before adding items to my bag. Therefore, we had to ensure our individual views were modularized and not tightly coupled in order to enable this.
Throughout the process of modularizing our views, we had to determine when to use an Activity versus a Fragment. Due to the bottom navigation framework we use, the bottom navigation bar can only live inside one Activity and each navigation tab must be a Fragment. However, building the entire app as a single Activity with multiple Fragments is a nightmare. Therefore, any views that are imperative to the core user flow and navigation would be Fragments inside a single Activity. All other user flows that are independent and do not need access to the bottom navigation bar, such as settings, checkout flow, etc., can be encapsulated in their own Activities.
Repercussions and Testing
Re-architecting the apps also means we needed to do extensive testing. We currently test our apps using a combination of unit tests and automated end-to-end tests. In addition to these tests, we also launched bottom navigation as an A/B test to learn more directly from diners.
Since app navigation is such a core component, we essentially needed to refactor a large portion of our automated test suite. Also keep in mind that because we initially launched this change as an A/B experiment, we wanted our tests to support both navigation schemes. Despite this daunting effort, we took a closer look to better understand why our automated tests were so brittle when it came to navigation. We realized the best way forward was to create an abstraction layer for navigation throughout the app so that no specific automated test had knowledge of which navigation scheme was currently running on the app. Overall, this is also a more robust solution for handling navigation throughout the app for our automated tests as we were able to apply the same philosophy of modularizing specific navigation components in our testing codebase as we did in our navigation implementation in the apps.
The A/B test confirmed that bottom navigation would indeed be accepted by our diners. It also enlightened us to refinements that make the bottom navigation experience more seamless. For example, we found with our initial implementation of the bottom navigation bar that the color of the bar did not offer enough contrast and was not noticeable. With a few tweaks to the color and style, we were able to easily remedy that before going 100% live.
Final Thoughts
Although, this was a massive undertaking over several months, it ultimately improved the code quality of both our apps and test suites to be more adaptable. We were able to take away a lot from this process to be able to apply to future projects. We learned that by taking a step back during the planning phase and taking a look at the big picture, we were able to identify the correct problems to solve first that would help us achieve our goals on time.
Bottom navigation is currently live on both Grubhub and Seamless.
Do you want to learn more about opportunities with our team? Visit the Grubhub careers page.
