I'm working on a new nav menu for my company's web app. I took loose inspiration from Google's material design tabs where, upon page overflow, arrows appear and the tab section is horizontally scrollable:

Nav menu screenshot

After coming up with this solution, I had to make a decision about how to handle submenu content. While I do believe that not having submenus would be the best solution, that's not on the table at the moment. So, I'm left with either traditional dropdown menus (that would have to be worked out with JavaScript due to overflow: hidden issues pertaining to how I built the tab area), or the idea that I came up with:

Flyout screenshot

Here's a Codepen to play with.

I'm calling it a flyout menu, though the term does exist to describe patterns that are similar but different.

Technically, it's a simpler solution. And because tab overflow is handled, it's not going to break the layout by working the way it does. However, because it is relatively novel (correct me if I'm wrong; I can't recall using a menu designed like this before), I'm concerned that it will be confusing to less technical users.

I'm asking for a critique of my flyout menu from a design perspective (as opposed to a technical one; there are some Codepen quirks and some beta quirks as welll). Is it relatively intuitive to use? When clicked, does the design provide enough feedback for a user to notice that the flyout happened? Does it mess with the convention that 'submenus are vertical lists' too much?

Any critiquing is much appreciated.


Thanks to all for your feedback! I left out some details that feel important after reading the answers and comments.

First, not everyone gets the full menu here. Teachers might only get the first two, while an admin would get all of the modules. Someone in admissions could theoretically only get students, admissions, and alumni. So, the people who get more options have a better chance of being a power user who can grasp this stuff pretty easily.

As it was mentioned, horizontal menus can get wrecked when feature creep happens. Rather than fight that battle which I didn't think I could win, I thought it'd be more prudent to account for the situation. Also, as it stands, the scroll doesn't trigger on the top-level nav until the screen is under 1000px wide. There are not a lot of desktop monitors left that are under 1024. Plenty of touch browsers could be, but people are more comfortable with the idea of scrolling as well as swiping to scroll there.

This could rightfully attract some 'graceful degredation' complaints, but I didn't think the experience was irreparably degraded. If a flyout menu causes arrows to appear, that should be a pretty solid hint that you need to scroll.

  • 1
    From a design point of view the function and aesthetics are super. My only critique is it's responsive-ness. Looks perfect on a 27" iMac but I'c scaled it to a 13" MacBook and it goes odd. Even scaling it further down, there is some awkward design rules in terms of the typography. But on a whole, looks fab. Commented Jan 27, 2015 at 17:02
  • 1
    On small screens the horizontal navigation is pretty much unusable. I'd recommend doing sub menus before doing something like that Commented Jan 27, 2015 at 17:47
  • 1
    @Nit - Criticism is expected, but I would hope that you could at least delve into the "why" a bit! Feel free to post an answer :)
    – Brendan
    Commented Jan 27, 2015 at 19:07
  • 1
    Remember that screen size isn't a direct correlation to viewport size--especially on the desktop.
    – DA01
    Commented Feb 3, 2015 at 16:04
  • 2
    Not sure if it's been mentioned, but when I click the sub-menus, and things instantly move around, it's easy to "lose" something. I would encourage just a fast and simple expand/collapse animation so that your eye has something to follow. The abruptness really throws me off.
    – Hanna
    Commented Feb 3, 2015 at 20:02

4 Answers 4


I think for a single level, the menu is perfect. It's the sub-menu that I believe might have some usability issues when it comes to people not so familiar with different types of navigation.

Some observations:

The arrows make it clear that you can scroll horizontally, and although you said you are still playing with the implementation, their size can be a problem (especially for mobile). To help with this you could make the whole row draggable, or scrollable by mouse if you are on top of it.

The sub-categories look really nice, but the color is a bit too similar to the un-opened state, which confused me a little when I clicked on "Students" and the sub-menu used the whole horizontal space. I didn't know if I was still on the main nav or not, because I didn't remember the original navigation.

Something you could try to help in distinguishing when you are in a sub-menu is use for example a color line, or just a color, going from "Student" to the last sub-menu item. That way you will know for sure you are inside a category:

enter image description here

Clicking on the category item should also close the sub-menu, but I think this is just an implementation issue that you probably have in mind.

  • Thanks for your feedback! The row is draggable on mobile and should be scrollable on desktop - do let me know if that's not the case. I do agree that more visual cues for the submenu can be given and will work on that.
    – Brendan
    Commented Feb 3, 2015 at 15:48

A scrollable menu makes sense on a phone where you have limited screen real estate and an easy intuitive touch-to-swipe UI.

A scrollable menu on a desktop web site, however, is just a way to hide navigation. It's not all that usable.

Having to use a mouse to scroll back and forth to find the particular menu item I am looking for is not a good user experience.

I will say you implemented it wonderfully. It's smooth, looks great, nice typography. But from a usability standpoint, I think it suffers. In general, you never want to use tabs if they have to extend beyond the real estate you have. This tends to always be the problem with horizontal menus. What fits initially soon doesn't as powers-that-be decide to add more and more options after the fact.


If there's no way around it, though...I'd suggest considering using the 'swipe to slide/scroll' option only on touch devices. On non-touch devices, I'd suggest using the [...] menu concept where you fit as many menu options as you can horizontally, with the last option being a [...] button (or the like) that then reveals the remainder of navigation options that wouldn't fit into one drop down menu. Still not ideal, but likely more usable on a non-touch device than the scrolling option.

  • Thanks for the feedback! Check out the Pen on mobile - it does scroll on swipe there. I thought about making it mouse-draggable, but I figured that the scroll is less likely to pop there, and the arrows are easier to click with a mouse than touch with a finger. I'm not opposed to the the "More" menu option, but we liked the idea of consistency between breakpoints, and dealing with submenus would be become more problematic. See my edits for some further explanation. Your usability concerns are certainly valid but I think that the occurrences of scrollable navs on the desktop will be rare.
    – Brendan
    Commented Feb 3, 2015 at 15:45
  • Given your updates, I'd say there are further options to consider. If the menu is only large for certain users, then how about sub menus that target that particular usage? My main concern with scrollable menu on the desktop is simply that it hides options behind multiple mouse interactions. That's usually not a good thing for your primary navigation.
    – DA01
    Commented Feb 3, 2015 at 16:03

In addition to the great advice Yisela offers and the comments by DA01, I'll add a couple points.

Users won't intuitively know they can drag to scroll - It's not immediately obvious that it's a horizontal menu, it's even less obvious that one can use touch and throw to navigate it. I'm not sure how you could remedy this besides showing users a helpful hint the first time they use it. Side note: You should enable click and drag functionality in addition to just touch.

Judging from what I think the app will be used for, one user won't need all of the options - It seems that there are different categories of users (students, admin, etc.) and that certain links are less applicable to one category of users than to others. Making the ones who won't even use the link scroll a good bit because of the links they don't need is bad practice.

Increased need of clicks (or dragging) reduce the use of that feature - Since, in some circumstances, users have to click the navigation arrows (or touch and drag, but let's face it - all users won't do this) twice before they can click their option, the cost of going to that page is much higher and users will consciously think about it being annoying to have to do so. That's never what we want as designers. Even touching and dragging would become painful if users have to do it often.

Here is the navigation at 330px wide (the minimum width for smart phones). You can see it takes two clicks of the right button to get there.

mobile nav

There's also an awkward size when the navigation isn't in it's full mobile version where the same thing happens.

awkward size

Regardless of whether or not you get this functioning a little bit better, I think it would be better off to go with a drop down menu or something similar. It's more intuitive and would most likely be better for user flow as well.

Another note is that the user buttons (under Addison Admin) are too small - touch users will have a tough time clicking them. The icons also are not very recognizable (I thought the sign out button was a share button, the change password button was a settings button, and the left one was something for analytics). I realize there are hover options with the title, but touch users won't see these and it's best not to rely on them.

With that being said, I do think that once this is cleaned up a bit it will be a very attractive navigation. I just hope it remains usable!

  • Thanks for your feedback! The user buttons will probably end up getting reworked a bit - I don't think it's necessary for "Change Password" to get such a prominent view and hope to get it incorporated into other settings. If we're down to two icons, I can maybe do away with icons entirely and just link the name and add a text "Log out" link. We'll see how that goes.
    – Brendan
    Commented Feb 3, 2015 at 16:06
  • As for the menu itself, I agree that, as it stands, there isn't enough to definitively let the user know that he can scroll. I think I can make some improvements without having to completely scrap the concept, though. And, I think that if people are inclined to swipe scroll the menu rather than click the buttons, the concern about multiple clicks goes away. I don't know if there's any research on this, but one swipe versus a click into a sandwich menu (a false dilemma, but a realistic one at this stage of the process) are probably pretty equivalent.
    – Brendan
    Commented Feb 3, 2015 at 16:06
  • 1
    Zach: What did you use to make those screen recordings? That's slick!
    – DA01
    Commented Feb 5, 2015 at 0:00
  • 2
    @DA01 I use Gifcam. There are others, but this is the most pleasant to use that I've tried so far :) Commented Feb 5, 2015 at 1:44

I quite like a lot of it, it's a nice design. I also prefer the minimised version. I think you need to tweak the whitespace around the name on a 'micro' level to make it more comfortable. I also think the font size should be 10 - 30% larger for the name.

All points made so far have been pretty good. I have some observations of my own, as well as some based on the answers of others.

  1. When the navigation bar is overflowing, and in its left most position, the arrow to go left should disappear. The same obviously goes for when it's in its right most position, the right arrow should disappear.

  2. It would be good to have the option to expand and collapse the options on the right, whenever the navigation is overflowing.

  3. I think the inline second level is an interesting and inspired idea, but as much as I like it, I'd have to rule it out for any site with a serious purpose. If this site is in regular use, it really should have an optimal user experience. The inline navigation just isn't the optimal option. Yes, users could still use it, but I'm 99% certain that there are implementations that they would be able to understand and use better/easier.

  4. Instead of having the options inline next to their parent option, you could place them in a row underneath, still inline with each other, but underneath the parent.

    Ex. Previous Website Design of Alfred Dunhill

    Unhovered State:

    Old Dunhill Navigation Bar

    Hovered State:

    Old Dunhill Navigation Bar in Hovered State

    Multi-Level Hovered State:

    Old Dunhill Secondary Navigation Bar in Hovered State

    It would allow for additional levels of navigation to easily be added later aswell. As you can see with the third example. I see that as a benefit for the type of site you're working on.

    I actually don't like it as a choice for their website, but I think it's a good option for what you're doing.

    You could even keep the exact same structure in your HTML, and just change some CSS, grab it with jQuery after page load, and appendTo() the parent parent parent ... container.

    If you've got your heart set on the inline navigation, Yisela's answer is the perfect enhancement.

  1. On a slightly off-topic note, I noticed in your jQuery code that you've duplicated the code for some functions unnecessarily. jQuery allows for multiple separate selectors to be specified like CSS. For example:

    Where you have:

    function minimizeMenuBar() {

    You could have:

    function minimizeMenuBar() {
        $('#main-menu, #flex-nav').removeClass('full-size').addClass('condensed-size');

    Again, it's a nice design overall already.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.