Problem/Motivation
So while creating/editing the menu link, the Parent item select input of the Menu Settings opens up a very long list of the every single possible menu item in one giant select list which can be a little crazy.
Steps to reproduce
- Navigate to edit any menu link.
- Open the Parent link select list.
Proposed resolution
So the proposed solution that we came up with after having a discussion with @lauriii was to have 2 separate select list. The first select list will contain the List of main menus and based on the selection of the first select list the second select list would contain it’s subitems.
Remaining tasks
- Accessibility review
Update now that #2519362: Redesign the menu link add form to be less overwhelming is fixed. Make sure the two work well together. See Comment #37.Update the "before" and "after" screenshots in the issue summary now that #2519362: Redesign the menu link add form to be less overwhelming is fixed.
User interface changes
Current add-form:-
Current edit-form:-
Proposed
Edit-form-collapsed:-
Edit-form-expanded:-
Add-form-collapsed:-
Add-form-expanded:-
Menu-link-selection-expanded:-
Parent-link-selection-expanded:-
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#82 | mnu-2.png | 124.38 KB | bnjmnm |
#82 | mnu-1.png | 181.01 KB | bnjmnm |
#68 | Add-form-11x.png | 404.05 KB | Utkarsh_33 |
#68 | Edit-form-11x.png | 355.93 KB | Utkarsh_33 |
#64 | parent-link-expanded.png | 398.48 KB | Utkarsh_33 |
Issue fork drupal-1428520
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
ELC CreditAttribution: ELC commentedHere's a screen shot showing the existing selection plus the proposed change .. as each box is selected, the children are ajax loaded
and a patch off the current git repository.
Comment #2
sunComment #3
jenlamptonupdating tags
Wonder if there's any chance this can get into D7 too? :)
Comment #4
chris_h CreditAttribution: chris_h commentedThis still requires an user to know what weight means and essentially guess what weight other items in the menu are in order to fit it in the correct place the first time around.
It would be better to take an approach along the lines of Menu Browser or Menu Order which get rid of weights entirely and allow users to choose a menu and drag & drop an item either as a child of a page, or above/below a sibling.
Also referencing #1101600: Users need to be able to select from list when adding menu items to a menu, which is the flipside to this problem from the list links page.
Comment #17
smustgrave CreditAttribution: smustgrave at Mobomo commentedThis seems like it would still be useful.
seems to be about what https://www.drupal.org/project/cshs does.
Comment #22
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #24
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedNext things to work on this is to get some code clean-up and maybe add some tests for this.
Comment #25
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #26
smustgrave CreditAttribution: smustgrave at Mobomo commentedIssue summary hasn't been updated in 12 years, so definitely think it should be updated to todays template.
Applying the MR though not seeing any difference when adding a menu link.
Comment #27
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #28
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedAttaching the screenshots demonstrating the new way of selecting the parent list.
Comment #29
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #31
smustgrave CreditAttribution: smustgrave at Mobomo commentedAdded screenshots from #28 to issue summary.
Moving to NW for threads from tim.plunkett, saving credit for.
Comment #32
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #33
smustgrave CreditAttribution: smustgrave at Mobomo commentedOnly rebased to see if the pipeline would pass. Had a bunch of errors before but think that was gitlab issue.
Believe this is good, as all threads have least been answered. And confirmed I get the same behavior as the screenshots
Comment #34
benjifisherI am adding #3379293: Make it easier to add a child menu item as a related issue. It is a complementary solution to the same problem.
The tests that I added in that issue should catch any problems, but it would be reassuring to have someone test manually that the changes here do not affect the default selection we get when using the "add child" link.
Comment #35
benjifisherI think this issue should also get an accessibility review, just to make sure it works well with keyboard navigation, scree readers, and such. I am adding the tag for that and setting the status back to NR.
Thanks for the attention to the issue summary. That will help in the review process.
Comment #36
smustgrave CreditAttribution: smustgrave at Mobomo commentedTabbing is fine.
But reading https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Liv... think we may need aria-live for the section that is auto updating.
Comment #37
rkollerWhile testing this issue I still had the changes for #2519362: Redesign the menu link add form to be less overwhelming applied. Turns out both issues are intertwined:
Quickly chatted with @benjifisher in the #accessibility channel where he posted the other issue and we were in agreement that the menu select field should be moved over to the sidebar right above the parent link select field. He recommended to post this comment on both issues and whichever issue is fixed second should adapt for the other.
And two additional observations when the select fields are announced by a screenreader (VoiceOver in my case).
1. The greater and less than announcements are confusing (see less_greater_than.mp4) and since menu and parent link are no single select field anymore < and > are not necessary anymore to visually distinguish menus for sighted users
2. For screenreader users the list is flat and none hierarchical (see flat.mp4). The pause just slightly differs based on the number of dashes.
Comment #38
benjifisherComment #39
benjifisherWe should make the same change to the node-edit form. I am not sure whether it makes sense to do that as part of this issue or if it should be a follow-up.
Comment #41
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedSo now the menu select list does not contain the < and > icons as requested in #37.1. Also #37.2 can be a follow-up for this issue.
Comment #42
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commented@benjifisher can
#39 be done in a follow-up as well?
Comment #43
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #44
lauriiiPosted some feedback on the MR.
Comment #46
benjifisherFrom #42:
Yes. That is what I meant by this: "I am not sure whether it makes sense to do that as part of this issue or if it should be a follow-up."
Comment #47
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #48
smustgrave CreditAttribution: smustgrave at Mobomo commentedNot on the accessibility team but still wonder if #36 applies. For the need of an aria-live region.
Comment #49
Nitin shrivastava CreditAttribution: Nitin shrivastava at OpenSense Labs commentedI'm not very familiar with the comment in #36. Could someone please provide some insights or suggestions about it?
I've executed MR #47, applied it successfully, and tested it locally Presently, the interface showcases two distinct dropdowns, each delineating the parent link and menu. I've enclosed a screenshot capturing the changes made after the patch.
Comment #50
Nitin shrivastava CreditAttribution: Nitin shrivastava at OpenSense Labs commentedComment #51
narendraRSometime it shows Parent link before Menu, which is not correct. See attached SS.
Comment #52
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI have added the weight to the select element.Attaching the screenshot for the same.
Comment #53
djsagar CreditAttribution: djsagar at OpenSense Labs commentedComment #54
narendraRFollow-up needs to be created for #37.2 and #39
Comment #55
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #56
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI have opened a follow-up for #39 in Improve menu parent link selection for node edit form.
Comment #57
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #58
narendraRFollow-up created, feedback addressed and changes looks good to me. Marking as RTBC.
Comment #59
narendraRMarking as NR for `Needs accessibility review` and `Usability`
Comment #60
smustgrave CreditAttribution: smustgrave at Mobomo commentedUsing a screen reader (mac's version of one) there is no announcement of the dynamic change to the list.
For the menu link followup I've always used https://www.drupal.org/project/cshs which has worked well.
Comment #61
benjifisherThe "Usability" tag means that the issue affects usability (and is intended to improve it). There is a separate tag, "Needs usability review", for issues that need review by the Usability team or a topic maintainer. For official descriptions of the issue tags, see Issue tags -- special tags.
Another reason to set this issue back to NW is that #2519362: Redesign the menu link add form to be less overwhelming was just fixed. We need to update the work here, and we need new "before" and "after" screenshots. I am updating the "Remaining tasks" in the issue summary and adding the tag for an issue summary update.
edit: oops, that issue is still RTBC. But it looks like it will be fixed any minute now.
Comment #62
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI have made some changes according to the latest changes in #2519362: Redesign the menu link add form to be less overwhelming. Attaching the screenshots of the initial steps.
Comment #63
AaronMcHaleCan we get new before and after screenshots in the issue summary now that #2519362: Redesign the menu link add form to be less overwhelming has landed.
Ideally five screenshots:
Thanks,
-Aaron
Comment #64
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #65
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI have added screenshots for both the states for both the forms as requested in #63.Marking it to needs review.
Comment #66
kunal.sachdev CreditAttribution: kunal.sachdev at Acquia commentedBefore and after screenshots are added and the changes looks good to me. But this still needs accessibility review.
Comment #67
benjifisherI am restoring the "Needs screenshots" issue tag because we still need to update the "Current" (or "before") screenshot now that #2519362: Redesign the menu link add form to be less overwhelming is fixed.
Usability review
We discussed this issue at #3405362: Drupal Usability Meeting 2023-12-15. That issue has a link to a recording of the meeting.
For the record, the attendees at the usability meeting were @AaronMcHale, @Emma Horrell, @benjifisher, @rkoller, @simohell, and @worldlinemine.
We agreed that this issue is a big improvement. Besides the usability problem of a really long select list, sometimes two parts of the menu tree look similar. For example, the links under "blog" might be similar to the links under "services". In this case, it is easy to move a link to the wrong place. If those similar sections are parts of different menus, then it will be much easier to avoid mistakes with this change.
Another point is that there are two ways to change the parent of a menu link: from the edit page for the link, or from the listing page for the menu. But if you want to move a link to a different menu, it can only be done from the edit page for the link. After this issue, that will be much easier.
There is one change that the Usability group would like to see as part of this issue:
This should be implemented with a delay, so that it is possible to navigate the Menu select list from the keyboard without constantly moving to the other select list. Or perhaps trigger the change of focus on mouse events but not keyboard events. I expect the Accessibility review will have more specific guidance.
In a separate Slack discussion, we considered whether the Menu and Parent link select lists should be grouped in a
<details>
element. Opinions were split: some like it the way it is, and others think the two select lists should be grouped for consistency with the other elements in the sidebar. If they are grouped, then the<details>
element should be open by default. It looks as though the current MR uses a<div>
element to group the two select lists.Another idea for a follow-up issue: consider changing the Add form to be consistent with the Edit form. Currently, the Add form only shows elements of the selected menu as possible parent links. That was a good idea before this issue, but it is worth reconsidering once this issue is fixed. I think it would simplify the code and make the two forms more consistent if we simply set a default value for the Menu select list.
Another idea came up: out of scope for this issue, but worth considering in a separate one. Just as the
node
module logs an Info message whenever a node is created, edited, or deleted, we should consider the same sort of logging for menu links. That would make it easier to fix the problem if, despite this issue, an administrator accidentally moves a link to the wrong place.Yet another idea (also out of scope): add a search function to the "Parent link" select list.
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
Comment #68
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedComment #69
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedAttached the screenshots of both the form before this patch.
Comment #70
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI think this can be done once we get a accessibility review on this.
Comment #71
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI created a follow-up for this Consider changing the menu-link Add form to be consistent with the Edit form.
Comment #72
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI think this would also help us to provide users with a good UX.I created a follow-up for the same in Add search functionality to the "Parent link" select list..
Comment #73
Utkarsh_33 CreditAttribution: Utkarsh_33 as a volunteer and at Acquia commentedI have created the follow-ups that are or could be a great enhancement in conjunction with this issue and also attached the required SS. Marking it needs review as it still needs reviews of accessibility team so that we have a good understanding of how should be proceed with the remaining tasks.
Comment #74
bnjmnmComment #75
bnjmnmComment #76
kunal.sachdev CreditAttribution: kunal.sachdev at Acquia commentedComment #77
bnjmnmThe accessibility of the grouping seems to work, but having it in a fieldset is introducing some style problems due to there being fairly opinionated fieldset styles that aren't ideal for this use case (particularly in Claro). Suggestion in MR.
Comment #78
kunal.sachdev CreditAttribution: kunal.sachdev at Acquia commentedUpdated the IS as before screenshots were added in #68.
Comment #79
kunal.sachdev CreditAttribution: kunal.sachdev at Acquia commentedComment #80
omkar.podey CreditAttribution: omkar.podey at Acquia commented@bnjmnm could you approve that the aria-label in div looks good. Thanks
Comment #81
nod_Umm, with umami, when I go to this page after applying the patch: https://drupal.ddev.site/en/admin/structure/menu/link/entity.entity_view... I see that the parent menu is "User account menu" and the parent is the correct "Display mode" from the Administration menu, saving the link doesn't break anything but there is something wrong with the default value for the parent menu.
Comment #82
bnjmnmRan into the same thing as @nod_ in #81