Responsive Navigation Patterns

Update: I’ve also written about complex navigation patterns for responsive design.

Top and left navigations are typical on large screens, but lack of screen real estate on small screens makes for an interesting challenge. As responsive design becomes more popular, it’s worth looking at the various ways of handling navigation for small screen sizes. Mobile web navigation must strike a balance between quick access to a site’s information and unobtrusiveness.

Here’s some of the more popular techniques for handling navigation in responsive designs:

There are of course advantages and disadvantages of each method and definitely some things to look out for when choosing what method’s right for your project.

Top Nav or “Do Nothing” Approach

Tim Kadlec Responsive Navigation

One of the easiest-to-implement solutions for navigation is to simply keep it at the top. Because of its ease of implementation, it’s found on many (maybe even most) responsive sites right now.


  • Easy to implement– you can implement your large-screen site almost as-is.
  • No Javascript dependencies – ensuring maximum compatibility
  • No back-breaking CSS maneuvers required
  • No tripping over your source order – no need to jump through hoops to shift nav lists around in the source. It flows au naturel.


  • Height issuesHeight matters in mobile. As Luke’s book explains, content-first, nav-second is preferred for mobile web experiences. You want to get the users to the meat-and-potatoes content as quickly as possible. That means getting the navigation out of user’s way so they can focus on the core information on the page. It can also be confusing when all the core content is cut off:
    confab responsive nav

    The site doesn't look different from page to page and doesn't expose the core content soon enough

  • Not scalable – What happens when you want to add a new section to your site? Where the nav fits neatly on one line now, what happens when your client says you need to add “products and services” to the nav? Or when you need to translate the menu to German?
  • Fat Fingers – Cramming links too closely together can easily result in unwanted proximity clicks
  • Cross-device issues – While text might look great on an iPhone, devices have different ways of rendering fonts. Sites can look great on an iPhone but break when viewed on other platforms:
    Responsive navigation breaking to multiple lines on small screens

    Responsive navigation breaking to multiple lines on small screens

In the Wild


Grey Goose Responsive Navigation

This clever solution keeps the nav list at the footer of the site, while the header contains a simple anchor link pointing to the footer nav. This approach clears up a lot of room for the core content while still providing quick access to the navigation.


  • Easy to implement– Simple anchor on top. Nav list on the bottom. That’s pretty damn easy.
  • No Javascript dependency– which means less testing and far better support.
  • Little CSS work required to scale up – Thanks to absolute or fixed positioning, moving the footer nav up to the top for large screens is a piece of cake.
  • Single button in header– A simple menu icon or link takes up very little room in the header, which frees up plenty of space for the core content


  • Anchor jump can be awkward/disorienting – Quickly jumping to the footer of the site can be a bit disorientating.
  • Not elegant– this seems weird to say, but other methods like the toggle method have a bit of sexy to them. A jarring jump, while awesomely practical, isn’t the elegant interaction mobile users have gotten used to from interacting with those highly-polished native apps.

In the Wild


The Select Menu

Viljamis Responsive Nav

One way of taming nav links gone wild is to transform a list of links into a select menu for small screens. This avoids the problems the top nav approach presents and is a clever way to save real estate.


  • Frees up plenty of space– a select menu definitely takes up a lot less space than a horizontal or vertical list of links
  • Keeps interactions in the header– instead of a footer nav, the select menu keeps the navigation functionality in the header, where users are used to seeing web navigation
  • Easily Recognizable– a select menu with a clear label saying “navigation” or “menu” is definitely easy for users to figure out.
  • Pulls up native controls– each mobile browser will handle select menus their own way. Touch devices will pull up the nav in a touch friendly list, while trackball/d-pad/pearl devices will pull up a select menu more conducive to that particular input method.


  • Lack of styling control– select menus are a pain in the ass to style. Each browser handles them in their own, usually clunky, way. Forget about cross-browser styling and coming out with anything that looks halfway consistent. As a result, the select menu can stick out like a sore thumb and really dirty up an otherwise good-lookin’ design.
  • Potentially confusing – Users are used to select menus in the context of filling out a form, but I’m not sure they’d grasp a form element out of that context. This is simply a hunch, so it would be interesting to test.
  • Handling subnav items– nested lists handled by select menus can look weird. Child categories are usually handled by indenting with dashes, and while it might get the point across I see it as potentially confusing and a little ugly.
  • Javascript dependency– It doesn’t require too much JS to convert the list to a select menu, but it’s worth pointing out simply because mobile browsers do the darndest things. But again, the technique is pretty cut and dry so there shouldn’t be too many hang ups using this approach.


In the Wild

The Toggle

Starbucks Responsive Navigation

The toggle is similar to the footer anchor approach, but instead of jumping down to an anchor at the bottom of the page, the menu slides open right in the header. It’s a good-looking approach and is relatively easy to implement.


  • Keeps the user in place– Where the footer anchor jumps suddenly, the toggle menu simply appears in place, which doesn’t disorient the user.
  • Elegant– This is definitely one of the more classy approaches. No awkward forms or page jumps, just a smooth animated flyout or basic show/hide.
  • Easy to scale up– All you need to do is hide the mobile trigger and show the nav list when the appropriate breakpoint is reached and you have yourself a normal large screen nav. All this can be accomplished with CSS.


  • Animation performance– Your mileage will vary when doing any sort of animation on mobile devices. Android is notoriously bad with CSS animations and so things might not be as smooth as you’d like. Also, for what it’s worth I’ve recently been animating max-height which seems to work well.
  • Javascript dependency– Again this approach relies on a bit of Javascript in order to trigger the toggle, but it’s minimal. I have one Blackberry test device that refuses to listen to any of this stuff, but most browsers, including proxy browsers like Opera Mini and Dolphin Mini, handle it just fine.

In the Wild


The Left Nav Flyout

Obama responsive navigation

Facebook popularized a left navigation for mobile that’s quite unique. The nav is accessed by a menu icon, which reveals a tray that slides in from the left and moves the main content over to the right.


  • Lots of space– While other nav techniques don’t work very well if you have a lot of list items, this approach provides a lot of space to expand. I think that’s why Facebook took to it.
  • Good looking– This menu is very sophisticated and advanced, so it definitely has a wow factor to it.
  • Facebook conventions – Facebook mobile users will be used to this pattern already since the web and native Facebook mobile apps utilize this left tray system.


  • Advanced– While the other methods modify simple elements, this shelf method has a lot of moving parts. As Stephanie Rieger pointed out, the Obama site navigation broke on everything but the most sophisticated devices. If your project is meant for a broader audience, you want to be very careful if choosing this approach.
  • Doesn’t scale well– this method is quite unique to mobile and doesn’t necessarily scale up to large screens easily. You can run a risk of essentially maintaining two separate navs for small and large screens.
  • Potentially confusing– When I first saw Facebook’s new mobile nav, I actually thought it was broken. Keeping a hint of the content on the right seems a bit weird to me, but this is all personal preference.

In The Wild


Fray Responsive Nav

The footer-only navigation is similar to the footer anchor approach, only without the anchor in the header. It follows the content-first, nav-second model, however it requires mobile users to scroll all the way to the bottom in order to navigate the site.


  • Frees up header space – It follows the content-first, nav-second model, but…


  • Difficult to Discover– Users (both on small and large screens) might not discover there’s a menu sitting in the footer.
  • Difficult to Access– Mobile users have to scroll the entire way down a page (which might be very long) just to get around the site.

In The Wild

The “Hide N’ Cry”

Authentic Jobs responsive nav

Follow this rule: Don’t penalize users for visiting your site on smaller devices. It’s a myth (PDF) that mobile users don’t want/need certain information. Mobile users will do anything and everything a desktop user will do, provided it’s presented in a usable way.


  • Clears up plenty of space– By removing the nav for small screens, you free up a lot of space! But that comes at a cost…


  • Removes content/functionality for mobile users– Hiding links and content is not OK. Responsive advocates say that responsive design removes many of the content disparities and experiential nightmares that can come from separate mobile sites, but if a responsive site is hiding content for mobile users it’s no better.
  • Adds extra page weight– Adding display: none for elements that are presumably unneeded for mobile doesn’t make it disappear. The code/images/whatever still gets download by mobile devices (which of course are more likely to be on slower connections).
  • Harder to maintain– Two separate navigations for small and large screens becomes a burden when maintaining the site.

In The Wild



Ultimately, mobile navigation should be like a good friend: there when you need them, but cool enough to give you your space. A bad friend is someone who’s not there when you need someone to talk to (when navigation is absent or hard to find), or someone who’s obnoxious because they’re always around and taking up space (dude, get off my couch). Finding the balance between accessible navigation and mobile screen real estate is an art that we’re all trying to sort out. I’d love to hear your thoughts.


Right after this was written, it looks like there’s been some other great posts discussing responsive navigation. Check out:

  • A Responsive Design Approach for Navigation, Part 1 by @filamentgroup Absolutely wonderful step by step guide to implementing the toggle approach.
  • Pull Down for Navigation by @inspectelement, an clever approach that reveals the navigation as the user pulls down the top of the page. Quick pros and cons:


    • Sexy as hell.
    • Great use of screen real estate.
    • Takes advantage of an existing smartphone convention of pulling down the top of the page to reveal more.


    • Potentially confusing– Mobile users are used to pulling down the top of the page to refresh a list of content items, not to reveal a navigation.
    • Relatively Advanced– Right now the demo only is working in its entirety on iOS. I checked Chrome for Android, Android stock browser & Opera Mini and they all kind of worked, but not fully. I’m sure this solution could be progressively enhanced to accommodate more browsers.
    • Explicit Instruction Required– you have to explicitly tell the user to pull down to reveal the nav, which is fine but could potentially be awkward in the site header.

    All in all these are minor points, but I’d love to see it working across more browsers!

Also, be sure to read about how to handle complex navigation for responsive designs.


  1. Awesome post, thanks a ton for this :)

  2. Great write up :)

    I would consider it worth mentioning that this is an overview of options most likely not intended to be mutually exclusive. CSS in general (not just CSS3) gives us a lot of power to manipulate the layout of a page so the possibilities of navigation extend beyond these options. A mix-and-match approach using these options might be called for if you are working on a site with complex navigation or loads of content.

    A good example of this is the Boston Globe site. They would probably be subscribed to the ‘toggle’ method for the primary navigation but more of the ‘do nothing’ method in the footer of the site.

    When building out responsive navigation systems try to look past just ‘what can we do with the HTML structure we have’ but rather ‘what is the best solution at this resolution from an experience standpoint’. This might present more hoops to jump through in your HTML, CSS or JS but a better final result.

  3. Hi Brad

    Making navigation work is the one time I’ll allow myself a bit of display:none to help along (I’m not hiding actual content, so if you squint it’s kind of okay).

    So, on a design where a footer anchor will work well for the small screen but I want the navigation at the top on larger screens (but where absolute or fixed positioning isn’t appropriate), I include the navigation twice in the markup (please, hear me out). On the default layout (mobile first), the top one isn’t shown, but the bottom one is, along with “go to nav” and “back to top” anchor links where appropriate. Then when the screen is large enough, the bottom one and anchor links are hidden and the top one is shown.

    One thing that always makes me scratch my head is what to label the “go to nav” anchor link. So far I’ve done no better than “Menu”. Also, I’m never sure what icon might be helpful to use next to it.

  4. This is a great breakdown and very useful. I attended Luke Wroblewski’s mobile first workshop yesterday and as he reviewed the navigation patterns it became clear that in my own site there was much room for improvement. We implemented the top nav pattern and on smartphones it’s taking up way too much space. Give ’em content – Not menus. (Looks like my site’s been that friend that been hanging around too much…)

    In the workshop there were also many, many questions about coordinating UI, design and development teams. Breaking out the patterns like you have is a great way to help kick start these early team planning meetings for a new responsive site. Thank You.

  5. Nice article! It might be worth noting that the select menu need not have a Javascript dependency if you duplicate elements, adding a list of links to the mobile site or a select box to the full site and show/hide. #pickyourevil

  6. We took the “top nav” approach on a recent site, but with a twist. On , you can see that the top nav (and secondary nav) exist but we’ve hidden the main page title on subpages, allowing the active menu item to serve as page title instead. Obviously this can’t work for sites with lots of pages, but it worked out nicely (at least, we think so) on this smaller site.

  7. I’m currently working on a site which by default will use the nav at bottom approach, with top anchor, as a fallback, but use the left slideout nav (w/swipe support) as the main nav. Also thinking about adding a left swipe as well, to reveal contact info for instance.

    Should work on any browser and progressively enhance the UX :)

  8. Great post indeed. In a recent project ( I combined the footer anchor and subnav items with a select menu. The select menu helped me to resolve a huge navigation bar. It was difficult to style, but I think the pulling up of native controls outweights the cons. Many thanks for sharing.

  9. Utwo

    Dind’t know that are so many ways… Thank you!

  10. Kevin

    Nice write up Brad.

  11. Thanks, great resource for upcoming projects!

  12. Christof

    What about using optgroup for select? How is the support for this? Admittedly no real 2 level nav support either as optgroup labels are not links but should be easy to add level 1 item as 1st item in each optgroup. Think this would be nicer than using “-” prefixes? Just don’t know how well mobile browser support is, IE9 on WP7 Mango does them well and nice it seems, have no Android or iOS around…

  13. Great article. Just want to point out that “the toggle” is missing from the table of contents

  14. Amazing post. Thanks for putting the time in. I never knew Starbucks had a responsive design!

  15. Great article never thought about categorising these responsive techniques or the pros and cons of each technique – thanks

  16. That top-menu, bottom anchor one is a great idea, I’m going to try implementing it soon. And the advantage is that you can just have a normal footer and then collapse the header at low screen widths.

  17. What do you think about the toggle I coded for ?

  18. well done

  19. Great post, to the point and very instructive! Among the plenty of posts about responsive web design this is one of the most useful at the moment

  20. This list rocks! I’d just like to point out that toggle menus don’t necessarily need javascript, but can be written with pure css and media queries.

  21. Responsive web designs are giving rise to an entire new for of web designing making your design more robust and device friendly.

  22. Great write-up. As ever, deciding which is best is a ‘it depends’ scenario so I imagine I’ll come back here to reconsider each time I need to implement one. Thanks for taking the time.

  23. Really well put together list of nav patterns Brad, love the comprehensive pros and cons for each technique. Bookmarked! I’ll be referring back to this post often. Well done!

  24. Alex White

    Thanks for the ideas. I’ve been looking into responsive web design for a while and have been debating on the best way to go about it. I’m not really a fan of any of the footer options. The select box is OK but I prefer either the facebook approach or the toggle approach.

  25. You practice what you preach. This post looks awesome in my droidx. Thanks for sharing your responsive knowledge.

  26. Great post! excellent to my next project!

  27. Great post! excellent for my next project!

  28. hello! very good work,excellent,

  29. Pascal

    With the “Obama” solution, il could also be used in a similar way to provide a wild screen solution.

  30. Very useful article and brilliament writing :)

  31. Tnx a lot!!! This was the right article to the right time for me :-)

    I tryed out all the above navs in my last projects, but the “one-and-only” is not borne yet. I think, it is a question of time – a lot op people use her smartphones now for interneting. They will lern fast…. the “confusing”-point in some navs is m.e. not the problem. For me it is more a question about – what will the customer say… :-)

    Btw: For my own work – i create my first responsive wordpress-theme: i prefer the “The Select Menu”.

  32. This is a great post. I recently had the dilemma of how I would display the navigation of a mobile version of a website. Initially I had it below the header but I had the height issue discussed in your post – users could not see any of the content below the navigations buttons. I opted instead to have it at the botom of the page, but I like the idea of the toggle that the Starbucks website uses.

  33. I’d go for either the Top Nav “Do Nothing” approach, or the menu toggle.

    Perhaps a poll would be really useful on this blog post to find out what developers like using :)

  34. Ed Charbeneau

    Brad, about a month or two back I tweeted you asking if you had a link to this exact type of article. Whether you saw the tweet or not, thank you for the post. This is an extremely insightful view of how to tackle mobile nav in a responsive site.

    “The Toggle” is my personal preference, and what will be used in most of my projects where larger menu systems are needed.

  35. joao polo

    To me, the new twitter bootstrap (bootstrap 2) presents a cool responsible layout, using a select menu on short displays, but a superb layout then item “the select menu” in this article.

  36. Awsome guide!

  37. Great write-up!

    I agree that The Toggle is the most elegant, but I think it’s problematic with subnav items. The Select Menu feels awkward too me. I prefer The Footer Anchor, at least when there is subnav items too.

    I wrote down some thoughts on these in

  38. How is this one.. Horizontal navigation and anything slider

  39. My question is: What do you call the Select Menu from within the site itself? Some examples use “Navigation.” Is that clear? Others use “Select a Page.” Is “page” accurate when, in fact, you may have major sections represented by the items in the menu and not simply pages? We’ve toyed with both “Menu” and “Sections” (the latter being the Boston Globe’s approach), but I’m not sure yet if either really resonates with users. And then, to make things more interesting, what do you call the level of navigation once you’re below the top level? Any advice is much appreciated.

  40. Hi Brad, thanks for putting this list together and sharing your thoughts – it’s super helpful.

    I designed and developed the Confab 2012 site you mentioned above. It’s the first responsive site I’ve built. You’re absolutely right – it does need some help in the navigation department. While it wasn’t a total do nothing approach (I changed the nav items to be larger, more spaced-apart and to look more button-like at small screen sizes), but that still doesn’t take care of the height issue you mentioned. That’s something that has always bothered me a bit and even though there is a highlight state to indicate the page a user is on, it doesn’t show enough of the page.

    I’ve since made the header/logo much smaller and that helps a bit, but I’m still pondering what method to go with. I’m leaning for the toggle approach but I want to make sure users know how to open the navigation easily. I think “menu” or “navigation” would work as a toggle word. Some sites simply show an arrow or 3 lines (like Starbucks) which I don’t think is very obvious.

    Anyway, It’s getting there!

    • Sean! You designed a hell of a website. I definitely don’t want you to think I was throwing your site under the bus. It’s a great site and the height issue is something that most of these responsive designs (including my own) deal with. These are all early days still and we’re all learning together, so keep up the excellent work!

  41. Very nice collection! The main problem for responsive navigations is the size and the whitespace between the navigation elements on mobile versions. Most developers know how to (re)place a navigation, but a lot of them don’t resize the elements and that’s the reason why the users have to touch a (too) small link…

  42. lukasz fiszer

    Recently I wanted to use a select menu navigation in one of my designs, but all existing plugins were based on jQuery. Using a whole heavy library just for one small piece of navigation, that’s not the best mobile friendly approach…

    So I decided to write my own plugin that would do the job. It is called selectnav.js and it’s lightweight (only 1.5kb), customizable and, of course, library independent. You can grab it from I hope it will be useful for some of you.

  43. ScreenOrigami

    As with everything in web design, the navigation pattern you choose depends on your project and target group. This is a great overview and resource. Thanks! :-)

  44. Food for thought for sure. I usually stick with the traditional NAV on top, but you called it that if a client wants to expand the categories, this can great quite the head ache.

    Good call.


  45. Teresa K

    Just what I needed today! Thank you, thank you, thank you.

  46. Illuminating, potent, and honestly – quite brilliant. One of the better posts on the topic I’ve read in months. Thanks for the enlightening mindset.

  47. A great write-up and I’m considering the toggle for our next site. We recently went with the Footer Anchor on our corporate site (the same one linked here to my name) and it works very well – intuitive and great device support, as well as fitting in well with our SOC.
    As for what to called the anchor – we just used ‘skip to menu’. Navigation as a word or concept doesn’t seem to be as recognisable generally.
    I thought it also worth mentioning that too often we don’t take advantage of the fact that mobiles can also be used as a telephone (gasp!) and it’s a good idea to include a prominent ‘call us’ link (we’re B2B).

  48. Great write up, Brad.

    I’d be interested in your rankings of best (or least worst) to worst solutions, perhaps with regard to presenting content and covering most mobiles.

  49. Great article.

    I just saw this from Smashing Mag; an interesting idea to “pull down for navigation.”

  50. we’re going through the process of converting a large content heavy site with 4 levels of navigation across to responsive.

    I’ll check back with the details.

  51. Great article! I’ve been looking for post like this..

  52. UX CD

    This is, as I see it, the biggest impediment to responsive design. I’ve seen literally dozens of sites and they work well as long as the navigation is very shallow (one or two levels deep), and the nomenclature is very concise. It becomes problematic when you have deep navigation (three, four or more levels), and large words. I feel this is something that the responsive evangelists step around. Many sites / blogs / gurus simply recommend that you collapse the nav levels. Problem solved! It’s not so easy. Sure, for your portfolio or design firm site, it’s fine, but most sites have navigation requirements well beyond “About Us”, “What We Do”, “Contact Us”, and copy written like haiku. You’ve done a great job of breaking down the various styles to date, but these are still limited, and not optimal for all experiences. This is a real challenge.

  53. Greetings from Florida! I’m bored at work so I decided to check out your website on my iphone during lunch break. I really like the information you provide here and can’t wait to take a look when I get home. I’m surprised at how fast your blog loaded on my phone .. I’m not even using WIFI, just 3G .. Anyways, great blog!

  54. I simply want to say I am new to blogging and site-building and seriously liked you’re blog. Almost certainly I’m likely to bookmark your blog post . You actually come with superb articles. Cheers for sharing with us your web-site.

  55. Jordicc

    I’m doing a WRD and using another type of approach. I put the menus (a 3 icons one and a classic hierarchical menu) before the footer. On the computer and tablet screen I positioned they up throuth CSS. And on the phone, let they be at hte bottom. Does it seems right?

  56. Tessa

    One thing to keep in mind when using the select menu method: mobile browsers render these dramatically differently. For example, my android renders select menus at 40px high, which is about double what you’d find in a desktop browser.

  57. Jeff Kraemer

    I second UX CD’s comment–these patterns work well for navs that are one of two levels deep.

    Brad (or anyone), have you seen any responsive navigation patterns that work well for three- or four-level navigation? I’m working on such a project, and it’s not possible to simply collapse the nav to two levels. I’m finding that it’s hard to avoid cramming the top of the screen with navigation at lower breakpoints.

  58. wonderful info. thank you!

  59. on my site ( I went for a “toggle”like approach – although I made it sticking it to the top (position fixed → no JS used here and degrades nicely) and expanding it in a (hopefully) pretty way.
    Furthermore the animation starts on :hover (which is tap on mobile devices) and the menu shrinks if you tap elsewhere. all in all it’s pretty unobtrusive and works on all mobile devices I tested it on (old android devices, galaxy nexus and iPhone)
    feel free to check it out 😉 (btw: in theory it degrades nicely, never encountered a device it doesn’t work on though ^^)

  60. Thanks for laying out all these nav options in one place. Very well thought out and very helpful for designing sites later. Thanks!

  61. Nice. Thanks for sharing this piece of information about navigation patterns.

  62. Thank you for this great post of various methods to implement responsive nav. I like that you have put in examples for each of your cases and that the pro and cons are also highly informative.

  63. Smilyan

    Please update the “Selectbox” as a means for navigation. More specifically, the part that says it is javascript dependant. Here is a way that it could be done with backward compatibility when javascript is turned off :)

    Thank you for the article.

    • The pattern still relies on Javascript to transform the navigation list into a select menu.

  64. Great post really helpful for a current responsive project, many thanks

  65. I think responsive navigation is the best way to go so no matter what device your visitor is on the navigation will look good. So one visitor could be on an iPod, one on a widescreen desktop computer, one on a laptop and one even looking at a big projector screen and they will all have a nice experience. Here are some great nav bars with and without a drop-down menu, and semi-transparent nav bars that will match any webpage background colour or design.


  66. This was all awesome… Just new to responsive websites, but it really helped a lot. Thanks

  67. Jhon

    Nice article, very usefull. Thanks!

  68. Wow, what a fantastic article. I’ve been scouring the web to see if I could find any opinion or tips on designing a navigation scheme for a mobile website that’s all on one page. I’ve got the site working pretty smoothly for desktops, with the links elegantly sliding you down the page to the appropriate section, and I can imagine it working for mobile devices ala a toggle that is “stuck” to the top of the screen. Has anyone seen this in use or have any advice on scripts I could check out that may help?

    I’m using a responsive framework (ala Foundation) that totally rocks. So, showing/hiding different elements is not a problem for different devices.

    Thanks so much!

  69. Awesome list. Thanks. Also used the bottom nav only with added top nav swipe. If they miss the top nav swipe, they are sure to get some nav at the bottom :)

  70. Gultekin

    That shows responsive design is a lot of hassle to fit the desktop design into smaller space. I think many people assume user experience is just about fitting the user experience of desktop to mobile. Then we look for workarounds. I’d rather do a mobile specific site. I am not omitting responsive design or seeing it unnecessary altogether but unless you have one menu with three options and no sub menu (slight exaggeration), and the smallest device is a tab, content need to be re-arranged and mobile users should have quicker access to content as they are generally moving.

  71. Great article. Looking forward to people coming up with new ideas for responsive and small screen navigation. I have uploaded a little JS app which will calculate the percentage widths of each navigation item for a responsive full width navigation. It was created out of necessity due to a lack of full width navigation websites out there at the moment –

  72. Thanks for the good advice. We are going to implement “the toggle” to our new responsive site.

  73. Great article, really usefull. Thanks!

  74. Marv

    Great post! Very useful, thanks.

  75. Thanks for this Brad. I just used the ‘Footer anchor’ method on a client site, and pointed them to your research in this post.

    Have a beer token.

  76. Hi Brad

    Following a link from azadcreative I happend to run into your site. The way you point out the pros and cons makes reading fun. Thanks a lot!

  77. nice article

  78. Excellent article. There are really a lot of ways a solve problem I didn’t have before this article :-)
    I like the starbucks-site example

  79. erictherobot

    amazing article! thank you!

  80. Just want to echo above – great article, good examples – my preference would be Starbucks – not that we’re there yet on our site which at the moment uses the first method… for now.

  81. Thank you very VERY much for this. We’re working on a new responsive design and have been looking for the starbucks menu version for a while. :)

  82. I read your site just so I can read your genuine writing form.

  83. Very very well written post Brad! And so useful for someone like me, who’s never before seen the various responsive nav methods compared, pros and cons. Thanks!

  84. littleguy

    Super excellent article! Amazing work!

  85. Great article, Brad. The examples, pros and cons are super helpful. Thanks, again.

  86. Great article, Brad. The examples, pros and cons are super helpful.

  87. Fantastic resource, thank you!

  88. This was very informative information Brad, thanks for updating us………..

  89. Subhash

    Thanks :)

    You saved me.

  90. Eric Mobley

    I really like the toggle method. Do you think the 3 horizontal bars has been used enough that users instinctively associate that with toggle navigation?

    By users I mean my mom or any user who doesn’t live and breath web design and digital marketing like you and I.

  91. Thanks a lot for posting “Responsive Navigation Patterns”.
    I actuallywill certainly end up being back again for alot more browsing and writing
    comments shortly. Thank you, Shanna

  92. Hi Brad, a great article, thanks a lot for posting!
    Even almost one year after you wrote the post, I found it very up to date and very fascinating!
    I promise to be back after trying out more…

  93. Joacim Nilsson

    Thanks Brad!

    I’ve found a descent solution to navigate. I think have the best example in use today with arrows. I could se this very easy to implement with an display:inline; and overflow:scroll; something like that:)

  94. Thanks for putting all of this info in one place! Great reference material =).

  95. Hi Brad,

    What do you think about a “Header Anchor” version of responsive navigation? Very similar with Footer Anchor method but when you press the Menu button you go Up instead of go a lot of pixels Down.

    In this way it`s naturally to keep the top navigation from desktop in the same place, instead of using some CSS tricks and the user will not be confused, because the navigation items are directly linked to the button that make them “appear”.

    And the page it`s loaded just below the menu (using javascript – that could cause some troubles).


  96. very useful info, thanks!

  97. Thanks for the wrap-up. This is truly helpful in developing sophisticated responsive webdesign for our internet agency’s website!

  98. Excellent thanks!

    For a site with 4-7 navigation items, I’m torn between The Toggle and The Footer Anchor. I agree the jump to the bottom can be jarring, but it does allow you to present a few more items.

    The Footer Anchor also has another “Pro” that you didn’t mention. When users get to the bottom of the page by scrolling, there’s no “dead end” – the links are right there for them to continue exploring the site.

    Do you know of any sites where they have combined a Toggle Menu at the top, with the menu repeated again in the footer? It’s a little inelegant to repeat the menu twice, but I think more people will use the menu at the bottom than will use the “back to top” link to get back to the navigation.

  99. Joseph Dickson

    “Reverie” a WordPress theme switched recently from a Fly Out menu to a Toggle.

    Probably a result of rendering glitches on the Fly Out, and design limitations.

    Toggle is their new choice and it is much smoother and not so alien to new users.

    Check it out

  100. Very timely as I am currently working on a responsive layout. Thanks a bunch!

Comments are closed for this post. If you've got something to add, feel free to reach out on Twitter.