Usability review
We discussed the current state of the navigation module at #3436905: Drupal Usability Meeting 2024-04-05. 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
usernameup the sidebar towardscreate- 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: #3438953: The default original strings of a navigation block could get populated by another installed language
3. Group was in line with the points raised in #3438789: Improve the clarity about the navigation block overview page and the "Place navigation block" dialog modal for the overview page and #3427940: Make "Place navigation block" a primary button and move it right before the table 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 #3427940: Make "Place navigation block" a primary button and move it right before the table, 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
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | parent item not clickable once the children opens.png | 45.35 KB | chike |
| #24 | hover and menu items open.png | 39.61 KB | chike |
| #19 | image (15).png | 34.49 KB | scott_euser |
| #19 | 2024-07-25_14-29 (1).png | 30.16 KB | scott_euser |
| #15 | navigation-simple_block-unclickable-menu-item__excerpt.png | 44.04 KB | anruether |
Comments
Comment #2
rkollerComment #3
rkollerComment #4
rkollerComment #5
rkollerAfter 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.
Comment #6
rkollerThe 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):
configurationtop 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.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.
Comment #7
rkoller@charles-belov tested the navigation against vestibular disorder for #3391723: [PLAN] Accessibility review for new Navigation bar. In addition he also left a few additional notes in the context of usability in general:
Comment #8
ckrinaComment #9
mstrelan commentedI 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.
Comment #10
anruetherNot 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.
Comment #11
aaronmchale@anruether just to double check, are you also using the
admin_toolbarmodule, 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.Comment #12
anruether@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 (which are now inaccessible). 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:
I tested this on simplytest.me and not other modules installed. I'll also try to upload screenshots.
Comment #13
anruetherComment #14
anruetherComment #15
anruetherComment #16
rkollerhm 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
structuretop-level menu item, then clickblock layout, then the submenu expands, and then i am able to click thesimple blocksmenu item which forwards me toadmin/structure/block/simple-block. I've also tested navigating to thesimple blockssub 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?Comment #17
anruether@rkoller And did you succeed in navigating to the block layout page with simple_block module enabled?
edit: I did not say you can't reach the simple_block page. I said that the link target of second level menu items which have children are inaccessible.
Comment #18
anruetherBut fair enough, let's add steps to repdroduce:
Comment #19
scott_euser commentedThanks 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:
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
Comment #20
joelpittetI 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...
Comment #21
scott_euser commentedHi @joelpittet, you can see a working example of that in the MR here: #3480321: Second level menu items can't be reached if they have children but that will be dropped off in favour of the 'Overview' approach which you can see the discussion there about.
Comment #22
joelpittetThanks @scott_euser that is where I should have commented.
Comment #23
ressaIt looks like a vertical menu on the left side of the screen is the only option in the new Navigation.
I prefer my administration menu to be at the top, is there an issue for this? It should be like Admin Toolbar, where I can hover my way over menu items, all the way to my destination.
It seems less than ideal, that you have to hover, as well as click, and then click some more, to access a common task, such as node display configuration:
Navigation:
Admin Toolbar (for comparison):
Also, you need to move the mouse over a much bigger area with a vertical menu, than with a horizontal menu at the top, For example, if you hover "Reports", and have to move the mouse all the way to the top of the screen, to then click "Status reports".
Comment #24
chikeIn support of what has already been said...
I hover on Commerce and the menu items open. I then hover on Products and the menu items don't open. I have to click on Products.
I finally click on Products and I am not able to get to the products page. Instead the child items now open.
For me to get to the products page, I will first have to go to Scheduled Products and then to Products.
The same way you can't go from Structure to Feed types. You first have to get to Add feed type and then make your way back to Feed types.
Comment #26
rkollerUsability review
We discussed this issue at #3574712: Drupal Usability Meeting 2026-02-27. The link to the recording: https://www.youtube.com/watch?v=B7ESB2dVsT0. The attendees at the usability meeting were @benjifisher, @pallavi singh3013, @rkoller, @simohell.
Long story short, after reevaluating our previous review we finally created an issue for point 1 in the issue summary. The issue can be found at #3576909: Expand sub menus by mouse click