WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#23716 closed defect (bug)

Discuss theme locations as meta box vs. checkboxes — at Version 5

Reported by: lessbloat Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Menus Keywords: 3.6-menus
Focuses: Cc:

Description (last modified by DrewAPicture)

Relocating a side topic discussion that started on the make/ui P2, and then moved to the wrong ticket.

To summarize chips last post (and kick us off here), here are the concerns Chip would like to address:

1) When assigning pre-defined custom menus to a Theme's defined Theme Locations, the process now requires considerably more steps, clicks, page refreshes, and time

2) When looking at the "Select a menu" dropdown, there is no way to determine if all Theme locations have an associated custom menu assigned

3) When editing a given menu, in the Theme Location field checkboxes, there is no indication that a given Theme Location already has a custom menu assigned to it

4) With long-ish custom menus, the "Theme Locations" field is buried "beneath the fold", resulting in no initially visible UI for assigning the current menu to a Theme Location

5) Overall, the page now seems to emphasize adding/editing custom menus, and seems to deemphasize assigning custom menus to Theme Locations, and the latter is arguably the more important role/task for Appearance -> Menus

3.6-Menus Tracking Ticket: #23607

Change History (5)

comment:1 follow-up: @chipbennett2 years ago

Just for traceability: under what ticket were the UI changes we're discussing first committed?

comment:2 in reply to: ↑ 1 ; follow-up: @lessbloat2 years ago

Replying to chipbennett:

Just for traceability: under what ticket were the UI changes we're discussing first committed?

#23119. But that ticket is off limits. ;-) I'm trying to spare anyone from having to navigate through the 239 comments on that beast of a ticket.

comment:3 in reply to: ↑ 2 @chipbennett2 years ago

Replying to lessbloat:

Replying to chipbennett:

Just for traceability: under what ticket were the UI changes we're discussing first committed?

#23119. But that ticket is off limits. ;-) I'm trying to spare anyone from having to navigate through the 239 comments on that beast of a ticket.

That's okay. I'd just like to skim, to make sure I'm not bringing up issues that were already covered/discussed/decided. :)

comment:4 @lessbloat2 years ago

My thoughts with regard to your concerns are:

1) When assigning pre-defined custom menus to a Theme's defined Theme Locations, the process now requires considerably more steps, clicks, page refreshes, and time

I agree, this does take a bit more time. Again, there is no perfect scenario here. I see 5 options. each has pros and cons, but we have to pick one of them.

1) Meta box - left column at the top

PRO's

  • It's in your face, you can't miss it
  • When switching themes, you can update all of your theme locations in one spot.
  • It's familiar for existing users

CON's

  • It's unnecessarily in your face. ;-)
  • It pushes menu item options down the page
  • It's awkwardly grouped in that left column when everything else is a menu item option
  • It forces users to take a third step (outside the flow of creating the menu) at the end of creating a menu, where they then have to select a theme location.

2) Meta box - left column at the bottom

PRO's

  • When switching themes, you can update all of your theme locations in one spot.

CON's

  • Chances are, it would get pushed past the fold for some users
  • It's awkwardly grouped in that left column when everything else is a menu item option
  • It forces users to take a third step (outside the flow of creating the menu) at the end of creating a menu, where they then have to select a theme location.

3) Meta box - right column at the top

PRO's

  • It's in your face, you can't miss it
  • When switching themes, you can update all of your theme locations in one spot.

CON's

  • It's unnecessarily in your face. ;-)
  • It would through the balance of the page all off
  • It pushes the menu editing screen down the page
  • It's awkwardly grouped in that right column when everything else is related to editing a specific menu
  • It forces users to take a third step (outside the flow of creating the menu) at the end of creating a menu, where they then have to select a theme location.

4) Meta box - right column at the bottom

PRO's

  • When switching themes, you can update all of your theme locations in one spot.

CON's

  • We actually tested this placement and it failed, because people were clicking the "theme location" "save" button incorrectly thinking that it was saving the changes to their menu.
  • Chances are, it would get pushed past the fold for some users
  • It's awkwardly grouped in that right column when everything else is related to editing a specific menu
  • It forces users to take a third step (outside the flow of creating the menu) at the end of creating a menu, where they then have to select a theme location.

5) A checkbox for each theme location inline for each menu

PRO's

  • It removes the "theme locations" meta box from the left column, making the actions one takes in that column nice and clear. This also pulled the menu item options up, making them more visible.
  • It reduced the visual clutter on the page. Forcing the user (especially a new user) to grok what was going on when they were presented with options to add menus, and edit menus, and add menu items, and set theme locations all on the same UI, was just too much to ask. For you it makes sense sure. It's the way you've been doing it all along. But for most users it was a terribly confusing experience.
  • It reduces the steps (page reloads) to get set up with a new menu from 3 down to 2.

CON's

  • We're moving functionality that existing users will have grown used to.
  • When changing themes, you've got to hop into each individual them to set the theme location.

Weighing my options, I'd be comfortable with either 5, or 2.

2) When looking at the "Select a menu" dropdown, there is no way to determine if all Theme locations have an associated custom menu assigned

All of the theme locations are listed out under each menu. When you load the page, the menu you edited most recently will be auto loaded. If another menu is set as a theme location, you will see it in grey next to the theme location:

http://f.cl.ly/items/3t1j44361h3V3o1r0n3s/already-set.jpg

So, yes, you will always see at-a-glance which theme locations have menus assigned.

3) When editing a given menu, in the Theme Location field checkboxes, there is no indication that a given Theme Location already has a custom menu assigned to it

Not true. See my answer in 2.

4) With long-ish custom menus, the "Theme Locations" field is buried "beneath the fold", resulting in no initially visible UI for assigning the current menu to a Theme Location

You're right. Again, it comes down to weighing the options out of the 5 listed above.

5) Overall, the page now seems to emphasize adding/editing custom menus, and seems to deemphasize assigning custom menus to Theme Locations, and the latter is arguably the more important role/task for Appearance -> Menus

I agree that we are emphasizing adding/editing custom menus. You can't set a menu to a theme location if you can't figure out how to create a menu in the first place. ;-)

Would love to hear others chime in with thoughts.

Last edited 2 years ago by lessbloat (previous) (diff)

comment:5 @DrewAPicture2 years ago

  • Description modified (diff)
  • Keywords 3.6-menus added
Note: See TracTickets for help on using tickets.