[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