[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:  normal                   |   Milestone:  4.8.1
Component:  Customize                |     Version:  4.2
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-           |     Focuses:  ui, accessibility,
  screenshots has-user-testing has-  |  javascript
  ux-feedback                        |
-------------------------------------+-------------------------------------

Comment (by celloexpressions):

 @melchoyce your message in Slack implied that [comment:150] provides a
 path forward, but I'm still waiting for direction here. I see the current
 iteration of the GitHub branch as ready to be merged at any time. If
 anyone disagrees with that assesment, please provide the following so that
 we can proceed with potential changes:
 - Analysis of the previously-published usability testing identifying areas
 needing improvement, OR new usability testing identifying problems with
 the current design approach
 - Specific problems with the current UX design based on theoretical
 concepts, and proposed changes
 - Ideas for improving the theme browsing model within the capabilities of
 the API (meaning, we work with the tags we have/that are managed by the
 theme review team, but we can explore alternate sorting and other
 capabilities that theme-install.php doesn't use)
 - Alternate design concepts that rethink the layout/design entirely, with
 reasoning for why we should consider moving in that direction. We
 previously did this, but I probably still prefer the initial design
 concept - if we want to do another full redesign we need some certainty
 that the end result represents an improvement.

 Personally, I'd prefer a design approach that filters themes first by
 subjects, then by features, and also prioritizes search. The latest and
 popular views could become sort options rather than distinct views (which
 the API supports). The separate favorites and featured views would be
 removed, as they provide little value to a majority of users (featured is
 just random themes currently). I'm skeptical of the concept to preserve
 the customize pane as a sidebar when browsing themes. I don't know that
 making these sorts of changes is necessary at this point, since ultimately
 we need to get something functional into the core experience and can
 iterate from there as the customizer evolves as a whole. But if the above
 points can be explored by those that don't think the current approach is
 viable, we could have a path forward here.

 Important considerations:
 - This project represents a significant performance improvement for the
 entire customizer on every load, by only loading theme data when it's
 needed.
 - Accessibility and the mobile experience are carefully refined in the
 current approach, and have been documented with extensive team reviews and
 on make/flow.
 - New users that start their experience in the customizer currently may
 not be aware of the variety of themes available to them. This can result
 in users giving up on WordPress far earlier than they should.
 - This project introduces the infrastructure necessary to offer theme
 functionality within the live preview framework regardless of what the
 feature looks like, and can easily adapt to different design concepts
 within that technical framework over time.

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