Feature Proposal: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer

This is the feature merge proposal for the new themes experience in the customizer introduced with #37661. Here’s an overview of the current proposed UI:

Customizer themes design and user flow mockup

Customizer themes design and user flow mockup by @folletto.

A theme is the most fundamental aspect of customizing a site. This project seeks to unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly in the customizer.

Walkthrough of the latest patch on #37661.

Walkthrough of the latest patch on #37661.

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 wp-admin when it was introduced in WordPress 3.4. The theme browser and installer were rewritten in WordPress 3.8 and 3.9, respectively, offering a fast JavaScript-based way to explore, install, and switch themes.

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 wp-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, the team 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. @folletto helped develop this initial concept in early 2015.

Technical Constraints & Requirements

There have been several technical limitations preventing theme installation in the customizer from being addressed previously. Most notably, such an interface requires “shiny” ajax-based theme installation, updates, and deletion, so that the user flow can 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 fully fleshed out for the customizer menus interface introduced in WordPress 4.3. With these technical constraints eliminated, theme installation in the customizer is now possible without additional significant improvements to the underlying themes or customizer APIs.

The customizer must currently be completely reloaded from PHP to preview a different theme. To perform a theme switch without a reload, theme-defined settings, sections, and controls would need to be updated dynamically with JavaScript. While the customizer internals have been working toward making this possible for some time, significant work remains to make inline theme switches possible. Therefore, changes to this part of the theme-switching workflow are out of scope for the current project, which focuses on the user-facing flow.

The biggest usability block that this limitation causes is that unsaved changes are lost when the theme is switched. Unsaved changes are currently handled by prompting users with an are-you-sure notice in the browser before making the switch. Unfortunately, limitations in JavaScript require the loading indicator to be hidden after the user decides to stay on the page or to continue to the new theme, causing confusion. In the new interface, this is 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. With customize changesets (transactions) (#)30937, a “save draft” option could also become possible in the future, allowing changes to be saved (potentially automatically) without being published between theme previews.

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 any theme on their site with their content and play with its options in the customizer in one click. If they decide it’s the wrong theme for their site, the themes panel can be quickly reopened and another theme selected and previewed with no harm done. A secondary action allows 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 filter along with the available theme headings unifies the previously-disorienting separation of themes and add-new themes on separate screens, with confusingly-separate search and header (add new/upload theme) functionality.

Proposed Themes Interface

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 project was implemented as a patch and cannot be reasonably converted into a plugin and back. The patch has been available on trac for six+ weeks, with iterations continuing to improve and polish the new experience.

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 highlights of the proposed details:

  • 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 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 UI diverges somewhat from what is found in the theme installer in wp-admin (which will remain), particularly around the filters.
  • The theme details view is unified between installed and available themes; clicking on a screenshot opens the details view to match the admin UI.
  • Primary buttons are used where clicking them takes you away from the current page (ie, for previews); secondary buttons are used elsewhere.
  • 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).

Usability Testing

Four usability tests have been conducted so far. The full test screencasts are available on Make/Design, alongside key takeaways. These tests expose a lot of largely-known issues with themes and the customizer in general, but did not reveal any significant issues with the proposed new theme browser. Because the tests were conducted in-person with a limited set of volunteers, additional testing with a broader user base would be ideal.

There has been design feedback since the user testing was conducted, resulting in some significant changes. @karmatosed has volunteered to coordinate additional testing in the next week to verify that the changes haven’t introduced usability regressions, and to test with a broader audience. Check out the call for user testing on make/design to help out here.

A visual record on a phone of the revised design has been posted on make/flow.

Extensibility

Because the new interface is built entirely on the customizer API, third-party plugins should now be able to integrate much more easily. This means that other theme marketplaces (including commercial themes) could realistically be browsed (and maybe even installed) from within WordPress, while leveraging the core UI exactly.

The presentational flexibility is available via the customizer API (with custom theme sections for other theme sources, and theme controls for individual themes), but there are likely some gaps in the ability to do this seamlessly in the internals. If anyone is interested in building this sort of functionality, please evaluate whether any additional hooks are needed so that they can launch alongside the new feature.

Review and Approval

In addition to a general core approval of this proposal, the following sign-offs are required before the feature could be approved for merge, based on the applicable elements of this list:

  • Flow (and mobile) review (see also an initial post)
  • Docs review
  • Security audit
  • Polyglots/i18n review
  • Design/UX review – tentative approval has been provided from @karmatosed and @folletto (with additional input from others in last week’s design meeting) with an expectation that minor adjustments will continue to be required. General design feedback is still welcome, but major changes are unlikely to be feasible at this point.
  • Accessibility review – @afercia completed an initial review, with the issues fixed in a subsequent patch. A comprehensive final review would be a good idea as well, since there have been significant design changes.
  • Code review – to be handled by @westonruter once the patch is otherwise deemed “ready” based on review from other teams.

To test, update to latest trunk and apply the latest patch on #37661. On your test site, open the customizer and “change” the theme. Try out the various filters, browse themes, and install and preview them. Also test the inline update and deletion functionality.

To meet the feature merge deadline for 4.7 (10/19), reviews from various teams and any corresponding iterations need to be completed by October 12th, leaving a week for final code review and commit. General feedback and specific reviews and action items should be provided as comments on this post.


Update: this feature was merged in 4.9.

#4-7, #4-9, #customize, #proposal, #shiny-updates, #theme-switcher, #themes

Customizer Theme Switcher Feature Plugin Merge Proposal

Ticket: #31303

Customizer Theme Switcher brings theme-browsing and theme-switching functionality into the Customizer. By integrating themes directly into the Customizer, live-previewing workflows are greatly simplified, and the relationship between themes and theme/site options is clarified for the user.

This plugin represents a significant step in moving all “Appearance” functionality into the Customizer, following Widgets. The future roadmap includes Menus, Theme-Install, and iterations on widgets that would allow the Customizer to entirely replace those admin screens for most users. Because the Customizer Theme Switcher plugin does not address theme-install, the admin page (themes.php) is fully intended to remain in use for now. We are proposing to redirect the front-end “Themes” link (in the admin bar) to the Customizer, as was done for widgets in 4.1.

Technical Overview

Customizer Theme Switcher is primarily about adding new UI for existing functionality using existing APIs, rather than introducing new functionality. The plugin operates entirely off of the WordPress 4.1 Customizer API, leveraging the new JavaScript API in particular. Themes is a custom section (that acts kind of like a panel). Each theme is a custom Customizer control.

The code is heavily Backbone.js-inspired, leveraging JS-heavy portions of the Customizer API to do things like underscore JS templates for rendering theme data. Most of the code is directly adapted from the Backbone-driven themes.php system (and the theme data is retrieved with existing functions), but things like the search/filter are written from the ground up to leverage the Customizer API (in that case, conditionally activating/deactivating controls).

In keeping with the goal to avoid back-end functionality changes, theme-switches are accomplished simply by leveraging the existing ability to pass a theme as a URL query arg when loading the Customizer; ie, the Customizer is simply reloaded to preview a different theme. Loading overlays are leveraged to make this process seem more instant. Unrelated 4.2 core work around Customizer Transactions could potentially improve how this works.

Core Changes & Merge Implementation Details

As outlined in the plugin’s readme there are several proposed technical and user-oriented changes that are best done as core patches (mostly in the merge patch):

UX

  • Remove #customize-info for theme previews.
  • Change front-end admin bar Themes link to point to themes in the Customizer (deep-linked).
  • When a new theme is activated, go to the home page (front end), not the themes admin.
  • If user doesn’t confirm that they want to leave unsaved changes, remove the customize-loading body class (requires core patch).

Code

  • Move custom section and control to class-wp-customize-control|section.php in wp-includes.
  • Merge all CSS into customize-controls.css, scope to .wp-customizer.
  • Move .themes-panel-back to the Customizer header, adjust JS accordingly.
  • Merge JS into customizer-controls.js, after the respective object types.
  • Merge customize_themes_template() into wp-admin/includes/theme.php, at the very end. Make sure that this file is included at the appropriate time as needed when adding the Customizer controls.
  • Merge remaining PHP (all in Customize Register callback) into register_controls() in class-wp-customize-manager.php.

User Testing

@designsimply has run four usertesting.com tests (see links in #core-customize), and we haven’t really seen any ongoing issues with the actual theme switcher. It has been difficult to get users to follow our instructions, but when they have used the themes-in-Customizer UI, the interactions have been fairly seamless and as-intended. Further testing could be beneficial after merge, but we think that in-person testing and feedback is generally going to be more effective for this particular plugin.

Outstanding Issues

The exact handling of the themes header display still needs some work – the backwards-sliding works well but the arrows to indicate it don’t. @folletto opened a ticket on core trac to work through some alternative options. Most of the accessibility issues have been fixed as well (@afercia please let me know if I’ve missed any), with the exception of the Themes section header, which will happen along with the UI changes there for everyone.

Future Plans

A future phase of this project will explore integrating theme-install in the Customizer and minimizing the distinction between installed and available themes. Due to the larger UI and UX changes proposed with that effort, we’ve decided to hold off on theme-install for now so that the basic theme-switching functionality could be built on a reasonable timeline for 4.2. This is similar to the manner in which the “THX” feature plugin team re-did themes in 3.8 and theme-install in 3.9.

#4-2, #customize, #feature-plugins, #merge, #proposal, #theme-switcher, #themes

Customizer Theme Switcher Update – 2/2

We’ve made lots of progress in the past week and will be holding another meeting tomorrow, Tuesday February 3 2015 16:00 UTC, in #core-customize Slack. The accessibility team did an extensive review and we’ve addressed nearly all of the issues that can be fixed in the plugin (big props to @afercia especially for reviewing and patching some of the issues). I made several core tickets (some with patches, some good-first-bugs) for some of the other issues that came up during the review.

@designsimply and @vizkr have been working on formal and informal user tests as well. It’s been a little tricky to try to nudge users in the direction of the Theme Switcher in the Customizer without explicitly asking them to change the theme, but they haven’t had any negative feedback or expressed that having themes in the Customizer felt at all out of place. We’ve made a couple of minor adjustments both to the plugin (improving the filter to search for tags without hyphens) and the prompts, and additional tests are in-progress. We’d like to encourage anyone that can to do informal in-person testing, asking for feedback on the workflows and/or comparing the themes admin screen to themes in the Customizer.

Our biggest remaining decision is whether to change the title of the “themes” section in the Customizer. Currently, it’s “Theme: Current Theme”. Open to suggestions here; we’ll tweak it for screen readers regardless if it works for everyone else as-is, but I’m not convinced that it’s the most discoverable option currently.

Here’s an agenda for the meeting:

  • Usertesting.com testing update – @designsimply
  • Theme section heading title discussion
  • Informal testing/feedback updates – anyone
  • Accessibility updates: ready for (or do we need) another round of testing for the plugin? – @afercia
  • Outstanding issues – anyone
  • Final proposal and core patch/merge plan and timing – @MarkJaquith, me, @DrewAPicture

#customize, #theme-switcher, #themes

Customizer Theme Switcher Update

The Customizer Theme Switcher feature-plugin brings theme switching into the Customizer. This project aims to clarify the relationship between themes and theme options by introducing a themes “panel” (it’s actually a custom section since it contains controls, not a multi-level hierarchy of sections and controls) to the Customizer. The themes panel slides in from the left instead of the right, implying a hierarchy of:

  1. Themes – change the entire layout of the site
  2. Theme/site options – tweak various options (default view)
  3. Panels – edit larger groups of site appearance options, such as Widgets and Menus

Essentially, the phase of the project proposed for WordPress 4.2 (and that exists in the plugin currently) brings the “THX38” theme browsing experience into the Customizer. Installed themes are browse-able directly in the Customizer controls panel, and have a details modal like the admin page. Functionally, theme-switching is accomplished by reloading the Customizer to live-preview a different theme. @westonruter is working on several related improvements that could further streamlining the experience from a technical perspective, but this feature plugin is focusing on the switching UI, with other improvements considered “nice to have”. @folletto and I have also started planning a second phase of the project for a future release that would also address installing new themes, and simplifying the distinction between installed and available themes. @designsimply is currently in the process of user-testing the plugin.

Get Involved

We’ll hold a meeting in #core-customize Slack to discuss the progress of the plugin this Tuesday, January 27, 2015 16:00 UTC, and continue at that time weekly as needed at that time. Development is happening directly in the WordPress.org plugins repo – I’ll give commit access to anyone interested in contributing code. Outstanding issues are noted below, but the plugin is generally ready for review of code, inline-docs, design, and accessibility (with each of those being theoretically good-to-go in the plugin). Note that the plugin can’t really work on mobile because the Customizer doesn’t really work on mobile, see #28784 (great 4.2 candidate if it gets a patch).

Known issues (see also a list of core merge notes in the plugin’s readme):

  • Animation closing the themes panel is broken (see commented-out CSS) (@celloexpressions)
  • Persist “return” & “url” URL parameters in the switch-themes links (@celloexpressions)
  • Don’t show the loading animation if there are unsaved changes to avoid getting stuck. Actually fixing the underlying issue requires a minor core patch. (@DrewAPicture)
  • Break out of the customize.php iframe if the Customizer was loaded with the customize-loader script (@celloexpressions)
  • PostMessage setting transport may not be working immediately after switching themes, cause unknown (@celloexpressions)

#customize, #theme-switcher, #themes, #thx38