[wp-trac] [WordPress Trac] #23716: Discuss theme locations as meta box vs. checkboxes

[WordPress Trac]

#23716: Discuss theme locations as meta box vs. checkboxes
--------------------------+------------------------------
 Reporter:  lessbloat     |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Menus         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  3.6-menus     |
--------------------------+------------------------------

Comment (by chipbennett):

 Replying to [comment:7 DrewAPicture]:
 > Do you have some kind of data to support this assertion that changing
 theme locations is somehow a more frequent task than editing menus? For
 regular, non-power-users?
 >

 Common sense?

 Users - normal, average users - switch Themes frequently. As far as I know
 api.wordpress.org data (and probably, wordpress.com data) still support
 that assertion.

 An average number of Theme switches greater than 1 will all but guarantee
 that users assign custom menus to Theme Locations more often than they
 create menus.

 >
 > > This new UI inverts the relationship between custom menu and Theme
 Location. Under the previous UI, and ''as designed/intended'', custom
 menus are assigned to Theme Locations. However, under the new UI, ''Theme
 Locations are assigned to custom menus''.
 >
 > Yes, yes it does.
 >
 > > > The theme location drop down allows you to select from multiple
 menus, which tells me it belongs on the menu management screen, not the
 add/edit screen (which should be all about a single menu).
 > >
 > > And yet, the resultant UI puts the Theme Location inside the metabox
 for individual menus - which is, essentially, exactly what you were
 arguing against earlier.
 >
 > There are a couple of things in play here:
 >
 > 1. '''Global vs individual menu settings.''' Before, you had a mix of
 global and individual settings that required multiple steps and
 experienced knowledge to configure. Adding & managing menus and setting
 locations were global, editing the menu title and items, auto-add pages
 were individual. Now, editing the menu title, items, location and auto-add
 pages are individual. The concept of adding a new menu was merged with the
 menu-editing UX and menu management stayed global but became more
 discoverable.
 >
 > 2. '''The 1:1 vs 1:many locations paradigm.''' With menus, there's
 always been (and still is) a 1:many relationship. You can set one menu to
 many locations. And with locations, it's 1:1. One location, one menu. The
 previous UI put emphasis on the locations side of the paradigm and
 completely ignored the menu side, which was odd because it was a menu-
 specific setting in a global context. The UI change makes that menu-
 specific setting individual rather than global.

 Interestingly, reading through the other ticket, it seems that more people
 liked the tabbed interface, and that the tabbed interface tested the best.
 But (without any supporting UI testing), one person opined that a tabbed
 interface was "too heavy" and the idea was subsequently dropped.

 Regarding the 1:1 vs 1:many relationship: the previous Theme Locations
 metabox met that need perfectly, and remains better than the current
 implementation in that regard. It was very easy to see:

 1. All the available Theme locations
 2. Menus assigned to all available Theme locations
 3. The same menu potentially assigned to multiple Theme locations
 4. The ability to change one or all Theme Location menu assignments, in
 one step

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23716#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software