Opened 9 years ago
Closed 9 years ago
#32743 closed enhancement (maybelater)
Customizer: Menus Panel Priority
Reported by: | celloexpressions | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.3 |
Component: | Customize | Keywords: | |
Focuses: | ui | Cc: |
Description
In the Menu Customizer plugin, the menus panel was given a priority of 30
for several reasons listed below. On merge, this was changed without discussion, user testing, or stated reasoning. This ticket proposes restoring the higher priority (lower number, current is 100
, and also considers changing the priority of the Widgets panel.
The priority of 30
was chosen because:
- Navigation/menus are more closely related to site identity (title/tagline) than anything else in the Customizer in core, so it makes sense for menus to follow title/tagline
- If you follow the most logical hierarchy of the order these settings would most often appear on the frontend/in the preview, it would probably be title/tagline, then menus, then potentially colors, header images, backgrounds, widgets near the footer, etc.
- Menus should definitely be before header/background image just based on expected frequency of usage as well as general importance. I'd argue the same for Widgets, so if we want to keep them together I'd move them both up
- Menus should ideally be in a different spot than the old Navigation section was for discover-ability - otherwise users might think that we just renamed that old section
Change History (4)
#1
@
9 years ago
- Milestone changed from 4.3 to Awaiting Review
#2
follow-up:
↓ 3
@
9 years ago
The admin menu and admin bar both put widgets and menus before headers and backgrounds, presumably based on usage and importance. That should be reason enough for the Customizer to do the same.
I don't have the ability to collect usage data, but I've personally never had a site where I update the header/background image more frequently than the menu once it's set up for the first time. A lot of sites chose not to use those features even when the theme supports it, while nearly every site uses menus. For example, a quick check of some of my, ocean90's and obenland's sites found no sites that use both features out of 10-12, while most of those themes support both custom headers and backgrounds. That's a lot of skipping over UI that's not being used to get to menus, which are being used on all but one of the sites I looked at.
The biggest issue here is that this was changed without any public discussion (at least, that I can find), or user testing to support moving it, when it's been where it was in the plugin for over a year without anyone expressing concerns.
#3
in reply to:
↑ 2
@
9 years ago
Replying to celloexpressions:
The admin menu and admin bar both put widgets and menus before headers and backgrounds, presumably based on usage and importance. That should be reason enough for the Customizer to do the same.
I'm not sure a presumption is reason enough.
The biggest issue here is that this was changed without any public discussion (at least, that I can find), or user testing to support moving it, when it's been where it was in the plugin for over a year without anyone expressing concerns.
Was there user testing that suggested moving it from where Navigation was?
I agree with ocean90:
I don't think this is a real issue, navigation and menus are the same. The menu customizer is an enhancement for the old navigation section.
I disagree. Header and background settings are definitely more related to site identity. For example you can have no site title but a header image which represents the site title. The same could apply for a background image, depends on how the theme has implemented the image, Twenty Fifteen is a good example for this.
Nav menus (and widgets) are site content.
Do you have any data for this? Or just personal preference?
I don't think this is a real issue, navigation and menus are the same. The menu customizer is an enhancement for the old navigation section.
Note: The decision about the current priority was done by @obenland.