Menus office hours recap (Jan 28)
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:
- One of the biggest disconnects I’ve seen is the concept of “theme locations”. Adding a menu, and then assigning it to a theme location seems broken.
- Trying to have menu management + editing + theme location assignment all on the same page is overwhelming.
- Tabs don’t work for users with lots of menus to manage, and they confuse some users (who think they represent menu items within a single menu). Side note: when we tested menu management via a drop down (instead of tabs), users didn’t notice the drop down, and wondered where the menus they had already created were. A “manage menus” tab appears to work for users, but it seems heavy for users with just a single menu.
- Switching themes poses a problem for menus in that there is no concept of a base menu. Every theme determines their own default menu, and even though two menus may have a single primary menu, you still have to re-assign your menu to that theme location whenever you switch a theme.
- Users have a hard time visualizing how the menu changes they are making actually impact their blog/site.
- Having to scroll to see all of the menu item meta boxes in the left column can be annoying, and it can make discoverability for items below the fold harder.
- If you have a long menu (with lot’s of menu items), you may be scrolling unreasonably down from the left to the right column.
- The fact that you can add menus to a custom menu widget is not exposed anywhere.
Did I miss anything?
lessbloat, 
Ricky Lee, 
cvernon 3:26 pm on January 29, 2013 Permalink
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.
deltafactory 3:41 pm on January 29, 2013 Permalink
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.
Bob Gregor 10:00 pm on January 29, 2013 Permalink
+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.
Philip Arthur Moore 3:43 pm on January 29, 2013 Permalink
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.
lessbloat 4:14 pm on January 29, 2013 Permalink
Thanks for pulling this together Philip!
A couple thoughts:
My gut agrees with you 100%. But it never hurts to at least attempt to back assumptions up with some data
Bob Gregor 10:02 pm on January 29, 2013 Permalink
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.
Ricky Lee 12:23 am on January 31, 2013 Permalink
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”.
Frankie Jarrett 4:01 pm on January 29, 2013 Permalink
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.
Joey Kudish 4:58 pm on January 29, 2013 Permalink
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_menuin their custom themes/plugins (which is not possible on WP.com).Hope this helps with deciding how to proceed.
lessbloat 5:48 pm on January 29, 2013 Permalink
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:
Jon Brown 5:50 pm on January 29, 2013 Permalink
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.
lessbloat 8:32 pm on January 29, 2013 Permalink
So, what if we used the number of menus a user has to determine what they should see. Here are my latest thoughts:
If they have 0 menus
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:
If they have 1 menu
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.
If they have more than 1 menu
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.
When adding a menu
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.
Other considerations
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?
Joey Kudish 8:57 pm on January 29, 2013 Permalink
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.
Bob Gregor 10:17 pm on January 29, 2013 Permalink
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.
Joey Kudish 2:47 pm on January 30, 2013 Permalink
Yes, I’ll gather more stats by Thursday afternoon and will include # of menu items per menu in that stat as well. Stay tuned.
lessbloat 2:12 pm on January 30, 2013 Permalink
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.
Scott Taylor 6:18 pm on January 30, 2013 Permalink
I like the dropdown at the top when there’s > 1 menus
kwight 8:14 pm on January 30, 2013 Permalink
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.
kwight 8:11 pm on January 30, 2013 Permalink
+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.
Bob Gregor 9:17 pm on January 30, 2013 Permalink
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
Helen Hou-Sandi 9:25 pm on January 30, 2013 Permalink
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
lessbloat 3:37 am on January 31, 2013 Permalink
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”?”.
Aaron D. Campbell 10:41 pm on January 30, 2013 Permalink
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.
Robert Chapin (miqrogroove) 10:59 pm on January 30, 2013 Permalink
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.
Aaron D. Campbell 11:13 pm on January 30, 2013 Permalink
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).