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.
I think this whole mess has (yet again) uncovered two major issues with how we do things in the WordPress community:
1. While all development is open, unless you make a serious effort there is very little chance you’ll know about what’s happening until it suddenly pops up as a new feature about to ship.
2. As the community of users grows, wide-scale user testing across all types of users becomes more important.
For those of us who follow core development and feature plugins with rapt attention, this new feature was not a surprise, but we are in the minority. Furthermore, the people this change will affect the most (the average user) are not aware of this discussion and will not know of the new feature until they come across it in an update.
I have no problems believing that early user tests have proven the Customizer menu handling to be far superior to the current system. Nor do I have any questions about the claims of critics that a removal of the current feature in favor of the Customizer solution will cause widespread confusion. And this is why I was never in doubt that those at the top of the pyramid would make sure the implementation would not be destructive, as exemplified by Ryan and others.
The larger implication here is that we need better communication across the board about what’s happening. Yes, some of that responsibility lies at the hands of the users, but the major onus is on us that work on new features. Due to the sheer size of the WordPress user base it is not responsible to spring new features on them, regardless of how well thought out they are. People have an intrinsic fear of anything new, and we have to make sure any time something changes in a fundamental way that we ease them into it. This can be done by providing ample information before the shift happens.