WordPress.org

lessbloat 1:13 pm on January 21, 2013 Permalink
Tags: 3.6 ( 63 ), menus ( 12 )   

• 

  Alex King 3:13 pm on January 21, 2013 Permalink

  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!

  • 

    Travis Northcutt 4:33 pm on January 21, 2013 Permalink

    @Alex can you expand on how that filter might be used? Can’t conceptualize it for some reason.

• 

  lessbloat 4:52 pm on January 21, 2013 Permalink

  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

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

  • Welcome
  • Time for office hours
  • Here’s where we’re at: http://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

  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

    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

      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

  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.