[wp-trac] [WordPress Trac] #31336: Customizer: separate navigation from options UI for better UX by removing accordion behavior

Sat May 23 06:40:44 UTC 2015

#31336: Customizer: separate navigation from options UI for better UX by removing
accordion behavior
--------------------------+------------------------------------------------
 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):

 [attachment:31336.8.diff]:

 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`:
 https://cloudup.com/cCkB__QgYo9
 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
 previous panel/section?
 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`,
 see #22237.
 > * I think the help toggle should be a bit lighter, !#555 instead of
 !#000.
 Fixed.

 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