[wp-trac] [WordPress Trac] #29949: Customizer collapsed mode is barely usable

WordPress Trac noreply at wordpress.org
Wed Oct 15 19:45:37 UTC 2014


#29949: Customizer collapsed mode is barely usable
------------------------------+------------------
 Reporter:  celloexpressions  |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  4.1
Component:  Customize         |     Version:  3.4
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:  ui
------------------------------+------------------

Comment (by celloexpressions):

 Replying to [comment:5 ocean90]:
 > * In collapsed mode we now have two uncollapse buttons, thats weird.
 Shouldn't it remain as a close/cancel button?
 I added the second expand button for two reasons: to make it more
 prominent as well as retaining the one at the bottom, and to ensure that
 users expand the controls and can save changes before closing, with all of
 that UI being consolidated at the top. I imagine the most common workflow
 will be: Customize, collapse, browse site, save/publish, close Customizer,
 so adding a second expand arrow to the top facilitates that and avoids
 users trying to close the Customizer and getting the AYS, then not being
 able to find the save button because the controls are collapsed. We could
 just leave the close button there, but particularly to avoid missing "Save
 & Publish" it seemed better to have the second expand button, and also to
 not move the first since it's unified with the collapse button.
 > * In <600px we also have two uncollapse buttons, the top one looks lost.
 Is there a reason for hiding the controls?
 Since horizontal space is so limited on devices that small, which tend to
 be portrait, we felt that it was more important to give the full width to
 the preview and to have a "header" on mobile. Since that would be
 implemented in the other ticket, this patch tried to avoid changing that
 much. We'd end up not showing the original icon, and in the meantime we
 would just have both, with the top one being a more realistic touch
 target.
 > * With the controls always visible you will never have the same preview
 as on the frontend because we will lose some pixels for the controls.
 I think the main point of collapsing the controls will be to focus more on
 the previewing component of the Customizer, with the workflow I outlined
 above. The point of this ticket is to make the fact that you're still in
 the Customizer (and probably have unsaved changes) clearer, and to bring
 quicker access to different sections. The collapsed mode takes 46px away
 from the site width, vs. the 300px that the expanded controls take, and
 essentially hides the UI to allow the user's focus to shift to the
 preview.
 > * Collapsing the controls shouldn't close any open controls.
 You mean closing the active section/panel and returning to the top level?
 We need to do something like that to successfully minimize the UI so that
 the icons can be displayed next to each other and there can be no
 scrollbar. If you remember the icon for the section that you want to go
 back to, you can just click that icon to auto-expand the section/panel
 when you want to re-expand the controls to make another tweak. I don't
 think that's particularly disruptive given the workflow outlined above.
 > * Is an icon enough let the user know what's behind the section? It
 should have at least a title attribute.
 I suppose we could add a title attribute, but rather than relying on the
 various ways that browsers implement (and no touch support, etc.), I think
 the dual expand buttons make it clear that you can just expand it back out
 to see the fill section titles.
 > With these points we would be closer to #28784 and curious why it's
 pulled of. Would like to see this happen in 4.1. The test plugin does
 already a great job.
 I want to see it in 4.1 also, but we still need to get to a complete
 patch. Again, it's tricky to patch that independently from this, but I can
 try to do that if you'd prefer to commit all three tickets together.
 Realistically, I would probably need to make one big patch, because the
 labels of the buttons will need to be different for the different layouts,
 so the patches will conflict if we try to do both separately.

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


More information about the wp-trac mailing list