Customizer: Improve menu creation flow

[melchoyce]

I consistently see in usability tests and on WordPress.com support that folks run into two issues when they create new menus:

1. They click "Add a Menu" thinking it will add a new page to their menu.
2. They forget to assign their new menu to a location, and then wonder why it doesn't show up on their site.

To address these issues, I've been working with some folks on an improved flow to guide people through creating a new menu:

• If you visit the menu panel before you have a menu, hide "Locations" and only show a prompt to create a new menu.
• 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.
• On the next screen, you'll see friendly instructions prompting you to add pages to your new menu. You can also still change your menu location and choose to auto-add new pages.
• When you return to Menus after you have at least one menu, you'll see Menu Locations as well.
• 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.)

Props to @zoonini for working through this improved flow with me, and @michelleweber for the friendly and informative new copy.

[lukecavanagh]

@melchoyce 

Really like the mockup for the improved flow for menu creation.

[afercia]

+1
a few things right off the top of my head:

• maybe the "Save & Publish" button shouldn't be enabled on all the intermediary steps since in some of them there's nothing to save, especially when users haven't made any change yet
• I'd consider to remove the placeholder Give your new menu a name since it's already clear enough what the field is about
• in the sentence Your theme can display menus in two locations I think the number of locations can't be a word, must be a number for translation issues otherwise it would need a different string for each, possible, number of supported locations

[karmatosed]

I really like this and can see it fixing a lot of issues I have seen users experience. I also have constantly seen users fall into this really big interface pothole. Great work @melchoyce.

I really like the guidance of this flow. It seems to blend really nicely tutorial and interface. I would second @afercia suggesting the 'save and publish' is disabled for some steps.

I also would really like to prototype this flow on some users as soon as possible.

[celloexpressions]

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.

[melchoyce]

Thanks for your feedback, everyone. I've uploaded a revised version of the flow: customizer-menu-flow-v2.png​

The updated flow makes some adjustments based on your feedback here, and other feedback I've received from more of WordPress.com's support folks.

While running this by more people, someone pointed out one scenario I missed entirely: what happens when a theme provides a default menu? That menu doesn't actually exist. To replace it, you need to create a new menu. Are we able to tell when this is the case? If so, I've added some alternate text for when you're using a theme which provides a default menu. Thanks again to @michelleweber for working with me on the copy.

We should also consider the option to create a default menu with the site's pages here, as the admin version of menus does.

I agree — and think that can happen independently of this improvement. We'll still need an "empty" state, in case someone deletes their menu(s).

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 wonder which is the larger problem: updating menus, or reassigning them to different locations? Because the menu creation and updating process includes assigning menu locations, I think they can be a secondary action from the main panel. By emphasizing location during the creation process, I think it's okay to de-emphasize from the panels screen.

[celloexpressions]

It looks like much of 5 isn't addressed in the updated flows, if there are reasons it would be good to see those written out.

The "default" page menu in the admin is equivalent to the default menu that most themes provide, which is usually the default fallback in wp_nav_menu unless themes change it. So these are really the same issue. I wouldn't add even more complexity to the flow by having a separate screen to change the "default" that's being shown - that could just be a message within the main setup flow or shown as an actual menu that gets created when they change it.

Again, though, starter content makes the no menus case, and even the default page menu fallback case, very rare, and probably something that we shouldn't design the flow toward including. There will be one or more menus created already when they get here on a fresh site in most cases (depending on their flow prior to customizing).

[melchoyce]

After consulting with some more support folks, I think we should try customizer-menu-flow-v2.png​ and see how it goes. :)

[jbpaul17]

Punting to 4.8.1 per today's bug scrub.

[celloexpressions]

Additional note on customizer-menu-flow-v2.png​: it doesn't seem necessary to add extra steps to change the menu name. I wonder if the input could be redesigned to act as a title while also being immediately editable instead of using an additional edit button. The proposed "save" button doesn't make much sense either since this is live-previewed.

[westonruter]

FYI: The nav menus panel and nav menu sections can now display notifications of their own. See #38794.

[westonruter]

Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.

[celloexpressions]

I did a very quick review through the initial PR last night. While it doesn't look like we'll be able to get it all into 4.9 given the timing, there were a couple of text changes that could go into 4.9 pretty easily with low risk of breaking things and minimal API reworking - do you want to extract those into a patch @bpayton?

With the rest of it, it looks like it will make sense to do some refactoring of the current code in the process of making these changes. That could use additional consideration/discussion.

[bpayton]

Thanks for your review, @celloexpressions! I agree that we won't be able to get all of this into 4.9. I met with @melchoyce earlier today and picked out the parts we thought we could reasonably complete and merge. We are hoping to merge the bulk of what is currently in the PR after taking time to polish it. I am taking a look at styles and reviewing code against our coding guidelines now.

I definitely don't want to force premature change, but are there things I could address to ease your concern? The main thing I have in mind from your review is that there is a specialized control that would be better represented with a new generic button control that supports a description.

For others' reference, I am maintaining progress in a personal GitHub PR:
​https://github.com/brandonpayton/wordpress-develop/pull/1

[westonruter]

In 41768:

Customize: Improve the menu creation flow.

Often, folks run into two issues when they create new menus: they click "Add a Menu" thinking it will add a new page to their menu, or they forget to assign their new menu to a location, and then wonder why it doesn't show up on their site.

This commit rearranges the order of items in the menu panel, and updates the flow for creating a menu by breaking it up into steps. Additionally, more help text has been added to guide people through the process of creating a menu.

Also adds default type lookups for Panel and Section instances. See #30741.

Props bpayton, obenland, westonruter, celloexpessions, afercia, melchoyce, zoonini, michelleweber.
Fixes #40104.

[pento]

[41768] is causing ​test failures.

[bpayton]

Patch for last-minute qunit failures

[bpayton]

I attached a patch for the last-minute qunit failures. My apologies for the oversight.

[westonruter]

In 41773:

Customize: Fix QUnit tests after failures introduced in [41768].

Props bpayton.
Fixes #40104.

[ocean90]

In 41792:

Customize: Add context to "View All Locations" string.

This is about navigation menu locations. Also updates the array alignment to use spaces.

See #40104.

[SergeyBiryukov]

In 41956:

Customize: Use typographic quotation marks in the strings added in [41768].

Props audrasjb, tobifjellner.
Fixes #42290. See #40104.

[afercia]

There's still an inline comment
// @todo Add tests for api.Menus.NewMenuControl

referencing wp.customize.Menus.NewMenuControl which was completely removed. See also #42357 by @herregroen. Maybe this removal needs to be at least mentioned in a dev-notes post?

[westonruter]

Replying to afercia:

There's still an inline comment
// @todo Add tests for api.Menus.NewMenuControl

referencing wp.customize.Menus.NewMenuControl which was completely removed. See also #42357 by @herregroen. Maybe this removal needs to be at least mentioned in a dev-notes post?

Yes, I agree. @bpayton is going to add NewMenuControl back in #42357, but the deprecated/removed classes should also be listed in a dev note. I'm asking if we can likewise get unit tests written in the patch for #42357.

[westonruter]

In 42034:

Customize: Deprecate nav menu classes that are no longer used, instead of removing them immediately.

• Deprecate PHP classes WP_Customize_New_Menu_Section and WP_Customize_New_Menu_Control.
• Deprecate JS class wp.customize.Menus.NewMenuControl.
• Also introduce wp.customize.Menus.createNavMenu() for logic to create nav menus separately from the logic for handling UI interactions.

Amends [41768].
See #40104, #42364.
Fixes #42357.

[bpayton]

There is a dev note for preview here:
​https://make.wordpress.org/core/?p=23818&preview=true

I'm a bit confused that it is tagged Public Preview but still requires login to core wp-admin, but it is available there for review. I wanted to use an animated gif to show the new menu creation flow and ability to create menus from the All Locations view, but the ones I was creating were 10MB which is too large. I ended up using smaller static images but feel like something is missing.

[melchoyce]

I wanted to use an animated gif to show the new menu creation flow and ability to create menus from the All Locations view, but the ones I was creating were 10MB which is too large. I ended up using smaller static images but feel like something is missing.

I can make you some videos, should be smaller 👍

[bpayton]

Thank you for taking the time to record those and update the post. It's much better.

In retrospect, I should have thought of that. :) Video is easier to use nowadays.

[westonruter]

Dev note: ​https://make.wordpress.org/core/2017/11/07/nav-menu-improvements-in-the-customizer-in-4-9/