Work accomplished since last office hours

• jkudish moved the theme location options to checkboxes for us to test
• I added accordion styling to menu items (for testing)
• We tested 2 new users with these changes (and they both performed the scenarios flawlessly)
• DrewAPicture implemented locations in the ‘Selected menu’ drop down

Major items discussed

1) Theme locations continues to be our biggest design challenge. We discussed a bunch of options and decided to go with checkboxes for theme locations for now – while we continue to stew on alternative approaches.

2) We discussed having settings at the top or the bottom, and settled on them being on the bottom.

On the docket

• Refactor accordion code (@lessbloat)
• Re-assess CSS in latest patch (currently 23119.28.1.diff), and move colors to colors.css (Looking for a volunteer here)
• Browser compat testing (Looking for a volunteer here)
• No JS testing (Looking for a volunteer here)
• Code review (Looking for volunteers here – hopefully from multiple people)
• Commit what we’ve got

After that

• Any additional accessibility work
• Additional code refactoring
• Am I missing anything?

p.s. @DrewAPicture, I added a title this time just for you.

We’ll only be focusing on changes to nav-menus.php for now.

I just posted an updated diff containing some of the ideas we discussed.

Remaining Tasks (already assigned to someone)

• Test theme locations as checkboxes (@jkudish volunteered to code this up). Note: we decided to leave widgets as checkboxes out.
• Menu selection dropdown should show location(s) it is used in (@DrewAPicture offered to tackle this)
• A round of user tests on 23119.23.diff, plus additional testing once “theme locations as checkboxes” and the accordion code is ready
• Updated copy for help tabs (both manage, and add/edit screen) (@DrewAPicture will oversee this)
• Updated copy for ​http://codex.wordpress.org/WordPress_Menu_User_Guide (@DrewAPicture will oversee this)
• Updated copy for ​http://codex.wordpress.org/Appearance_Menus_Screen (@DrewAPicture will oversee this)

Remaining Tasks (still needing a volunteer)

• Code up menu item boxes as an accordion for us to test (similar in style to customizer).
• Code reviews (multiple people please )
• RTL testing
• Browser compatibility testing
• No JS testing

Comment below if you’re interested in helping out. Thanks!

My hope is that we can stay true to the WordPress Philosophy by optimizing the experience for the majority of users, and leaving edge cases for plugins to handle.

One issue at this stage is that I can only guess as to what the majority looks like. I’m going to attempt to gather some data from WordPress.com as to how many users have one menu vs. more than one vs. none. This should give us some additional insight into the best way to approach menus.

For this weeks meeting my goal was to list out, and then (roughly) prioritize the biggest pain points associated with menus. Since I have little data at this point, this prioritization is based on the assumption that the vast majority of users have either no menus or one menu.

Here’s how I prioritized things, please weigh in if you disagree:

• One of the biggest disconnects I’ve seen is the concept of “theme locations”. Adding a menu, and then assigning it to a theme location seems broken.
• Trying to have menu management + editing + theme location assignment all on the same page is overwhelming.
• Tabs don’t work for users with lots of menus to manage, and they confuse some users (who think they represent menu items within a single menu). Side note: when we tested menu management via a drop down (instead of tabs), users didn’t notice the drop down, and wondered where the menus they had already created were. A “manage menus” tab appears to work for users, but it seems heavy for users with just a single menu.
• Switching themes poses a problem for menus in that there is no concept of a base menu. Every theme determines their own default menu, and even though two menus may have a single primary menu, you still have to re-assign your menu to that theme location whenever you switch a theme.
• Users have a hard time visualizing how the menu changes they are making actually impact their blog/site.
• Having to scroll to see all of the menu item meta boxes in the left column can be annoying, and it can make discoverability for items below the fold harder.
• If you have a long menu (with lot’s of menu items), you may be scrolling unreasonably down from the left to the right column.
• The fact that you can add menus to a custom menu widget is not exposed anywhere.

Did I miss anything?

The way I see it, we have 3 options:

1) Nacin’s concept

We could push in the direction of Nacin’s concept.

2) The two screen approach

We could go with the two screen approach. Here are a couple of updated screenshots (nothing is finalized):

When you have no menus:

Management screen (default screen you see when you click the “menus” link on the left nav):

Editing a single menu:

Assigning a menu to a theme location (linked to from the management screen, and from the “menu saved” success message):

3) Scale back

The other option is for us to scale back our scope, keep all of the existing structure of the existing menus screen the same, and focus on making minor improvements in copy and flow.

We need to figure out which option we think will work best for users and commit to it before moving forward.

Office hours will be held tomorrow (Thursday) at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev. I hope to see you there.

Here’s a reminder of more or less where we’re at: http://make.wordpress.org/core/2013/01/16/heres-a-quick-update-on-the-3-6-menu/

In addition to talking about the feature, we’ll figure out a good time to hold all other bi-weekly meetings. Thanks!

Last week we:

• Merged the the UI into two screens. Â Now we have manage menus & add/edit menus.
• Tested this new two screen approach. Â It went really well (we put two users through – videos are on the Make/UI P2).
• Improved & simplified some copy
• Added a new hookable “common links” meta box with “home” and “Log in” as the default links (both of which are fairly confusing to try and add to a menu otherwise).
• Added keyboard accessibility for rearranging menu items

What’s left:

CODE

• Break this out into two separate files 1) manage 2) add/edit (@jkudish is on this)
• Code review everything (@jkudish volunteered)

DOCS

• Updated copy for help tabs (both manage, and add/edit screen) (@DrewAPicture volunteered)
• Updated copy for http://codex.wordpress.org/WordPress_Menu_User_Guide (@DrewAPicture volunteered)
• Updated copy for http://codex.wordpress.org/Appearance_Menus_Screen (@DrewAPicture volunteered)

TESTING

• Once the code items are complete, I’ll run another round of user tests (@lessbloat)
• RTL testing
• Browser compatibility testing
• No JS testing

If you’ve got some time, we’d love your help with testing the latest patch.

Lastly:

I’d love to hear all of your thoughts, concerns, criticisms.

@markjaquith and I are excited to have @lessbloat leading this. Take a look at all the user testing that has already been happening over at #23119 and make sure you comment here if you’re interested in helping out!

Ron talks about upgrading from MU to 3.0.