Bring back hovering

Problem to solve

Finding a page using the sidebar requires clicking on a collection to expand it. For users that frequently switch around projects, or are looking for something this can be cumbersome.

My biggest gripe with the new navigation is that accessing any page via the sidebar with my cursor now requires 2 clicks instead of The best functionality about the old sidebar was that it would, on hover, show you all the sub-items. Now, I have to click once to enable the sub-menu and then another time to go to the page I need. - #409005 (comment 1412420491)

New design should make people do less clicks to reach frequently used places, not more. - #409005 (comment 1420861858)

Before I could mouse-over and click to the submenu item I want to navigate to, now I have to click twice. One additional click -> bad user experience and effort to achieve my goal. - #409005 (comment 1417405852)

The main thing I keep doing is checking the commits graph, very nice feature. Now I seem to have to click 3 times instead of 2 to get there. - #409005 (comment 1417173627)

It was easier before when "Merge requests" and "Pipelines" was directly clickable. Now we are two clicks away from both of them. - #409005 (comment 1417120394)

Proposal

We could address this by changing the orientation of the chevrons and adding a menu that appears on :hover like the old navigation

Implementation plan

Bring back hovering - 1st iteration (behind fea... (!124863 - merged)

• On medium viewports and larger (>768px), replace the collapsible menus in the sidebar with fly-out menus that open to the right on hover.
• Leave the experience unchanged on smaller viewports.
• Everything should still work for touch inputs regardless of screen size.

Still to-do in follow-up MR(s)

• Add tolerance for diagonal mouse movement from ... (#419813 - closed), see !124863 (comment 1449966208).
• Fix flyout menu behavior when new sidebar is in... (#419769 - closed), see !124863 (comment 1458946098) and !124863 (comment 1462142469). !127621 (merged)
• Don't open flyout directly after collapsing a section, see !124863 (comment 1458809901) and !124863 (comment 1462142465). !127487 (merged)
• Try to prevent overflow on screens with very small height but large flyout, see !124863 (comment 1462142472). !127398 (merged)
• Improve test coverage of new code, see !124863 (comment 1465757270) and !124863 (comment 1465757292).
• Technical debt: Avoid changing props here: !124863 (comment 1465757243)
• Refactor feature flag assignment in tests: !124863 (comment 1472630065)

changed milestone to %Next 1-3 releases

added Category:Navigation & Settings Navigation redesign Technical Writing UX devopsmanage featureenhancement frontend groupfoundations sectiondev severity4 typefeature workflowdesign + 1 deleted label

assigned to @aregnery

added 1 deleted label and removed 1 deleted label

added severity3 label and removed severity4 label

mentioned in issue gitlab-org/manage/foundations/team-tasks#256

mentioned in issue #406285 (closed)

removed Technical Writing label

@pgascouvaillancourt could you look at weighting this please?

I added a basic implementation plan and weighted this to a 2

@samdbeckham / @cdybenko now that there is a weight. Do we want to move this from %Next 1-3 releases to %16.2?

Good spot @aregnery I assumed it was already there.

@aregnery What are our plans regarding mobile devices? In the old navigation, a recurring issue was that you could not access a sub-section directly on mobile due to the lack of hover state. You needed to access the parent section first in order for its children to be expanded, then click on the correct sub-section.

If we are going to reintroduce the hover state, it'd be great to not harm the mobile experience the same way. I guess that the most obvious workaround would be to replace the hover event with a click/tap when the former isn't supported, but having the sub-menu pop-out to the right might still be troublesome in narrower viewports. WDYT?

Yes agreed @pgascouvaillancourt. Looks like when the breakpoint hits <769 the :hover interaction no longer is possible. What do you think about just starting from there?

starting from there?

@aregnery to clarify, we'd leave the experience as-is until the 768px mark. Above that, we'd apply the new designs with hover state? Sounds good to me

Yes, exactly @pgascouvaillancourt

@pgascouvaillancourt @aregnery I want to point out that touch input and screen size are independent things. The iPad pro is 1024px wide with touch inputs, and the resized window on my mac is 520px with mouse input. We should make sure the navigation works for touch inputs regardless of screen size.

Absolutely @samdbeckham. The breakpoint approach is at best a first iteration. Ideally, we'd detect the devices capabilities and fall back to click events when the device does not support hover. I don't think I've seen this sort of feature detection in GitLab yet though, so maybe this warrants a whole new issue. Maybe we could consider exploring the ability to open the sidebar on swipe at the same time. WDYT @aregnery?

@pgascouvaillancourt the only place I can thin of replacing click for hover is with pinning. So if we should isolate that to a separate issue, then that totally makes sense to me.

Question: Would you open one and give a high level implementation perspective on doing that kind of swap?

added workflowplanning breakdown label and removed workflowdesign label

unassigned @aregnery

changed the description

set weight to 2

added workflowready for development label and removed workflowplanning breakdown label

changed milestone to %16.2

changed the description

mentioned in issue gitlab-org/manage/foundations/team-tasks#272

assigned to @thutterer

created branch 415343-bring-back-hovering to address this issue

mentioned in merge request !124863 (merged)

mentioned in issue #409005 (closed)

added workflowin dev label and removed workflowready for development label

@aregnery I started working on this today, !124863 (merged), and have a quick question:

What should happen when I click the section title? At that point, the flyout is visible. Should a click on the title:

1. close the flyout and expand the section (as currently implemented in my draft)
2. navigate to the first item (as currently implemented in the old navigation)

Option 1 feels a bit better to me, but I could image some users also liking option 2. WDYT?

Let's start with closing the flyout and expanding the section @thutterer

mentioned in merge request !125082 (merged)

mentioned in issue gitlab-org/manage/foundations/team-tasks#277

mentioned in issue gitlab-org/manage/foundations/team-tasks#278

mentioned in issue #417237 (closed)

mentioned in issue gitlab-org/manage/foundations/team-tasks#280

Why not just open all the sidebar pages by default and let the user collapse them. Maybe if the screen height is larger than some value?

This combines the best part of having a sidebar (all interaction remains inside it), and the old single-click usage. IMHO.

The same way you track the pinned elements, you could also track the collapsed sections and keep them collapsed on page load.

marked the checklist item On medium viewports and larger (>768px), replace the collapsible menus in the sidebar with fly-out menus that open to the right on hover. as completed

marked the checklist item Leave the experience unchanged on smaller viewports. as completed

marked the checklist item Everything should still work for touch inputs regardless of screen size. as completed

As for the Make it work while the sidebar is in "peek" mode item, I think we may also want to look into avoiding extra clicks for the viewport is < 768px wide. Extra clicks seems to be one of the more common complaints in the feedback issue.

WDYT, @aregnery @thutterer?

I wonder if reimplementing the squashed/thin sidebar, as it is on the old nav, is the best approach That's a fair amount of work though, probably.

I wonder if reimplementing the squashed/thin sidebar, as it is on the old nav, is the best approach

#389958 - The biggest downside to the sidebar rail is we can't squeeze everything into it neatly. At some point, things will have to be cut.

@markrian I think we need to work through #415856 (closed) to figure out things like this. Also, maybe only making peek possible with #402488 (closed) might suffice.

@aregnery I'm considering bringing #415856 (closed) into %16.3 in our planning today. Would this be mostly on design or engineering to find the right breakpoints?

@cdybenko I didn't see anything in the agenda on the topic, but I'd say the behaviors of the breakpoints should be first set by designers in #415856 (closed) and then engineering can give us their take on the feasiblity of the targets.

re-labelling as workflowin review as it's been in review for a couple weeks already.

@thutterer Try to stay on top of these labels please. They help us with planning and seeing where things are at a glance

added workflowin review label and removed workflowin dev label

mentioned in issue gitlab-org/manage/foundations/team-tasks#282

changed the description

changed the description

changed the description

changed milestone to %16.3

added missed:16.2 label

mentioned in issue gitlab-org/manage/foundations/team-tasks#284

mentioned in commit 4852707f

@thutterer looking at all the items in still to do this looks like a much bigger weight than the 2 it has currently. What do you think about splitting this one up and weighting accordingly?

@samdbeckham Yeah, all details considered, it's more than a 2 for sure now

Splitting off some chuncks is a good idea. I just didn't want to split off too fine-grained too early either, so I opened !127398 (merged) as a quick follow-up today. I have another one in the works for tomorrow, but latest after that, I'll create proper issues for "Add tolerance for diagonal mouse movement" and the "Make it work while the sidebar is in peek mode" items.

mentioned in merge request !127398 (merged)

mentioned in merge request !127487 (merged)

changed the description