Material Design & Your Android App Navigation Strategy

In April the design team over at Google released some updates to their Material design specifications. One in particular that really got me thinking was the new App Structure section located under Patterns. Prior to the launch of the World Surf League app, this section did not exist. Based on the number of views and a number of more complex data views (e.g. athlete rankings by gender, tour and year), we implemented the Navigation Drawer. With this new documentation out in the wild I wanted to revisit the choices we made when we were designing the Android app and see if were completely off base with our decision.

Courtesy of Google’s Material Design specification, a phone Tab Bar, closed side nav and open side nav.

Structuring the Views

Our primary goal was to ensure instant discoverability of World Championship Tour live broadcasts and keep fans continually engaged with the video (more on how we did that another time). Fans should expect that when they open the app, they’re one tap away from initiating the live video feed and getting an overview of the current heat scores. During the times when live event broadcasts were not occurring, we also needed to offer users an experience where they could:

1. Discover live broadcasts on demand videos, articles and galleries (Home)
2. Check rankings for their favorite athletes (Rankings)
3. Keep track of the event schedule (Events)
4. Play Fantasy Surfing (Fantasy Surfing)
5. Check out their bookmarked content (Bookmarks)
6. View their personalized World Surf League Feed (by following athletes) (My WSL)

This list obviously became the primary navigation structure for the app.

Choosing a Top Level Navigation Strategy

In the updated Google documentation, they offer three different strategies for you to consider when designing your app.

1. Embedded Navigation
2. Tabs
3. Side bar with navigation drawer

We never considered a single view with embedded navigation. It made sense to avoid selecting a nav strategy that did not prominently display the latest content front and center. It was also expected that fans would be frequently visiting sections and traveling quite deep into scoring and results data. Fans would need an efficient way to pivot between the different views

Considering we were going to use a Tab Bar UI Controller for the iOS version of the app, we discussed heading in a similar direction for the Android version of the app.

“Three to four horizontal tabs are the recommended maximum, using short strings, to avoid scrolling on smaller devices.”

We ultimately steered away from that choice originally, but I wanted to take a moment to consider the above statement. Specifically avoiding scrolling on smaller devices. A Tab bar works great on an iPhone because we’ve only got 3 screen sizes to deal with and a rigid structure of an icon and label (or no label if you’re icons are clear as day) and within easy thumb tapping distance.

Android we’ve got a hell of a lot more screen sizes to handle (check out this article on Business Insider). Sure, trying to mimic a 5 item on Tab Bar on Android could be done, however it would either need to scroll horizontally or take the overflow route that the NFL and Facebook use (an iOS convention that I’m not entirely convinced belongs on Android).

The Navigation Drawer

Which brings us to the Navigation Drawer (or side nav). Some argue that going the way of the “Hamburger” makes things less obvious. In some cases (mostly on iOS) I would agree, however when designing for Android the following factors should be considered.

The side nav is a prominent piece of UI featured in nearly all of Google’s Core Applications. It is also recommended navigation strategy that they are invested in and an actual Android API (see DrawerLayout). When people first pick up an iPhone or Android, they become familiar with the pre-installed OS apps. If those apps feature navigation patterns that users become familiar with, then it is extremely likely they’d recognize that pattern in your app as well. For example, both YouTube and Newsstand (both apps I looked at for initial ideas) use a side nav for their primary navigation.

Like we did you may be wrestling with a decision to implement a Tab Bar or Navigation Drawer. Android’s variable screen sizes make it hard to predict how consistently your Tabs may display across smaller screen sizes. Having icons represent tabs (like AirBNB) could mitigate this somewhat, but those icons would need to be very clear about what they represent. It also starts to make things difficult when you navigate deeper into an app and have tab bars stacked on top of menus, to filter more complex data sets.

Finally, consider the importance of each main view within the application. If you choose the navigation drawer you’re making a choice that the first screen the user sees is the most important view. In the case of the World Surf League app, it absolutely is. It’s the place to discover the latest content and easily access live events when they’re happening. If a user engages with our app by watching a live broadcast for over 6 hours and then leaves, we consider that a success. Sure we’d love for them to explore other views like Rankings & Events however it does not upset us if they don’t.

With these considerations in mind, what might be obvious on one platform, may not in fact, be obvious on another. Comparing the data between iOS (Tab Bar) & Android (Navigation Drawer) the fan behavior flow is almost identical between the two apps.

Reflecting on the process and considering these specs I believe we made the right choice for the World Surf League Android app. You are of course absolutely welcome to disagree and argue with me about it on Twitter. I’d love to see someone take a stab at a Tab Bar for the WSL app and show me how it’s done (though it has to look good on a HTC Desire C).

For more product design thinking I usually post my thoughts here.