Here's a list of potential enhancements that I'd like to test for 3.6:

A) Managing menus as tabs can be confusing. Sometimes users think the tabs represent the menu itself, and they'll create multiple menus by mistake (thinking the tabs represent menu items). Tabs also pose a problem, after you get 10+ menus. I'd like to test the idea of removing the tabs altogether. My thought was to add a "add menu" link next to the header (similar to other areas of the admin), and move menu selection to a drop down select box.

B) In the "add new menu" view, new users get confused as to what they are supposed to do. Both of the users we tested wanted to click the "Create Menu" button first (not noticing the menu name field). I'd like to test adding focus to the menu name field, and moving the "Create Menu" button closer to the name field (just for this add new screen).

C) The "theme locations" section appears to be semi-confusing to users. I'd like to test moving the functionality to the bottom of the page, and changing the formatting, so that it no longer matches the formatting of the rest of the left column, and perhaps changing the wording a bit.

D) I'd like to add an intro sentence which explains that menus can be used as custom navigation within your theme (we'd link to "theme locations" at the bottom of the page), or within widgets (adding a link to widgets). It will just be a quick, short sentence to introduce the concept of menus, while at the same time exposing the fact that menus can be used in widgets.

E) There's a lot of wasted space in the left column. Moving "theme locations" to the bottom of the page will free up a little space, but I'd like to see if there is anything else we can do to eliminate the need to scroll. I'd like to test changing the left column to an accordion (using jQuery UI). Thus eliminating a bunch of padding, and showing only one menu items options at a time. We'll test it and see how it performs.

F) When a user saves a change to "theme locations" it would be nice to give them a link to preview their new menu.

Once we complete some patches, we'll test these enhancements by re-running more users through the same set of user tests.

I like the idea of using a select field in place of the text input and have an option to "add new" which then shows the text input with the create menu and a cancel button(to switch back to the select). I can create an example if anyone else is interested in this approach.

23119-E.diff​ includes D, and turns the existing meta boxes into an accordion. I hacked it together with a few lines of JS and CSS. I chose to do it this way rather than mess with jQuery accordion, because all I'm really concerned with at this point is testing the concept. We'll test this version with some additional users and see how it performs (then we can come back and review the best way to handle this).

Setting the focus on load into the input field looks like a useful addition. But what happens when the user is just exploring the UI, looking for something else? It is quite a long way to get back to the left hand navigation without a mouse.

The new menu input could be a datalist, so we can select a menu to edit without going down the whole page.

This morning, I ​ran two more users through the same set of user tests as the first two users (from a week ago). From the above patches, B was the only only one that stood out as a clear improvement to me. I've reverted A, C, D, E & F in 23119.7.diff​.

Next, I'll post another series of diffs based on observations from all 4 user tests, and then I'll test them again by running two more users through. We'll keep at it until we've smoothed over all of the rough parts.

Since multilingual support is enabled via any number of plugins, and not built into core itself, I'm not sure how much if anything we can do to anticipate what plugins might or might not do to that screen.

I think this all looks great! Very nice. My only (very, very minor) quibble with C is that I think the theme location settings should only be moved to the bottom if E is also done, so that the theme location settings aren't pushed way down on the page.

23119.9.diff​ adds a simple fade in effect to items when they are added to a menu (one user didn't notice where the menu item went after he saved it). It also adds a slideDown effect to the yellow message bar (just something I'd like to test).

I'm not totally against it. My only reservation is that by swapping the two, you no longer see both meta boxes at smaller resolutions. Currently you see "pages" peeking out at the bottom (making it more discoverable):

23119.10.diff adds a "sub menu" description to menu items that are dragged to any sub menu position. A couple of the users didn't really understand why the menu items could be dragged there. Hopefully this will provide a bit more clarity:

Not sure "sub menu" is really quite right - I think it implies a display style, which might or might not be true in a given use. The concept of hierarchy is a little more of a complex one, but the help text should probably indicate "order and hierarchy" or some such.

Not sure "sub menu" is really quite right - I think it implies a display style, which might or might not be true in a given use. The concept of hierarchy is a little more of a complex one, but the help text should probably indicate "order and hierarchy" or some such.

I'm not totally against it. My only reservation is that by swapping the two, you no longer see both meta boxes at smaller resolutions. Currently you see "pages" peeking out at the bottom (making it more discoverable):

I think it makes sense to keep Pages second so you can see multiple boxes.
If you then minimise the custom box it should remember that so Pages will move higher.

"sub item" is certainly more accurate, although I'm going to play devil's advocate and wonder if we're wandering too far into trying to teach the concept of web navigation as a bulleted list with hierarchy via text on the menu screen :)

"sub item" is certainly more accurate, although I'm going to play devil's advocate and wonder if we're wandering too far into trying to teach the concept of web navigation as a bulleted list with hierarchy via text on the menu screen :)

I believe that removing the tabs for listing all menus is necessary here.

What about a "New Menu" screen that has the most basic needs for a menu? Name, theme location, etc. Lots of room for help text. Creating the menu takes you to the menu manager page. This is more in line with a completely new menu than a submenu, though, and I doubt core devs would want to break it out of the Appearances menu.

If not that, an alternative is to use a Manage Menu/New Menu nav tab exactly like the Themes menu.

Removing the noise from what's needed to "build an existing menu" vs. "create a new menu" is what I'm getting at.

The dragging/ordering verbiage takes up quite a bit of space for seasoned users (a whole menu item can practically fit there) - maybe we can intro-tooltip some of the menu directions for first time users?

The dragging/ordering verbiage takes up quite a bit of space for seasoned users (a whole menu item can practically fit there) - maybe we can intro-tooltip some of the menu directions for first time users?

Or maybe that line can appear below the menu items?
If you add lots of menu items it will obviously be off the page but people should have seen it before that as they start adding items - unless it's a first time user editing an large existing menu I guess.

I believe that removing the tabs for listing all menus is necessary here.

What about a "New Menu" screen that has the most basic needs for a menu? Name, theme location, etc. Lots of room for help text. Creating the menu takes you to the menu manager page.

Riffing on this. What about something like:

Using WP_List_Table to list the menus instead of tabs.

Thoughts?

That's a good start. The theme location/menu assignment underneath the WP_List_Table class seems out of place, though. Would this make better sense as maybe a third column on the menu screen? Plus, that'll make it a sortable to help those with lots of meta boxes.

That's a good start. The theme location/menu assignment underneath the WP_List_Table class seems out of place, though. Would this make better sense as maybe a third column on the menu screen? Plus, that'll make it a sortable to help those with lots of meta boxes.

Not sure how well that would work since you can only assign a single menu to a location, it might make for a really awkward UI to have that assignment be in the list of menus

The theme location/menu assignment underneath the WP_List_Table class seems out of place, though. Would this make better sense as maybe a third column on the menu screen? Plus, that'll make it a sortable to help those with lots of meta boxes.

I don't think so. The theme location drop down allows you to select from multiple menus, which tells me it belongs on the menu management screen, not the add/edit screen (which should be all about a single menu). It always felt out of place to me in at the top of the add menu items column.

I don't think so. The theme location drop down allows you to select from multiple menus, which tells me it belongs on the menu management screen, not the add/edit screen (which should be all about a single menu). It always felt out of place to me in at the top of the add menu items column.

That's fair. I think you can make the menu mangement screen two column with the menu assignment on the left. With the WP_List_Class and it's paging/screen options, it could be pushed way down the page.

I like the idea of using WP_List_Table for the menus and even still having the theme location metabox adjacent to it.

Has anyone considered maybe capitalizing on the post edit UI for menu editing as we similarly did for media editing in 3.5? Title becomes menu name, the metaboxes column could hold the "add menu item" metaboxes, etc. Just a thought.

Technically speaking, this is a little bit different than attachments - a menu is a taxonomy term, and each nav menu item is a post in that post type associated with that taxonomy term (both the taxonomy and post type being non-exposed/non-public). Not saying that it's not an idea worth pursuing - just noting that it'd be more involved than what was done in 3.5 for the attachment post type.

Technically speaking, this is a little bit different than attachments - a menu is a taxonomy term, and each nav menu item is a post in that post type associated with that taxonomy term (both the taxonomy and post type being non-exposed/non-public).

Oh, it's definitely a little bit different :)

The main reasoning I bring up a split UI is twofold:

The UI as-is is cluttered and doesn't have a clear primary purpose. Currently, it's used for creating and managing menus as well as assigning menu locations. It's a vacuum-packed approach that is both difficult to organize and emphasize priority.

A split UI allows for prioritizing the screens' purpose. A screen for managing menus and locations, a screen for editing the menus. The latter screen is familiar to people because it's re-used all over the Dashboard.

It occurs to me that a split-UI approach should not be outside the realm of possibility but two unique pages should; that's another menu item under Appearance.

What about a stepped approach similar to how the ​WP-Table Reloaded plugin handles it? A management screen leads to a table-editing screen and you're given two buttons: "Update Changes" and "Save and go back".

So in this context you could have "Save Menu" and "Manage Menus" on the menu-editing step.

Would there be any support for breaking Menus out of the Appearance section? I've often thought that would make sense, seeing as how menus are essentially pieces of content, much like posts, pages, comments, other post types, etc. That would support using a UI similar to those other pieces of content (All Menus, Add New).

Would there be any support for breaking Menus out of the Appearance section? I've often thought that would make sense, seeing as how menus are essentially pieces of content, much like posts, pages, comments, other post types, etc. That would support using a UI similar to those other pieces of content (All Menus, Add New).

I was literally just thinking this. I know it would add to the 'noise' on the left-hand menu, but it would also fix the awkward tabs for manage/new.

Would there be any support for breaking Menus out of the Appearance section? I've often thought that would make sense, seeing as how menus are essentially pieces of content, much like posts, pages, comments, other post types, etc. That would support using a UI similar to those other pieces of content (All Menus, Add New).

+1 for moving Menus out of Appearance. With a split UI it just makes more sense, avoids the problem users have with tabs on the Menu configuration page, works with the existing UI conventions for the Dashboard, etc.

Plus, Menus has always felt *buried* in there; most new users are unaware of this tool until I point it out, so I'm sure this is a pain point for a lot of new users.

Would there be any support for breaking Menus out of the Appearance section?

My worry with this would be, how often do you customize menus? My guess is that many (dare I say most) users will do it once to add menus while first customizing their site, and then only very occasionally revisit to make small changes. So, while conceptually it make sense (since there is both a management screen, and an add/edit screen), I'm still not certain it warrants a spot in the main nav.

I agree with @lessbloat on leaving it as-is under Appearance. We can have two screens (two files, whatever) without needing two menu items. And as @helen points out, menus aren't your fly-by-night average post type, in fact they are a taxonomy.

I would however still argue for 2 separate files (the same as how we handle the two tabs in Appearance > Themes), but that's mostly because it's easier to do targeted help tabs without having to stuff them full of two screens' information.

My worry with this would be, how often do you customize menus? My guess is that many (dare I say most) users will do it once to add menus while first customizing their site, and then only very occasionally revisit to make small changes. So, while conceptually it make sense (since there is both a management screen, and an add/edit screen), I'm still not certain it warrants a spot in the main nav.

Thoughts?

That's a fair argument; I don't know any users that change this once it's been set up, except maybe occasionally.

I would however still argue for 2 separate files (the same as how we handle the two tabs in Appearance > Themes), but that's mostly because it's easier to do targeted help tabs without having to stuff them full of two screens' information.

Sounds fine by me. The converse however is that you then have two pages with very similar markup. Anyone else want to weigh in on this?

Adds a new "Common Links" meta box with "home", and "log in" for starters. This is hacked in (I'm just anxious to test it), so if you can think of a better way to add it (perhaps make it more extensible) I'm all ears.

Re-organizes the meta boxes on the "add/edit" screen, so now it's: (Pages, Common Links, Custom Links, Categories) by default.

Changed "Label" under "Custom Links" to "Link Text". We'll test this and see how it performs.

What other links do you imagine under "Common Links"? Do you expect this to auto-populate with actual frequently-used links as users add items to their menus? Or is it just meant to be a specially-curated list of links?

If the latter, then I suggest that we rename it to something different, as "common" suggests to me that they would be links I've inserted before. Also, wonder if anyone has extra suggestions as for links to add in there? Seems silly to have that meta box for just 2 links. Then again we should make it extensible for plugin developers to add their own links in here.

I like the added search bar on top of the menu location meta box, but now that it's there, I wish both of them were on the other side of the list table, e.g. 2col:1col vs 1col:2col.

The search box seems confusing to me when visually paired with the metabox because the list table is what's going to change if you search for something. And actually, what would the workflow be if you searched? Does it just filter down the list table view?

I haven't poked into 23119.14 yet, so just wondering about row actions. Has there been discussion about what row actions we might want for the list view?

Would please ask that we also consider accessibility in the discussion. There is an outstanding trac ticket #14045 (and duplicate #21289) about accessibility of the custom menu builder. Basically it is impossible or very difficult to be able to fully create a custom menu and amend the hierarchy if you can't use a mouse. The drag and drop functionality is an alien concept to blind users who will probably be using keyboard interaction with their screen readers.

Any solution to the Menus functionality should either be a) accessible for everyone, or b) an alternate accessible version should be provided alongside the drag/drop interface (as per Widgets).

Have heard mention on another ticket that there might be a rudimentary accessible non-js version in place already. Is that actually true, and could it form the basis for an accessible way forward?

I Believe the double-tab separation between Management and Creation modes is really a nice and useful addition; should make all the difference for users to make the distinction naturally over time.

I only have one suggestion:

Add Menu

I feel like the menu name hasn't enough prominence where it is right now. I'd try to put it outside the box to make the information hierarchy clearer (outside defines how the menu is going to be defined; inside defines what belongs to this context).

Is "Use this menu within your theme" locked in for the metabox? If so, I'd almost be tempted to change "Assign a theme location for this menu" to mimic that. As I mentioned on Skype, it might also be worth it to swap out the anchor text based on whether the menu already has an assignment -- something I'll play with.

Linking to widgets is something I've not fully worked out yet. I like that we're exposing the fact that you can use menus in widgets. My only worry is what happens when the user clicks the link? There is a lot on that page, and I think it will be hard for most new users to make the connection that they then need to 1) add a "custom menu" widget to their sidebar, and then 2) select a menu within that widget and save it. Wondering if there is anything else we can do there to bring more clarity to this process.

I like it, probably better than the 'Assign a theme location for this menu' anchor on the update message. Consistency in messaging is better because people read it, click the link, repeat it and look for something that matches. And if it matches exactly, all the better.

Linking to widgets is something I've not fully worked out yet. I like that we're exposing the fact that you can use menus in widgets. My only worry is what happens when the user clicks the link? There is a lot on that page, and I think it will be hard for most new users to make the connection that they then need to 1) add a "custom menu" widget to their sidebar, and then 2) select a menu within that widget and save it. Wondering if there is anything else we can do there to bring more clarity to this process.

For sure the last thing we want to do is dump a user on the Widgets page to connect the dots for themselves. How about just some hint text, like:

"You can also use the Custom Menu Widget to add menus to the sidebar of your site. Manage my widgets."

That's a bit wordy, but at least points the user in the right direction...

Testing
1) Focus on a menu item (there has to be more than one)
2) pressing the right, left, up or down key.

Supports RTL. Supports moving single item as well as items with children (sub items). Ideally, it should behave identical to drag/drop. With that said, there is a lot going on here, so please ping me if you notice any issues.

Patch also adds class-wp-menus-list-table.php back in (was missing in 23119.18.1.diff​)

What other links do you imagine under "Common Links"? Do you expect this to auto-populate with actual frequently-used links as users add items to their menus? Or is it just meant to be a specially-curated list of links?

My thought was to show "Home" and "login" by default. Mostly because these are particularly hard to figure out how to add to the menu. But then to allow theme devs to hook in and add/remove whatever links they want. I don't think we should auto-populate with frequently-used links.

If the latter, then I suggest that we rename it to something different, as "common" suggests to me that they would be links I've inserted before.

Open to suggestions. How about "Helpful links", or "Quick links"?

Also, wonder if anyone has extra suggestions as for links to add in there? Seems silly to have that meta box for just 2 links.

I think it's okay to have just 2 links. I don't want to add too many, or we'll lose the "Custom Links" meta box at the bottom fold.

23119.20.diff​ adds a filter for the $common_links array, also swaps out get_site_url() for get_home_url() on the default 'Home' link.

Just a note about "Home" links. As long as we keep "common links" as the type "custom" (vs page, post, CPT, taxonomy, etc.), there's code already in place to make sure the home links can be recognized as the "current" page. See wping/nav-menu-template.php for more on that.

lessbloat - jkudish: Do you think we could do away with bulk actions on the menus list screen? I just think it will be pretty edge case that someone has enough menus to need them, and if we got rid of them, the list table would align with the "Menus within your theme" meta box.jkudish - yes can do. can you add that to the ticket so I remember?

I especially see the benefit for plugins that may have specialty feeds or pages to link to. As it stands, if you want anything custom, you have to type it out yourself.

Yes , I agree with you I was thinking about something like that before a few months , It's very good to plugins and themes to give the user more powerful menus .

Another Idea is to add a context menu items , I means add the ability to show items for the logged-in-users or shows items in home page only ... etc ... I think it's a plugin job but it still a good idea :)

I couldn't agree more with this. The ability to automatically add child pages (preferably with a checkbox that can be turned on or off depending on preference) would be a great improvement to menus.

Even though Menu's are separate from the actual page structure, in my experience many novice users assume that child pages will get added with the top level page automatically.

The best case senario would be to have all subpages physically added (when the option is checked) so that individual subpages can be removed if necessary.

I see how you could make a case for this, but to be fair, when you add pages to a custom menu, what you see is then an accurate representation of what the menu will be after saving, so it's not as if any behavior is hidden from the user.

Furthermore, the default behavior (which I just tested in 3.5 with the Twenty Eleven theme active), with no custom menus created, is to add all pages to the menu, including child pages, as sub-menu items under their parent pages. Because of this behavior (which is good, imo), adding a checkbox to the custom menu creation area titled something like "Add all child pages automatically" would be rather ambiguous, as it could have five meanings that I can think of right now, depending on where it was placed:

Only add currently extant pages which have the page I'm actively adding as their parent. If new child pages are created later, do not add them automatically.

Regardless of when they come into existence, add all child pages of the page I'm actively adding to this menu. If I add a new child page next week, add it to the menu.

Do # 1, but for all parent pages currently in the menu.

Do # 2, but for all parent pages currently in the menu.

Do # 1, but for all parent pages, regardless of when they are added to the menu.

Do # 2, but for all parent pages, regardless of when they are added to the menu.

I should note that this list went from two scenarios to six scenarios as I was typing it. Suffice it to say, I think adding such a checkbox has the potential to introduce a lot of confusion and complexity! However, like I said, I could see a case (whether I agree with it or not) for it, so perhaps it would be worth creating a ticket to discuss.

I've been thinking about the proposed new layout over the weekend, and the one thing that still bugs me is the "Menus within your theme" meta box. It still seems out of place. I mocked up an alternative approach, and wanted to get your take:

What if we removed the "Menus within your theme" meta box from the manage screen.

And put it at the top of "Screen Options":

Then the "default menu for your theme" link in the "Save Menu" success message would simply slide down "Screen Options" when clicked.

We of course would user test this approach to find out if it actually works for users.

I've been thinking about the proposed new layout over the weekend, and the one thing that still bugs me is the "Menus within your theme" meta box. It still seems out of place. I mocked up an alternative approach, and wanted to get your take:

What if we removed the "Menus within your theme" meta box from the manage screen.

And put it at the top of "Screen Options":

Then the "default menu for your theme" link in the "Save Menu" success message would simply slide down "Screen Options" when clicked.

We of course would user test this approach to find out if it actually works for users.

Thoughts?

The problem with this approach is that you are hiding primary functionality within the Screen Options tab, which should be used to show/hide items in the admin screen.

If you want to get rid of that meta box, you might as well get rid of the two tabs and use the header "Add New" method and just display it on the menu screen in the same spot it's always been.

mmm , I am not sure about the best way to achieve this but I have an idea on how can we do it , Simply adding a check-box beside the menu item title , so by checking more than one item makes easy to move or delete ... etc

I also took some time over the weekend to sort of hone in on what exactly the problem is that we're solving. Having not watched the initial tests, I came to the conclusion that we're really trying to relieve two main pain points:

Managing multiple menus in an easily discoverable way

Cramming the workflow into a single screen

At the devchat last week, @nacin made a pretty valid point that the proposed two-tab workflow feels "heavy". I think that if we step back a little bit at look at both the pain points we're trying to address and the ideas we've come up with thus far, we can take it from a new, educated approach.

If you look at, for instance, the way @lessbloat was able to direct the focus on the "New Menu" screen by using an overlay to disable anything but the new menu creation form, that's something that works really well to promote visual hierarchy.

What if we do something like this:

Menus overall workflow:

Return to the original idea of a single-screen menus workflow

Menu location metabox & multiple menu management:

Move the idea of assigning a menu to a location into the menu editor itself, therefore tying it more to the workflow of, "I'm editing this menu, I want it to be used in 'this place'"

Drop using the tabbed navigation system for switching between menus. In my experience, users seem confused by this most of the time.

Leverage the "location" metabox/area to instead act as the primary launchpad for toggling between menus and use the overlay effect to highlight this area when you first hit the page.

I can do a mockup of this once I get to the airport but that's the gist of it. It's the equivalent of a UI refresh but not a complete overhaul.

adding a checkbox to the custom menu creation area titled something like "Add all child pages automatically" would be rather ambiguous .

I agree with you , What about adding a checkbox in the Page Meta Box ( or any post-type that supports Hierarchical ) shows when selecting a parent item ( Item that have a child items ) titled by something like 'Hierarchical ?' ...

At the devchat last week, @nacin made a pretty valid point that the proposed two-tab workflow feels "heavy".

I'm not particularly attached to the idea of having a manage screen and an add/edit screen. With that said, I do expect any concept we consider to test as well, if not better than the 2 tab approach.

The only measure of effectiveness that I have to fall back on is that the two tab approach seemed to ​test well (especially since the users were only working with 1 or 2 menus). Neither of them seemed confused, or overwhelmed by the manage screen.

What if we do something like this:

Menus overall workflow:

Return to the original idea of a single-screen menus workflow

Menu location metabox & multiple menu management:

Move the idea of assigning a menu to a location into the menu editor itself, therefore tying it more to the workflow of, "I'm editing this menu, I want it to be used in 'this place'"

Drop using the tabbed navigation system for switching between menus. In my experience, users seem confused by this most of the time.

Leverage the "location" metabox/area to instead act as the primary launchpad for toggling between menus and use the overlay effect to highlight this area when you first hit the page.

I'm happy to test anything we think might perform better. But my gut says that any single screen that attempts to:

As a heads up I just ​ran one more user through to test the 2 tab concept. I was looking to test an idea I had about visually highlighting the “Menus in your theme” meta box when a user clicks there from the “add/edit” screen success message. It doesn't appear to have helped in that regard, but using the two tabs still seems to offer a fairly simple flow overall.

I was travelling so I am just catching up on the conversation here and going to quickly throw in my thoughts on everything that's been said (but will bare repeating at the Menus ​discussion in a few minutes as well. Essentially I agree with @lessbloat on most of his points, but will elaborate:

I agree in regards to complex functionality, that should stay in plugins and we should keep the UI minimal and clean while affording functionality for ~80% of users

I am also not married to the two tab UI, but just as the test confirm, it's a much better interface than what we had before. If someone makes a good mockup that shows a redo of the one tabbed UI, I might jump ship :)

The "locations" meta box was a bit odd on the right side. But it also most definitely does not belong hidden in "screen options", that's a really bad place for it. I think that either below or above the list of menus may be a better place for it. It's hard to only display it when editing a specific menu since it's the kind of thing that could be changed without needing edit a menu.

Perhaps the menu name/save area has room to grow. This might be a good spot for assigning them to a theme and a little slide toggle could be used. I use this exact method in one of my plugins to allow for lots of different options that wouldn't otherwise fit.

In theory this is a good place for picking the in-theme menu locations, and one we should accommodate/allow for. However since most or at least not all themes support the theme customizer, and we need to remain backwards compatible, we can't have this as the only way to set theme menu locations.

For some reason I thought that a theme needed to add theme support for the customizer. I tested it out and you're right. My mistake :)
I noticed that menu theme locations are already available in the customizer though...

Keep in mind: themes aren't the only place menus can be used, so we need to be careful that we don't force a workflow that assumes they're only used in themes. I believe lachlanj has input on that and also some use cases to give a better sense of how menus are actually used in the wild/production.

Keep in mind: themes aren't the only place menus can be used, so we need to be careful that we don't force a workflow that assumes they're only used in themes. I believe lachlanj has input on that and also some use cases to give a better sense of how menus are actually used in the wild/production.

I know that menus also used in widgets, it doesn't break anything. We just change the UI and present a new User Experience for changing theme design.

Keep in mind: themes aren't the only place menus can be used, so we need to be careful that we don't force a workflow that assumes they're only used in themes. I believe lachlanj has input on that and also some use cases to give a better sense of how menus are actually used in the wild/production.

Thanks rmccue, I thought it might be helpful to show 2 different 'real world' cases for how we have used menus on client sites.

​http://cl.ly/image/0l3p2j1F3p2y - This theme uses 7 menus locations in total, 3 standard menus but the theme also has 5 different landing pages for each department in the company, and each of these has it's own unique menu.

This is similar to what has been discussed above, but I thought some screenshots might help

This is what i was thinking:
The "Customizer" will be used to assign specific menu/sidebar to the theme.

Please note, we are only focusing on menus improvements for this ticket (but I hope to see improvements to widgets in a future release as well).

Assigning the theme location inside the customizer is definitely worth testing (especially since it's already coded up). It would eliminate the meta box from the manage screen, and give the user a visual representation of the change (and how it affects their theme). If we continue to support IE7 in 3.6, we'd have to come up with a work around, since the customizer doesn't work (that I recall) in IE7.

Amazing progress on making Menus more usable. Have you considered something like this for the "manage screen"?

Allow people to drag their created menus into the theme's menu locations, instead of using dropdowns on its own panel. (We could also eventually include registered sidebars there, and automatically create a "custom menu widget" when you drag a menu to them.)

Amazing progress on making Menus more usable. Have you considered something like this for the "manage screen"?

Allow people to drag their created menus into the theme's menu locations, instead of using dropdowns on its own panel. (We could also eventually include registered sidebars there, and automatically create a "custom menu widget" when you drag a menu to them.)

A drag and drop interface was discussed on IRC, and dismissed as too clumsy and not terribly accessible, much like the current widgets interface.

I apologize if the timing is off (too late?) but I believe there is another important UI shortcoming that I have not seen mentioned (in browsing this ticket).

The part of the screen that holds the UI containers from which menu content items can be selected is dysfunctional when there are many items (pages/posts/categories) to choose from ... especially when there are additional custom post-types and they too are populated with much content.

Hey, thanks for chiming in. It's never too late (until we hit code freeze ;-)). I actually played around with a similar concept a while back: ​http://davemart.in/?p=74.

The big drawback to this approach that I saw (aside from it being a drastically different flow from what users are used to - and as a result something they would have to likely re-teach themselves), is that you lose the ability to add multiple pages, categories, or posts at once. In the current flow, you can select a bunch of pages, and add them all at once. With the flow you propose, you'd have to add each page one by one. I feel like that is a blocker for going this route.

The big drawback to this approach that I saw (aside from it being a drastically different flow from what users are used to - and as a result something they would have to likely re-teach themselves), is that you lose the ability to add multiple pages, categories, or posts at once. In the current flow, you can select a bunch of pages, and add them all at once. With the flow you propose, you'd have to add each page one by one. I feel like that is a blocker for going this route.

My main point is that the second largest (if not largest) UI real-estate area should go to the "things I can add to the menu".

The tabbed area makes it possible to allocate more real-estate to each of the "types of things" that can be added to the menu. I see no need to have on screen at the same multiple sources. If I am looking for posts - then let me see just posts. When I want to select from pages or categories or anything else I don't need to scroll down to look for them ... and to lose sight (literally) of the menu I am working on.

Within the tabbed area there is then plenty of space that can be used for better search and filtering.

Because the spaces are tabbed it may be possible to do on demand loading of data (instead of loading everything, everytime the screen loads). That may drastically improve page performance ...

AND you can use that improved performance to do a smarter load ... like indicating somehow which items have already been added to the menu.

You can still add checkboxes for selecting multiple items and an "add to menu" button. However what I tried to suggest was one click add instead of two click add. Instead of clicking to select each menu and then having to move the moust somewhere else AND clicking one more time "add to menu" you simply add directly. It feels to me like a faster, smoother and more efficient experience (unless I am missing something).

It feels to me like a faster, smoother and more efficient experience (unless I am missing something).

Let's try and keep this thread on task please. I do appreciate your input. But, the mockup you presented has a number of shortcomings, the largest of which I already mentioned (it being a drastically different flow from what users are used to). Which no amount of reasoning can remedy.

I do appreciate your input. But, the mockup you presented has a number of shortcomings, the largest of which I already mentioned (it being a drastically different flow from what users are used to). Which no amount of reasoning can remedy.

@lessbloat, why not change the current flow? WordPress 3.5 changed drastically the media manager and the wordpress community embrace those changes. People love changes.

I mocked up my interpretation of Nacins concept ​here. I'd love to hear your thoughts, but let's keep feedback for that design over on that thread for now.

That mockup still does not address the most important area of the screen - the things I can pull into the menu. Try to populate the mockup with real content (put in a list of pages/posts/categories/custom post types ... and see that you simply can't.

It feels to me like a faster, smoother and more efficient experience (unless I am missing something).

Let's try and keep this thread on task please. I do appreciate your input. But, the mockup you presented has a number of shortcomings, the largest of which I already mentioned (it being a drastically different flow from what users are used to). Which no amount of reasoning can remedy.

This is off-topic (but I will not pursue it further then this short comment), but I think it is important. Is there a way/place/opportunity in the WordPress development process to debate your position? I'm OK with you asking me to back off ... really ... but is that the best thing for a design effort?

This is off-topic (but I will not pursue it further then this short comment), but I think it is important. Is there a way/place/opportunity in the WordPress development process to debate your position? I'm OK with you asking me to back off ... really ... but is that the best thing for a design effort?

It's funny you should ask. Earlier today, @lessbloat proposed three approaches for this nav-menus action on the make.wordpress.org/core P2 site. Your two cents on that post are welcomed and encouraged.

Earlier today, @lessbloat proposed three approaches for this nav-menus action on the make.wordpress.org/core P2 site. Your two cents on that post are welcomed and encouraged.

Seems like the core P2 does not post my comments, so i will write my response here.

The current menu screen has too many functions (add new menus, edit existing menus, manage manus, assign menus to theme locations). Its all mixed up in one screen. Very confusing. This is why i prefer the two screens approach.

Not to mention that the "two screens approach" very similar to the post/page UI, which makes it much easier to use.

Seems like the core P2 does not post my comments, so i will write my response here.

I don't see any comments from you awaiting moderation and other people are commenting just fine. Can you try to figure out what's going wrong there? This ticket is getting extremely long and difficult to follow, and it would be sad to lose your comment and its context.

Is there a way/place/opportunity in the WordPress development process to debate your position?

Absolutely. For clarity's sake:

I'm really not trying to be a jerk. (honest!) :-)

This ticket is not the best place to post drastically new ideas.

Even though I'm the lead for this feature, I don't have final say on any of it (that is left to Mark and Aaron). My role is to assist in the development, but also to keep the development of this feature on track, and on time.

We've got office hours for this feature each Mon & Thu at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev. After we've covered any agenda items, you are free to bring up whatever ideas & concerns that you may have. There is also the ​make/core P2. You are welcome to leave whatever comments there that you'd like (as long as they are on topic). Those are your two best options, if you'd like to present a new idea.

jkudish will gather ​some more data for tomorrows meeting (held this Thursday @ 21:00UTC in #wordpress-dev). We need finalize the direction we're taking with menus if this is going to make 3.6 - I hope to see you there.

When users have 1 theme location, and zero menus, and at least one page, we show them a simplified blank slate screen. We pre-populate it with the menu items that show up on their site by default (when no menus have been added).

Single Menu State

When users have one menu, we take them right to editing it (they don't see the menu management drop down):

Add Menu State

We reduced the amount of copy, and improved the visual hierarchy:

Multiple Menus State

When a user has more than one menu, we show them a drop down at the top where they can select another menu. This replaces the tabs approach which was confusing for users on multiple fronts:

Menu items

We added keyboard accessibility for moving menu items

We added "sub item" as helper text when menu items are dragged to a sub item position (multiple users had a positive reaction to this, as it improves clarity as to what just happened if they drag a menu item to a sub position by mistake).

Custom Links

Changed "Label" to "Link Text" (Before this change some users were not adding link text - since the change, everyone has).

Since the admin messages never fade away, some users were experiencing trouble knowing if their menus were saved (when they saved their menu multiple times in a row). We added in a slide down effect, which appears to have fixed the issue (we might consider doing this admin-wide).

In the Zero Menus State, I'm assuming from the presence of the "create menu" button that clicking that button (whether menu items are rearranged or not?) creates a new custom menu. Is that correct?

If so, I feel that may be a little confusing/non-obvious. Perhaps some copy explaining that this is the default menu (based on existing pages, right?), and that clicking the button saves it as a custom menu that can be edited, would be best?

In the Zero Menus State, I'm assuming from the presence of the "create menu" button that clicking that button (whether menu items are rearranged or not?) creates a new custom menu. Is that correct?

Yes, that is correct.

If so, I feel that may be a little confusing/non-obvious. Perhaps some copy explaining that this is the default menu (based on existing pages, right?), and that clicking the button saves it as a custom menu that can be edited, would be best?

If so, I feel that may be a little confusing/non-obvious. Perhaps some copy explaining that this is the default menu (based on existing pages, right?), and that clicking the button saves it as a custom menu that can be edited, would be best?

23119.22.diff​ changes it to: "Edit your default menu by adding or removing items. Drag each item into the order you prefer. Click Create Menu to save your changes." (suggestions welcome).

The idea behind the "zero menu" state is that it simplifies the flow for the majority of new users (based on the assumption that their theme has a single theme location).

Upon clicking "Create Menu" in the "zero menu" state, 23119.23.diff​ auto-saves the users new menu as their primary theme location. This saves users from having to manually select a menu for their single theme location (at this point we know they only have one of each), thus streamlining the flow, and consolidating two steps into one.

Users with themes that have zero theme locations, or more than one theme location will not see the zero menus state, and are taken right to the add new screen if they don't have any menus.

Note that this patch is sort of the minimal amount of work/code required to make this work, it can/needs to be cleaned up a bit and if we proceed with this approach we also need to remove the theme locations metabox code (which I've commented out the add_meta_box line for now + added a todo for)

Here's how the checkbox looks:

Here's it looks if a menu is already assigned to a location (adds a note under the checkbox):

Let me know what you think and if you can test this, please do and let me know if there's any issues.

I also have 2 unrelated notes of something I noticed with this latest patch that we should probably fix:

'delete menu' link should be red

there should be some explanatory text under 'Menu Structure' before you add items to it, otherwise it's a very confusing heading on it's own

How will that work when there are many theme locations, a dozen or so? Yes, that’s rare, but then it will look rather confusing, I guess.

Note: This is just a proposed concept (something we'll test with a couple users). If it flops in usability testing, we're back to square one.

The theme location checkboxes will just stack on top of each other. I would think a dozen would be extremely edge case. My guess is that the majority of themes have 1-3 theme locations. Thanks to Philip we have ​some data to back that up (my guess is that this same pattern is found in most wp.org themes as well).

I suppose we could add a hook in there, so theme devs could swap out the checkboxes for something else. But I suspect that if you're using a theme with 12 theme locations, you're a step above the average user, and you can likely figure out what's going on.

Which I actually don't mind at all. I changed my mind after posting this. I feel like the checkboxes should stay stacked, as we're adding (currently uses 'Menu Name') in light gray next to one if it is used by another menu.

The theme location checkboxes will just stack on top of each other. I would think a dozen would be extremely edge case.

For a regular blog, yes. When WP is used as a CMS, no. I had to do this multiple times: Custom menu locations for custom post types (sidebars in singular views) for custom roles and combinations of both.

I suppose we could add a hook in there, so theme devs could swap out the checkboxes for something else.

Added explanatory text back under 'Menu Structure' before you add items

If you create more than one menu, and Menu 1 is already assigned to a theme location, you'll see:

I'm open to copy/formatting suggestions for the "Set to" bit. We can also add a confirmation JS alert if they click the Primary box, asking if they're sure they want to switch the Primary theme location to this new menu (as it can only be set to one menu at a time).

Supports RTL. Supports moving single item as well as items with children (sub items). Ideally, it should behave identical to drag/drop. With that said, there is a lot going on here, so please ping me if you notice any issues.

Can you please elaborate on this functionality? From the standpoint of a blind person, how would I be moving this item and know where I'm moving it? Moving something without vision, even while only using the keyboard, seems to me something that would inherently require vision.

Whereas, for instance, ordering items in the accessibility mode of the widget screen relies on numbers to delineate where the widgets would be.

;-) Sorry, I take responsibility for that. I'm still learning how to use Trac effectively.

From the standpoint of a blind person, how would I be moving this item and know where I'm moving it? ... Whereas, for instance, ordering items in the accessibility mode of the widget screen relies on numbers to delineate where the widgets would be.

The only thing I've done is make it possible to rearrange the menu items via the keyboard (vs. requiring users to drag and drop menu items with a mouse). As you've pointed out, this improves accessibility for some users, but not all. To be honest, this is the first I've seen/heard of the accessibility mode in widgets.

For full disclosure, I'm really a novice when it comes to accessibility design. With that said, I'm eager to help where I can, so I appreciate your bringing this to my attention. A couple of questions:

If I set you up with a sandbox for testing with the latest (23119.25.diff​) patch applied, would you be wiling to make a list of all of the remaining in-accessible elements on the menu screen?

In the widgets accessibility mode, is going to a new screen to re-assign order helpful in that it removes other distractions, or was it just coded up that way?

For full disclosure, I'm really a novice when it comes to accessibility design. With that said, I'm eager to help where I can, so I appreciate your bringing this to my attention. A couple of questions:

If I set you up with a sandbox for testing with the latest (23119.25.diff​) patch applied, would you be wiling to make a list of all of the remaining in-accessible elements on the menu screen?

Yes, provided you walk me through what I'd need to do on my end. The extent of my testing has been on nightly builds.

In the widgets accessibility mode, is going to a new screen to re-assign order helpful in that it removes other distractions, or was it just coded up that way?

I don't know; I wasn't part of testing this when it was being introduced.

23119.27.diff​ adds the locations in a comma-separated list to the 'Selected menu' dropdown. I'd love to iterate the foreaches around L#462.

Also note:

I moved the $locations and $menu_locations bits up to about L#395 just below where we set $_nav_menu->truncated_name so I could reuse the arrays previously reserved for the locations checkboxes around L#555.

There's no way to select menus from the drop-down. Perhaps a no-js button?

It's difficult for me to fully comment on functionality from just a screenshot, but for accessibility reasons it is always desirable to have a 'Go' button of some sort when a select or drop-down is being used as a navigational device. Where the page or context changes purely triggered by the onchange event, this means that keyboard only users (including screen readers) will be triggering such functionality as they roll through the options in the select.

It looks like there's still some trailing whitespace. For example, wp-admin/js/nav-menu.js line 399 has only changed because there's a space at the end now. Whoever commits can probably fix it, but it's likely that you can set your editor to trim trailing whitespace automatically.

23119.29.2.diff​ fixes some coding standards on the new stuff, makes hex codes 6-digits on the CSS colors and some other small stuff.

Not sure I'm onboard with the 'Go' button on the dropdown select. I like that we have the button, but not 'Go'. I also think 'Selected menu' should change to maybe just 'Select menu', especially if we're adding a button. Thoughts?

It looks like there's still some trailing whitespace. For example, wp-admin/js/nav-menu.js line 399 has only changed because there's a space at the end now. Whoever commits can probably fix it, but it's likely that you can set your editor to trim trailing whitespace automatically.

Thanks for the tip. Found a plugin for Coda. As far as I can tell, 23119.29.3.diff​ should do the trick.

made some minor code standards/spacing adjustments (both in php and in js)

adjusted the way we count the number of existing pages to use wp_count_posts() instead of get_pages() for performance reasons

using absint() when getting the recently edited menu instead of just (int), just to be safe

using empty() instead of just ! when checking if there is a recently edited menu, just to be safe

using empty() instead of comparing against 0 when checking if there is a currently selected menu

making use of selected() in the new menu selection dropdown instead of doing an if dance and manually echoing selected=selected

replaced a URL that we were manually building with ? to use add_query_arg() instead

addressed @ocean90's comment about the tax label name

removed some unneeded remove_query_arg()

fixed incorrect usage of esc_attr_e()

added missing escaping on one of the submit buttons

js: cached $(this) in a few spots that we missed it

js: yoda conditions

Note: I did not review the css

Note: Between wp-admin/nav-menus.php and wp-admin/includes/nav-menu.php we have a lot of code. We should probably take a closer look to see if there's any repetition, unused code and such to see if we can optimize a bit. This seemed like beyond the scope of this initial code review, so I didn't dig too deep for now.

There's no way to select menus from the drop-down. Perhaps a no-js button?

It's difficult for me to fully comment on functionality from just a screenshot, but for accessibility reasons it is always desirable to have a 'Go' button of some sort when a select or drop-down is being used as a navigational device. Where the page or context changes purely triggered by the onchange event, this means that keyboard only users (including screen readers) will be triggering such functionality as they roll through the options in the select.

grahamarmfield, it seems like the redirect on change would only take place upon selection of a select option, not just in browsing the select options. Can you please clarify which is the case for screen readers?

grahamarmfield, it seems like the redirect on change would only take place upon selection of a select option, not just in browsing the select options. Can you please clarify which is the case for screen readers?

For most keyboard only users, when encountering a dropdown they would use the up and down arrow keys to review the options. This (I believe) fires the onchange event whenever a new option is moved to. So hence my comment re context change triggered by onchange.

There is a keystroke combination in Windows that allows the dropdown to be opened and the options to be reviewed without firing the onchange event until the enter key is pressed. But this keystroke combination is not widely known and is therefore likely to be hardly used.

So if the change of context is not triggered by the onchange event, but instead by tabbing away from the dropdown (onblur?) then I guess we're into a bit of a grey area.

The issue with not providing a 'Go' or 'Select' (or whatever) button is not just a problem for keyboard and screen reader users. Those using speech recognition software also need to be catered for.

For most keyboard only users, when encountering a dropdown they would use the up and down arrow keys to review the options. This (I believe) fires the onchange event whenever a new option is moved to. So hence my comment re context change triggered by onchange.

In most browsers it is Shift+Arrow. But you have to know in advance when you need that.

So if the change of context is not triggered by the onchange event, but instead by tabbing away from the dropdown (onblur?) then I guess we're into a bit of a grey area.

Would still not be a predictable behavior.

The issue with not providing a 'Go' or 'Select' (or whatever) button is not just a problem for keyboard and screen reader users. Those using speech recognition software also need to be catered for.

A button is also easier to use on a touch screen, because there is enough space around.

So I guess lessbloat has been manually incrementing his patch numbers. Just so you know, if you upload 23119.diff over and over, Trac will change it to 23119.2.diff, 23119.3.diff, etc.

Anyway, 23119.diff​ is based off 23119.31.refresh.diff​. The only thing I did is take out the "Add %s" strings where %s was a post type name or taxonomy name. Strings like that aren't translatable. If it turns out that we need a string like that, it would need to be added to the labels array in get_taxonomy_labels() and get_post_type_labels(). Since it doesn't currently exist though, many plugins and themes won't be using it and a default might be worse than not having the word Add prepended.

What is the benefit of changing the metabox title Custom Link to Add Links? These are all links which can be added to a menu.

The prefix Add should be removed to be consistent with the other titles. IMO Custom should come back too, since there is still a way to get the old Link Manager back, which isn't meant here.

One of the things we're still implementing is ​making the menu items into an accordion. This improves the experience by decreasing the chance that the user will have to scroll to access all of the menu item options.

One downside of having most of the menu items closed on the left side is that it becomes harder for a first time user to know what is going on there. "Custom link" doesn't really convey any action. By switching it to "Add links" I felt like the underlying functionality became more discoverable at a glance, and the concept became much more clear (that each of the accordion options on the left allow me to add menu items).

An alternative could be to add a header above the accordion, something like: "Add menu items". This would be less redundant in the use of the word "Add", but it would push the accordion options down (slightly), and make for much less of a balanced UI (right now it's ​squared off nicely with a straight line across the top of the menu items accordion box, all the way across to the menu editing box). Happy to take a stab at it, if we think that approach would be better.

My best guess is there's a problem with set_theme_mod() setting an invalid, absint-ed menu location with a value of 0, which therefore translates into an undefined offset into the second foreach for the select box.

23119.3.diff does the trick for the undefined offset and array_merge errors.

Also to note, there is a case of an "invisible" menu on a vanilla install. When you first visit Menus and create a new menu, it's saved but you're sent back to the Create Menu screen as though you don't have any menus.

As @jkudish ​notes, it's likely caused by $nav_menu_selected_id being empty without a menu_id in the URL.

23119.3.diff does the trick for the undefined offset and array_merge errors.

Also to note, there is a case of an "invisible" menu on a vanilla install. When you first visit Menus and create a new menu, it's saved but you're sent back to the Create Menu screen as though you don't have any menus.

As @jkudish ​notes, it's likely caused by $nav_menu_selected_id being empty without a menu_id in the URL.

​23119.4.diff (which includes 23119.3.diff) should fix the "invisible" menu issue and make sure that we always display a menu if one exists.

Perhaps we should look at opening a new ticket and/or individual tickets for new stuff cropping up such as refactoring and/or docs, etc. When we hit what would be 23119.7, the incrementer will restart at 23119.32

I totally misunderstood the UI here and couldn't figure out how to create a new menu. However, it was obvious once someone pointed it out to me. I'm unsure if this was just me being an idiot, or if there is a genuine UX problem. Currently I'm erring on the side of "Ryan being an idiot", but thought I'd point out my difficulties in case it has any impact on decisions here.

I totally misunderstood the UI here and couldn't figure out how to create a new menu. However, it was obvious once someone pointed it out to me. I'm unsure if this was just me being an idiot, or if there is a genuine UX problem. Currently I'm erring on the side of "Ryan being an idiot", but thought I'd point out my difficulties in case it has any impact on decisions here.

I agree with you. Even though having the 'Add Menu' button up in the header is consistent with the other UI screens, I feel like it's really not very discoverable up there. @markoheijnen didn't see it right away the other day either.

I'd be curious to see if user tests will confirm there's a discoverability problem.

Open to additional thoughts on this, but this was actually intentional. For your first menu we preload all of the menu items that show in your theme by default (before you add our first menu). We do this out of convenience. When you click the "add new" link, I don't think we should preload any menu items. If you'd like to add a menu for a menu widget, you should be able to do so without first having to remove a bunch of menu items.

Perhaps we should look at opening a new ticket and/or individual tickets for new stuff cropping up such as refactoring and/or docs, etc. When we hit what would be 23119.7, the incrementer will restart at 23119.32