Feedback from the Usability Meeting (05 Apr 2024)

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.

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.

@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.

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.

Not sure if this should be a new issue. With navigation in 10.3 there are now some items that can't be clicked. Like Block layout or Paragraph types. This seems to be because parent items are not clickable anymore.

@anruether just to double check, are you also using the admin_toolbar module, because that does add a load of extra menu items for things like individual content types, that might not play well with the navigation module.

@AaronMcHale No, I am not using admin_toolbar.

The thing is, that navigation does not support linked, second level menu items with children. It seems that in core, we only have overview pages which list the child items in these situations. But contrib modules often define child-items of second level core menu items or bring there own menu item structure that work like that. Two examples:

1. paragraphs: Paragraph types is not clickable (child of structure)
2. simple_block: Block layout is not clickable (simple_block adds child link)

I tested this on simplytest.me and not other modules installed. I'll also try to upload screenshots.

hm i've just installed simple_block on a instance of the starshot prototype which is running on 10.3.1 and using the navigation module and the gin theme. i've also spun up an instance of 10.3.1 with simple_block on simplytest.me. in both cases, the local as well as the simplytest.me, i am able to hover over the structure top-level menu item, then click block layout, then the submenu expands, and then i am able to click the simple blocks menu item which forwards me to admin/structure/block/simple-block . I've also tested navigating to the simple blocks sub menu item just by the keyboard, which also works. so on my end i am unable to reproduce the issue you ran into. have i missed or done anything differently in the steps i've described?

then click block layout, then the submenu expands, and then i am able to click the simple blocks menu item which forwards me to admin/structure/block/simple-block

@rkoller And did you succeed in navigating to the block layout page with simple_block module enabled?

But fair enough, let's add steps to repdroduce:

1. Disable toolbar, enable navigation
2. Enable simple_block
3. Open structure submenu
4. Click on Block layout
5. Menu item is not clickable

Thanks for the work on this one.

I agree on the 3rd level, e.g. Taxonomy Overview is not possible to navigate to, you need to first go to e.g. 'Add vocabulary' /admin/structure/taxonomy/add then use the breadcrumb to get to the overview at /admin/structure/taxonomy

I would also like to second this one:

The title within the drawer wasn't considered click-able. It looked like a header with no affordance being a clickable link.

We had clients with the same issue, it was not obvious that they could get at the /admin/people list from this 'People' so they believed they only had access to create new users, but not access a list of existing users to make sure their colleagues could log in:

A possible solution to that one (which could apply to the lower level as well) is to separate the menu item link from the ability to navigate to its child items:

This seems to match the advice in https://infinum.com/blog/website-navigation-dropdown-menus/ which shows that its 'Version 2' which has both the top level link clickable + the overview link within the sub-navigation as being the quickest to achieve the task + the least margin of error for users.

A less clear UX article on it from NN hints at this too in item 12, but the separation only becomes clear when you actually visit the example they point to

I am seeing what's been reported in #12 by @anruether and echo'd by @scott_euser in #19.

Boils down to second level parents are not possible to to navigate to because the entire item is intended to toggle the children.

The primary menu item parents are possible to navigate to, though you need to click twice as they open those items. One to open the children and on the header of the children.

Proposal: split button for the arrow? I was going to give you an example of a site I did, but just saw that I broke the JS on it while I was getting the link, lol... there goes my day...

Hi @joelpittet, you can see a working example of that in the MR here: 🐛 Second level menu items can't be reached if they have children Active but that will be dropped off in favour of the 'Overview' approach which you can see the discussion there about.

Thanks @scott_euser that is where I should have commented.