Navigation options starting with mobile
The great thing about designing for mobile, as opposed to desktop, is that there are a reasonably well-established set of design conventions regarding the application’s navigation.
Furthermore, there is an even more limited number of mobile and tablet navigational design convention that scale well to desktop.
Starting with mobile navigational design is straightforward in comparison to starting with the design of desktop's navigation. The desktop, with its ample screen real-estate, has too many equally good options for how its navigation structure can be designed.
Mobile, on the other hand, with its limited number of pre-established patterns, allows the designer to determine the right solution quickly, and move on. Start with mobile.
Listen to this blogpost on your podcast app under: Gregory Schmidt, or YouTube
Major navigation structures starting with mobile
The examples here use components found in Google Material Design, but these principles apply broadly across most apps. There certainly are other navigational patterns, but I believe these are most common.
On-page navigation
Bottom tab navigation
Top tab navigation
Side navigation drawer
Combining navigation patterns
1. On-page navigation
Most applications actually use an on-page navigational structure. Essentially, the home page contains buttons within the content area that take the user to different parts of the app.
There are many variations of this.
Buttons on the home screen are square or round buttons
Tiled cards across the home screen
Rows of content - think of the standard messaging application. Each row witihn the main space links to the conversation thread space.
Floating action button - I’m going to throw this component within this design pattern.
When the appication is simple and straightforwad, this is a great option. But often additonal major spaces exist in the app, and a more compelx and persistent navigational structure is needed.
2. Bottom Tab Navigation
Over the last few years many applications have moved towards a bottom tab navigation design. There are several good reasons for this.
1. Bottom tabs are easier to reach with your thumb on mobile phones. This is important as for many phones the top of the screen is now too far to access. Also on tablet, you do not obscure the screen with your hand while selecting a button at the bottom of the screen, as opposed to if it was at the top.
2. Bottom tabs make it very clear at all times, which part of the app you are in. Knowing where in the application one is, is essential part of a good experience.
3. Bottom tabs make it very clear the other major spaces within the application. This encourages users to explore.
4. Bottom tabs provide focused notifications. Alerts (e.g. new messages) can be targeted to the specific major space they come from and indicated on its respective bottom tab.
5. Bottom tabs accommodate up to and including five tabs on mobile, which should be enough for most simple applications.
6. Bottom tabs scale nicely to desktop and by moving from the bottom of the screen, to the left navigation bar.
7. It is easy to embed an 'action button' or 'primary action button' directly into the app bar. (Though from what I can tell, this trend is going away).
The largest downside is that the application can have no more than five main bottom tabs. If your application has more then five major spaces, this option doesn't work, without funky extensions such as trying to turn the fifth tab into a 'more button' or using scrolling bottom tabs...which is generally not a used design pattern.
There remains debate if the bottom navigation tabs need to persist across all screens in the app, or not. I generally think they need to persist, but haven't fully looked into this.
3. Top navigation tabs
Placing the navigation tabs at the top of the screen has many advantages.
1. The top navigation tabs look good if there are only two tabs, or can scale easily to hold more than five. Additional tabs are able to overflow off-screen.
2. The overflow design scales well across all devices. As the screen width increase, the tabs that previously had overflowed come into view.
3. The navigation tabs can use large text. Text buttons are good. Larger text is better. The move away from icon-based navigation started years ago.
4. The information hiearchy is very clear. The navigation tab is at the top of the page, and the content underneath.
The major downside of this pattern is that the tabs are hard to reach when at the top of the screen on modern mobiles. The workaround to this is to enable the user to swipe anywhere on the screen content left or right - and to connect this gesture with changing the taps in the top navigation tab bar. The Twitter application has a great example of this demonstrated within a user's info page.
4. Side navigation sheet
AKA. Hamburger Menu
I am happy to see that most applications have moved away from hamburger menu navigation as the means of their primary navigation between the app's major spaces.
Don't get me wrong; this navigation entity does serve a useful purpose. It's primary benefits are :
1. Holds an almost limitless number of navigational buttons
2. Can display long text tiles for each navigation button
3. Has space for an icon
4. Still has room to display additional information within each navigation button (such as unread messages or other labels/flags).
However, as an application's primary means of navigation, it has several problems.
1. Changing major spaces within the application always requires two-clicks. The user has to open the menu and then select the icon.
2. When one loads the application, it is not intuitively clear all the major spaces within the application, as this important information is hidden within the navigation menu.
This is a classic example of unknown unknowns. The user doesn't know they should open the menu, and they don't know what they are missing behind the menu.
3. It is harder to display notifications and nudge the user to other parts of the application. In bottom tab (and even top tab) navigational structures, because buttons to other spaces of the application are clearly visible on screen, the developer can show notifications of update on content from those spaces and in turn encourage the user to go to them.
4. The hamberger button is far away - way up in the top of the screen. An important work around for this is to ensure if the user swipes starting on the screen edge towards the middle they can 'pull' this navigation menu from the side. (However, this doesn't work if running the application as a web page as such a gesture loads the browser's prior page.)
Combining navigation patterns
1. Can pair with pretty much any other pattern
On-page navigation
Hamberger menu navigation
2. Can usually pair together just fine
Top and bottom navigation tabs: the bottom navigation tabs remain the primary navigation, and the top bar which is smaller remains the secondary navigation.
When shifted to desktop, the bottom tabs move to the left navigation bar.
3. Acceptable to pair together
Two top tab navigation bars: these tab bars at least follow the standard visual heiarchy with the topmost bar being primary, and the bar underneath it being secondary. Obviously this can be done bad, but generally there are applications where this is done well.
4. Never pair together
Two bottom tab navigations ontop of each other. It is impossible to know if the primary navigation is the most bottom navigation bar, the bar above it.
