[wp-trac] [WordPress Trac] #37661: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer

[WordPress Trac]

#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 folletto):

 Sorry about that, I didn't have time yesterday to detail further. Thanks
 for the 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'd probably not address this directly, since it would become
 automatically fixed once we're able to do "true search" across whichever
 filter gets selected.
 However, if we do want to include a search for that, yes, I'd just
 replicate the same search filter module.

 > 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.

 Yes, so splitting in pieces:

 * The themes list view slides in either from the left (from below the
 customizer) or from the right. Speed to be determined, but I'd start with
 something around 300ms.
 * The bottom bar "collapse + device preview" slides out to the bottom. I'd
 try something fast-ish like 100ms.
 * The top bar fades out + fades in. The chain of fades needs to be ready
 when the themes list has done sliding in, so it has to do everything in
 less time than that. An alternative animation would be a "slide up"
 imagining the button is hidden and the bar is a cropped view of a layer
 behind.

 I'd note however that to preserve the mental model would be ideal a
 different animation for the list bit. I'll just mention here for
 reference, but I think it's challenging to do right now:

 * The preview zoom back (gets smaller) and fades to transparent on the
 same color of the theme list background. At the same time, the theme list
 zooms from above (so scaled more than 100% and getting smaller until
 reaches 100% and fits the available space) and at the same time fades in.

 > 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.

 I put the icon there to preserve the space for the check, otherwise it's a
 bit awkward. That component is troubling until we fix it, so I wouldn't
 spend too much time trying to "fix" it in this current form.

 If the mark is perceived as loaded or success, or people try to "click"
 it, it causes no harm either way, and it wouldn't be "wrong" either, so I
 don't think it's an issue (i.e. if while performing automatic search the
 user clicks on it, the click in practice doesn't do anything, but it would
 look like the search was activated, so it works).
 Changing instantly when it get focus is a fix for the current undefined
 behaviour, so I think it's valid. We can review that later tho.

 > 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".

 I tried. The answer there is no, because that's the "focus" behaviour and
 would both be ambiguous (is it the piece I've tabbed on, or the one I
 activated?) and also we would still need an explicit marker. So the
 border-left marker stays, but it's focus.

 (device preview uses a combination of highlight for hover and side-border
 for focus, which actually should be used on customizer as a whole, not
 sure if its an issue with the test site tho).

 > 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.

 I'm ok. But if we want we can simply reuse the ? marker in the same
 position as all the other pages.

 > 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.

 The margin is still within the title, so it's not really a separate thing.
 However I understand it could be read differently, even if I'm not sure
 what else one could think in terms of source. If we see that causes
 problems, I'd just remove the space. :)

 > 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.

 Agreed. The entire design constitutes a general vision, it can be
 partially implemented in future releases until done.

 > 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.

 I switched from the look of preview to the primary button look because on
 mobile that becomes the primary action, and it's also an existing
 customizer design pattern.

 Given the complexity of the filters, I don't think it would be more
 effective to show the themes immediately. Or, to say in a different way: I
 take this as a first implementation, where the filters are limited, and
 where simply reusing existing customizer patterns without shuffling where
 the themes list is located is a better first approach which won't require
 any special attention to the mobile layout.

 For that reason, I'd start there, and then review later the decision with
 a more complex design, as we see fit.


 > 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.

 If the answer here is positive, I'd like to know the reason why the main
 filter bar (either in wp-admin themes or in the main screen here) can
 exist without form component visible (option boxes) while it would be
 required for that specific filter screen. It's not a design issue in
 general: adding the checkboxes is rather easy. But since we were trying to
 inherit visual elements also from the wp-admin bar, it would inform the
 design change for me. :)

 > 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.

 I'd avoid the accordion approach, but I can understand the reason of the
 request. Given it's more a technical limitation, I won't weight in further
 here.

 The only proposal I'd make there is to maybe then switch in the i3b
 "Accordion" the "Upload Theme" to a slider, while keeping the filters as
 accordions (I didn't do that in the above mostly to discuss a more purer
 version).

 I hope it helps. :)

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