[wp-trac] [WordPress Trac] #40104: Customizer: Improve menu creation flow

[WordPress Trac]

#40104: Customizer: Improve menu creation flow
-------------------------+---------------------------------
 Reporter:  melchoyce    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.8
Component:  Customize    |     Version:  4.3
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui, administration
-------------------------+---------------------------------
Changes (by celloexpressions):

 * version:   => 4.3
 * component:  Menus => Customize


Comment:

 It's great to work on this flow - it definitely needs work. The initial
 suggestions here offer several improvements. I do think it would benefit
 from more iterations before nailing down the best solution. I'm concerned
 that aspects of the initial proposal actually introduce more complexity,
 in some cases unnecessarily so. A few of my quick thoughts are:

 > If you visit the menu panel before you have a menu, hide "Locations" and
 only show a prompt to create a new menu.
 Great idea, and this could potentially correspond with more-visible help
 text. The panel help is hidden here, making it not very discoverable for
 the initial setup flow. I do wonder whether any users will actually
 encounter this anymore since starter content typically creates menus. We
 should also consider the option to create a default menu with the site's
 pages here, as the admin version of menus does.

 > When you click "Create new menu," open a temporary, interstitial panel
 with a prompt to name your menu and pick a location to add it to. You'll
 only see this screen when you make a new menu.
 This is largely how the current process works. It just slides down instead
 of over. And we don't show the locations. So I'd suggest splitting this
 into two ideas: changing the cognitive model for how a menu gets added and
 how those controls show up, and encouraging selecting menu locations
 before adding content to a menu.

 I'm not sure that I'd support changes to the first part of that - the
 current approach clarifies the way a new menu gets added to the existing
 list of menus, and could actually help avoid the mistake of clicking the
 button to think you're adding an item to the menu where you can quickly
 get back (I've done this, and it's really something we should think about
 the design of that button for, as opposed to the broader UX of how adding
 new menus works). Either way, it needs some further exploration I think,
 the current proposal seems like it's trying to solve the wrong problem.
 The second part seems like a good idea to me - selecting the menu location
 before you start adding items to the menu. This would probably scale best
 if the menu location checkboxes were added between the menu name and the
 create menu button in the current new menu section, before you get the
 visual of the menu being created and the ability to add items coming in.

 So, for these two points, my suggestion would be to start by reworking the
 controls within the `new_menu` section, including looking at adding
 locations, adjusting labels, etc. and then look at whether changes to the
 presentation of that section are necessary. Note that the new menu section
 is a customizer section object, for several reasons involving the
 technical and UX aspects.

 > I'd consider to remove the placeholder Give your new menu a name since
 it's already clear enough what the field is about
 Agreed. Strive for simplicity. More text isn't necessarily better, even if
 it's friendly and intended to be helpful. We can also remove the current
 placeholder and make that a proper label as the mockups show.

 > The copy in Menu Locations has been adjusted to be friendlier and more
 helpful, including links to the Widgets panel and to any documentation we
 might have on the Custom Menu widget. (I couldn't seem to find anything in
 the Codex? Maybe we should write some.)

 We already have the widgets link, so this is primarily a matter of
 rewording. I'm not sure whether or not the section's description should be
 split to show the widgets part after the locations. This could be somewhat
 problematic for UX of plugins adding controls to this section and I see
 why it's moved, but am not sure that it really needs to be. Current text
 is:

 {{{
 Your theme supports 5 menus. Select which menu appears in each location.

 You can also place menus in [widget areas](linked) with the “Custom Menu”
 widget.
 }}}

 The custom menu widget is pretty straightforward, so I don't think it
 should be necessary to link anywhere external. If we need to say anything
 else about it, we should look at whether a more guided flow might be
 helpful here, such as selecting a widget area and providing a button that
 creates the widget and navigated to its controls field automatically. The
 disconnect between widgets and menus is the biggest issue here.

 It's not mentioned in the bullets above, but the other thing I'm unsure
 about is moving the menu locations section. It's currently at the top
 because it's critical for it to not become lost below a large number of
 menus, and the interface needs to scale to sites with many, many menus. I
 don't think it's necessary to add the number of locations outside of the
 section itself since that's only relevant once you're ready to actually
 make change there, in the section. I do like the addition of the heading
 text that separates the menu locations section from menu sections; this is
 a good iteration on the gap between these sections. This UI has already
 been refined with the customize controls spacing grid, fonts, etc. and
 also implemented with a decently-extensible API in #37661 - the code for
 that should be copied out of the patch there, or we can use it directly
 once that's back in core depending on how long this project takes.

 One other note - menus in the customizer are historically managed via the
 customize component.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40104#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform