Navigation problems with Tertiary nav widget on mobile

[andreasn]

We're trying to use the tertiary widget in our project (Cockpit), and we're having some navigation issues, especially on mobile.
It's very hard to get a good overview of all the items, the arrows have very small hit targets, that if I hit them gives a somewhat unsatisfactory behavior (so sorry for the vagueness, but I have a hard time putting my finger on what it is. I think it's something that it reveals the items little by little, but not sure).

I want to create a property where it does not do overflow: hidden; and just show all items inline after each other.
Any good pointers for how I can create that?

[andreasn]

So my thinking was
To remove:
display: inline-flex; from .pf-c-nav__tertiary-list

And add:
display: inline; to .pf-c-nav__tertiary-list .pf-c-nav__item

and then display: none; to the buttons somehow.

[andreasn]

Here is the design we're aiming at. See the section Mobile sizes

[garrett]

We'd want flex-wrap: wrap;; the inline-flex vs. flex probably doesn't matter.

In IRC yesterday, we were thinking about suggesting 3 different overflow styles for the nav (and probably for tabs too):

• wrap
• overflow menu (something that Firefox and Epiphany have at the side of their tabs, noted with a down caret)
• overflow scroll (which is what it is now)

The overflow wrap or menu would be preferred to be a default versus scroll. The UI/UX of scroll is really very bad for a ton of reasons.

Here's a tertiary navigation in mobile width:

It's impossible to know how many items there are or to quickly switch to any others. In fact, some people would even think there are only 2 items. They may easily miss the > icon or think it's for something else.

Here's the unscrolled version:

There are 10 items! And someone would have to know to tap the tiny icon and also tap that icon a lot of times to get anywhere on that list.

So that's why I'm suggesting overflowing the tertiary navigation instead of making it scroll as it currently does. We want people to understand our applications and interact with them, not do some meta-interaction chore of tapping several times to see and interact with parts of our UIs.

For PatternFly, as different applications have different needs, it would be nice to have something like pf-m-overflow-wrap, pf-m-overflow-menu, pf-m-overflow-scroll classes (with one of the non-scroll ones by default, optimally) and appropriate React widget attributes.

[mcoker]

Hey @garrett and @andreasn. We recently overhauled the tabs component and it looks like the design may solve some of the problems with the scroll buttons. They're more clearly defined and always visible when there is overflow content.

PR - patternfly/patternfly#2757
Demo - https://patternfly-next-pr-2757.surge.sh/documentation/core/components/tabs

cc @mcarrano what do you think about the design issue above and @garrett's suggestion of alternate layouts?

[garrett]

@mcoker: Thanks for the update! I like what I see on the revised tabs. Great work! 👍 Hopefully we'll be able to use it in a release very soon. (Is there a way to use it in a pre-release / beta version for the tabs? Or is it in the next PF4 version already?)

[mcarrano]

@garrett I think you raise some very valid issues about the usability of scrolled tabs in the context of a mobile app. I'd want to investigate this more in the context of a screen like you have above.

@mcoker if you feel like there is nothing more to do here from a Core perspective, please feel free to transfer this issue over to design.

[mcoker]

@garrett that's great to hear! If you use core directly, the code is available in this pre-release version - https://github.com/patternfly/patternfly/releases/tag/prerelease-v4.3.6.

If you're using react, we have an issue open to introduce this work in patternfly/patternfly-react#3951. That work will be available in a pre-release version you can use to test until it's released in the next major version of patternfly, which we're targeting for mid-May.

[mcoker]

@mcarrano transferred the issue.