[wp-trac] [WordPress Trac] #28979: Customizer panels should have the same priority hierarchy as Sections

[WordPress Trac]

#28979: Customizer panels should have the same priority hierarchy as Sections
--------------------------+-----------------------
 Reporter:  mattwiebe     |       Owner:
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  4.0
Component:  Customize     |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  ux-feedback   |     Focuses:  ui
--------------------------+-----------------------
Changes (by celloexpressions):

 * keywords:   => ux-feedback
 * focuses:   => ui


Comment:

 Biggest UX thing for me is that we need to do something about the tiny
 arrow indicators for sliding down/right if we even want to consider this.
 Some things sliding down and others sliding sideways and switching
 contexts seemingly at random results in incredibly confusing UX, and it's
 nearly impossible to tell which direction the arrow points if they aren't
 grouped by direction (and it's not great anyway).

 I have a feeling, for some reason, that people will use panels more
 appropriately (and generally try to keep their interfaces simpler/easier
 to use) if they're all at the top, as that implies their importance and
 pushes traditional sections lower. Also, a reminder for everyone that
 panels do support priority, and are sorted by their priorities. Once there
 are more core (and plugin) panels, the grouping at the top will make more
 sense. I've been using the Customizer with both Widgets and Menus panels
 since this was introduced, and that may be influencing my opinion here.
 But '''since there will inevitably be more core panels in the future, any
 proposed changes/implementations here need to be tested with multiple
 panels. Making a decision here based solely on the placement of Widgets
 would be a big mistake'''.

 @nacin do you have a why for "widgets shouldn't be at the top, that's
 wrong"? Besides the current implementation, Widgets are currently at the
 top because they're the most likely to be edited the most frequently.
 Users rarely change things like site title/tagline, colors,
 header/background, static front page, etc. after initial setup, but
 they're likely to tweak Widgets much more frequently. If they're near the
 top, users don't need to search long for them when they visit the
 Customizer for the first time in a while looking to make a change there.
 In the context of panels generally, the argument is that panels should
 generally be used for things that require an entrely separate context, and
 one that would be used more frequently than standard sections. Eventually,
 everything that's currently in a top-level section could potentially be
 moved to a "theme options" panel, so we should consider that possibility
 as well.

 A big reason to have kept this on #27406 is that the path to the
 implementation we currently have is documented there. Other than comments
 specific to the sorting issue, we went with an API that specifically makes
 panels and sections distinct objects, like sections and controls are. That
 `WP_Customize_Panel` extends `WP_Customize_Section` is an implementation
 detail, IMO. And rather than mixing sortings, I would be interested in UI
 changes that give panels hierarchy with respect to top-level sections, as
 they're fundamentally different things.

 Dump of relevant comments from #27406 to attempt to de-fragment the
 discussion:
 celloexpressions:
 > We can (and should consider) group top-level-sections and pages together
 for sorting by priority in the page approach; and could look into a
 WP_Customize_Group class that WP_Customize_Section and WP_Customize_Page
 both extend (@westonruter's idea).
 ''Note: the "page" approach is what made it into core; in the other
 approach, sections had parent sections that were still sections.''
 > Should all panels be listed before top-level sections, or should they
 have mixed sorting? I think it's better to keep them separate, as the
 small arrow indicators are more effective when grouped, and users are
 probably more likely to need to use a panel then a top-level section when
 entering the Customizer at any given time (if Widgets and Menus are
 panels, for example).
 ethitter:
 > Sections already support priority. Since a Panel is an extension of the
 WP_Customize_Section class, shouldn't it respect priority?
 helen:
 > Not sure about grouping panels vs. sections - I can see how it would
 make sense to group them together, but the ordering feels wrong with
 Widgets at the top.
 celloexpressions:
 > Sorting/priorities: in the current implementation, all panels are
 displayed by their priorities and then all sections are displayed by their
 priorities. Until there are more panels in core, that does mean that
 widgets will often be alone at the top (pending theme/plugin panels). We
 certainly could do mixed priorities, although that would be a bit less
 elegant, as we may need two copies of everything in WP_Customize_Manager
 (panels, sections, and the combined array, perhaps groups). I think we
 should think about this from a UI/UX perspective and get some feedback.
 For me, having the panels at the top makes sense because the types of
 things that'll go in panels will generally be more-commonly-used (ie,
 users change their widgets more frequently than their site title/tagline,
 header/background, colors, static front page, etc.). Could probably get
 some stats from .com to back that up (even though their customizer UI is
 fairly different).

 > Only remaining item here, barring any bugs, is whether panels and top-
 level sections should have independent or mixed sortings. The current,
 separate approach is a cleaner implementation and asserts than panels
 contain more-commonly-used controls. It also makes it easier, as a user,
 to distinguish between panels that will completely change the Customizer's
 context and sections, which simply open inline. I imagine that would
 create a really strange user experience, unless there is a more obvious
 visual distinction between panels and top-level sections. Eventually, I
 could see a time when we may force all sections to be contained in a panel
 (placing unspecified ones into a generic panel), so we may want to
 consider that as well.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28979#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform