Designing cross-platform navigation layout
Navigation is the backbone. Do it wrong and your app/website/platform becomes nearly unusable. I will tell about the choices we made and learned from it designing a functionality-heavy Trading Platform for a wide range of screen sizes and different platforms.
There are different types of navigation systems: contextual and flow-based are dynamic, they are adjusted for a current place in the product and user state. Universal (or global) navigation is static and accessible from everywhere. I would advocate for an elaborate combination of different types. For simple products, it’s great to make a flat and clear universal navigation, but in many cases too many irrelevant choices are overwhelming. And what about different devices? Should you have the same choices on a mega-sized screen and phone? Let’s dive into it.
Rule number one — keep it simple and intuitive.
“Simplicity is the ultimate sophistication“
Leonardo da Vinci
Simplicity requires a lot of work and thoughts, but it pays of to invest into it at the earliest possible. Changing the navigation logic of a living product is can be very harmful to the user experience.
Many products start with quickly scaffolding MVP that over time would get different features here and end up like a Christmas tree. Two things can help to solve this for navigation — clustering smartly and keep the future functionality in mind. So when you build a new part of the product, it can naturally land to the right place in your navigation. Product Architecture done right is half of the success, I wrote about my ideas about it here.
The goal is to limit the number of choices in the high level of your menu to 5–7 items. It’s proven that the human mind can’t simultaneously hold in mind more items. Another sweet benefit is that it becomes very easy to use iOS native menu bar or other visible mobile navigation. Otherwise, you would have to reshuffle and throw away items for the mobile version — not the best way to an excellent cross-platform experience.
This can include direct actions, like search and quick order in our case, single standing pages, or a bunch of logically connected pages. The classic example — combining settings and profile pages into one environment with contextual navigation in it. But sometimes it can be challenging to find a common ground for a number of actions. Mapping out user journeys can help. In Trading we could distinguish 3 rarely overlapping sections:
- Exploration mode — a place to lay back and research the markets
- Active trading mode — more dynamic trading environment
- Analytics mode — revising personal results and planning for future
This way we could naturally split tens of pages, widgets and actions that used to be all over the place into 3 environments and let them evolve independently one from another.
Platforms and screen sizes
There are several aspects that can influence the choice of the layout -
- Supported platforms — are they going to be web apps or native apps or both?
- Use cases on different devices—should desktop and mobile apps provide the same functionality?
It has found out that many active traders are using Multiple (!) Mega Size Screens to see as many numbers as possible simultaneously. And on the other hand, they were using mobile apps so they can quickly react to market changes or browse through news somewhere in the metro. That made the design choices incredibly difficult. We would have to fight for every “pixel” of air in our layouts — another very important number could fit there.
Technically wise we have decided to build a responsive app with React, that could be integrated into the native iOS and Android apps. That made us to sacrifice many native app benefits. On the other hand, it allowed us to build a single piece of software faster and with a smaller team and we would not have to maintain 3 or more different tech stacks.
This decision has influenced many layout choices. On one hand, it’s a good practice to stick to native navigation solutions — menu bar for iOS and hamburger for Android, plus the one more for the mobile web version, on another one it would make the cross-platform experience not consistent, it would be more difficult to maintain different layouts and educational resources. Eventually, we have chosen to adjust the navigation only to the screen size, but not the device platform.
So we ended up with these breakpoints:
- Mega displays
- Tablet (portrait and landscape)
- Mobile (portrait and landscape)
Designing responsive layouts is the next. Currently, the most popular solution is top navigation that shrinks into hamburger on mobiles. There are quite a few problems with it. The horizontal top navigation length depends on items' names length, languages support can be difficult. Responsiveness also becomes challenging: on some resolutions, it does not fit on others it’s way too empty, if make it fixed — it will take the valuable space that could be used to show few more lines of text. As for the hamburger, it is hidden, often not intuitive to find, it’s harder to keep the content hierarchy because there is no limit for a number of items — it can end up becoming a long long list.
Our solution was to use fixed side navigation for larger screens and bottom iOS-style navigation for smaller ones.
The desktop navigation was meant to be fixed to the side. So yes, it would eat away that space. But is it really a problem? Most of the laptop screens are horizontally oriented, so you would balance the viewport by reducing the width rather than size (remember MS Word 2003 Toolbar?). Second, remember that in most of the websites you get huge side margins? Wide lines of content are harder to perceive, even in old books you can find text distributed into several columns. So we would leave that space empty anyway.
The biggest concern was using the icons versus text. Fixing section titles on the side was not the option, then we would take way too much space, we would depend on the word size (yep, German will take more space than Chinese), and it would take way too much attention when it is not necessary. People do not need to read the menu at every single moment.
Fortunately, there are no that many desktop devices that are touch only, so we can rely on hover actions to show tooltips to highlight icons. Another benefit of having fewer menu items — people need to remember just a few icons, probably they will do it the first time they try the app. We can also show sub navigation for some sections.