Nav Menu Improvements in the Customizer in 4.9

In our usability tests with prior releases, we identified two common problems users encountered when trying to create a menu.

  1. Clicking the Add a Menu button in an attempt to add a page to their new menu.
  2. Forgetting to assign the menu to a location.

In WordPress 4.9, we’ve updated the Customizer’s menu creation flow to address these issues.

An Updated Menus Panel

The Menus panel layout and copy have been updated for clarity. The panel now shows menus first and locations second. This puts menus front and center and allows the panel to adjust more easily to specific scenarios. For example, when there are no menus, the panel asks users to create a menu and explains the steps to be taken.

Before After

Menu Creation

When the user clicks Create New Menu, the Customizer opens a dedicated menu creation section. Using a dedicated section allows us to guide the user through each step of menu creation. We start by inviting the user to provide a clear name for the menu and to select its new location. Once the menu is created, we guide them to add menu items and highlight the Add Items button if the user doesn’t find it after a short time.

Create a Menu for a Location

The locations section now allows the user to create a menu for a location that has not been assigned a menu. When the user clicks a location’s Create New Menu link, the Customizer opens the Menu Creation section with the location preselected.

Deprecated UI Classes

With the addition of a dedicated menu creation section, a number of classes are no longer used and are being deprecated.

The following PHP classes have been deprecated along with their files:

  • WP_Customize_New_Menu_Control in
  • WP_Customize_New_Menu_Section in

The following JS class has been deprecated (but not its containing file):

  • api.Menus.NewMenuControl in

Related Tickets

  • #40104 Customizer: Improve menu creation flow
  • #36279 Add an “add new menu” button to the menu locations section in the customizer
  • #42114 Customize Menus: UX Improvements
  • #42116 Customize Menus: Add “It doesn’t look like your site has any menus yet” view
  • #42357 NewMenuControl class has been removed from trunk

#4-9, #customizer, #dev-notes

Customization Meeting Notes: January 16, 2017

We had a meeting today in #core-customize to kick off the customization focus in 2017. Here’s a summary of what we chatted about:

    • Check out and for some great discussion, and share your own thoughts.
    • What are your biggest customization pain points?
      • WordPress doesn’t help you setup your site according to your goals.
      • What’s a featured image? What’s a header image?
      • Moving (“dancing”) in and out of panels hunting for what you’re trying to edit is difficult.
      • Why can I click on one thing to edit it but not another thing?
      • User expectations from @ianstewart:
      • If you can’t see it, how can you edit it?
      • We need an improved flow for content editing as part of customization that better ties that together with the surface-level tools.
      • Moving, adding, and deleting chunks of content and “features” in a design should be possible.
    • What if the customizer panel is blank, and stuff shows up only when the user clicks something in the preview? Would they be able to do everything they need?
      • We made a step towards this with Edit Shortcuts in 4.7.
      • But, Edit Shortcuts is a bandaid.
      • Need a balance of contextual tools and global controls.
    • How many tickets can we close by iterating on a whole flow?
    • What are the drawbacks of direct manipulation?
      • (Direct manipulation = I see it, I tap/click it to edit.)
      • Focused on what you see in front of you right now, rather than your whole site across multiple screen sizes.
      • It’s easy to mess up the site layout and design if you can control everything.
        • This is where “undo” could be handy.
        • Hard to tell if you’re customizing something locally or something globally.
      • Should we separate content, layout, and design?
    • @karmatosed is going to be leading user research and testing:
      • Have a series of posts on here on make/design asking for input, focusing on how people are using the Customizer to build sites for themselves and for clients.
      • Have people test the Customizer and report bugs to Trac.
      • Frequent Trac triage of Customization component.
      • Have a public “call for testing” for every new feature or flow iteration. Would be good to integrate these into local WordCamps and meetups as well.
    • We need to continue working on the technical architecture of the Customizer in preparation for future features and customization flows:
      • Changesets: #31089.
      • REST API for Changesets: #38900.
      • Customize Snapshots: GitHub PR.
      • Bigger features we know we want to support in the future need to be scoped and architected now, while we’re designing, so they’re ready to be implemented later.
        • I think it’s important to identify the big picture technical stuff, the things we’ll know we need for sure to support implementing the fuzzy design that will come clearer into view. It will take many months to implement. We can’t wait for design to be “finished” before we start development. It needs to be iterative. — @westonruter
    • Potential wins in the 3 months?:
      • Merging edited starter content on theme switch:
      • Pain points with lost widgets and menus when switching themes.
    • Many of the features and flows we want to build out in the future (drafting changes, revisions, content blocks) need to be worked on in collaboration with the Editor team.

We also continued the discussion past the meeting time. The conversations were a bit too long to summarize, but you can catch up starting here.

If you’re interested in getting involved, please add your input to the “What makes a great customization experience?” thread and join us in Slack.


Focus Tech and Design Leads

There are three main focuses this year: the REST API, the editor, and the customizer.

For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

Each focus will have a tech lead, and a design lead, and I’ll be working closely with each to make sure we’re aligned and moving diligently in the right direction even though we don’t have the normal release hooks. These starting leads will be:

REST API: Ryan McCue and KAdam White.

Editor: Matias Ventura and Joen Asmussen.

Customizer: Weston Ruter and Mel Choyce.

Given there is no set timeline for releases that would normally set a term, these leads are free to bow out at any time they feel they can’t contribute fully and we’ll find a replacement.

You might be wondering what each lead is responsible for. The REST team gave some thought to this for their focus, and this is the list they came up with:

Tech Lead responsibilities:

  • identify and ensure implementation of first-class REST API usage within WP-Admin,
  • replacing/refactoring admin-ajax use.
  • overall REST API architecture
  • infrastructure and endpoint performance
  • security at an infrastructure and endpoint (data-exposure) level
  • improving authentication options and documentation
  • working with the Design Lead to build new, or expand on existing, endpoints
  • working with the Design Lead to address usability feedback for the infrastructure and endpoints

Design Lead responsibilities:

  • usability of endpoints for internal or external clients
  • usability of the infrastructure from the perspective of a API client
  • working with the Editor and Customizer focus teams to collect requirements and gather feedback
  • identifying ways to improve the overall experience for folks building clients or consuming endpoints (like documentation)

#customizer, #editor, #rest-api