Navigating Mobile Apps – Specification
Part 3 of 3
Illustrations by Lana Milinovic
In the previous two articles, you could read about the high-level flowcharts and you learned about navigation patterns rules for each platform. In this last article in the series, I’ll deep dive into specifications and conclude the navigation topic overall. Let’s jump into the specs.
Title choices
Both platforms have similar choices for titles. The main difference is the title alignment.
iOS
Large title left aligned (for the top-level parent navigation)
Regular title centered (for the child navigation)
Android
Prominent title left aligned (the parent and child navigation)
Regular title left aligned (the parent and child navigation)
Above mentioned options are the default ones provided by the platform. I noticed additional types popping out like:
Title w. subtitle
Large and long titles for child screens
Large image w. the title below
Interactive titles
No title
Material Design describes very nicely the role of the title. It provides value to the user by showing the screen the user is currently on, the section the user is currently in, or the app being used. It's a must-have, so if you go with no title in the navigation component, you need to make sure that the user can easily identify where they are. Other than that, creativity is yours.
Most common navigation title choices
Interactions
When choosing a proper navigation type it's valuable to know what kind of interactions users can perform on a specific screen. Especially about how the screen can be dismissed. In this article, I'll focus only on navigational interactions, as on-screen interactions could be a book long read.
The most common navigational interactions for the child screens are:
Swipe right
Swipe down
Swipe up
Swipe left
Tap
Swipe right (from the edge)
Go backward in a navigation flow (iOS all versions and Android from version 10 with the gesture navigation)
Show off-screen content like the navigation drawer (Android)
Android versions below 10 don’t have a swipe right to go back gesture. Users can navigate back by tapping on the Up or Back button.
Swipe right interactions
Swipe down
Dismiss modal or minimize chevron screen (both platforms)
It will dismiss small bottom sheets or bottom sheets with the handle that can expand to a full screen (both platforms)
Refresh page content. Be aware that swipe down to dismiss the screen can interfere with this interaction (both platforms)
Swipe down interactions
Swipe up
Expand bottom sheets to a full-screen modal (both platforms)
Close the app if it’s swiped from the bottom of the screen (iOS and Android)
Scroll to see more content (both platforms)
Swipe up interactions
Swipe left
Switch between tabs (Android)
Go backward in a navigation flow in the flow (Android 10)
Swipe left interactions for Android
Tap
Going forward in the flow by tapping on an element (in most cases)
Tap on a segmented control to see the next tab (iOS)
Going back if it’s performed on the Back or Up icon (both platforms)
Tap interaction usually moves user forward, unless it’s a back or cancel button
Transitions
Moving users through the flow is seamless only when you choose the right transitions that are invisible to the user (or when they feel natural). How do you choose transitions?
First, you choose them by platform rules and then if you have more time, feel free to experiment. Based on the types of axis we mostly use for navigating, I like to divide platforms by:
X-axis transitions dominant - iOS mostly uses slide left/right transitions on the x-axis for navigating further in the flow
Z-axis transitions dominant – Android-based devices navigate further in the flow by using zoom in/out or container transform via z-axis
Y–axis transitions are present on both platforms for slide up/down modal views and action sheets. I will not go further into details, you can check transitions on respective platform guidelines. You can also find a nice side-by-side comparison on this page.
iOS X-axis transitions and Android Z-axis transitions
Tab Bar and Bottom Navigation Bar
Main specs
I would not spend too many words here. The main thing to know is that both platforms suggest using three to five tabs on mobile devices. For tablets, Apple noted that you can add a few more. The rest you can find on Apple and Material guidelines.
Visibility
I've participated in various discussions and read some interesting articles on how to properly implement the bottom navigation visibility. In the end, my conclusion is these options:
Keep it visible always, unless you have a high-cost task, then hide it
Keep it visible on top-level parent screens and hide it on all child screens
If you deep dive into the official guidelines from Apple, you can find that "it should remain visible everywhere. The exception to this is in modal views.". Material Design gives you the choice of showing or hiding it after the parent screens by saying “When moving downward in the app’s hierarchy... a bottom navigation bar can be displayed persistently for quick navigation between an app’s sections.".
Users can benefit additionally from having visible bottom navigation:
The bottom back button – On iOS, it can be used as the back button, which can be easier to reach. Some apps implemented this on Android also (Instagram, YouTube), but didn't run into this often.
Back-to-top button – When a user scrolls down, they can tap on the navigation item and use it as a back-to-top shortcut on both platforms.
I prefer to keep bottom navigation visible whenever it can be. So that it serves as a high-level breadcrumb for users. I also hide the bottom navigation for a walkthrough or focused screens (high-cost action flows).
However, it all depends on the context and goals of your app. Before making any final calls regarding bottom navigation visibility rules, you need to answer the question – Is it important for users to be able to switch the context fast? If your user doesn't need to be able to switch fast then don't show the bottom navigation on child screens, and vice versa, show it if it’s needed.
Bottom navigation visible all the time vs. hidden on all child screens
Test it, test it, and test it
That’s it! Now you know everything to create smooth navigation. But have in mind that navigation is always contextual. Think about how the user reached content. What was a path? Even if the content is the same, the path might be different.
You can read the guidelines and follow them blindly. But my advice is – test it. Create a quick prototype (at least that's easy today) and test it by yourself, test it with your coworkers, test it with your users, test it on competitor apps, test it on most popular apps, and test it on both platforms. Switch your phone for a month or two and get familiar with another platform. Answer the questions like – Does it feel right? Is it invisible? Is it smooth? Is it familiar to our users? Do they complete tasks fast? Test the shit out of it, until it feels smooth. Once you gather the findings, establish your rules to follow and document them in the design system for your product.
Create prototypes and test your navigation
The above written are guidelines and the conclusion based on official documentation and my experience. At the end of the day, if your (custom) app navigation doesn't give a headache to your user, then you’re good to go.
You're the champ for reading all this till the end! High five! Also, feel free to share any comments or feedback with me.
When writing this article iOS 14, Android 11 and Harmony 2.0 was the latest mobile OS version.
