New PF4 Navigation

@MariaAga dark grey looks weird. I meant more like #F0F0F0 which is lighter and closer to white than to grey.

Reports (section name) look somehow bigger and bolded than other items. Group names should be smaller, look here.

The flyout is a menu so it takes this style: https://www.patternfly.org/v4/components/menu/#with-titled-groups
Should I change it?
New white-grey divider: (accidentally missing one div in the monitor)

Thanks, it looks better. I agree that it’s a bit confusing from which first-level item stems the second-level menu but I was told that the interaction is clearer in a clickable prototype and not in a static screenshot. (@ekohl )
I contacted the designer that works on the nav design, she also suggested the usage of blue lines (the same color as a hovered state). So I’m playing now in the sandbox to see if that’s the solution.

Here the group name is 14 px, item name 16 px, and a bit different color so the group name doesn’t look more prominent than items.

I said it might. I haven’t tested it myself just yet.

Processing: Hardware Models.mp4…
Thanks @MariaAga for enabling the discussion, overall I really liked it, though there are few things that we need to adjust in my opinion, here are my 2 cents:

I like the older menu’s width which was smaller 200px vs 250px, and I kinda liked the arrow that used to be there though I can live without it :slight_smile:

new:
new-nav

old:
old-nav


another thing which might need a bit fixing is the margin / padding of the secondary-nav headers,
new one: 16+8+8 = 32px
old one: 18px

look at the secondary menu padding above “Monitor”:
new:
Screenshot (41)

old:
gnome-shell-screenshot-FPYPB1


Hovering items background, personally I prefer the dark one so it doesn’t mix with the page content.

Before, we used a dark background when hovering items:
gnome-shell-screenshot-Q9USB1

In the new version we use a white light background
gnome-shell-screenshot-OZ9XB1


The last thing, on my laptop screen the “Content” menu which is quite long, makes a scrollbar appear and it looks like you can never reach its ends, in the older version there’s no need for a scrollbar and the page didn’t “jump”.Maybe when fixing the padding there will be more space, or maybe we need to split this menu into more categories.

new:

old:

Hi, some of the parts you are referring to are out of date, can you look at the new screenshots in this thread? Also the arrow should appear after “npm i”.
And the scroll is broken currently.

Just adding my comment from Gchat, so we won’t lose it.
So I met with other designers and described our issues in the nav. They pushed rather for tertiary nav than overriding PF4 patterns.
So e.g. the host nav would look like this:

Primary > Secondary > Tertiary

Hosts > All hosts
Discovered hosts
Create Host
Content Hosts
Host Collection
Register Host
Provisioning Setup >
Templates >
Compliance >

There are content issues in the nav which we could address in the next release and make it better. (based on next year research in initiatives) Also there were voices for implementing menu search.

That formatting looks off. So it would be:

Hosts
  Hosts
    All Hosts
    Create Host
    Register Host
  Provisioning Setup
    Architectures
    Hardware Models
    Installation Media
    Operating Systems
  Templates
    Partition Tables
    Provisioning Templates

Would I need to expand the second level as well? That feels like a step back in usability. Is there any reasoning provided why a tertiary level would be better?

Yes so a user will have to expand Hosts, and then expend Templates to get to “Provisioning Templates”.
This was the solution that was suggested by PF4 to address the “long menu” issue Ron described, where in the new design some of the menus will need scroll as their height only starts in the middle of the page.

Sorry, I haven’t noticed incorrect formatting. Here it is:


The point was to have the entire Host section in a second level (better discoverability) and the rest in the third level. Maria is correct about reasoning.
In 7.1. we should address navigation content, which needs some UX love (based on some previous research), but for now, let’s just implement the PF4 pattern.
It’s a flyout so there is not much time lost in hovering on the secondary item to see tertiary content.

I still miss the reasoning that we need to change the current menu. Other than that it isn’t PF4, what’s wrong with it?

The reasons are:

  1. We want to stop using pf3 as its not supported anymore.
  2. We want to maybe use a new design that will be easier for a user to use.

That still doesn’t describe any problems with the current menu. If you’re talking about easier to use, there must be specific areas that you think can improve.

Maybe it’s just a trauma that I have with fly-out menus. A long time ago Foreman had a fly-out menu that frequently annoyed me. Mostly when it lost focus if I moved my mouse to the wrong place. It was replaced with the current menu and that has always felt good to me. It’s been clear and predictable in its behavior.

Lets differentiate between two issues here:

  1. The current menu uses components from Patternfly 3 which is no longer supported and is technical debt we should get rid of. I’m not sure what part exactly of the menu (both behaviour and design wise) we get from the Patternfly 3 component and what we implement ourselves, and if it is different with regards to the PF4 components. We could decide to either switch the components to Patternfly 4 components, or build our own. This decision, imho, should depend heavily on how much we get from the PF4 components and how much we need to implement on our own.
  2. Patternfly 4 contains some recommended patterns and designs that have undergone user testing and research. However, in this case it seems that the designs they propose do not give a good enough solution for our usecase. We can decide to either continue the discussion with the PF team and reach a better solution, or decide to ignore their proposed designs (or part of it) and override some of the styling to better fit our use cases.

Additionally, we might be able to reduce some of the issues by reorganizing the actual menu tree - something we’ve discussed several times in the past but never actually done.

I don’t like how “Content Hosts” are under Hosts and not under “Content”. But I am sure others will prefer it the way it is. :stuck_out_tongue_winking_eye:

AFAIK the idea is that the new host detail page will merge it all to “hosts”. Eventually we should end up with a single host overview and a single host detail page. Some hosts just happen to have content and the pages will reflect this.

2 Likes

That will be nice, when we get to this “eventually” land! :stuck_out_tongue_winking_eye:

Wanted to also mention here that in this new design there won’t be a “compact nav” option like we have with the icon navigation:

1 Like

It’s better to think about Content Hosts more as “Hosts which consume Content”. Then it sits better under the Hosts menu.

But as others have said, this should eventually be solved when the grand unification of Hosts pages happens. (Can’t come soon enough in my book).

That’d be a shame, I really like the compact mode as it wastes less screen for me on my laptop. :frowning: