: 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

@Angie364

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.


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.
It would be good to have the option to expand and collapse the options on the right, whenever the navigation is overflowing.
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.
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.





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.

Vote Up Vote Down

@Murray976

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!

Vote Up Vote Down

@Shelley591

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.

Vote Up Vote Down

@Radia289

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.

Vote Up Vote Down