Website Navigation Bar Hovering Issues

[bkunst1991 (Berengere Kunst)]

Hello,

Just a regular Fedora User here.

I wanted to give my feedback about the navigation bar at fedoraproject.org and start a discussion about its user interaction. I have the feeling that using the mouse-hovering to display section/subsections does not make for a pleasant experience compared to single click as the user has to carefully move his mouse to avoid hovering an unintended section by mistake.

Here is an example workflow based on my experience:

• Hover Get Fedora, the detailed navigation panel appears

• Move the mouse to Editions

=> Now if you trace a straight line from “Get Fedora” to “Editions” you endup on the blue header bar and the entire menu disappears. In order to do it properly, the user has the move his mouse down first and then left.

Same happens when I hover “Atomic Desktop”. I then have to carefull move my mouse to the right to avoid touching “Editions” or “Spins” as it would cause the entire section I want to interact with to disappear and be replaced by another one.

This adds an unnecessary level of complexity as most of my interactions have to be redone at least twice.

I checked a previous version of the site that was one year old and it was using single-click for its interaction. Is there a specific reason for this change? Would it be possible to start a discussion about dropping hovering entirely and restoring the single-clicks only mode?

Thanks for reading.

[glb (Gregory Lee Bartholomew)]

There was an older version of the site that used javascript instead of CSS for the nav menus (I think it was a bit more than a year ago, but I’m not sure). We had several complaints about requiring javascript, so that menu was redone using CSS and that is when the hover navigation was added. You can still click on things to pin your selection.

Edit: I see that it is a bit twitchy if you don’t go straight down from the menu. I think something else was changed somewhere along the line because I don’t believe the menu used to disappear like that if you tried to go straight from Get Fedora to Editions. I’ll see if I can fix that.

[bkunst1991 (Berengere Kunst)]

I see. Thanks for the explanation.
Yes the menu disappearing is actually the main issue for me as it resets the pins.
Thanks for the quick answer. I really like the fedora website. One of the best there is out there.

[glb (Gregory Lee Bartholomew)]

I’ve submitted a potential workaround: nav: extend the hover region of the get fedora menu button (!1024) · Merge requests · fedora / Fedora Websites and Apps / Fedora Websites / fedora-websites-3.0 · GitLab

Edit: If you want to test this out, this link should work, at least while the build preview exists (I think the preview builds get purged shortly after the MR is merged.)

Edit2: I’m not sure I like the way it causes that large menu to appear when the user moves their mouse down from the browser’s bookmarks bar. It might be better if that phantom div’s pointer-events were initially disabled (so it wouldn’t do anything) and then it was only activated when the user hovered over “Get Fedora”. Maybe it could be set to go back to inactive after a short delay. It’d be a bit more code, but I might give something like that a try.

Edit3: I’ve added the pointer-events toggling so the phantom div’s effect will only appear when transitioning off the “Get Fedora” button. New build preview: Fedora Linux | The Fedora Project

[bkunst1991 (Berengere Kunst)]

Thanks for the preview.
Unfortunately, I think there are still some issues with the hovering:

• The phantom div seems to be linked to the “Get Fedora” section. If I hover on “Contributors”, move down to the menu and then hover by accident on the phantom div, it will activate “Get Fedora” instead of keeping “Contributors” active.
• Clicking on “Get Fedora” will pin the menu, thus making the phantom div always present. If I move down the mouse (making the menu disappear), hovering anywhere in the phantom div will make it reappear.
• Unrelated to your change: Pins do not seem to propagate from sections to subsections. Clicking on “Get Fedora” will pin it, thus disabling hovering for the other elements as expected, but then clicking on “Atomic Desktop” will disable the “Get Fedora” pin and thus hovering on “Contributors” will change the menu.
• Minor: The entire menu is not changing the cursor to “pointer” for clickable items.

My css is a bit rusty, so I struggle to see what the ideal solution should be. This might be a matter of personal preference, but I still believe a click-only scenario would be far simpler to implement and maintain:

• Click on a section to make the menu appear
• Click on the subsections to navigate
• Click on a close icon, outside of the menu or on the pinned section to make the menu disappear

[glb (Gregory Lee Bartholomew)]

The entire menu navigation concept (highlights/focus on hover, pointer type, etc.) is suppose to imitate the default behavior of the bookmarks menubar. (Firefox and Chrome exhibit the same behaviors, I’m not sure about Safari, I’m not a Apple user.) But the implementation is admittedly crude and I’m happy to fine tune it.

Turning off hover completely seems like a more drastic change, but we can poll the community about it and see what people think.

@bkunst1991

Unrelated to your change: Pins do not seem to propagate from sections to subsections. Clicking on “Get Fedora” will pin it, thus disabling hovering for the other elements as expected, but then clicking on “Atomic Desktop” will disable the “Get Fedora” pin and thus hovering on “Contributors” will change the menu.

There is a variable that holds the state information about what menu item was last clicked. Just creating more variables to hold more button states should be enough to fix the problem of clicks on the secondary menu overwriting the record of what button was last clicked on the primary menu. I’ll look into it.

[bkunst1991 (Berengere Kunst)]

Yes, turning off the hovering is way more drastic. Despite my personal preference, if there is a solution that works and doesn’t require to do it, we should definitely keep it (and maybe poll the community later).
And I agree that adding extra variables would most likely fix the problems. I am happy to help with the testing.
Thanks for looking into it.

[glb (Gregory Lee Bartholomew)]

Thanks for the constructive feedback.

[litemotiv (Olivier)]

@bkunst1991

My css is a bit rusty, so I struggle to see what the ideal solution should be.

The way to fix this is to position the submenus at the top of the screen, and give them a padding or border that is equal to the height of the main menu bar.

In that scenario when leaving the ‘Get Fedora’ menu item the cursor will hover over the activated submenu, which will make it stay visible.

Here’s a working example where the padded section is bright blue and the cursor is hovering above it, outside of the Get Fedora menu item:

[glb (Gregory Lee Bartholomew)]

Interesting. But if the menus are extended higher with a transparent border or padding, can you still click through them and hit the main menu buttons? I guess I’ll have to give it a try and see what happens.

[litemotiv (Olivier)]

If you give the menu buttons a position:relative and z-index:1 and the submenus a z-index:0, then the menu buttons should be above the submenus which will allow you to hover over them or click them normally.

[glb (Gregory Lee Bartholomew)]

I can’t get it to work. I think those changes are incompatible with the existing layout which already uses various z-indexes to switch which menu is showing. Also, the divs that make the submenus are nested within the div that makes the top-level menu, so if I increase the z-index of the top menu, that automatically adds to the z-index of the submenus.

<template>
  <!-- DESKTOP NAVBAR -->
  <nav id="desktop" class="hidden md:flex h-[var(--nh)]">
    <div class="w-full h-[var(--nh)] px-2">
      <FpNavLogo />
    </div>
    <div
      class="section-headers h-full px-4 flex flex-none justify-end text-white"
    >
      <!-- note: 4px border reduces available height by 8px -->
      <div
        v-for="(category, level0index) in Object.keys(navigation)"
        :key="category"
        class="section-header relative flex items-center h-full rounded-2xl hover:bg-fp-blue-500 bg-clip-padding border-4 border-transparent"
      >
        <!-- DESKTOP HEADER -->
        <input
          :id="`button-${category}`"
          type="radio"
          name="lock"
          class="section-button absolute left-0 w-full top-0 h-full rounded-2xl block"
        />
        <label
          :for="`button-${category}`"
          class="relative z-10 px-2 text-sm text-white select-none block pointer-events-none"
          >{{ $t(navigation[category].label) }}</label
        >
        <!-- DESKTOP MENU -->
        <div
          :id="`section-menu-${category}`"
          class="section-menu fixed top-[var(--nh)] h-[var(--mhmd)] lg:h-[var(--mhlg)] xl:h-[var(--mhxl)] left-0 right-0 lg:px-[10vw] bg-neutral-100 dark:bg-neutral-900 overflow-hidden hidden"
        >
          <!-- DESKTOP SUBSECTIONS (LEFT COLUMN) -->
          <div class="py-2 w-[20vw]">
            <div
              class="px-2 text-base font-semibold uppercase text-fp-blue mb-2 select-none"
            >
              {{ $t(navigation[category].label) }}
            </div>

Feel free to fork the repo and submit a MR to fix the problem if you feel inclined. Otherwise, the phantom div seems adequate (though it isn’t perfect).

[glb (Gregory Lee Bartholomew)]

@glb

@bkunst1991

Unrelated to your change: Pins do not seem to propagate from sections to subsections. Clicking on “Get Fedora” will pin it, thus disabling hovering for the other elements as expected, but then clicking on “Atomic Desktop” will disable the “Get Fedora” pin and thus hovering on “Contributors” will change the menu.

There is a variable that holds the state information about what menu item was last clicked. Just creating more variables to hold more button states should be enough to fix the problem of clicks on the secondary menu overwriting the record of what button was last clicked on the primary menu. I’ll look into it.

Here is a build preview with the added variables to track the main and submenu states separately. It has been submitted as a separate MR from the one that adds the phantom div to extend the hover effect, so it doesn’t contain those changes.

Fedora Linux

[litemotiv (Olivier)]

@glb

I think those changes are incompatible with the existing layout which already uses various z-indexes to switch which menu is showing.

Yes it’s possible that a more extensive overhaul would be needed for that. I don’t know if i want to dig into that at this point, since i’m not familiar with the website and the rest of the code, so it would require some time to investigate and test things out.

[bkunst1991 (Berengere Kunst)]

It looks much better thank you. I have two comments though:

• Clicking on a pinned item should unpin it.
• Once pinned, hovering outside of the menu should not make it disappear. Instead the user should perform a manual click to make it go away (either click outside of the view or unpin it).

Basically, a pin action should disable any hovering action until an unpin action is performed.

[glb (Gregory Lee Bartholomew)]

I’ll have to think about how to get it to do that, but I’ll work on it.

[glb (Gregory Lee Bartholomew)]

@bkunst1991

• Clicking on a pinned item should unpin it.

I’ve implemented this. It can be tested using the below link for as long as the build preview exists (it shouldn’t get purged until sometime after it is merged).

Fedora Linux

@bkunst1991

• Once pinned, hovering outside of the menu should not make it disappear. Instead the user should perform a manual click to make it go away (either click outside of the view or unpin it).

I haven’t figured out how to implement this request yet, but if something comes to me, I’ll try.

@bkunst1991

I am happy to help with the testing.

Thanks. The above MR is a somewhat significant change, so I would appreciate a bit more testing and feedback. @nikodunk and @darknao, I would like your feedback as well. Thanks.

P.S. Navigating to other pages in the build by clicking on the menu entries will not work. It is a known limitation of the current build-preview system. The actual links will work on the production system, however.

[bkunst1991 (Berengere Kunst)]

Thanks for the build.

@glb

I haven’t figured out how to implement this request yet, but if something comes to me, I’ll try.

Would it not be possible to simply disable hovering entirely if a pin variable is enabled? I would say this is where the value of pin system resides and I wouldn’t merge anything until we have a solution for this specific issue.

I also found some minor glitches:

• The phantom div seems to highlight “Get Fedora” when we hover over it after having pinned any other section
• The phantom div does not seem to stretch to the fedora logo
• A disappearance of the menu should reset the pin variables, otherwise the phantom div remains active and hovering over it would make everything reappear

[glb (Gregory Lee Bartholomew)]

@bkunst1991

Would it not be possible to simply disable hovering entirely if a pin variable is enabled?

The only way I know to disable hovering at runtime is to set pointer-events-none on an element. Unfortunately, that also disables click events and then none of the menu buttons will work at all. I might have an idea for a workaround, but I’ll need to experiment with it a bit.

Edit: I’ve been overlooking something obvious. If I duplicate some of the CSS rules that govern the menu behaviors, the hovering effect doesn’t have to be disabled “at runtime”. There is still some interaction between the two navigation methods, but I think I have something workable now. Here is the latest build preview: Fedora Linux | The Fedora Project

[glb (Gregory Lee Bartholomew)]

@bkunst1991

• The phantom div seems to highlight “Get Fedora” when we hover over it after having pinned any other section
• The phantom div does not seem to stretch to the fedora logo

Fixed. Here is a new build preview: Fedora Linux | The Fedora Project

@bkunst1991

• A disappearance of the menu should reset the pin variables, otherwise the phantom div remains active and hovering over it would make everything reappear

I think this problem has been superseded by solving your earlier request – “Once pinned, hovering outside of the menu should not make it disappear. Instead the user should perform a manual click to make it go away”.

Edit: Here is an updated build that fixes the shadow effect at the bottom of the nav menu. I had turned it off in the previous build because the shadow would flash as the mouse passed over a checked/selected menu item and that was distracting. Here is the latest build with the menu shadow restored (it doesn’t flash now ): Fedora Linux | The Fedora Project