[wp-trac] [WordPress Trac] #28979: Customizer panels should have the same priority hierarchy as Sections
WordPress Trac
noreply at wordpress.org
Sun Aug 10 21:54:30 UTC 2014
#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
More information about the wp-trac
mailing list