Ryan Boren published a post to the Make/WordPress Core blog this afternoon, titled Trust, Live Preview, and Menus in the Customizer. In it he clarified the reasons why he and several other core contributors are committed to iterating the customizer and identified the feature as a means of building user trust through live previews.

Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

Boren briefly summarized the history of the customizer and alluded to a few possibilities the framework may offer in the future:

The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.

The Menu Customizer plugin was tentatively approved for merge during last week’s core development meeting. In order for the it to be officially approved for merge on June 17th, the plugin will need to meet the feature plugin criteria outlined in the core handbook.

“We have eight days to get the Menu Customizer plugin ready for merge,” Boren said. During this time the flow team will be testing and documenting the flow and visuals for the menu customizer.

Boren invited anyone who wants to contribute to this effort to create flow comparisons of the existing flow through Appearance > Menus versus flow through the customizer. This essentially involves walking through the experience of setting up menus, taking screenshots of the flow, and publishing them as a captioned gallery.

“Please help us capture the flows through Appearance > Menus used by you and your clients,” he said. “We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used.”

Anyone can contribute to WordPress in this way, as it doesn’t require any coding. The core team is looking for people to capture real user scenarios to help in making the final decision.

There is No Timeline for Removing the Appearance > Menus Screen

In the original merge proposal for the Menu Customizer the plugin’s author, Nick Halsey, outlined what he called a “fairly aggressive” plan for the removal of the old menus admin screen. As contributor resources are scarce when it comes to the Menus component, Halsey favored focusing all new development on the UI in the customizer.

The timeline he outlined was for WordPress 4.3 to point the Menus link in the admin bar to Menus in the customizer and later releases (WordPress 4.5 or 4.6) would remove all core links to the Menus admin screen.

WordPress users reacted strongly to this aggressive timeline for removing the old menus screen, but the timeline was merely a suggestion as part of the proposal. Halsey was not keen on merging the plugin without a definitive timeline for removing the old menus, a factor which he considered a “dealbreaker” for merge.

However, WordPress 4.3 release lead Konstantin Obenland confirmed that no official timeline has been set.

@pollyplummer There is no timeline either way. — Konstantin Obenland (@obenland) June 9, 2015

Ryan Boren also confirmed that WordPress will continue to maintain the Appearance > Menus screen should the plugin be officially approved for merge in the coming days:

Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.

This confirmation should assuage those whose opposition to the Menu Customizer was solely based on the aggressive timeline proposed for removing the old menus screen.

The great divide on the Menu Customizer revolves around one aspect of improvement that Boren mentioned in his paragraph about the future of the customizer: scaling to large screens. The vast majority of WordPress users and developers who are following this debate are those who would be more likely to configure a menu in a desktop environment and not via mobile (where the customizer is currently designed to shine).

Many who oppose the merge of the plugin have identified the cramped UI as the primary reason that it does not provide a better experience for users. You would be hard pressed to find anyone who is opposed to live previews or better usability on mobile devices.

Those who manage WordPress sites via desktop are not willing to sacrifice the old menus screen for a new UI that currently caters primarily to smaller devices. Until the Menu Customizer can adequately provide a UI that fully adapts to all screen sizes, resistance to the feature is likely to continue.