In the UMN 2011 test we discovered that the checkbox to add a menu link is not discoverable. Which led to users to look for other ways to add menu items, taking them to the Menu item creation - which on itself was confusing (for example, #1101600: Users need to be able to select from list when adding menu items to a menu ).
It seemed in part the problem that was causing this is the checkbox looked like just another setting (because its a checkbox).
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | Screenshot from 2015-06-29 09:40:22.png | 50.04 KB | lunk rat |
| #12 | Screenshot from 2015-06-29 09:41:37.png | 27.38 KB | lunk rat |
| #4 | Add-to-Menu.jpg | 36.39 KB | eigentor |
Comments
Comment #1
David_Rothstein commentedComment #2
Jeff Burnz commentedHiding all the menu options behind a control is probably a bit of a hack to begin with.
Why not simplify the menu form, for example just show the "Parent item" drop list and when the user selects the menu the rest of the form fields appear. Except the parent item term is horrible, change that to something like "Choose menu", etc etc.
Comment #3
Skin Halo commentedComment #4
eigentor commentedHaving Radios and Checkboxes is soo nineties, and obsolete since the Views 2 UI at latest. Click a link that sais what it does.
Note: Also works without icon. Is more fun with ;)
I also noticed Clients not supposing this is where they add the menu. Checkbox is confusing. So Once they click that and get to the maybe confusing parent item stuff, that is another story. But I guess this issue is about getting them there first.
Alternative Wording "Add to menu" "Add this $content type to Menu"
Comment #5
sunThe widget is actually provided by Menu module. And this issue tries to improve the current situation, no bug involved.
Comment #6
Bojhan commentedActually, this is major.
Comment #7
samwillc commentedI agree, this is a problem I am facing now.
The client is taking over the site. So I have only 1 option (out of 2):
1) Don't give clients permissions to administer menu items (desirable) - they create a page, save, menu item appears as if by magic in the correct place.
2) Allow them the menus permission - they create a page, have to check the box, choose a parent (?!), click save.
Option 1 would be great if when they created a page, it would actually make the menu item! You can set the default parent (for when they check the box), but without allowing them permissions, they create a page and it doesn't show up in the menu, so that's no good.
Where is the set default parent AND menu item so when they create a page, it automatically puts it into the menu structure (that the site creator has chosen)?
Sam.
Comment #8
Bojhan commentedThis is no feature, its a usability issue - not focused at introducing new features but changing existing UI patterns.
Comment #9
samwillc commentedIt's a real problem this one. I have had to allow clients a lot more access than I would have wanted. This had led to broken layouts where they have checked the box, selected the main menu and stuck in one too many links pushing the (once neat menu) onto a new line.
It's not the only problem I've had with permissions and the vertical tabs menu on content types. These items should really have their own little sections moving down the page. They don't need to be all hidden and difficult to find.
+1 for usability problem.
Sam.
Comment #10
dawehner#2315773: Create a menu link field type/widget/formatter would have allowed to let people configure how menu links look like in the node UI, but I doubt that one will happen.
Comment #11
yoroy commentedWe ought to have improved this situation by introducing the right hand sidebar. Something to try and validate during usability testing.
Comment #12
lunk rat commented@yoroy in the 2015 usability study most users did see the option in the right sidebar, and used it! However a few still missed it completely and ended up going to Structure > Menus to complete the task (or got stuck there, see #2513606: Menu admin UI should guide new users to add links to "Main navigation" menu). Therefore I don't think the settings-in-sidebar quite solves this.
One idea would be to couple it with the Title field, just beneath it. We did receive feedback that conceptually Title and Menu go together, so users expected to see menu options as they titled their page. Here's a mockup for that:
My thinking is that they would be less likely to miss it here, and less likely to overlook it as "just another setting" because titling your content and linking to your content are conceptually "linked" so to speak ...
It would clutter the form a bit, though, when used:
Also, since URL path is conceptually tied to menu and title, that could be included here, too.
Just an idea, this could certainly have its own problems ...
Comment #26
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #27
smustgrave commentedThis may still be relevant but really what is there to do?