Previously: GSoC Project Proposal: WordPress Menu Customizer.
Week 1 – 5/19: Introduce the ability to view all existing menus as customizer sections with menu items as customizer controls.
Week 2 – 5/26: Add the ability to edit menus (change labels, attributes, re-order items), including a temporary solution that includes the screen options found on the existing menus screen. Run user tests on the existing menu management screen to inform UI decisions for the initial iteration, coordinating with the WordPress core UI team.
Week 3 – 6/2: Implement an input-type-agnostic re-ordering mode, merging the existing UIs on the Menus screen and in the Widget Customizer (should particularly help with touch & keyboard input). Implement a version of #27406 into the plugin (pending its completion for core, potentially also assist with the core patch if needed), to maintain 3.9 compatibility. Move all menus (customizer sections) to the menus/navigation super-section, and implement the theme location controls in the new interface. Begin implementing a panel to add new widgets, potentially re-using components from the Widget Customizer’s equivalent UI (and potentially making it more easily re-usable outside of core).
Week 4 – 6/9: Create the ability to add items to menus, utilizing the slide-out panel from the Widget Customizer. For the first iteration, include sections containing pages, custom links, and categories, similar to those on the existing menus page.
Week 5 – 6/16: Second iteration of the add-new interface. Introduce a global search feature, an experimental approach to adding custom links, add all appropriate post types and taxonomies, and create a one-click add/remove menu items mode. Implement any additional ideas for adding items proposed by the WordPress core UI team.
Week 6 – 6/23: Midterm evaluations – critical functionality should be complete (editing & adding to menus, changing menu locations). Publish plugin (with WordPress 3.9 compatibility) on WordPress.org repository to facilitate community testing & feedback. Begin extensive user testing to facilitate further UI iterations. Add ability to create new menus, and delete menus, with the appropriate corresponding menu location UIs adapting accordingly.
Week 7 – 6/30: Address the need to implement screen options into the new menus interface. Work through the list of outstanding issues with the implementation, and begin responding to community feedback. 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 dealing with deep menu-nesting (sub-menus) within the narrow customize controls area.
Week 8 – 7/7: Implement refinements for simplified use-cases, such as those added in WordPress 3.6 (#23119). Continue addressing bug fixes and enhancements based on community feedback. Add new hooks and create usage examples for them (#18584), if scaling issues can be resolved.
Weeks 9 – 12 – 7/14-8/4: Run user tests on the existing menus screen and the Menu Customizer. Iterate the UI and codebase based on user tests and feedback from WordPress core designers and developers, giving special attention to the experience for new users and a stronger emphasis on the ability to use menus in widget areas. 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. Final project, as both a functioning plugin and a core patch, should be 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.