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

Comments

David_Rothstein’s picture

Issue tags: +UMN 2011
Jeff Burnz’s picture

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

Skin Halo’s picture

eigentor’s picture

StatusFileSize
new36.39 KB

Having 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"

sun’s picture

Component: node system » menu.module
Category: bug » feature
Priority: Major » Normal

The widget is actually provided by Menu module. And this issue tries to improve the current situation, no bug involved.

Bojhan’s picture

Priority: Normal » Major

Actually, this is major.

samwillc’s picture

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

Bojhan’s picture

Category: feature » task

This is no feature, its a usability issue - not focused at introducing new features but changing existing UI patterns.

samwillc’s picture

It'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.

dawehner’s picture

Issue summary: View changes

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

yoroy’s picture

Priority: Major » Normal
Issue tags: +UMN 2015

We ought to have improved this situation by introducing the right hand sidebar. Something to try and validate during usability testing.

lunk rat’s picture

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

Menu link coupled with Title field

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:

Menu link expanded

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

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank 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!

smustgrave’s picture

This may still be relevant but really what is there to do?

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.