Make WordPress Core

Tagged: menus Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 7:07 pm on December 19, 2014 Permalink
    Tags: , menus   

    Menu Customizer: Call for Contributors 

    After a few months off from working on the Menu Customizer to focus on improving the Customizer API in core, I’m starting to pick up development on the feature-plugin. Now that it’s approaching a reasonably usable state, and is compatible with the latest major release of WordPress (4.1), I’d like to begin efforts to see if we can propose merging it into core for WordPress 4.2.

    But there is a lot of work to be done. When Menu Customizer was my GSoC project, it was closed to contributors per GSoC rules. But development is now open to everyone, and I could use a lot of help with both development and non-development tasks. Here’s a list of items that need work:

    •  Development
      • Build-out the core API for adding Customizer sections and controls entirely with JavaScript, #30741 and its related tickets (PHP, JS)
      • Drag & Drop menu item reordering needs to do sub-menus (code imported from nav-menus.php is commented out in menu-customizer.js currently) (JS)
      • Fix problems with previewing updates to menu items, and with previewing newly-added menus once items are added (JS)
      • Eliminate the PHP closure that currently facilitates menu previewing, for PHP 5.2 compatibility (PHP)
      • Redo the add-menu-items “panel” to lazy-load its contents & utilize Backbone sub-views (PHP, JS)
      • Improve the core Customizer on mobile, then make Menu Customizer work on mobile (CSS)
      • Think about an API or otherwise action hooks to allow plugins to add menu item fields, #27066, #21898, #18584, etc. (PHP)
      • Inline docs audit, once we’re mostly done (PHP, JS)
      • Comprehensive code review by people like @westonruter, @ocean90, or @nacin, once we’re mostly “done”, preferably before a core merge proposal. Initial code review/cleanup from anyone can start now
    • Design
      • Overall UI audit/review, propose changes
      • Consider things like #29158 in relation to how the menus UI looks
      • Discuss approach to screen options (currently an icon in the Menus panel header)
      • UX audit, propose changes
      • Evaluate user flows & menus use-cases
      • Conduct user tests
    • Other
      • General user feedback – getting the word out about the plugin and collecting feedback (reviews & support forms on the .org repo would be a good place for feedback). Anyone reading this can try the plugin and provide feedback too :)
      • Accessibility audit
      • Backwards-compatibility audit; in particular, assessing whether Menu Customizer could replace the Menus admin screen, and what further features or use-cases would need to be addressed to do so
      • Research the history of the Menus UI in core and document how Menu Customizer addresses ongoing concerns; also consider open tickets in the Menus component (for merge proposal)

    Development is happening on the WordPress.org plugins repo the a GitHub repo. Some helpful links: create a ticket, Menu Customizer tickets, development log. It’ll probably also be possible to contribute via Github if that’s your preference – talk to @westonruter about how he does it.

    This project will primarily take place over the next month, when core development is largely on hold for the holidays and between releases, and when I’m in between semesters at school. The goal is to be merge-ready before the 4.2 feature-plugin merge consideration happens in January. If you’re interested in helping out, please comment on this post or ping me in WordPress Slack in #core (@celloexpressions).

    Due to the timing of this project around the holidays, we’ll probably do mostly asynchronous communication, but I would like to try a kick-off meeting in #core Slack on Monday, December 22, 2014 18:00 UTC; please come by if you’re interested!

    • diddledan 9:11 pm on December 19, 2014 Permalink | Log in to Reply

      Hi Nick,

      you may find my plugin https://wordpress.org/plugins/custom-menu-fields/ useful as it provides an api for menu fields to be added by plugins. I’ve not updated it in a while, but you’re welcome to have a look and reuse anything you like the look of (we are all GPL afterall :-p) – I might be able to have a look at your code over the weekend or holiday period and see if I can develop and send you any patches I think you might find useful.

    • Nick Halsey 7:51 pm on December 22, 2014 Permalink | Log in to Reply

      Had our first meeting today. Ongoing discussion will happen in the new #core-customize channel on Slack, so stop by if you have any feedback or want to help out!

  • Nick Halsey 12:20 am on August 8, 2014 Permalink
    Tags: , , menus   

    GSoC Menu Customizer Update: Live-previewing Menus 

    I’ve finished implementing menu-previewing in the Menu Customizer plugin, building on the scalable approach to saving menus that I discussed in my last update. The entire Menus experience is now consolidated into a Menus panel in the Customizer, where you can preview your menus as you make changes. It’s really nice to have Menus easily accessible alongside the rest of the site-appearance-management tools in the Customizer.

    I only have about a week and a half left in my GSoC project, and I’m hoping to focus on improving the add-new-menu-item panel in my remaining time, making it scale and implementing the search functionality. I’m also planning on cleaning up the codebase and implementing the ability to manage menu hierarchy (submenus).

    If you’re interested in testing the Menu Customizer, and live-previewing changes to your menus, you can get the plugin here. Please note that it currently requires PHP 5.3+, but it’s getting less and less alpha by the day.

    Post-GSoC Plans

    After the GSoC coding period is over, I’m planning on transitioning Menu Customizer development to the feature-plugin format, gathering a group of interested contributors and holding weekly meetings to coordinate our efforts. While it won’t be ready for core consideration by 4.1, and requires some more core Customizer infrastructure to really work well, we’ll continue working on the plugin until menus in the Customizer really shine, and are ready for core.

  • Nick Halsey 3:15 pm on July 15, 2014 Permalink
    Tags: , , menus   

    GSoC Menu Customizer Update: Scalable Menus 

    Since my last GSoC update, I’ve spent a fair amount of time helping prepare the Customizer for 4.0 beta 1. But I’ve also continued working on the Menu Customizer and have a lot of progress to report.

    Add & Delete Menus

    You can now add new menus, via the “+ New Menu” section. Added menus currently have some issues, though; you’ll probably need to reload the page before adding items works. The problems stem from the lack of a proper JS API for adding, deleting, and managing Sections and Settings (and Panels), and the incompleteness of the existing Control JS API. This will probably need to be resolved in core before the Menu Customizer can be considered for core integration, see #28709.

    I’ve also implemented a menu-deletion mode, which can be toggled from the add-menu section. It’s too easy to delete menus otherwise, even with an AYS confirming the delete, because deleted menus cannot be restored, and are not “previewed” before being published to the db (added menus aren’t either). It’s probably worth augmenting the AYS to state the menu name being deleted, and to add an extra warning if it’s active in a theme location or a widget.

    Saving Menus and Menu Item Data in a Scalable Way

    In core, menus do not scale well at all. You don’t have to look very deep into the code to see why – massive amounts of data for each item are hidden on the admin screens (much of which never changes) and then must be updated every time a change is made.

    Since one of the goals of this project is to experiment with new approaches, I’ve begun implementing a new approach for saving menu data, which is currently in use in the plugin. Thanks to my mentors @ethitter and @obenland for guiding me on the best approach to take here, and @westonruter for the way he implemented the Widget Customizer UI, which inspired this exact approach. Here’s how it works:

    • Each menu has a nav_menu Customizer control that contains an ordered array of numerical menu item ids (known throughout the core menus codebase as their db ids).
    • When an item is added, it is created as an orphaned draft via ajax, and its id is added to the nav_menu setting’s array.
    • When an item is deleted, its id is removed from the nav_menu setting’s array.
    • When menu items are reordered, the order of ids in the nav_menu id is updated to match.
    • When menu items are moved into and out of sub-menus, the parent menu item id is updated in the individual item’s data (not yet implemented).
    • When a menu item field is changed (by default, this would mean changing the label or, for custom items, url fileds; there are screen options for several others), the original item is cloned and the copy is updated with the new data, using a wrapper for wp_update_nav_menu_item() that doesn’t require passing all existing (unchanged) menu item data. The cloned item’s id is returned and replaces the original id in the nav_menu setting (thereby marking the original item for deletion). Additional changes are saved to the cloned item until the settings are saved, at which point all items are marked for a new clone to be created if changes are made (not yet implemented).
    • When the user saves their changes from the Customizer (via the customize_update_nav_menu action), the array of ids is compared to the currently-published menu’s items. If there are items that are no longer present, those are marked for deletion. For each of the new ids, the corresponding menu item (which already exists) is updated to be published, assigned to the corresponding menu (for the new items created as orphaned drafts), and the item’s menu_order is set to the id’s position in the nav_menus setting array. Finally, all of the removed items are deleted.

    While menu previewing in the customizer is not yet implemented, it will also be able to use the nav_menu setting’s array of ids to display an augmented set of menu items. I’m also still working on ensuring that menu item data is not posted during the customize-save ajax, but the data isn’t needed so we’re most of the way there already.

    UI Aside


    Quick aside: @DrewAPicture pointed out in IRC that the new Customizer close and panel-back icons don’t really match the save button. I’ve done some rough explorations of potential alternatives; if anyone’s interested in discussing them and possibly implementing a change here, feel free to ping me in IRC (@celloexpressions) and/or create a ticket and/or comment here.

    Finally, I’m hoping to finish implementing menu previewing by the end of this week, fully utilizing the Customizer. Once this is done, I’ll essentially be at feature-complete stage (other than some little details and several known bugs) and ready to iterate (I’m already planning on working on the add-menu-items backend, as it currently doesn’t scale).

    • michalzuber 5:30 pm on July 17, 2014 Permalink | Log in to Reply

      I’m figuring out why is `@todo: Remove choices` in the `wp-includes/class-wp-customize-control.php` ? Couldn’t get it.

      • Nick Halsey 5:43 pm on July 17, 2014 Permalink | Log in to Reply

        That’s more related to the Customizer post, but I think that’s leftover from the initial customizer development in 3.4. We can remove the todo, since removing $choices is no longer an option due to back-compat.

    • Weston Ruter 8:26 pm on July 22, 2014 Permalink | Log in to Reply

      When an item is added, it is created as an orphaned draft via ajax, and its id is added to the nav_menu setting’s array.

      Something that I’ve been exploring with Customize Posts is the addition and deletion of postmeta. Instead of actually mutating the database, when creating new meta I’m creating faux post meta IDs and then referring to them in the preview filter. When saving the Customizer settings, these posts meta are then inserted at that time. It’s not quite done yet, as I need to now gather the post meta IDs that were inserted at the time of saving, and update the setting to refer to them.

      Generating a virtual post meta ID: https://github.com/x-team/wp-customize-posts/blob/85dc4e562ea806c17480899f5d94f93d42297de1/js/customize-posts.js#L611-L618

      Sanitizing a setting that includes virtual post meta ID: https://github.com/x-team/wp-customize-posts/blob/develop/php/class-wp-customize-posts.php#L303-L310

      It would be ideal if Menu Customizer could add new menu items virtually without touching the DB.

      • Nick Halsey 10:12 pm on July 22, 2014 Permalink | Log in to Reply

        I’m not sure if it would be possible to add items without touching the DB in a scalable way. The primary reason for doing that is so that menu item data doesn’t need to be sent to the server all at once when saving, which causes scaling problems currently (for example, imagine if 100+ menu items were added to several different menus upon initial setup of a site – that data would all go up together).

        In the existing menus system, items are similarly added to the db via ajax before being made available for manipulation in the UI. So, the concept of orphaned draft menu item posts is existing and currently being leveraged here.

  • lessbloat 5:26 pm on February 8, 2013 Permalink
    Tags: , menus   

    Menus Office Hours (Feb 7) 

    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

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

    After that

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

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

    • Drew Jaynes (DrewAPicture) 5:57 pm on February 8, 2013 Permalink | Log in to Reply

      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.

    • sireneweb 4:50 pm on February 11, 2013 Permalink | Log in to Reply

      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

      • lessbloat 6:14 pm on February 11, 2013 Permalink | Log in to Reply

        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.

  • lessbloat 4:41 pm on February 1, 2013 Permalink
    Tags: , menus   

    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)

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

    Remaining Tasks (still needing a volunteer)

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

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

    • Joey Kudish 4:46 pm on February 1, 2013 Permalink | Log in to Reply

      In addition to the checkboxes, I’ll help out with code reviewing and all the testing :)

    • Jon Brown 5:53 pm on February 1, 2013 Permalink | Log in to Reply

      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”.

    • Travis Northcutt 12:18 am on February 2, 2013 Permalink | Log in to Reply

      @lessbloat, what is the “deadline” for getting the accordion done for testing?

      • lessbloat 1:14 pm on February 4, 2013 Permalink | Log in to Reply

        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.

  • lessbloat 2:53 pm on January 29, 2013 Permalink
    Tags: , menus   

    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?

    • cvernon 3:26 pm on January 29, 2013 Permalink | Log in to Reply

      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.

      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 | Log in to Reply

      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 | Log in to Reply

        +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 | Log in to Reply

      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.

      • lessbloat 4:14 pm on January 29, 2013 Permalink | Log in to Reply

        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:

        • My guess is that this is true for themes in general. So, I’m not sure how far off it is compared to wp.org usage.
        • Menus can also be added within widgets. My guess is that out of users who have multiple menus, chances are the majority of them only have one theme location menu, in addition to one or more custom menu widgets (again, just a hunch).
        • Even if all we get out of this is a better picture of how many users have no menus vs. one menu, I’d still find that hugely insightful.

        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 😉

        • Bob Gregor 10:02 pm on January 29, 2013 Permalink | Log in to Reply

          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 | Log in to Reply

          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 | Log in to Reply

      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 | Log in to Reply

      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.

      • lessbloat 5:48 pm on January 29, 2013 Permalink | Log in to Reply

        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 | Log in to Reply

      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 | Log in to Reply

      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:

      • We’d auto populate the “blank slate” view with all of their existing pages. However, this menu is not actually created until they click “Save Menu”. If they navigate away from this page without clicking “Save Menu”, they will still technically have zero menus.
      • If they have only one theme location, we’d just use the theme location name (i.e. primary) as the menu name, and we’d auto assign this menu to their theme location upon saving.
      • We’d hide all “manage menus” functionality
      • And test using an accordion for the menu item options on the left (vs. meta boxes).

      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

      • We’d take them directly to the edit screen for that menu.
      • We’d hide all “manage menus” functionality

      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.


      • Joey Kudish 8:57 pm on January 29, 2013 Permalink | Log in to Reply

        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 | Log in to Reply

          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 | Log in to Reply

            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 | Log in to Reply

        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.

      • kwight 8:14 pm on January 30, 2013 Permalink | Log in to Reply

        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 | Log in to Reply

      +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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

        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:


        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 | Log in to Reply

      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 | Log in to Reply

      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 | Log in to Reply

        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).

  • lessbloat 7:12 pm on January 23, 2013 Permalink
    Tags: , menus   

    For tomorrows “Menu” office hours I only have one agenda item: To figure out where we’re headed with menus in 3.6.

    (More …)

    • Devin Reams 7:37 pm on January 23, 2013 Permalink | Log in to Reply

      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.

    • Maor Chasen 8:58 pm on January 23, 2013 Permalink | Log in to Reply

      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.

    • mssbee 2:19 am on January 24, 2013 Permalink | Log in to Reply

      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.

    • Cliff Seal 2:35 pm on January 24, 2013 Permalink | Log in to Reply

      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.

    • iamronen 3:29 pm on January 24, 2013 Permalink | Log in to Reply

      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).

      • lessbloat 2:22 pm on January 25, 2013 Permalink | Log in to Reply

        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. 😉

    • Robert Chapin (miqrogroove) 4:53 pm on January 24, 2013 Permalink | Log in to Reply

      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.

    • lessbloat 2:14 pm on January 25, 2013 Permalink | Log in to Reply

      Office Hours Notes

      • See logs for full transcript.
      • We talked through likes & concerns for both options 1 & 2 above.
      • In the end we agreed to push forward with option 1.

      Next Steps

      • I plan to spend today working through all of the option 1 concerns (that we covered in office hours), and I’ll come up with another proposal for a mockup to move forward with (which I’ll post to this thread for review).
      • After that we’ll get a prototype hacked together, we’ll push a few cycles of user tests through it, and see how it performs.

      Ideas, mock ups, concerns, comments, criticisms are all welcome. :-)

    • lessbloat 2:03 am on January 26, 2013 Permalink | Log in to Reply

      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.

      • Drew Jaynes (DrewAPicture) 2:33 am on January 26, 2013 Permalink | Log in to Reply

        These are great! Looking through these, I have a couple of concerns:

        • “Copy items from existing menu” is interesting, but will we be able to maintain the hierarchy when the items are copied over?
        • With “Switching Themes”, it isn’t immediately clear what the process is to “reassign” a menu to a theme location (the current workflow). After a moment, I realized you would “Copy items from existing menu” via “Other menus” but we should provide some kind of contextual help for that. Maybe in the empty menu space?
        • We’ll need to be careful of not assuming too much about users, especially in terms of this “editing one menu at a time” mentality with the surrounding controls.
        • Would “unattached” menus live under “Other Menus”, or is that strictly for theme switching?
      • iamronen 6:28 am on January 26, 2013 Permalink | Log in to Reply

        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.

      • Joey Kudish 8:01 am on January 26, 2013 Permalink | Log in to Reply

        Nice work. I really like the updated direction! A few comments:

        • I agree with Drew regarding switching themes, what happens then?
        • What happens if your theme supports several menu locations, it’s not quite clear to me from the mockups how it is that you assign menus to theme locations anymore.
        • Considering how little real estate the “add menu” button takes up and how valuable it might be to some users (especially those are now used to the current workflow) I am not convinced that hiding it by default is a great way to go about it. Could this be tested with existing users?
      • lessbloat 2:26 pm on January 26, 2013 Permalink | Log in to Reply

        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

        • I really like the use of vertical tabs instead of meta boxes.
        • I like that for the majority of users they can jump right into building their menu, and that it is already assigned to a theme location.

        My concerns

        • The “Select a Menu” portion on the left hand side seems out of place to me. It doesn’t fit with the other two accordion options (add items, copy items). If a user is required to select from multiple menus, I still feel fairly strongly that we need to separate the “manage” functionality from “add/edit” functionality, otherwise there is just too much to take in on that single screen.
        • The concept of copying menu items from one menu to another works from a technical standpoint, but it seems overly complex.
        • To think that someone who just switched their theme will know to copy their menu items in order to bring their menu items over from their other theme is asking too much. Even if we could provide contextual help, it seems way more confusing than the way it is now (choose a menu for each theme location and click save).
        • I feel like this approach over complicates widget menu creation as well. The old way of adding a title, and selecting a menu seems like an easier flow to grok than forcing users to make a choice between creating a menu or selecting an existing one, and then switching contexts from widgets to menus and then back to widgets again in the same flow.
        • The concept of having “Menus in your theme”, and “other menus” under “Select a menu”, complicates things. It’s hard to tell the difference between the two. The user will wonder why they cannot delete the “menus in your theme” menus, but they can delete the “other menus”.
        • What happens if a user switches themes a dozen times (trying to find the right one). They’d come to menus and find at least a dozen menus from all the previous themes they tried (since the idea here is to pre-build all theme location menus for each theme). Not to mention, we’d have to write the code that pre-creates all theme location menus each time you switch a theme.
        • While, hiding the “add menu” button seemingly simplifies things for new users, I don’t think it will work. Existing users will wonder where it went. If we leave it there, new users will no doubt get lost trying to add a new menu (either following one of hundreds of existing menus tutorials on the web, or by following instructions in a book, or by just stumbling onto it), when in fact their theme locations menus are already created.
        • If we add icons for each menu item option (in the vertical tabs), what happens when you add a CPT? Would they have to add their own icon? That sounds too complex. I don’t think we can use icons here.

        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:

        • We could spend our energy iterating on the one piece that still seems broken (selecting a theme location), instead of trying to smooth out all of the complexities that come with option 1.
        • We could simplify things for users with just one menu. If they only have one menu, we could remove the tabs and the manage screen, and take them right to editing that one menu.
        • We could bring the new vertical tab menu items selection concept over (I much prefer that to meta boxes, and having to scroll if you have lots of them).

        That’s my proposal, what do you think?

        • iamronen 5:59 pm on January 26, 2013 Permalink | Log in to Reply

          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:

          • menus will be more straightforward and intuitive.
          • there won’t be a need for complex behaviors such as “copying menus” which will only create useless copies of the same thing.
          • there won’t be a need for a unique and complicated interaction and relationship between menus and widgets (the current widget is fine and will be better understood once menus become more clear)

          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.

          • lessbloat 3:22 pm on January 28, 2013 Permalink | Log in to Reply

            I guess I’m unclear, where exactly are you proposing that menus should go?

            • iamronen 4:08 am on January 29, 2013 Permalink

              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.

    • paaljoachim 12:48 pm on January 28, 2013 Permalink | Log in to Reply

      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.


      Have a great day!

    • Bob Gregor 9:56 pm on January 29, 2013 Permalink | Log in to Reply

      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!

  • lessbloat 1:13 pm on January 21, 2013 Permalink
    Tags: , menus   

    Menus discussion today 

    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: https://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!

    • Alex King 3:13 pm on January 21, 2013 Permalink | Log in to Reply

      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!

    • lessbloat 4:52 pm on January 21, 2013 Permalink | Log in to Reply

      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.

    • lessbloat 8:54 pm on January 21, 2013 Permalink | Log in to Reply

      Here’s the rough agenda I’d like to follow today if possible:

      • Welcome
      • Time for office hours
      • Here’s where we’re at: https://core.trac.wordpress.org/ticket/23119#comment:131
      • There was some concern in the last dev chat that the manage screen is too heavy?
      • 2 files or 1?
      • Common links name: “Handy links”, “Useful Links”, “Helpful Links”, “Quick Links”
      • Alex King’s first point: being able to fully override the output of any particular menu item
      • Theme locations
      • Linking to widgets
      • Alex King’s second point: being able to filter in new “types” of menu items (not 100% sure what he meant with this one)
      • Anything else?
    • lessbloat 4:45 pm on January 22, 2013 Permalink | Log in to Reply

      Here’s a recap of what we covered:

      • Office hours for menus in 3.6
      • Nacins menu workflow concept
      • “Common links” meta box

      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:

      • The current UI is too advanced, and any workflow improvements should make it more simple for users.
      • The most common use case is having one menu.
      • The vast majority of menus are used in theme locations and widgets. We should tailor around those two use cases.
      • The current workflow: A) create a menu from scratch, and then B) assign it to either a theme location, or a widget can lead to confusion, and is quite possibly overly complex.

      And proposed a rough concept along the lines of:

      • With the custom menu widget, you’d: 1) add a custom menu widget to the sidebar 2) click a “Edit this menu” link/button which takes you to a screen where you’d edit that menu. This would likely take you to nav-menus.php?menu=that-menu-id. If the custom menu widget is newly added, it would take you to the “add new menu” screen.
      • With theme locations, instead of selecting from a drop down of menus that you’ve created, each theme location would just have a link to edit that menu. You’d 1) Click the edit link under the theme location you’d like to edit, 2) Make changes to that pre-existing menu, 3) click save, and be done.
      • We’d no longer need to display a list of menus you have, we’d just display a list of theme locations. Widget menus are represented in the widgets section, so they don’t need to be listed anywhere.

      Edge cases brought up (which we’d have to consider to make this work):

      • While theme locations and widgets cover the vast majority of use cases for menus, you can use them elsewhere. wp_nav_menu() accepts ID, slug, or name of a menu. As such, we’d still need to be able to provide a way for users to add menus outside of theme locations and widgets. How would we display these additional menus?
      • What happens to my predefined theme location menus when I switch themes to a theme which has a completely different set of theme locations? How would that work in the UI?

      “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:

      • Move the ‘Home’ link out of the Pages
      • Make it easy to add a link to the login form (which many users have trouble with)
      • Make these links easily discoverable
      • Provide a filter for plugins to add/remove links to this “other” metabox

      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?

      • lessbloat 6:27 pm on January 23, 2013 Permalink | Log in to Reply

        I mocked up my interpretation of Nacins concept:

        A couple notes:

        • My thought was that we could add another option in screen options to show/hide the “add menu” button on the page (in the normal spot next to the header). It would be hidden by default. This way, advanced users can still add menus for the edge cases mentioned above (when added, they’ll also show up in the “Select a menu” area), but the majority of users will no longer have to deal with the complexity of adding a menu and then assigning it to a theme location.
        • When you switch themes, any menu which was assigned to a default menu, would just become an unassigned menu. You could then click to edit the unassigned menu, and then assign it to a theme location in the new theme (through a drop down or something – perhaps at the bottom of the right column). Widget menus would just transfer over.
        • Upon adding a custom menu widget, you’d see this:

        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.

        • Aaron D. Campbell 6:50 pm on January 23, 2013 Permalink | Log in to Reply

          My first thoughts:

          The things I like:

          • I really like the way this handles new widgets.
          • I like that it feels very light weight.

          The questions/concerns:

          • I’d love to see how you’ll handle adding existing menus as a widget. For example, if you change themes and you want one of those unassigned menus to be used as a widget or if you create the menu before you add the widget.
          • Widgets save immediately, so we need to make sure that a new widget with an empty menu has no output. We also need to make sure that updating a menu used in a widget clears any cache associated with the widget.
          • If you have a decent number of menus, even just 10, then you really start pushing down that left column of items to add.
    • Robert Chapin (miqrogroove) 4:49 pm on January 24, 2013 Permalink | Log in to Reply

      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.

  • lessbloat 8:32 pm on January 16, 2013 Permalink
    Tags: , menus   

    Here’s a quick update on the 3.6 menu changes we’ve been making:

    Last week we:

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

    What’s left:


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



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

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


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

  • Aaron D. Campbell 1:07 am on January 8, 2013 Permalink
    Tags: , menus   

    WordPress 3.6: Menus 

    For menus we’re going to try to focus on some UI improvements. Menus work pretty well but users, especially the less-technical ones, are easily confused. We’ve seen them try to add menus without names because they see the “Create Menu” button before they see the menu name field, we’ve seen them add a bunch of menus instead of menu items because they’re unclear on the difference, etc, etc. The goal for the 3.6 cycle is to make menus a little more intuitive and user friendly.

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

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar