The idea is: show as many navigation items as will fit horizontally with a UI toggle to show the rest. I like the idea. Why hide everything behind a toggle if there is room to expose the most important links? How it looks and how it is implemented could vary. Let’s look at some examples!
According to this Brad Frost post, this pattern was coined by Michael Scharnagl, and this is the visual demo:
The pattern made it into Brad’s Responsive Patterns:
See the Pen Priority+ Navigation by Brad Frost (@bradfrost) on CodePen.
In that demo, the navigation jumps from either showing all the links, or showing just three with a “More” link.
The whole idea for this post came from a little thought I had where I wondered if there was a simple CSS way to have navigation items “drop off” the edge only as there was room, disappearing behind a menu toggle. My idea was to make the navigation of a fixed height with hidden overflow and wrap them. So as a navigation item wrapped, it would visually disappear. Here’s that concept:
See the Pen Drop Away Nav by Chris Coyier (@chriscoyier) on CodePen.
The only thing that I don’t love about that technique is the fixed height. That’s always a warning flag in CSS. When text is involved, it ends up being a bit of a magic number. That is subsided a bit by the fact that you could set it in em or rem so it increases as text increases. But still.
Ben Callahan showed me some examples in the wild. Here’s on at NCSBN.org:
And Wonderful Machine:
Luke Jacksonn made a demo he calls the “Greedy Navigaton”. Interesting in how it knows how many navigation items are hidden.
See the Pen Greedy Navigation by lukejacksonn (@lukejacksonn) on CodePen.
AWS implements the pattern as well, as implemented by Tom Horton:
John Oxton King designed an interesting variation on the pattern he called the “Infinite horizontal navigation”:
There is some sentiment that The Guardian may have been the first example of this out there. See:
Use it? Love it? Hate it?
Interesting concept. My only problem with the concept is will people understand to click the three bars (or hamburger icon or navicon or whatever you want to call it). I like the last example with the number, though I would add the word more in my opinion.
Another option I have seen is having the main nav links as seen in these examples but the additional menu items are in a side flyout menu. Of course, this assumes you manually split the menu vs having it auto-collapse as needed.
I think for this type of navigation, instead of the hamburger I’d consider an ellipsis.
I think I’d like to test with “···” (3x
·-ish icon). That kind of nav does have some traction on Android :-)
The design pattern has potential, but I don’t think it beats a good responsive design. I can only think of one use-case where it might be preferable to use the “priority navigation”, where the page is being pulled into another site (perhaps as an article or in an iframe).
I agree with Jesse, using an ellipsis instead will make user click to see more
I recently implemented a similar concept for the new menu navigation on a site that I am working on. I have the project up on codepen if you would like to check it out so far:
For my menu, since everything was floated to the right, I used the position of the first menu item from the left of it’s parent container. It also collapses into a mobile menu. :)
Just post it man!
Excellent example. I recently worked on project where this could have been a great solution.
Definitely will try this out on next project. Thumbs up. +1
Nice, Ryan, I like how the logo “lifts its skirt” when the menu opens on über small screens…
“Use it? Love it? Hate it?”
Obvious Always Wins http://www.lukew.com/ff/entry.asp?1945
Saw this first time on Virgin America’s website. not quite the exact same solution, but it also very modular in the way that it scales.
Implemented it that way (with the burger for more) in some projects. I think it’s how the web should work today.
It’s a nice trick, but I would be cautious not to let the option degrade the decision-making around information architecture in the earlier stages.
This is eerie because I was up late last night trying to think of a good solution to replacing the hamburger. So I made the top bar fixed with 5 of our most popular links, and on the right is a hamburger hybrid that has “more” instead of the middle line. I guess great minds think alike. :) I’ll just have to see if it’s a good idea.
Thanks for featuring AWS! Although I was the one to point it out, credit goes to another one of our other engineers, Greg Stallings (not to mention our Design and UX teams).
Great idea. I have often found that people have different ideas of hat links are important though.
Similar to a nav I created a while ago: http://martinblackburn.github.io/responsive-nav/
Interesting ideas, and don’t get me wrong, the solutions are not short of clever and creative.
But I’m honestly on the fence with the proposed solutions, for two reasons:
1- This navigation pattern is the perfect candidate for a Flexbox-based solution, so why not harness its power? Flexbox support is 100%: http://caniuse.com/#search=flexbox.
Here’s how I would do it:
2- Luke’s “Obvious Always Wins” (http://www.lukew.com/ff/entry.asp?1945) says it all.
Good article on point 2. It supports my idea with the top charms menu that I created and the new navigation architecture suggestions that I have made for the site.
I’ve polished up the commenting and created a separate pen for the collapsing menu navigation example that I posted earlier:
Flexbox support is definitely not 100%.
@Halley Carleton, sure it is, lemme show you:
Click here: http://bit.ly/1E9FCx8
And here: http://i.imgur.com/tin3YVW.png
I’m seeing a lot of red/orange under IE, that doesn’t seem like 100%.
Also- with your flexbox solution you’re making the last option larger, which implies priority to me. If it’s a higher priority, why is it at the end of the list at larger sizes?
@Thomas Horton, the red/orange in IE is out of scope for these solutions and Flexbox. The current state of browsers say otherwise.
Hmm, interesting view about the last link conveying more importance in the navigation. Larger doesn’t necessarily mean higher importance, after all, position and location also play a role in the concept of hierarchy and that last link is below the rest.
But I see your point, which is certainly valid. So I improved the responsiveness of the nav based on your idea (huge Thanks for it BTW), check it out: http://codepen.io/ricardozea/pen/022b38c6c395368ec4befbf43737e398
How about using
nth-childselectors for this purpose. Combined with checkbox hack it gets pretty easy.
I made a demo.
Check it out- http://codepen.io/abhisack/pen/jPPXBB
@Ricardo: Reading caniuse always needs to be done in context. You claim 9 out of 9 boxes is 100%. 9 out 9 means latest browsers. Few projects can ignore IE10 and below. And what about Android 4.x, which has a sizable audience? As this is all about responsive navigation, many projects cannot ignore that either. And then there’s the issue of 2 (or 3) different syntax versions for flexbox.
So no, it’s not that simple.
@Ferdy, I see what you’re saying but I think you’re confused.
This solution is for mobile-only browsers, IE9 and below are not part of this scope. So the solutions provided here or the use of Flexbox do not apply for those browsers.
As far as IE10 and Android 4.x are concerned, Flexbox works 100% just fine with the
-webkit-prefixes. I assume you’re using Autoprefixer to automate vendor prefixing and old Flexbox syntax.
On the other hand, one needs to look at the analytics to determine how much traffic comes from mobile IE10 (which I’d dare to say, it’s minimal if any) and Android 4.x. As for Android 4.x our analytics show that people use Chrome more than the default browser, and its usage increases every period.
In no way I meant to ignore any browsers, what I meant was simply that modern browsers have 100% support for Flexbox.
Worst case scenario, the solutions provided here can actually be considered the fallback in case Flexbox isn’t supported and you want to steer away from using the old syntax.
TBH, to me it’s really quite simple.
There’s absolutely nothing simple about Flexbox in its current state. Unless you want to deal with polyfills, prefixes, and all that. Definitely possible.
My bigger point is that this solution is NOT for mobile browsers only. Any navigation pattern in the responsive sphere is for ALL browsers. That’s the point of responsive in the first place.
@Ferdy Not sure why you think there’s currently nothing simple about Flexbox when all modern browsers have green boxes in the caniuse.com results. I see the “half full” part.
There’s no need for polyfills to use Flexbox. Flexie doesn’t make things easier, so no need to go that route, especially if it’s only to support the 2009 syntax. No production-ready polyfill for the latest syntax either. I don’t see any other polyfills either: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#flexible-box-layout-spec
These solutions look particularly for mobile browsers: the conversations here are about how the solutions work in small screens.
I recommend taking a look at Zoe Gillenwater’s talk in SmashingConf Oxford 2015: Enhancing Responsiveness with Flexbox – https://vimeo.com/124796320 (start viewing at 2:35).
And finally, “responsive” isn’t exclusively tied to ALL browsers. Don’t forget email clients, we do “responsive” for them as well.
This is a great solution for sites with dynamic navigation, where you don’t know how many links there are going to be. Keeping the higher priority links at the front of the list and pushing the less important links into a ‘+ more’ link. It’s not ideal, but it’s a good solution to a challenging problem. A site called PamperPad does something very nice like this, similar to the first example given.