Creating experiences for mobile devices is all the rage right now. However, poor experiences on mobile devices are the source of my rage.
I’ve recently been tasked with creating an alternate mobile navigation solution that healthily accommodates racks on racks of sub-menus. The current solution is an accordion style menu that increases in height as child, and grandchild…and great-grandchild, menus appear.
These kind of menus aren’t so bad when you have a child menu or two, but they can create issues that can only be solved by depending on user intelligence. Example: when there is a menu option that has a page of it’s own and has a child menu beneath it, it can be hard for the user to control this option.
I’ve illustrated it below:
Some sites require the user to tap the area once in order to activate the drop down menu, and require the user to tap twice in order to go to that page. Counter-intuitive, no? And what happens if the user wants to close that sub-menu? Tapping again takes the user to the new page—it doesn’t close the item.
One of the first menu options that came to mind was one I had used in the past on another site I UXed (yes, I’m making that a word for right now).
There are three variations of menus available:
- Overlapping levels
- Covering Levels
- Overlapping Levels with Backlinks
Overlapping levels is the option pictured above. When you open a sub-menu it appears stacked on top of the previous menu with just a peek of the previous menu available on the edge. This gives you an area to tap/click if you’d like to go back to that menu.
Covering levels is the option that sets each sub-menu to completely cover the previous menu. A back button is included so that users can go back to the previous menu if they choose.
Overlapping levels with backlinks combines the features of the first two options. You get the layers stacked, a peek of the previous menu, and a back button. This is the most user friendly option.
Overlapping levels with backlinks is the closest option to what I think my team needs. However, there are a few additional things we use regularly that it could be helpful to find in the mobile nav. Check them out.
We might need a…
My team usually needs a logo, search option, and a navigation in the header area of our sites. We don’t always include a search bar (sometimes we just drop in an icon), but the ability to search is often the crux of the sites we create—it’s important. Naturally it’s the kind of functionality I’d like to include in the mobile nav.
Some users don’t assume that hitting return/enter will submit the search query. For those users, a search button is handy. However, it doesn’t need to appear until a user actually starts searching for something. So, on this nav, the search button won’t appear until a user starts typing.
Sometimes it’s nice to have the logo in the open state of the mobile nav as well. Why? Here are two reasons:
- The user should always know what site they’re on if they need to break their focus for a minute—say they have to take a phone call
- Because a user can open a nav and then open a new tab. When they later scroll through their open tabs, the logo will hint at what site they were on. This could be the difference between a completed user journey and a closed tab.
Pluses instead of Arrows
One of the common solutions is to add an arrow, which is meant to imply that something will slide down if there are sub-menu options. I was once a supporter of this icon—I confess. However, I now lean towards using the plus (+) sign for instances in which I want to let users know that there will be “more” if they interact with the button.
For a while, I viewed the plus sign as an indicator that the user could add more of something (like add an item to a shopping cart). I think it’s safe, now, to use this as a “more” indicator. There are arguments to be made for either option (I’d love to hear yours on Twitter).
Enough about that.
Here is the first-round mock-up I created that I’m hoping will be a coverall solution for us.
Hit me up on Twitter and let me know what you think.