Please note that this post only contains the Project Description and Schedule of Deliverables sections, as they are the most relevant to public discussion.

Describe your idea in detail:

WordPress 3.9 introduces the Widget Customizer: a better way to edit widgets. This is a major step in the process of migrating every component of WordPress’ Appearance menu to the Theme Customizer, where users can live-preview their changes before publishing them. The remaining features that should be incorporated into the Customizer are theme-switching, menu management, and improved background-image handling. Once the Customizer is feature-complete, we can begin to experiment with alternative approaches to accessing the customizer, making it feel more like an editing mode on the front-end of the site, alongside the front-end content-editor.

Menu management would be a particularly useful addition, as it could address long-standing usability concerns with menus and theme locations. The Menu Customizer would offer the ability to visualize where menus are located, as well as how the order of menu items and sub-menus are displayed in the theme. The menus screen was refreshed a year ago in WordPress 3.6, and the research and user testing completed during that process provides a good starting point for implementing menu management in the customizer.

The user interface of menu management in the customizer would be comparable to that of the Widget Customizer. The first step would be to either implement or abstract functionality for super-sections in customizer controls, where the top-level section heading slides over to reveal sub-sections containing each menu (and for widgets, each widget area, see #27406). The scope of my work here depends somewhat on whether this is addressed before GSoC starts, but the goal will be for this functionality to exist in an API in core, which is utilized by both menus and widgets.

Unlike widgets, menus are not theme-specific, and new menus can be created at-will. The existing menus / theme locations paradigm should be maintained by migrating the existing theme locations selector to the new interface, and adding the ability to create, edit, and add to individual menus, all within the super-section of customizer controls. There should be a mechanism to easily identify the currently active menu in the preview, and to identify the corresponding menu in the controls when exploring the preview. Menu items should be able to be re-ordered and moved into and out of sub-menus several levels deep. New items should be able to be added from all of the sources available on the menu management screen (post types, taxonomies, and custom links). Ideally, support for custom post types and taxonomies should be added as well (see #16075). Adding menu items could work similarly to adding widgets, with a slide-out panel, but the visual organization of items within the panel would need work, as widgets do not have hierarchy. The entire interface must be accessible for all input types, including keyboard, mouse, and touch. Since the Customizer doesn’t have a concept of “Screen Options,” the screen options in the current menus interface should be ported to the Menu Customizer in some way if possible.

The technical implementation would likely be similar to that of the Widget Customizer feature. Like many JavaScript-based features in WordPress, including the Widget Customizer, the Menu Customizer would be implemented with Backbone.js. Technical improvements to menu-management could also potentially be ported back to the existing menu management screen, eliminating the current issues with scaling by only saving data that is changed (#14134). While re-factoring nav-menus.php would not be in scope for the Menu Customizer project initially, the work done here should be able to be ported to the old interface easily and could potentially be added to the scope of the project if it is ahead of schedule. The Menu Customizer would provide a workaround for users affected by #14134, too, as the new Backbone-powered UI shouldn’t have scaling issues. If the Menu Customizer provides all of the features of the existing menu management screen, while clearly demonstrating that it is a better solution than the existing screen in user tests, it could potentially replace the existing screen entirely for users that can access the Customizer (JS enabled, IE8+, IE 10+ with domain-mapped front-end).

In addition to adding the menu management functionality, this project would make other small improvements to the customizer as necessary, such as an API for super-sections and the slide-out item-adding panel, and better documentation and code examples of the customizer, as time allows.

What have you done so far with this idea:

I have shared a broader customizer-improvements proposal on wp-hackers and discussed it with Andrew Nacin and Lance Willett. Of the ideas I proposed, menu management and theme switching in the customizer are the most intriguing, and the most complex.

Lance indicated that there is ongoing work in many of the areas of the customizer, including background image improvements and conceptual theme-switching ideas. Other ideas I proposed, such as adjusting the way users access the customizer to make it feel more like an editing mode, like front-end-editing, would benefit from the customizer being more feature-complete first. Theme-switching would require extensive new UI/UX development, while Menu Management would use a similar UI to the Widget Customizer. Therefore, menu-management in the customizer seems to be a good place for a GSoC project to develop a new solution.

Nacin suggested that menus should be implemented in Backbone.js, and that the current menu management screen could also benefit from this improved approach. Perhaps both UIs could share the same core interface and code. I’ve began investigating existing Backbone.js implementations in WordPress core, such as the new “THX” themes screen, as well as researching the principles behind Backbone.js. I’ve also added consideration for potential improvements to the existing screen to my project description, although if the Menu Customizer is implemented well enough it could potentially replace the existing screen entirely for supported users. Unlike with widgets, it should be possible to incorporate all of the existing features within the customizer to the extent that there is no compelling reason to maintain the standalone menus screen. However, this consideration would be made near the end of the project and is more of a long-term implementation consideration than a definite objective.

Plugin, theme, or core: The Menu Customizer will be developed in a plugin, with every intention of being included in core. This means that all core coding and inline documentation standards must be observed throughout the project, and it should be as lean as possible in terms of both code and UI. Given the project timeline, it is likely that this plugin would be a proposed feature plugin for inclusion in WordPress 4.1.

Supporting code such as super-section and slide-out panel APIs in the customizer would likely be developed directly as core patches, but would potentially also be included with the plugin to facilitate testing the plugin while running older versions of WordPress.

Anticipated challenges: Menus are tricky, and core may not have found the best UI for them yet. While the Menu Customizer aims to fix many of the issues with the current interface, there is always the chance that it introduces additional usability issues. It has been proposed that menus should be tied to pages rather than site “appearance,” but there are inherent issues with this approach that have caused much pushback from the WordPress community. Therefore, the Menu Customizer project aims to maintain the paradigms of the existing system, while providing a new interface with which to manage it. Once the functionality is completed, any issues should be easy to identify by running user tests. If the internals are well-constructed, tweaking the interface to adapt to any issues that arise should be straightforward. The Backbone.js-based implementation will enable this flexibility. There is a good chance that the Menu Customizer combined with the Widget Customizer will make the ability to add menus to widgets clearer; some effort will be dedicated to ensuring that this interaction works well (adding a menu, then adding it to a widget).

Finding a good way to highlight menu edit-ability in the preview will likely be one of the more challenging UI aspects to consider after the functionality is complete, as that issue affected the Widget Customizer project.

Potential mentors: No preference.

Milestones and deliverables schedule:

I plan to work 40-hour weeks throughout the project to ensure that the Menu Customizer can be completed and prepared for a potential core merge by the end of GSoC. Each week would function as a cycle with clearly defined progress goals to ensure that the entire project stays on schedule. Once enough of the functionality is in place, the plugin where the Menu Customizer is developed would be released on WordPress.org with updates being pushed every Friday at the completion of each cycle.

• Community Bonding Period: work with mentor to adjust project scope and implementation strategies. Research the Widget Customizer implementation as well as other uses of Backbone.js in WordPress core to determine a specific plan for implementation. Research the WordPress 3.6 menus refresh for potential UI/UX considerations. Monitor potential progress of Customizer super-section support in core (for widgets), and adjust project schedule accordingly (much of the work scheduled for the first few weeks could be eliminated if someone else picks this up before GSoC starts, in which case more time could be devoted to working on the Menu Customizer itself). Super-sections are a prerequisite for implementing the Menu Customizer, but could be implemented via the plugin first if needed.
• Week 1 – 5/19: develop (or abstract from widgets) an API for WordPress core that allows super-sections in the Theme Customizer, depending on potential work by others during the community bonding period (after the release of WordPress 3.9). Post a complete draft patch to core trac by the end of the week. Determine Menu Customizer plugin structure and create the plugin files and outline the structure with documentation. Continue researching specific implementation strategies based on existing work in WordPress Core.
• Week 2 – 5/26: work with core developers to improve and finalize the Customizer super-section API and get it committed to core trunk. Develop an API for a slide-out panel in the customizer (this is the panel that is used to add widgets and would be used to add menu items; may end up being a full-fledged addition to the Customizer API, may only be extracting re-usable functionality from the add widgets panel to be used more generically), and submit as core patches. Begin modifying the core Widget Customizer implementation to utilize the new super-sections. Continue outlining the plugin structure.
• Week 3 – 6/2: Begin working on the Menu Customizer itself in earnest. Introduce the ability to view all existing menus as customizer sections with menu items as customizer controls in the plugin by the end of the week. Migrate theme locations controls to the new interface. Submit core patches for using the new super-section API for managing widgets.
• Week 4 – 6/9: Add the ability to edit menus (change labels, attributes, re-order items), with the Customizer’s live preview updating accordingly. Release initial version of plugin on WordPress.org.
• Week 5 – 6/16: Add ability to add items to menus, utilizing the slide-out panel abstracted from the Widget Customizer.
• Week 6 – 6/23: Midterm evaluations – critical functionality should be complete (editing & adding to menus, changing menu locations). Add ability to create new menus, and delete menus, with the theme location selectors adapting accordingly.
• Week 7 – 6/30: Work through the list of outstanding issues with the implementation. Much of these will likely be UI/UX quirks that come up through the development process and are delayed in favor of completing the basic functionality. Examples could include addressing the screen options in the existing menu management interface and dealing with deep menu-nesting (sub-menus) within the narrow customize controls area.
• Week 8 – 7/7: Complete all features and fixes in-scope for a solid 1.0 by the end of this cycle.
• Weeks 9 – 12 – 7/14-8/4: Run user tests on the existing menus screen and the Menu Customizer. Iterate the UI based on user tests and feedback from WordPress core designers and developers. Ensure the code is thoroughly documented and meets all core style guidelines. Test in all supported browsers and devices, with as many themes as possible, and with as many edge-cases as is feasible (ie, massive menus, huge numbers of menus, deep hierarchies, etc.). Fix bugs as they come up. Address whether the functionality is ready for core. If all goes well, consider whether the Menu Customizer could potentially replace the existing menus screen for supported users and develop approaches for user-discovery (for example, deep-linking).
• Week 13 – 8/11: Prepare a core patch for the plugin merge, and draft final proposals for inclusion of the feature in core. Goal to have final project, as both a functioning plugin and a core patch, competed by the firm pencils-down date of 8/18. In the event that the plugin is unlikely to be accepted for core inclusion, continue development of outstanding issues and gathering feedback from the community, with the goal of reaching a good stopping point for the official end of GSoC.

Other commitments: I will be taking exams during the community bonding period, but my semester ends the week before GSoC officially starts. Otherwise, I am available for the entire summer.