[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:  westonruter
     Type:  feature request          |      Status:  reviewing
 Priority:  high                     |   Milestone:  4.9
Component:  Customize                |     Version:  4.2
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, accessibility,
  user-testing has-ux-feedback has-  |  javascript
  patch needs-testing                |
-------------------------------------+-------------------------------------

Comment (by celloexpressions):

 https://github.com/xwp/wordpress-develop/pull/216 has been updated to
 address all feedback in [comment:181] except as noted below. [attachment
 :customizer-theme-showcase-i5.png] is along the lines of what seemed like
 the best strategy for mobile to me. The latest PR now contains a rough but
 functional version of that. Some of the icons and animations still need
 work.

 Some notes/questions:

 > - Use the option form controls for clarity.
 I'm not sure what you mean here.

 > - Align the right edge of "Filter themes" button to the right edge of
 the theme thumbnails below.
 Unfortunately this is not possible in all cases because there can be a
 scrollbar next to the themes but not the filter bar on some screen sizes,
 and the scrollbar width varies by browser/device. I updated the spacing to
 align when the scrollbar is shared (unsticky filter bar) and to match the
 spacing but not account for the differential scrollbar otherwise, which
 makes it aligned for as many situations as possible.

 > - The three-columns filters snap to one-column at 1120px, while there's
 still plenty of space. Let's make them snap to one-column later at 980px.
 Updated the spacing here to better align with the themes grid, and to
 break at better points. I tested all the way down to the mobile breakpoint
 where we lose the separate sidebar and made some optimizations. One
 highlight: I dropped the filter themes button and themes count to a second
 line under the search bar on small screens for space. That way we don't
 need to worry about fitting all of the translations in or hiding/changing
 labels or other information.

 > - Trying to use it made me wonder of the "Live Preview" label on the
 action button. It doesn't seem correct in this context. The wording here
 is tricky because it's not "activating", but it's "being previewed in
 customizer and will get activated only if the user saves changes in
 customizer". I'm thinking something like to "Try Theme" or "Pick Theme".
 Even just "Preview" I think it would work better, given we are inside the
 customizer. Can anyone think of other alternatives?
 "Live Preview" matches the term used in wp-admin where the preview can be
 live with the site's content, whereas "Preview" is used to mean the
 (fairly unhelpful) .org-based previewer. "Try Theme" may make sense, but
 I'd lean on sticking with existing terminology for now unless anyone else
 has better ideas.

 > - When a theme is being "Previewed" there needs to be an option to
 revert back to the original theme. But currently the original theme is
 shown in the list as any other, and the one being previewed is marked as
 "Current". I think we can improve something here to make sure the user can
 easily pick again the original theme, and be also assured it's not really
 "Current" but being tried out in customizer. An option would be to mark
 the the theme currently "Live" (in production) with a button that says
 "Revert" instead of "Preview", while the label of the theme active in
 customizer should be instead of "Current:", "Previewing:". Makes sense?
 This is actually an existing problem in core (since 4.2), made more
 obvious by the ability to more-easily install and preview themes. This
 seems like a good piece to break off to address later (needs a closer look
 at the integration with the customizer's internal mechanisms for
 previewing themes). Everything is previewed in the customizer, so it's
 less likely that it's implied that something else is live, but it would be
 good to clarify this.

 > - When something is typed in the search box it currently hides all the
 themes and show the spinner. Would be possible to keep the themes visible
 but maybe with an "alpha" channel and visualize the spinner near the
 search box? It's not a big deal, but feels a bit jumpy otherwise.
 We could look into this, although the immediate clearing reinforces that
 it typipcally does take some time to reload themes from .org and also
 rescrolls to the top automatically. It could actually be more frustrating
 to fade and then replace, because it allows you to second-guess changing
 your query and you may continue looking through the faded themes from the
 previous search, only to abruptly lose context whenever the new themes
 finally load. There's a jump either way, so the question is whether it
 should happen when you finish typing a search or after the results are
 loaded.

 > - Also, the spinner doesn't show up for "Installed themes", just for
 "WordPress.org themes".
 All installed themes are loaded at once, when the section is first opened.
 The search bar there is actually a filter that instantly shows/hides
 installed themes as you type, so results actually show up before we could
 even show a spinner. We could add one, but it would show up after the
 results, which is a bit odd.

 > - I'm not 100% sure about this, but I think the search should be
 preserved between the two options: if I search for "twenty" in "Installed
 themes", when I switch to "WordPress.org themes" it should preserve the
 "twenty" search, and vice-versa. Makes sense?
 This makes a lot of sense. Often, users will try to search in the wrong
 place - this lessens the resulting frustration by preserving their search
 term and automatically opening the other section to that search result. If
 they don't want that to happen, it's easy to change.

 >> Feature filter "features" list has been condensed to eliminate less-
 useful options to better emphasize the more-useful options.
 > How did you determine this? Can you share the data that you used to make
 this selection? Regardless, I would advise to not change the filter
 number, label or else in this ticket. It should be a discussion on its
 own, separate, to be done after this piece gets wrapped up.
 This is part that I wanted input from other teams on. However, it's been a
 slow process (several years), and core is already out-of-sync. It's the
 focal point of the .org browsing experience here, so it seems worth a few
 changes to improve the basic usability while we wait for broader changes.
 Data was obtained by using the new UI and comparing number of themes
 returned when the search contained only one feature, and in some cases
 also comparing that to a search for the feature. Here's the full list of
 removed tags with reasons (they can still be searched, just are visible in
 the default feature list):
 - BuddyPress: searching for "BuddyPress" returns far fewer results than
 using the BuddyPress filter, indicating (along with manual analysis) that
 many of the "BuddyPress" themes are either using the tag incorrectly or do
 not make enough use of BuddyPress to mention it in the description. These
 also represent a very small percentages of themes in the directory (< 5%).
 This is also the only "feature" that is support for a plugin - we should
 explore additional plugin tags grouped separately from features as a
 future way to bring this back. Currently, the best experience for finding
 a theme supporting a particular plugin is searching for the plugin name.
 - Custom Menu: 2370 out of 2650 active themes in the directory support
 menus; applying the filter does not filter down the results significantly
 enough to be worth the space. There is also no filter for widget support,
 which is a comparable feature. We can add custom logo in its place, which
 is in core but hadn't been returned from the .org API list still.
 - Flexible Header: unclear to new users and overly specific (a subset of
 the custom header feature). Only half of custom-header themes tag
 flexible-header, but there are far more relevant features on the list that
 become lost when we have too many feature tags like this. Redundant to the
 Custom Header filter.
 - Front Page Post Form: this functionality belongs in plugins (or core),
 not themes, generally speaking. Only used by 89 of 2650 active themes in
 the directory, and it's unclear whether many of the themes using it
 actually support the feature at a quick skim though the results.
 - Microformats: very difficult for themes to actually implement fully (as
 core contains a partial implementation), and confusing to the average
 user. Most people I've observed confuse this with Post Formats. This is an
 example of a more technical tag that may be better grouped separately from
 "features".
 - RTL Language Support: this is something that the .org API should filter
 internally based on a querying site's language, not be exposed to users.
 - Threaded comments: most themes support this, and it's really a core
 feature other than styling. Less relevant to most users than most of the
 other features on the list.
 - Translation Ready: this tag is required and is more useful internally
 for the theme review team at this point. Again, language-related tags
 should be used internally for .org processing but not exposed to users.

 If there are strong objections, the GitHub commit is isolated for that
 change and can be reverted.

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