[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
--------------------------+-----------------------

Comment (by folletto):

 Replying to [comment:16 celloexpressions]:
 > But in practice it introduces a lot of extra mouse/finger movement
 (especially for finding the back button) and cognitive load with the
 entire context shift for every section. Existing sections are designed
 with the expectation of being displayed in an accordion, and users expect
 that, so I'm not sure that we could change it at this point even if we
 resolved issues like the back button (touch swiping works great for touch
 devices here). Sliding down vs. sideways for sections vs. panels also
 gives them functional hierarchy, which is good, whereas everything sliding
 would imply more of a parent/child setup, which we moved away from with
 the implementation in #27406 (API-wise).

 I feel this is a mix of a few different arguments coming also from the
 ticket you link... let me try to disassemble it. :)

 The most important point imho is that the cognitive load of slide-ins is
 lower than accordions, not higher, this for a moltitude of reasons:

 1. The number of clicks is identical
 2. The positioning is preserved both in the navigation AND in the
 customization panel: fixed positioning helps people with spatial memory to
 recall items, creating visual trust.
 3. Slide-ins separate also clearly navigation from content. It won't be a
 mix of navigation and content, like the accordion (note that this isn't
 something new, many accordion solutions ask for a uniform set of content,
 like all menu, instead of mixed one. The same recent Google Material
 Design manual outlines accordions for menus only).
 4. Moving sections rely on our spatial memory overall, while things that
 fold/unfold will keep moving the whole page up and down: I click an
 accordion, content appears in between, suddenly the "next" item is way
 below, moving it as a target.
 5. It's easier to scan a pure list of items, instead with an open
 accordion the menu is disrupted.
 6. An open slide-in is clearly just that, thus helping the user to focus
 on that content, instead of having first to separate it from the context.
 It's a cleaner solution.
 7. Not to mention the potentially improved elegance of keyboard
 navigation... (left-right-esc). ;)

 This doesn't mean that accordions are bad overall, clearly, however they
 must be very carefully isolated from context, and used where possible not
 as navigation but as exploration (i.e. not menu-with-content, but already
 descripting items with "more"). ;)

 I'd note also in regard of #27406 that slide-ins are a better solution
 regardless of their use as a multi-layer hierarchy, or not. In other
 terms: if we could instantly convert all the accordions to slide-ins right
 now, it would still be an improvement even without implementing a multi-
 layer structure (even if I'd personally find it the natural step forward).
 I've seen your work there... I think it was the right direction... and
 reading the thread does look to me that there was agreement on that being
 a better solution, no? :)

 Plus, all of this, good for desktop, would be just bliss on mobile. ;)



 > Great idea! We could even slide in `themes.php` in a full-screen iframe
 from the left of the screen, and then trigger a new full pageload to get
 out of the iframe as soon as the user navigates somewhere (such as, most
 commonly, to customize a new theme). If you want to make a new ticket, or
 even re-open #26890 with a comment, I can throw together a rough patch as
 I have an idea for how we could accomplish that from a technical
 perspective. Now that we have an AYS for unsaved changes, linking away
 from the Customizer isn't a huge deal. If the Customizer was opened from
 `themes.php`, we would already have that page's DOM loaded thanks to
 customize-loader, so it would just be a matter of changing the animation
 that closes the Customizer iframe. Not the ideal experience that doing it
 all in the customizer would be, but a good approach while we build up the
 API, and at least we can start to make the themes vs. theme/site options
 relationship clearer. If we get a few people working on it, could probably
 get that into 4.1.

 Sounds great!
 Reopened #26890... let's see... ;)

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