Custom Menu widget should include a shortcut to load selected menu inside the customiser

[paulwilde]

Similar to the "Original" link that loads the selected menu item inside the website preview there should be a shortcut inside the "Custom Menu" widget that loads the selected menu directly inside the customiser.

Such a shortcut would save travelling through 4 sections:

1. Back to widgets
2. Back to home
3. Menus
4. Select menu

[valendesigns]

Sounds cool, are you able to create a patch?

[celloexpressions]

Will be as easy as api.section( menu section id ).focus(), but yes, needs a patch for 4.3.

[celloexpressions]

32683.diff​ is a first-pass at adding an "edit menu" button to the nav menu widget when used in the customizer, which links directly to the associated nav menu section. This is great for user flow, and the button updates when the selected menu is changed.

In the patch, the JS is included fairly hickily, but without a JS API for widgets, I think this approach could work. It's scoped specifically to the ids of each widget so it should be fine. If anyone has an idea for a better approach, would love to see it.

[celloexpressions]

@westonruter how does this look? I'm not thrilled with the placement of the JS but it works pretty well in terms of a usability enhancement.

[westonruter]

@celloexpressions thanks for that. This is definitely a good starting point. I agree that the JS needs better placement, but it provides the prototype for what is needed. Adding a link from the widget to the menu section is indeed a huge usability improvement. One improvement that I see is the behavior of the back button. A user would probably expect after clicking “back” that they would be taken back to editing the widget and not be taken to the list of menus. If a user doesn't expect this (such as we who have gotten so used to navigating around panels so much), then they probably should.

I've been thinking about this a bit this week and I think we could very nicely override the back button here to serve as a breadcrumb/history navigation rather than a structural navigation in particular cases. For example, when clicking on Edit Menu, it could invoke this JS logic instead of just expanding the section. Consider this logic:

/**
 * Focus (expand) another construct and return to this control when it is collapsed.
 *
 * @param {wp.customize.Section|wp.customize.Panel} construct - The thing to expand.
 * @this {wp.customize.Control}
 */
function focusConstructAndRturnToControlWhenCollapsed( construct ) {
        var control = this;

        construct.focus();
        function onceCollapsed( isExpanded ) {
                if ( ! isExpanded ) {
                        construct.expanded.unbind( onceCollapsed );
                        control.focus();
                }
        }
        construct.expanded.bind( onceCollapsed );
}

To simulate from your browser console:

1. Open the Site Title and Tagline section.
2. Paste in the above function into your console.
3. Focus on the blogname and pretend there is a button to expand a given menu section.
4. Paste this into your console: focusConstructAndRturnToControlWhenCollapsed.call( wp.customize.control( 'blogname' ), wp.customize.section( 'nav_menu[87]' ) );
5. Notice that you are now in the given nav menu section (adapt the ID as needed in your example).
6. Click on Back and notice that instead of being navigated to the Menus panel that you are instead brought back to the blogname control with focus applied.

This would be a great improvement to usability I think.

[celloexpressions]

Needs an updated patch per slack conversation and Weston's comment above.

[celloexpressions]

Restructure JS, show/hide the edit button when a menu is selected.

[celloexpressions]

Change the back button to go back to the widget when closing the menu section. Adds a reusable function for this to the wp.customize.Control object, as well as passing the widget control as a second parameter to the widget-added event, for additional context where needed.

[celloexpressions]

32683.2.diff​ includes the updates discussed in Slack and above, improving the placement and structure of the JS and letting users navigate directly back to the widget after editing the associated menu.

This is really great for UX and also facilitates a couple of API improvements as noted in the patch descriptions. Should be close to ready now.

[westonruter]

@celloexpressions I did another pass in 32683.3.diff​. I removed the additional control arg being passed to the widget-added here because this is the same event that is being used on the widgets admin page, and there the arg wouldn't be available. I think adding it does make sense, but I think we should do that in another ticket to consider any implications to JS written specifically for the widgets admin page.

Also, I moved focusConstructAndReturnToControlWhenCollapsed into private scope and renamed to focusConstructWithBreadcrumb. Since this is the only instance of us needing this functionality so far, and because the name is unwieldily, I decided to make it private for now. We can make it public in another ticket once we have a second use case and can agree on a better API for it (I just came up with that verbose name for illustration purposes).

I'll commit this unless you have any further feedback.

[celloexpressions]

32683.3.diff​ looks good to me!

[westonruter]

In 37437:

Customize: Include shortcut button in Custom Menu widget to edit the selected menu in the Customizer.

Clicking on the Edit Menu button focuses on the corresponding nav menu section. Upon collapsing the nav menu section, the focus is returned to the Custom Menu widget instead of taking the user to the menus root panel. In this way, the back button behavior is modified once to serve as breadcrumb/history navigation. The Edit Menu button with the breadcrumb back button behavior greatly reduce the number of UI interactions needed to edit a menu referenced in a Custom Menu widget.

Props celloexpressions, westonruter.
Fixes #32683.