[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:
     Type:  feature request          |     Status:  new
 Priority:  normal                   |  Milestone:  Future Release
Component:  Customize                |    Version:  4.2
 Severity:  normal                   |   Keywords:  has-patch has-
  Focuses:  ui, accessibility,       |  screenshots
  javascript                         |
-------------------------------------+-------------------------------------
 == Background & History ==

 The customizer originated as a tool for previewing and customizing themes
 and as such, was closely integrated into the theme browsing experience in
 the admin (in WordPress 3.4).  Eventually, as the customizer's role grew
 to that of a framework for live-previewing any change to a site, it became
 apparent that it would benefit from a more direct way to switch themes,
 without entering the admin context. The Customizer Theme Switcher plugin
 was created, and after some refinement, merged into WordPress 4.2.
 However, while it initially included external links to install themes in
 the admin, these were eventually removed due to the jarring experience of
 unexpectedly leaving the customizer.

 Currently, there is no indication that additional themes can be installed
 when viewing available themes in the customizer. For new users, it may
 take quite a bit of time to discover the ability to install themes, via
 wp-admin, or they may give up on WordPress before making this discovery.
 This is a usability dead-end where a user's flow is disrupted in the
 process of discovering, installing, previewing, and activating themes,
 both on initial site setup and when considering a redesign.

 When the theme switcher plugin was developed, we made preliminary plans
 for a theme installation interface as a second phase of the project.
 Specifically, it would leave the "preview" context of the customizer, but
 retain the same identity in the user experience and provide cognitive
 hierarchy from the options in the various customizer sections by sliding
 in from the right instead of the left. @folletto helped develop this
 initial concept early last year.

 == Technical Constraints & Requirements ==

 There have been several technical limitations preventing theme
 installation in the customizer from being addressed previously. Most
 notably, such an interface would require "shiny" ajax-based theme
 installation, updates, and deletion, so that the user flow could
 persistently stay in the customizer themes interface rather than jumping
 to separate "installing" views. This is now possible with phase 2 of
 "Shiny Updates" in WordPress 4.6. Additionally, expansions of the
 customizer JavaScript and JS-templated controls APIs to better support
 dynamically-registered controls were needed to support theme installation
 within the customizer framework, and these were added for the customizer
 menus interface introduced in WordPress 4.3. With these technical
 constraints eliminated, theme installation in the customizer can now be
 considered without requiring significant improvements to the underlying
 themes or customizer APIs.

 The way that the customizer currently previews themes requires the
 customizer to be completely reloaded from PHP to preview a different
 theme. Ideally this will eventually change, but due to the complexity of
 redesigning the internals to make use of a theme setting, and eventually
 to adjust which theme's registered sections, settings, and controls to use
 dynamically, changes to these pieces should be explicitly out of scope for
 the user-facing flow project. The biggest usability block that this
 limitation causes is that unsaved changes are lost when the theme is
 switched. This is currently handled by prompting users with an are-you-
 sure notice in the browser before making the switch, but limitations in
 JavaScript require the loading indicator to be hidden after the user
 selects either to stay on the page or to continue to the new theme,
 causing confusion. In a new interface, this could be further mitigated by
 displaying a warning that there are unsaved changes, with an inline button
 to save and publish them, at the top of the interface, so that it is in
 the user's flow before they begin browsing themes. With transactions, a
 save draft option could also become possible in the future, allowing the
 changes to be saved without being published.

 == Previewing Themes ==

 One of the biggest challenges with theme installation in wp-admin, and
 opportunities in the customizer, is previewing themes. Currently, a
 customizer-like frame displays a preview hosted on WordPress.org, with
 limited content. Rather than opening this potentially-disorienting similar
 but different interface, the proposed flow de-emphasizes the distinction
 between installed and available themes. The primary action for available
 themes is now "Install & Preview", which installs the theme and live
 previews it in one step. Users can now see the theme on their site with
 their content and play with its options in the customizer. If they decide
 it's the wrong theme, the themes panel can be quickly reopened and another
 theme selected and previewed with no harm done. A secondary action would
 allow themes to be installed without instantly previewing, so that the
 installed themes tab can become a personal theme library of sorts, where
 users can save themes that they might want to try on their site. Installed
 themes being a tab along with the available theme headings unifies the
 previously-disorienting separation of themes and add-new themes on
 separate screens, with separate search and header (add new/upload theme)
 functionality.

 == Initial Proposal ==

 Based on the preliminary design work done by @folletto as well as the
 goals and proposals presented above, I have put together an initial
 nearly-fully-functional proposal for a new themes interface in the
 customizer. Due to the tight integration with the existing system, with
 the existing theme control and section as well as internal elements in the
 customizer manager and theme details template requiring moderate
 modifications, this needs to be completed as a patch and cannot be
 reasonably converted into a plugin and back. To counteract this challenge,
 I have completed the major structural development process already, so that
 iterations can focus on the UI, UX, accessibility, and smaller details
 that won't impact the base functionality. A list of development tasks
 leading up to this point and remaining tasks is forthcoming.

 The technical implementation continues adapting the concepts present in
 the backbone.js-based themes experience in wp-admin to leverage the
 customizer API. With the themes experience natively built on the
 customizer framework, it should be much easier for developers to improve
 and maintain the core experience in the future as well as extending the
 core experience in a structured way.

 A few notes on the initial proposal, which will be supplemented with
 visuals and a patch below:
         - The themes experience is unchanged on the top level of the
 customizer, but selecting the change theme button now opens a panel that
 fills the entire screen, as the preview is not relevant when considering a
 theme change.
         - The customizer UI identity is preserved by using similar design
 cues, such as the #eee background with white backgrounds indicating
 actionable UI, and the current theme display in the header, which matches
 the display in the customizer pane.
         - Where possible, the UI is identical to that found  in the theme
 installer in wp-admin (which would remain, of course).
         - The theme details view is unified between installed and
 available themes, with clicking on a screenshot opening the details view
 to match the admin UI.
         - Primary buttons are used where clicking them takes you away from
 the current page; secondary buttons are used elsewhere.
         - Installed themes are no longer loaded every time the customizer
 is opened, resulting in potentially significant performance improvements
 by only calling `wp_prepare_themes_for_js()` when needed. This also allows
 themes in the customizer to be fully disabled with `remove_panel( 'themes'
 )`.
         - The loading strategy attempts to balance performance with wait
 time by loading theme data from Ajax in large batches (100 themes)  and
 following up by rendering screenshots as they become visible (as the
 existing interface does).

 Note: this ticket description can be adapted for a make/core post once
 initial feedback is incorporated.

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