[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 celloexpressions):

 Replying to [comment:15 folletto]:
 > Ok, I guess this ticket is for visual styling as well. Is there already
 a ticket to address the overall design of accordions/slide-ins? :)
 I think that would be here. I do like the idea of everything side-sliding,
 as things are organized in a more intuitive hierarchy that is a more
 common UI pattern. 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).

 > The proposal you make is very similar to a design concept I was working
 on too, even if the "slide back" actually triggered a full screen view
 (from the left slides in a full page that covers everything, which is in
 practice the 3.9 theme browser), the reason is that it would be too
 constrained to fit inside a small column (even if, that would be exactly
 how it would behave on mobile).
 > But apart from that, I agree 100% that it should be the hierarchy to
 imply there.
 >
 > We could still add an intermediate step: it could be simply a link back
 (click, open Themes panel in the admin area), and we can work on the
 better interaction (sliding panels, API, etc) at a later stage. ;)
 >
 > So... worth a new ticket? ;)
 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.

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