[wp-trac] [WordPress Trac] #31336: Customizer: separate navigation from options UI for better UX by removing accordion behavior
noreply at wordpress.org
Sat May 23 06:40:44 UTC 2015
#31336: Customizer: separate navigation from options UI for better UX by removing
Reporter: | Owner: ocean90
celloexpressions | Status: assigned
Type: enhancement | Milestone: 4.3
Priority: normal | Version: 4.0
Component: Customize | Resolution:
Severity: normal | Focuses: ui, accessibility, administration
Keywords: has-patch |
Comment (by celloexpressions):
Panel description design now matches @folletto's latest design, and has a
hover state for the icon.
I think the gray padding around widgets search is actually the correct
color - that part is the only non-interact-able region in the add-widget
panel. That being said, we should rethink the color patterns for widgets,
add-widgets, menus, and add-menus. Let's do that in a future pass or other
ticket, potentially after Menu Customizer is merged.
Replying to [comment:43 ocean90]:
> * I think the Customizer should get the same background color (#eeeeee )
as the admin (#f1f1f1) has.
I was leaning towards saying #eee, but then I realized that if we go
lighter we constrain the range of usable grays even smaller than it was
before. While we're mostly fixing these issues by being smarter about the
patterns of white and gray that we establish, I'm really worried about
reducing the contrast below the #eee that it currently is (and that the
Customizer had had for some time now). We don't match the rest of the
admin much at all in terms of broader UI patterns (ex. white navigation,
vs. darker), so I'm not too concerned about the slight difference. On an
average monitor it looks slightly better with the increased contrast that
#eee provides, whereas I'm guessing it may be opposite on a higher-end
screen. I'd rather design for something that is less likely to break or
appear overly washed-out on a majority of users' devices. #eee is also
used in a bunch of different places, not just that one background color,
so I don't think we should change it unless there's another reason besides
matching the admin.
> * `<?php _e( 'Customizing' ); echo ' ▸ '; _e( 'Widgets' ); ?>`
should be one string so the arrow can be flipped for RTL.
Widgets is the dynamic panel title, so we can't fully combine them. In the
latest patch, I added the arrow to the customizing string.
> * A widget can suddenly disappear: https://cloudup.com/c_QRWhciccQ
It's hidden when it's dragged out of the widget region, which is a bit odd
but could be argued as expected behavior. Other than the header part, this
is caused by an `overflow: hidden` in `common.css` on `.accordion-section-
content`, which I'm not sure that we should change or override.
Also, since this flows so much better, I think we're fine with losing the
ability to drag widgets between areas, since there's still the move-to-
area functionality in reordering mode.
> * The animation is broken on iOS and needs to be disabled for
`.customize-panel-back`, see `.ios .control-panel-back`:
Should be fixed, but needs testing.
> * Tab order: `a.customize-controls-close` is focussed initially,
clicking tab once doesn't focus something, at least it's not visible. I
would expect that the help icon gets focussed. (Chrome 43)
Looks like that was getting added in JS. Should be fixed now.
> * Since a section slides now too, do we really need to visually
distinguish between a section and a panel? I don't think so.
If someone else wants to patch it, go for it. But I still disagree. While
the general UX is similar, panels and sections are fundamentally
different, which is why we didn't go with an API that simply allowed
nested sections when panels were first introduced. While it may not matter
much to users, the UI should at least hint at the distinction, and I don't
see it hurting anything.
> * I noticed the different transition too, should be fixed.
I'm not sure that it can be fixed, unfortunately. We could investigate
further when things stabilize after a first-pass is committed.
> * It's odd, that you can't click the whole panel title to close the
current panel. Again, I don't think a user needs to know if she/he is
seeing a section or a panel.
We can't functionally change that because of the help toggle (and future
potential screen options toggles). So if we want it consistent we'd have
to reduce to only the arrow on section headings to be clickable (or at
least to appear clickable).
> * Am I the only one who is missing keyboard navigation to return to the
It's at the top in the panel/section headers, just like for mouse and
touch users. If we want to hide top-level or previous-level accordion-
section-title tab-ability we could do that, and then they'd just go
directly to the collapse link at the end of the section. But I don't think
that's necessarily an improvement. Or if you mean something like `esc`,
> * I think the help toggle should be a bit lighter, !#555 instead of
I really think we should get a first-pass committed here so that fixes to
all of these little details can be more easily patched by others without
running into duplicated efforts. As of right now, likely due to the size
of the patch for the initial overall change, it's difficult for others to
iterate on these patches, and then when @valendesigns did (just fine), I
was concurrently working on an iteration and had to merge them.
Ticket URL: <https://core.trac.wordpress.org/ticket/31336#comment:51>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac