[wp-trac] [WordPress Trac] #37661: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer
WordPress Trac
noreply at wordpress.org
Tue Sep 27 23:34:35 UTC 2016
#37661: A New Experience for Discovering, Installing, and Previewing Themes in the
Customizer
-------------------------------------+-------------------------------------
Reporter: celloexpressions | Owner: celloexpressions
Type: feature request | Status: assigned
Priority: high | Milestone: 4.7
Component: Customize | Version: 4.2
Severity: normal | Resolution:
Keywords: has-patch has- | Focuses: ui, accessibility,
screenshots needs-testing has- | javascript
user-testing ux-feedback |
-------------------------------------+-------------------------------------
Comment (by celloexpressions):
Thanks @folletto!
A couple of questions:
- One other flow we need to consider is for users who can't install themes
and on multisite. For those, they can only see installed themes, and
there's a search filter for those. Presumably that'll be the only thing in
the sidebar?
- I'm thinking about sliding the themes in like add-menu-items slides in,
sliding the collapse and device preview bar down out of view, and quickly
fading the theme count over the save & publish button when the panel
opens. If anyone has other ideas for animations, please let me know.
- Do we need the icon next to the search box? I'm worried that the check
mark will imply "loaded" or "success" as opposed to it being the selected
section. It'll also change to the checkmark as soon as there is an `input`
in the search field, and it's unclear whether it's acting like a submit
button.
- For all of the filters, could the border-left work to show the active
section instead of the check mark? Thinking we'd match the UI for device
preview. I like the idea of changing the text color as a secondary
indicator for "selected".
- Are we okay with dropping the help text? The "your local site" labels
help clarify what it explains, so I'm okay with removing it.
- What about icons or another approach to differentiate the sections that
can expand rather than the margin? The additional margin implies some
separation from the "Browse all WordPress.org themes" text, perhaps
suggesting that those sections aren't from there.
And a few technical limitations we need to consider:
- Due to timing and effort required to update the patch to the different
design, we'll punt shiny theme uploads to a future release, and save the
UI design for later. Themes can still be uploaded in the admin, and users
who need to do that aren't the primary target for this feature.
- For the mobile view, we wouldn't be able to use the existing "preview"
button to show themes. A primary button at the top feels like the wrong
interaction to actually view themes - they should be visible as soon as
you make a selection. Probably the easiest solution would to place themes
under the filters, and we could potentially collapse the filters toggle
into a menu button of sorts on smaller screens, like the previous mockups
did.
- @afercia can you confirm that the feature filter should remain
checkboxes instead of what's shown in the mockup above for accessibility?
We can change this to apply the filters automatically, and/or adjust the
styling of the labels. There will be more hits to the .org API if the
feature filter triggers a new request whenever boxes are checked, but the
user testing expressed a preference for that functionality and that would
provide a better experience.
- The implementation will get a bit messy with the custom section headers
being separated from the content (where themes are shown), which the API
doesn't structure out logically. Further splitting that to show things
like the feature filter in a sliding panel as opposed to inline in an
accordion should be avoided if at all possible. Can we live with the
accordion approach? This UI is still used for secondary navigation in the
customizer, notably for menu item controls and the available menu items
panel. It'll also be easier for any 3rd-party marketplace plugins to build
on.
If we can answer/decide on these questions before my dev window on
Thursday, that would put us in a good place to get these changes made
without falling behind.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37661#comment:55>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list