[wp-trac] [WordPress Trac] #27403: Improve UI for linking areas of Customizer preview to corresponding controls (desktop and mobile)
WordPress Trac
noreply at wordpress.org
Thu Nov 3 02:47:34 UTC 2016
#27403: Improve UI for linking areas of Customizer preview to corresponding
controls (desktop and mobile)
-------------------------+--------------------------------------------
Reporter: westonruter | Owner: sirbrillig
Type: enhancement | Status: reopened
Priority: high | Milestone: 4.7
Component: Customize | Version: 3.9
Severity: normal | Resolution:
Keywords: ux-feedback | Focuses: ui, accessibility, javascript
-------------------------+--------------------------------------------
Comment (by folletto):
> Btw here is one of Folletto's wireframes used for the theme switcher (so
yes it is out of context):
https://core.trac.wordpress.org/attachment/ticket/31289/customizer-
themeswitcher-i2-structural.png I am sharing it because it shows a preview
button. If that is the right approach for showing a preview I do not know.
It's not: that is the existing Preview button for mobile. It toggles
between the customizer sidebar and the preview. Overloading it with an
extra meaning on desktop would be an issue.
> I very much agree, but there seems to be no agreement about how to make
them discoverable. We've tried having them always visible which may be the
most discoverable (and this has been user tested on WP.com) but it does
obscure the preview and there must be some obvious way to toggle them.
I still think we're circling around this for more historical and
theoretical reasons than good usability and pragmatism:
* Icons should be always visible because that's what the user is meant to
do there: the user clicked "Customize".
* There's already the toggle, which is the collapse icon.
> I just opened the Customizer for the first time since this was
implemented and I saw some edit buttons appear for a moment and then
disappear. The discoverability of these is exceptionally low and I had to
play around with mouse hovering and clicking before I figured out how they
appear. This needs user testing.
The approach of having the icons always visible is working well on
WordPress·com too, so it's not as if we don't have a track record proving
its effectiveness. Millions of users are already using it, successfully.
And if I'm not mistaken (I can ask for hard data tho) we had virtually
zero complaints. Which is impressive, and happens very rarely for features
of this size.
One thing we can consider is to relabel the "Collapse" icon. That's
probably the clearest, most intuitive improvement we can do, as "collapse"
doesn't really mean anything.
My advice:
1. Restore the "always visible" behaviour.
2. Change "Collapse" to something different.
Ideas for "Collapse" alternative labels:
* "Full view"
* "Show all"
* other?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/27403#comment:103>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list