Critique: Scrollable flyout nav menu

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.


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.

Source : Link , Question Author : Brendan , Answer Author : Yisela

Leave a Comment