[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