Article overview

Mobile: Never Use Native Drop-Downs for Navigation

· By · 14 comments ·

Native drop-downs are poor for navigation due to limited screen real estate.

This is the 4th in a series of 8 articles on mobile usability that draw on findings from our mobile e-commerce usability report.

Many responsive mobile sites are using native drop-downs (as in: a select tag) for main navigation and many plugins have been developed for this specific purpose, yet our usability research shows that this is a poor strategy. On the tested mobile e-commerce sites that used native drop-downs for navigation, the test subjects showed decreased control and overview of the menu items.

During testing, nearly all subjects scrolled up and down category lists before selecting an option, many explicitly stating that they wanted to see all the categories before selecting one – even if they felt they had spotted a good match early in the list, the subjects still scrolled the remaining items just to make sure they knew what their other options were (before then scrolling back and selecting the good match). The subjects exhibited the same behavior on homepages where they often scrolled up and down to get an idea of what their options were, even if they saw what they were looking for right away.

This strong tendency towards scanning all options before selecting one is at the core of why native drop-downs are a poor choice for navigation. When open, a native drop-down only utilize ~50% of the screen, which made it needlessly difficult for the subjects to get an overview of their options.

selectNav.js is a plugin that turns custom navigation items into a native drop-down.

With only half of the screen used to display the available options, users will have a difficult time scanning and comparing the available options. To make matters worse, the drop-down often starts out at the top with only 3 options visible to the user (left image), and even when scrolled to align optimally, no more than 5 options can be seen at once (right image).

Another issue with the navigation options only taking up 50% of the screen is that the scroll area for those options is similarly small. The smaller scroll area resulted in less accurate scrolling as there was so little room to “drag” the content that many subjects flicked to scroll instead (which of course is a much more inaccurate way of scrolling).

Finally, we also observed a few instances where subjects mistook the navigation for filtering options. This was especially true of category and search result pages where subjects were on the lookout for filtering options and then simply jumped to the conclusion that the drop-down was such a feature.

Solution: Custom UI Drop-Downs

It’s very important to underscore that drop-down navigation isn’t bad at all, it’s native drop-downs (as in: a select tag) which are unsuitable for navigation due to the way they have been implemented in the major smartphone operating systems (such as iOS and Android).

The Boston Globe expands the navigation items inline, which makes it easier for the user to compare and scroll them.

While the navigation at The Boston Globe is very similar to how the native drop-down works in terms of interaction (you first click “Sections” and then a set of simple items are revealed) it is significantly better because the options aren’t limited to a dialog but can take up the entire screen if necessary. In the above all 10 items are shown at once; quite the improvement in terms of overview, scannability and “scroll control” when compared to the meager 5 items that can be shown in a native drop-down dialog. (The navigation items on Boston Globe are, however, on the short end, being only ~5,3mm tall.)

CSS-Tricks is a great example of how custom drop-downs allows you to tailor the design of the options to your site.

Another benefit of implementing custom drop-down UIs for navigation is that you have complete control over the design of the options. This means you can optimize the design and layout of the shown options (which you can’t with a native drop-down). CSS-Tricks, shown above, is a great example of this where, when expanded, the menu items are displayed in two columns and each has a descriptive icon next to it. It can also be more subtle, like the earlier Boston Globe example where arrows have been added to indicate virtual space.

During testing the subjects had no issues using these types of custom UI navigation as long as they followed basic design conventions, had adequate hitarea sizes (device manufacturers recommend a minimum of ~7×7mm), and the trigger element was designed as a link / button (so that the subjects knew it was clickable).

It should be noted that native drop-downs are not poor for all purposes – they can work well in forms where keeping page context can be as important as the options themselves. However, native drop-downs should not be used for main navigation as they simply afford too little overview of the available options and are needlessly difficult for users to scroll accurately.

Antoine P. April 23, 2013 Reply to this comment

This article is not particularly objective. By “Mobile” you mean “iPhone” and I regret to say that the element ‘select’ is much better managed by Android.

Jamie, Baymard Institute April 23, 2013 Reply to this comment

Hi Antoine,

Thanks for your feedback.

However, there are many different implementations of the ‘select’ tag on Android, and some of them are very close to the iOS design (and these two groups combined make up a very significant share of the smartphone market; certainly enough to spend a few hours to avoid poor navigation UI on those devices). But it is true that some Android distributions are different and more suited for navigation. However, even for those Android distributions the ‘select’ tag is still not optimal for navigation since you can’t do custom designs of the options.

AWKM April 26, 2013 Reply to this comment

Indeed.

On my android phone using the SelectNav site referenced it opens a “full screen” list of radio buttons that I can select. If I don’t want any I just hit the “back button” that is a physical control on the device itself.

The entire menu on the SelectNav site fits on one window. No scrolling required. It actually works quite well.

Karl Malden May 31, 2013 Reply to this comment

So maybe Android does it right sometimes. But you can’t ignore the other crummy implementations just because Android has their act together. When programming for mobile devices, you have to think about the lowest common denominator. Especially when it has a huge market share.

HugoNS April 26, 2013 Reply to this comment

I’m sorry Antoine, but i totally disagree with you.
Android management of the element “select” also has it’s problems. For instance, In android phones, if you have an option, in a select element, that is too long, this option will not break into 2 or more lines, something that happens naturally on iOS.

Bart April 26, 2013 Reply to this comment

The solution is that Apple should redesign the native controller to respond to longer lists of options. Browser vendors should also rethink how select boxes work on desktop too, since developers keep trying to build better versions with CSS/JS.

Andy Moore May 2, 2013 Reply to this comment

Mobile is bigger than just iPhone.

molbal May 3, 2013 Reply to this comment

In Windows Phone, it feels more ergonomic to use. It takes the whole screen and I prefer it. It’s always faster than CSS/JS solutions.

Like this: http://i.stack.imgur.com/NxDnC.png

Ali Reid May 8, 2013 Reply to this comment

It doesn’t matter that there are other phones; when using the select tag you MUST take into account iphone interactions, whether you like them or not. You have to design for multiple devices, not just the one you happen to use. Even Internet Explorer.

Intxt May 17, 2013 Reply to this comment

I somewhat agree with ALi Reid. He has a point that regardless what you think of it, design has to cater for all devices. I do also like the alternative you have suggested though. All too many people complain about a service without having any suggestions of their own.

Stuart August 13, 2013 Reply to this comment

Even though Android has a market share of over 60%, and the iPhone market share is 13%, designing for Android at times feels like designing for IE. Sooo many different versions of the OS, it’s hard to make the site work in all of them correctly.

Merne December 10, 2013 Reply to this comment

What about the pros of using native? There was no time spent on this. What happens when scripts update and your “custom” solution now has to be maintained to work with new technologies? I agree that navigation is a case where a custom interaction should be used, but this article is very biased.

I’d also like to question some of the “conclusions” that we’re jumped to. Just because a user scrolls through their options, doesn’t mean they have a hard time processing or seeing them. I think that was rather rash to assume that they were hindered by the native interaction. You didn’t talk about how the user felt during this time. Did you even take note of it?

What about testing the proposed solution? Did you see what the user said/felt if the UI took over the entire screen to show them all the options? If it were me, I would feel lost, like I was taken off the current page.

My 2 cents.

Allan White December 10, 2013 Reply to this comment

@Merne – as this article is condensed from their m-commerce study (http://baymard.com/mcommerce-usability), I would guess that details like that would be there. I also felt like they did support their rationale with feedback from the users, and timing the users on those tasks would reveal whether it was more efficient or not.

Christian, Baymard Institute December 27, 2013 Reply to this comment

Hi Merne,

Thank you for commenting your concerns. This article is based entirely on how the test subjects were observed to behave and how they responded during our large scale usability study of 18 mobile commerce sites. Every single interaction was recorded and later on transcribed and analyzed which took almost 6 months – so yes, we did take note of how users reacted and felt when interacting with the native dialog for main site navigation – as outlined in the article – a few being confused and mistook it for a filters menu (severe issue, low frequency), while most had issues getting an overview of their options due to the native drop-down only utilizing half the screen (low to medium severity, high frequency).

Agree that using a non-native drop-down menu of course required proper testing and maintenance. A visibility toggle is however relatively simple.

Post a comment!

Close overlay