 | newtonsongbird on Suggestions |
 | Kim Parsell on Core Contributor Handbook |
 | Lance Willett on We’re getting very close… |
 | Muhammad Abdi on Core Contributor Handbook |
 | Maor Chasen on We’re getting very close… |
We’ve all been distracted with other stuff these past 2 weeks. DrewAPicture put together a parent ticket for all of the remaining menu items.
Remaining Tasks
I’d like to try and wrap all of these up ASAP.
Here’s a recap of yesterdays office hours.
Work accomplished since last office hours
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
After that
p.s. @DrewAPicture, I added a title this time just for you. 
RE: title, “He can be taught!”
We also need to do an extensive round of RTL testing as well as completing docblocks for any new functions we’re introducing, @access private or not.
I can start on no-js testing this weekend.
I did a round of RTl testing/fixing (I’m not sure I would call it extensive, but I think I caught most everything).
I can start on no-js testing this weekend.
Awesome! Thanks for that.
I also added more complete docblocks to new functions in 23119.28.2.diff
I can help with browser testing. Are we covering ie7? Or just 8+?
Hi, very nice 
When you use Mega drop down menu, you can’t delete all children from main menu. It would be great if we can Expand/Collaspe main menu and delete all children sub menu from main menu
I asked @jkudish to gather some data around avg number of menu items per menu for sites on WP.com. Out of 1000 random sites (with at least one menu added), here’s what the distribution looked like:
Excluding the menus with zero items added, the average comes out to 5.
So, based on this data, should we make some sort of expand/collaspe menu item functionality a part of core, or keep it in plugin territory?
I think my preference would be to keep it as a plugin, but I’d love to hear everyones thoughts.
Just a small correction to the description above, it was 3000 sites, not 1000. A lot of them didn’t have any menus at all, which is why if you add up the above numbers you don’t get 3000
Also, I agree with @lessbloat, I think this is plugin territory.
We had a great discussion yesterday during office hours. I’m excited to say that we’ve found our direction.
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)
Remaining Tasks (still needing a volunteer)
)Comment below if you’re interested in helping out. Thanks!
In addition to the checkboxes, I’ll help out with code reviewing and all the testing
I agree that the checkboxes shouldn’t be there for widgets, that’s be very confusing IMHO. However, maybe there should be a little tool tip or note below theme locations directing users that “Menus can also be added tomwidget areas via the custom menu widget available on the widget settings page”.
@lessbloat, what is the “deadline” for getting the accordion done for testing?
I’d like to wrap up all dev for this feature ASAP. I’ll likely pick it up if no one else grabs it by tomorrow.
We’re still in the process of determining the best direction for menus in 3.6 (mock ups and ideas welcome!).
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:
Did I miss anything?
1.
I agree theme locations isn’t working as it is now defined and managed.
Most sites I make & use have only one menu, so I do not declare theme locations at all in the theme. This is how it should work, that you don’t need to understand the concept of theme locations unless you have many menus and know how you want to organize them. This should all be hidden by default.
I like the idea of have the “base menu” concept just be a single menu that is not assigned a theme location, OR no menu at all in which case the fallback is to pull from all pages structure. Then if someone wants to get more complicated there should be another level of complication with multiple menus, in which case we want theme locations.
2.
Also, the way the wp_nav_menu() behaves differently [generates different html, accepts different arguments] whether or not any menu is declared [just takes the existing pages], or whether the menu is assigned to a theme location. This is a template tag issue but relates to how menus are managed in the admin & database.
I agree with every point here. Two more thoughts, based more in the plugin/api area:
The steps required to implement a “custom menu widget” are not obvious. At first glance at the code, it seems to rely on a complex interaction of both PHP and Javascript. The solution might be in documentation rather than changes to the code, but it’s still an area I would like to see improved.
I would really like to see some additional filters to enable better caching alternatives. Even with an object cache, constructing a large menu results in a high number of cache hits. I have seen some opportunities to cache the menu item objects or even static HTML and greatly improve that part of the page output.
If these requests aren’t out of scope, I can assist/suggest specific changes to code.
+1 on the unclear menu management API! I had almost forgotten how I had to reverse engineer the custom menu widget to create a plugin menu item interface. Not clear at all.
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.
If my quick-and-dirty digging is correct, then only a very tiny handful of themes on WordPress.com use more than one menu in any significant manner, which means that the number of users who use more than one menu should be even smaller.
I’d highly recommend approaching this problem with the direction that users will primarily need one custom menu for their blog, with the caveat that I’m sure the case could be made for more if a theme is more CMS-centric.
Thanks for pulling this together Philip!
If my quick-and-dirty digging is correct, then only a very tiny handful of themes on WordPress.com use more than one menu in any significant manner
A couple thoughts:
I’d highly recommend approaching this problem with the direction that users will primarily need one custom menu for their blog
My gut agrees with you 100%. But it never hurts to at least attempt to back assumptions up with some data
My experience with theme / custom WordPress development has shown that 98% of my client sites (wp.org) use just 1 menu location / no menu widgets.
Having built close to 100 themes since release of Menus, I can say 1 primary and 30% of time using depth=1 for footer menu is correct. Just started using Theme Location attribute since switching to _s as our base theme before we gave clients Editor level permissions and named menu “Main”.
Great to see this list of pain ponts in priority. The more I think about it, the more I am liking the concept of a “base menu”.
I just have a few more to add, which could perhaps fall under something already mentioned above, but I wanted to mention them anyway.
1. Some users are finding it difficult to figure out how to nest menu items and create levels. There is no visual representation on the Menus screen that would suggest items can be clicked and dragged to the right to perform nesting.
2. When adding a new item to a menu it is automatically appended to the end. This can create headaches for menus that are very long. It would be great to see the UI supporting drag and drop of the items directly into the menu list, similar to how widgets are placed in a sidebar area.
3. Requiring that users go to Screen Options in order to select additional item fields (class, description, etc.) seems counterintuitive. It would seem that a simple “view more/view less” accordion could reveal the additional fields on a per-item basis.
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.
I went ahead and got this data for you. I selected 4 random sets of 1000 WordPress.com blogs that have had wp-admin activity in the month of January 2013. I then calculated for each blog how many menus they have (total, so regardless of how that menu is being used) and collated the results. 75.78% of blogs have no menus; 18.23% have 1 menu; 5.925% have more than 1 menu.
I put together the full breakdown of my calculations here: https://docs.google.com/spreadsheet/ccc?key=0AszYZoR3BU_jdHJmZHRTQ19PcGdHSWhhempWRzBDeHc#gid=0.
Let’s keep in mind that this is WordPress.com users and not self-hosted users, and I suspect there is a significant higher amount of “power users” on the .org side, who use menus differently, via widgets (which is possible on WP.com), and by calling directly wp_nav_menu in their custom themes/plugins (which is not possible on WP.com).
Hope this helps with deciding how to proceed.
Very cool. Thanks so much for tackling this @jkudish! Even with your disclaimers in mind, I find this data insightful.
Here’s a pie chart of the breakdown:
Maybe a crazy idea and maybe overly influenced by my personal preference for building on Genesis… But what about getting rid of theme locations all together in favor of a single primary menu location that automatic tied to the primary menu and making the rest widget areas? (note I think the widget UI is in far greater need of a make over than the menus, but that’s definitely OT here). My initial thought is additional menu areas would show up on the widget page and custom menu widget widgets could be dragged in?
I’d thought a while back that menus should be more like links were. An interface to build the link list/menu, but not the interface that actually places menus/links on the page/theme.
Note, don’t know that I love the idea, I typically build custom themes with 3 menu areas (above header, below header, footer), but separating placement of menus and construction of menus sounds like a great idea.
So, what if we used the number of menus a user has to determine what they should see. Here are my latest thoughts:
About 76% of users would see this (based on WordPress.com’s stats).
They’d see:
So, if a user (with zero menus) came to the screen above, and immediately clicked “Save Menu”, they’d see:
About 18% of users (based on WordPress.com’s stats).
They’d see
So, based on the above approach (and the stats from WordPress.com), 94% of users would never see the management screen.
After landing on menus, they’d see something like this:
Clicking on a menu would take them to something like:
Clicking the blue “Menus” header link (vs. showing tabs here), or the “menus” link under “Appearance” in the left nav would take them back to the manage menus view.
Users would see:
and then after creating their menu, if they had a single menu:
If they had multiple menus, we’d link up “Menus” in the header.
Switching themes
If a user has one menu, and the new theme has one theme location, and the user has no custom menu widgets, can we just auto-assign the existing menu to the theme location upon switching?
Long menus (with lot’s of items)
This makes menus hard to manage because you have to scroll to see all of your menu items, and when you add new menu items, they are added to the bottom by default.
My preference (again based on usage stats) would be to keep this in plugin territory. This seems like it would make a great little plugin that could:
1) Add collapsable tree functionality for menu items
2) modify the “Add to Menu” button under each menu option to be a split button “Add to top”/”Add to Bottom”, and
3) include drag and drop of menu items from the left.
I don’t feel like this functionality should be exposed to the majority of users.
Thoughts?
This seems like the logical way to proceed based on everything that we’ve talked about and worked on thus far. I’ll try to gather more usage stats about how users use menus from WordPress.com before our next office hours on Thursday.
Thanks for those stats! Any chance you can find some stats on # of menu items?
I think that will be very indicative of how we proceed with the UI.
heres another view of the data you shared: http://cl.ly/image/143B0G3x2y3A definitely looks like a normal distribution.
Yes, I’ll gather more stats by Thursday afternoon and will include # of menu items per menu in that stat as well. Stay tuned.
Here’s an alternate flow that we may consider for when users have more than one menu. It ditches the management screen altogether in favor of a drop down.
We tested using a drop down before (and it tested poorly), but I don’t think we put enough emphasis on it. It’s worth testing again, as long as it doesn’t overwhelm users (having so much on the same page).
I also played around with adding check boxes under “use in”, as technically a user could use a single menu in multiple theme locations. I wonder if we could allow the user to select a widget placement from this screen as well via a check box. If they checked “Main Sidebar”, we’d auto-add a custom menu widget to the botom of the main sidebar widget area, and set the title of the custom menu widget as the name of the menu.
I like the dropdown at the top when there’s > 1 menus
Do we even need the Optional Settings part in the 0 menus layout, as that’s default behaviour anyways?
Also, +1 for your handling of long menus in plugin territory.
+1 for the Dropdown. I expect it would test better in this format, as it’s distinguishable from the other side metaboxes (by, um, not being on the side), unlike the current layout.
part of the problem with the discussion is that there is a large variety of use cases. Here is a visual: http://cl.ly/image/3t0i3g2Y1G0y
The # of menus data shows the right column to be the typical use case. # of items data is TBD
As much of a problem as theme locations are, I don’t think moving the assignment into the editing of a given menu is the solution. We are then adding a problem of what happens if multiple menus are assigned to the same location, because it then becomes possible to do so.
Have some other thoughts I need to chew on. Will comment again when I have sentences
I had two thoughts here. If a theme location currently has a menu assigned to it, we could :
1) append the name of that menu (perhaps at #999), something like:
and/or…
2) onclick trigger a JS confirmation modal that says something to the effect of, “Are you sure you want to change your primary theme location from “Primary Menu” to “Main Navigation”?”.
There was plenty of discussion at the beginning of dev chat: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-30&sort=asc#m543523
It seems like http://f.cl.ly/items/3y2I0T1q2u3d3G3O0X1h/menus-multiple-select.png is pretty close and worth testing, with the one concern being the settings where a menu is assigned to a location.
It’s still difficult to add tags to a menu. I tend to fall back on making a list of custom URLs when I can’t find things. It’s usually easier and faster too.
Assigning menus is definitely broken. Every time I activate a theme on a new site it looks messed up. There should be menus assigned by default when assignments are missing.
Go to Screen Options, check the “tags” box, and then add them like you add anything else (check boxes on left and use “Add to Menu” button).
For tomorrows “Menu” office hours I only have one agenda item: To figure out where we’re headed with menus in 3.6.
I like your concept.
While it does require more screens to manage a menu (find the menu from the list, then click to edit it), I think simplifying and making the views granular is ideal:
1. See all menus (then go edit them)
2. Edit a menu’s contents
3. Assign a menu to a theme location
Some bloggers may only have one menu and this is overkill (just like those with one sidebar) but, many more complex sites may have dozens or a hundred menus, theme locations, etc. A question: what is harder and less flexible to satisfy all these possible use-cases?
I also think a simpler, granular interface for each action may allow for better long-term goals: new enhancements, making it mobile/responsive friendly, etc.
I just love the 2nd approach. Especially liking the theme customizer integration. Though, I have never seen an internal use of breadcrumbs within the dashboard. It just seems out of place.
I like the first time menu screen. I am not a huge fan of more windows to open to get to what I want. Seems this whole project started from the thought that current menu screen is too difficult and even adding a home link is a challenge. I agree with Devin that the average user would probably have only one menu, as this might be overkill. Simple to me is simple interface that is intuitive that doesn’t take multiple clicks to get to.
I think the flow of #2 would be most scalable and easiest for first-time menu creators to do what they want—but, can we incorporate the accordion-looking ‘Add Items…’ menu from the Nacin concept? I think all the individual CPT boxes, expanded automatically, become hard to locate at a glance.
I think that all three designs fail to address a core issue in the menu-editing screen. The left side that contains all the visual containers with sources of items to populate the menus is unpleasant to use when there is lots to choose from (many pages, posts, categories … not to mention websites with custom post-types … which create even more boxes).
I’ve tried in the past to describe the problem in more detail here: http://www.odharma.com/2010/07/review-of-wordpress-menus-user-interface/
The problem is (in my opinion) so severe that you would be hard-pressed to even draw a mockup that properly reflects the problem.
This discussion started in a TRAC ticket where I mentioned a few more benefits from a modified design:
1. 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”.
2. 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.
3. Within the tabbed area there is then plenty of space that can be used for better search and filtering.
4. 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 …
5. AND you can use that improved performance to do a smarter load … like indicating somehow which items have already been added to the menu.
6. 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).
I think that all three designs fail to address a core issue in the menu-editing screen. The left side that contains all the visual containers with sources of items to populate the menus is unpleasant to use when there is lots to choose from (many pages, posts, categories … not to mention websites with custom post-types … which create even more boxes).
I agree, in that it does suck to have to scroll down to get to additional menu item options. Let’s see if we can figure out a way to improve this.
The problem is (in my opinion) so severe that you would be hard-pressed to even draw a mockup that properly reflects the problem.
That indeed sounds like a severe problem.
So far none of these address the issue of adding Tags and Posts to menus.
As for the screen layouts, I think two are appropriate considering there isn’t easy tabbing between menus.
Look in screen options.
Office Hours Notes
Next Steps
Ideas, mock ups, concerns, comments, criticisms are all welcome.
Here are some updated mockups based on our discussion Thursday.
One Menu
This is all the vast majority of users would see:
Multiple Menus
Custom Menu Widget
Switching Themes
Adding A New Menu
Let me know what you think. I tried to cover all of the concerns mentioned in the meeting on Thursday.
These are great! Looking through these, I have a couple of concerns:
well done.
I would consider better balance between the two halves of the screen. There seems to be a lot of potential dead space on the right (menu side) and a lot of crunched up stuff on the left (things to put in menu). I would try either 50-50 or even 60-40.
Nice work. I really like the updated direction! A few comments:
So, my worry after working through all of these mockups is that by trying to be overly simplistic, we’re actually increasing complexity. 
Have a peek through each of the mockups above, and I think you’ll see the same thing.
Things I like
My concerns
In contrast
Out of the last 3 users we tested on option 2 (see results here and here), one of them completed all of the tasks flawlessly, and the other two only stumbled on a single step (selecting a primary menu).
After the meeting on Thursday, I was fairly confident that we could make option 1 work. After working though all of the edge cases, I’m now much less confident.
My proposal
What if instead of diving head first into option 1, we instead chose to keep iterating on option 2:
That’s my proposal, what do you think?
I think that a lot of the complexity you mentioned is rooted in what may be a false notion that menus are a part of the site “appearance” – that they belong to a theme.
A different view would be that menus are another means of organizing “things” in my website (kind of like categories are used to organize posts).
Though the primary purpose of menus is for navigating in the site (indeed a thing of appearance) that is not what governs their content.
My intuition (I have no data to back this up) tells me that most people (who have one menu) when they change themes, do not change menus. I can definitely say that in almost all of the websites that I’ve created that have had many menus – that the menus should have stayed when themes switched (the fact that they don’t has forced me to do twisted things in my theme management practices).
I believe that the fact that menus are a part of themes is a behavior that has evolved from their technical development, not from what they are and do. Their underlying story is just now surfacing.
If you free menus to be another organizational entity regardless of appearance (though I realize this may be way beyond the scope of 3.6) then they most absolutely should be split into the common WordPress paradigm of managed list and single-item edit.
I also believe that presented in this way, people will more quickly understand that they can create more menus (since they know this visual paradigm intimately from working with posts and pages).
This way:
The only apsect of menus that I can think of that should remain as part of the appearance/theme configuration would be theme locations.
I realize this may sound radical … but I believe that the complexities you listed are telling us that the underlying story of menus has not been properly addressed and it needs to be re-examined if a good solution is to be found.
I guess I’m unclear, where exactly are you proposing that menus should go?
I can’t think of a good answer for that (though I may have inklings of a better question).
The two options I currently see are (1) inside the “appearace” menu or (2) a separate admin-section. For now, I am indifferent to them.
In either case, I think it would be better to have them conform to the dominant UI pattern that includes a list of Menus (where the description can be a textual preview of the menu contents) from which you can choose to edit a menu.
I looked at the above wireframes and created some of my own to give inspiration to others. Psd and jpg files are included in this link for anyone to continue testing out things.
https://www.dropbox.com/sh/4vpue85dkzsrk0q/6FtXDun3QD
Have a great day!
One thought regarding copying menu items – that should be a dragabble / droppable interface. Much lessbloat (pun intended) perhaps drag / drop w/ a featured pointer?
I like the two tab iteration better – one tab for doing the majority of the work – editing and building menus, and another tab for changing assigning / them. The non-metabox menu builder is a huge improvement, but I don’t like seeing the unrelated options of select a menu and copy menu items. Those feel out of place.
In any case – I definitely agree we need to keep iterating. Great work lessbloat! The mockups are looking great!
I’d like to hold our first menus IRC discussion today at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev.
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!
I will be on a plane and unable to attend the IRC meeting, but wanted to throw in my request for being able to filter in new “types” of menu items and fully override the output of any particular menu item. Super-useful for mega-menus, etc.
The change to 2 screens sounds like it will address to “too many menus for the UX design” – awesome!
@Alex can you expand on how that filter might be used? Can’t conceptualize it for some reason.
Thanks Alex,
wanted to throw in my request for being able to filter in new “types” of menu items
Mind explaining that one a bit more, and I’ll bring that up in the meeting.
wanted to throw in my request for being able to…fully override the output of any particular menu item
I was thinking about this over the weekend, and I agree. I think this will go a long way towards making edge cases (collapsable trees, bulk menu item actions, etc…) easily extensible via plugins. My goal is to keep this clean, lean, and mean for the majority of users, but to also make menus easy to extend.
Here’s the rough agenda I’d like to follow today if possible:
Here’s a recap of what we covered:
Office hours for menus in 3.6
We’ll plan on having office hours Mon & Thu at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev
If there’s an agenda (there likely will be for the next couple), I’ll post it here on the make/core P2. Otherwise feel free to come with questions/thoughts.
Nacins menu workflow concept
Nacin shared the following observations:
And proposed a rough concept along the lines of:
Edge cases brought up (which we’d have to consider to make this work):
“Common links” meta box
We proposed “Common Links” meta box in 23119.14.diff. Currently it defaults to showing a “home” link, and a “log in” link. Both of which are relatively hard to add to a menu.
The idea is to:
I had hoped to settle on whether we should keep this new meta box, and if so, what we should call it. Both are still up in the air.
Things to think about before our next office hours
1) How can we make Nacins concept work?
2) Should we keep the new custom links meta box? If so, what should we call it?
I mocked up my interpretation of Nacins concept:
A couple notes:
Or something similar, which would take you back to nav-menus.php.
What do you think? Could this approach work? If not, why?
p.s. Please don’t focus on the aesthetic of the design at this point. This is just a rough mockup. If the concept works, we can focus on improving the way it looks next.
My first thoughts:
The things I like:
The questions/concerns:
A common problem with this mockup and the 3.5 system is that there is no visual indication of where to find Tags, Posts, and other menu items that are missing by default.
Here’s a quick update on the 3.6 menu changes we’ve been making:
Last week we:
What’s left:
CODE
DOCS
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.
This is going really well. Kudos to @lessbloat and everyone else that helped!
Also, you can never have too many eyes on things like a “Code review on everything” and all the various documentation pieces. I’m sure @jkudish and @drewapicture would appreciate the help.
Agreed, any help is welcome
I’d also like to look at removing the Home link from the Pages metabox since we’ve moved it to the “Common” or “Userful” links metabox. #14325
Seems reasonable.
As a follow up to the dev chat, please add any thoughts/concerns you may have to the ticket #23119 so that we can continue to iterate & move forward with this. Thanks!
lessbloat, and 
Ricky Lee, 
Travis Northcutt 4:46 pm on February 27, 2013 Permalink | Log in to Reply
What’s the ticket?
lessbloat 5:01 pm on February 27, 2013 Permalink | Log in to Reply
Sorry. That would be helpful, hey?
Edited a link in there.
Cor van Noorloos 8:00 am on March 1, 2013 Permalink | Log in to Reply
Hi Dave, I hope it still would be OK to have a few suggestions/comments?
The
.nav-menus-php .delete-action a { color: #bc0b0b; }currently is in the wrong color (should be red) and it missing the1px 2pxpadding.Besides that I think the new menu contains a bit to much info (or perhaps displayed at the wrong place).
Instead of a complete walkthrough I’d prefer some strong statements like “No menu’s yet” as is done almost everywhere else.
Or if required a general
.descriptionclassed paragraph with some further explaination including some anekedote about Jazz.The
#nav-menu-headeralso looks a bit awkward. Especially its height. (it always has, even though it’s looking much better now. +1)Have you thought about moving
.button button-primaryabove and below the metabox?