Critique: Scrollable flyout nav menu

Question

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:

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:

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.

UPDATE:

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.

Answer 1

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:

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.

Answer 2

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.

UPDATE:

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.

Answer 3

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.

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

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!

Answer 4

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:
   
   
   
   Hovered State:
   
   
   
   Multi-Level 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.

---

5. 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() {
       $('#main-menu').removeClass('full-size').addClass('condensed-size');
       $('#flex-nav').removeClass('full-size').addClass('condensed-size');
       ...
   

   You could have:

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

   Again, it's a nice design overall already.