WordPress.org

lessbloat 2:09 pm on March 7, 2013 Permalink  

• 

  Chip Bennett 2:18 pm on March 7, 2013 Permalink

  Can I throw in a vote for returning the “Theme Locations” meta box? IMHO it is far more intuitive to associate Theme Locations with menus, than to associate menus with Theme Locations. It is also far more useful to see, at a glance, what Theme Locations have assigned menus, than to see what Theme Locations a given menu is assigned to.

  To test:

  Step X: Assign a custom menu to every Theme Location provided by the current Theme

  I think this step – critical to the setup of any given Theme – has been made more difficult with the current UI changes.

  • 

    lessbloat 2:35 pm on March 7, 2013 Permalink

    Thanks for your feedback Chip. Honestly, neither solution is ideal. The decision came down to a choice between the lesser of two evils.

    The old way of doing this had several down falls:

    • The positioning of the theme locations meta box was confusing. It was aligned in the left column at the top, which A) pushed the menu item options down (which was not ideal), and B) seemed out of place when the rest of the actions in that column dealt with adding menu items to your menu. With the new layout, all of the items in the left column now perform the same function (adding new menu items).
    • With the old way, adding a new menu was a three step process. 1) Add a new menu (enter the menu name, and click “create menu”), 2) Add menu items, and then 3) Select a theme location. The new approach reduces this to two steps.

    As such, I feel like the new approach simplifies things for the better.

    • 

      Chip Bennett 2:55 pm on March 7, 2013 Permalink

      The positioning of the theme locations meta box was confusing. It was aligned in the left column at the top…

      Agreed. But why not put the Theme Locations metabox in the main column, right above the Menu-Edit metabox?

      The new approach reduces this to two steps.

      But the reduction-in-steps isn’t associated directly with the change. After creating a new menu, the user must still assign the menu to a metabox – only using checkboxes now instead of the dropdown.

      Also, this workflow appears to assume: a) a New Theme, with b) no previously created custom nav menus. Have you done UI testing for a user who already has created custom nav menus, then switches Themes?

      And to keep responses in one place:

      Also, you can see at a glance which theme locations are assigned to which menus in the menu select drop down

      “At a glance” requires clicking the select, in order to see all menus/Theme locations. That’s an extra step from the old UI, when all Theme Locations were visible without user interaction. Also, I’ve not tested: how does the current UI scale when the same menu is applied to multiple Theme Locations?

      • 

        Chip Bennett 3:12 pm on March 7, 2013 Permalink

        Oh, and I forgot to mention:

        Also, you can see at a glance which theme locations are assigned to which menus in the menu select drop down

        You also cannot tell from that select whether all Theme Locations have menus assigned.

        The only way to know if there are any Theme Locations without menus assigned is to make a mental note of the assigned locations in the dropdown at the top of the page, then compare that mental list with the list of checkboxes at the bottom of the Edit-Menu metabox.

        IMHO, that is a pretty significant UI loss inherent in this change.

    • 

      Chip Bennett 3:51 pm on March 7, 2013 Permalink

      I moved discussion to Trac, as it seems more appropriate there. Let me know if I’ve picked the wrong ticket.

  • 

    lessbloat 2:39 pm on March 7, 2013 Permalink

    Also, you can see at a glance which theme locations are assigned to which menus in the menu select drop down: