Usability review and feedback from testing

Created on 6 April 2024, 3 months ago
Updated 29 April 2024, about 2 months ago

Usability review

We discussed the current state of the navigation module at 📌 Drupal Usability Meeting 2024-04-05 Needs work . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, @skaught, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

On the request of @ckrina this is only a hopefully short summary of the main points we had a clear consensus about during the meeting. For clarification or more in depth elaboration just ping us.

1. Interacting with the new navigation by mouse has several potential stumbling blocks for the user:

  • Continuous showing & hiding of the drawer on hover when moving from eg username up the sidebar towards create - makes things busy and distracting.
  • Mix of interaction patterns, on click & on hover for top-level and only on click for sub menu items in the drawer leads into confusion and conflicts in particular in the context of top-level menu items.
  • Even with the triangle pattern we occasionally managed getting out of the hover tunnel

Suggestion was to expand on click instead of to expand on hover by default, and adding a user setting to switch to hover interaction plus creating a follow up issue discussing improvements for the hover interaction.

The attendees of the Drupal Dojo Austin as well as @charles-belov raised the same point independently in their testing.

2. In the context of navigation blocks, there are potential original language mixups for navigation block titles on multilingual sites. See the created: 🐛 The default original strings of a navigation block could get populated by another installed language Active

3. Group was in line with the points raised in Improve the clarity about the navigation block overview page and the "Place navigation block" dialog modal Active for the overview page and Make "Place navigation block" a primary button and move it right before the table Active for the place nav button to improve clarity and keep the user in control.
In addition there was the suggestion to have more than one region in the sidebar to for example enable to control also the blocks in the footer including the user nav block. In consequence, in case there should be only a single region change the button to action link on top outside the table as suggested in Make "Place navigation block" a primary button and move it right before the table Active , if there should be more than one region change the pattern to the one used on the block layout page.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

🌱 Plan
Status

Active

Version

11.0 🔥

Component
Navigation 

Last updated about 21 hours ago

No maintainer
Created by

🇩🇪Germany rkoller Nürnberg, Germany

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Comments & Activities

  • Issue created by @rkoller
  • 🇩🇪Germany rkoller Nürnberg, Germany
  • 🇩🇪Germany rkoller Nürnberg, Germany
  • 🇩🇪Germany rkoller Nürnberg, Germany
  • 🇩🇪Germany rkoller Nürnberg, Germany

    After a bit of a back and forth I'll add two more UX related feedbacks to this issue. I'll change the title again to reflect that and to make this issue a collection of those results. The issue summary i keep reserved to the outcomes of the usability meeting I only add notes in case other results are confirming points made in the meeting.

  • 🇩🇪Germany rkoller Nürnberg, Germany

    The day before the UX meeting the attendees of the Drupal Dojo Austin tested the navigation module. For the record the attendees were: Buster Neece, @cutehair, @rocketeerbkw. I think adding a comment about the results to this issue is the better choice, that way all the relevant points are collected in a single place instead of splitting everything into separate issue, plus one point is confirming a problem raised in the UX meeting (see the note in the issue summary):

    • The title within the drawer wasn't considered click-able. It looked like a header with no affordance being a clickable link.
    • If you are on a desktop and the viewport width is narrow enough that the sidebar switches to the navigation pattern for mobile it is impossible to move with the cursor within the sidebar. The drawer is immediately triggered on hover and the drawer is overlaying the sidebar.
    • Moving the mouse cursor horizontally in the navigation pattern for desktop is more cumbersome, challenging, and taxing than moving vertically for some attendees.
    • Having just a single submenu expanded, in particular in the context of the configuration top level menu item, was considered challenging for new users and people with a small working memory. To know and remember which sub menu item contains which sub-sub menu items.
    • If only the user navigation block is available and the submenu for the username is expanded on larger screens, the button at the bottom and on top submenu inside the drawer are in no in close proximity and challenging to reach with the straw test.

    Overall @rocketeerbkw summed it up nicely. If you compare the navigation menu with the current toolbar in Core it is a no brainer. He would switch immediately without a thought. But if you compare the navigation to the admin_toolbar, from a his perspective the hover functionality in the horizontal admin_toolbar was perfect for him. He was able to easily reach every part of the admin ui with ease quickly. With the navigation that experience in the context of hover isn't that flawless yet.

  • 🇩🇪Germany rkoller Nürnberg, Germany

    @charles-belov tested the navigation against vestibular disorder for 🌱 [PLAN] Accessibility review Active . In addition he also left a few additional notes in the context of usability in general:

    • Mobile now triggers at a narrower width. The same width that was triggering mobile layout and behavior yesterday now displays desktop. I now have to set the browser to about 2/3 width to trigger mobile layout and behavior. (Note:For context, when he first tested the day before, from some reason his browser had a too narrow width triggering the nav pattern for mobile, making him think, and worry, that pattern would be the sole way to interact by mouse).
    • I'm not seeing any animation concerns in either mobile or desktop.
    • I'm noticing the behavioral differences between mobile and desktop. Specifically mobile requires a click to go to the next menu level. Desktop displays the first level on hover and the second level on click. I believe your usability team already identified the hover/click inconsistency.
    • I agree with your usability team that would be better to give the user the option as to whether to expand on hover or on click when in desktop layout.
    • There does seem to be a delay on the hover expansion in desktop. However, I think it's too brief, as the expansion of happens if I move the mouse at a moderate speed. I have to move the cursor quickly to avoid the flickering of submenus appearing and disappearing, and that's not necessarily something I would do.
  • 🇪🇸Spain ckrina Barcelona
  • 🇦🇺Australia mstrelan

    I haven't been following this much at all but tested this out for the first time today. I'd have to agree with the issues with mouse interaction, I found it too sensitive as I would often accidentally trigger a drawer to open. I also expected to click, and if I tried to hover and click quickly it would respond to both the hover and the click, animating twice. I also found it annoying if I open Reports and then move the mouse to the top of the drawer quickly but miss completely it closes the drawer and I need to re open it. I think clicking would work best. I also think it should be possible to middle click or ctrl + click on the top level items to open their index pages in a new tab, currently this is only possible if the item does not have children.

Production build 0.69.0 2024