Shiny Updates v3 Kickoff Chat

While the biggest chunk of Shiny Updates v2 was merged into WordPress 4.6, there were still plenty of ideas that didn’t make it in time. I think it would be worthwhile to bring more shininess to WordPress 4.8 or 4.9. Regular chats have been dormant for a while, but I’d like to continue them starting Wednesday, 19 October 2016, 17:00 UTC in the #feature-shinyupdates Slack channel.

Topics for the first chat will include a brief update on current shiny updates bugs in WordPress core and the planned goals for Shiny Updates v3 (e.g. update-core.php). Some of the ideas can be found on GitHub.

Now is a great time to get involved and help making WordPress updates even more shiny. Please come join us next week and contribute to the continuing abolishment of The Bleak Screen of Sadness™.

#feature-projects, #shiny-updates

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.

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

Shiny Updates in 4.6

After being approved for a partial merge, Shiny Updates V2 was added to WordPress core in [37714]. Thanks to that change, updating as well as installing and deleting plugins and themes has become much easier for users. With the exception of the wp-admin/update-core.php screen, those actions are now all performed via AJAX, avoiding what we internally called The Bleak Screen of Sadness.

Visual Changes

If you wanna see Shiny Updates in action, check out the merge proposal post which contains screenshots and a video.

Proposal: More Shiny Updates

One big user facing change is about search: There is now an AJAX search on both the Installed Plugins screen as well as the Add New Plugin screen, this means the search results change as you type, drastically simplifying your workflow.

Under The Hood

The JavaScript responsible for shiny updates (enqueued via the 'updates' handle) has been completely revamped to improve the UX across the board by displaying better progress updates and error messages.

If you’re in any way relying on this JavaScript, you will notice that wp.updates.update() has been renamed to wp.updates.updatePlugin(). The same goes for the plugin update success / error callbacks.

In addition to that, callbacks are now passed as arguments to the wp.updates.updatePlugin(), wp.updates.updateTheme() and the like, e.g. wp.updates.updatePlugin( { success: wp.updates.updatePluginSuccess, … } ). The whole code is thoroughly documented.

However, you probably won’t ever need to call these functions directly. Instead, you might wanna hook into the custom jQuery events that are being triggered throughout the code, like 'wp-plugin-install-success'.

Shiny Updates V3

While the last iteration of Shiny Updates has been merged into core, development of the plugin continues to happen on GitHub. If you’re running the Shiny Updates feature plugin on your site, everything will continue to work when using 4.6.

The current version of the plugin now only contains things that didn’t make it into 4.6 and is our base for further development. Feel free to keep it running and provide feedback!

#4-6, #dev-notes, #shiny-updates

Shiny Updates V2: Partial Merge Approved

During the extra meeting held today, Monday June 13th, 2016 at 13:00 MDT, Shiny Updates V2 was approved for a partial merge to core. The changes that will be merged are install, update, and delete for themes and plugins in single and multisite.

This affects:

  • plugin.php
  • plugin-install.php
  • import.php
  • themes.php
  • themes-install.php
  • The “more-detail” modals in those screens

The parts that will not be merged are the changes to update-core.php. The team now has time until Wednesday, June 15th 23:59 UTC to get the core patch committed.

Congratulations and thanks to the Shiny Updates team for all the hard work they’ve put in this release. Most notably @obenland, @swissspidy, and @mapk. Thanks to everyone who reviewed, helped test, or otherwise contributed to Shiny Updates V2, we hope to see you involved with Shiny Updates V3. 🙂

The full chat log is located here: https://wordpress.slack.com/archives/core/p1465844429000062

#4-6, #feature-projects, #shiny-updates

Additional meeting to consider the Shiny Updates plugin for merge

As announced in last week’s dev chat we’ll have an additional meeting to consider the Shiny Updates plugin for merge today, June 13th, 2016 at 19:00 UTC.

Following a summary of the merge discussion from June 8th.

Merge Criteria

A plugin exists in the official WordPress plugin repository, is updated regularly, and is used/tested by the community.

✅ https://wordpress.org/plugins/shiny-updates/

Weekly chats are taking place on Slack, and the feature lead is attending the weekly core dev chat.

✅ Meetings took place in #feature-shinyupdates.

A kickoff post and regular update posts are published publicly, tracking the progress and major decisions of the feature plugin.

✅ Kickoff post at https://make.wordpress.org/core/2016/04/18/shiny-updates-chat/ and update posts at https://make.wordpress.org/core/tag/shiny-updates/

The feature works in all of the browsers that WordPress officially supports.

✅ IE8+ and other current browsers were tested

Touch devices can use the entire feature with no hindrance, with visual records for major flows through all new interfaces on all devices posted on Make/Flow. Make sure it functions properly on mobile by asking the Flow team to review it.

✅ https://make.wordpress.org/flow/tag/shiny-updates/

Visual records comparing old flow with new flow are provided for any feature that changes or replaces existing interfaces.

The code conforms to the WordPress coding standards.

✅ Assured through the use of a code sniffer and Travis CI: https://travis-ci.org/obenland/shiny-updates

Similarly, the code is well-tested, and has unit tests.

✅ QUnit tests: https://github.com/obenland/shiny-updates/blob/master/tests/tests.js, closed issues: https://github.com/obenland/shiny-updates/issues?q=is%3Aissue+is%3Aclosed

The code is well-documented. (Be sure to ask the Inline Docs team to review it.)

🅾️ @drewapicture wasn’t around but @obenland said that “he’d like to wait with the review until there is a core patch, and he pinged me this morning saying he wanted to review it today”.

The code follows the plugin security best practices, and has undergone a security audit.

🅾️ Only a rough audit was done. @aaroncampbell was asked to look at it.

The user interface/experience has been tested through user testing, and appropriate feedback was incorporated. (Be sure and ask the Design team to review it.)

🅾️ @mapk was the design lead and provided help with design questions. Turns out there was no review for the whole project, only comments on GitHub issues and talks in Slack. A review was requested on May 16th.

The design is fully responsive, displaying properly on any mobile device, and using graphics that are ready for hi-dpi/retina displays.

✅ https://make.wordpress.org/flow/tag/shiny-updates/

HTML validates to the proper doctype.

The code has all of the proper hooks in place for localization. (Be sure to ask the Polyglots team to review it.)

WordPress continues to function, and the feature is still usable, with JavaScript turned off.

✅ That’s true, except for the Update All button.

The feature can be used with just a keyboard.

✅ Confirmed by @aferica.

Any required accessibility support has been added, including (but not limited to) off-screen text, ARIA, and JS-assisted. (Be sure to ask the Accessibility team to review it.)

A merge proposal has been published on the Make/Core blog once the plugin is ready.

✅ https://make.wordpress.org/core/2016/06/02/proposal-more-shiny-updates/

 

More Feedback

  • @jorbin: The QUnit tests should be merged with the existing tests.
  • @michael-arestad started with a design review during the chat.
  • @helen asked: “Given that there was a goal of really polishing the plugin and that it literally has the word “shiny” in the name, how much changing post-merge are people comfortable with?”
  • @mikeschroder raised a concern on error specificity which is something that he’d consider to be a big support problem.
  • @jorbin asked: “Who is comfortable merging after the unit test changes unless something the team working on shiny updates team or security team or design team considers major comes up?” @jorbin, @joemcgill, @azaozz, @jeremyfelt, @mapk, @markjaquith, @mikeschroder, @ocean90, @boonebgorges, @karmatosed, @ipstenu, @afercia, @rachelbaker, and @paulwilde reacted with a 👍.
  • @helen objects: “This seems a little like flexing to favor a merge – that poll is actually saying “this is not ready for merge until XYZ”. I am not saying that that is necessarily a terrible thing, but per my question about what amount of change people (project contributors, committers, etc.) are comfortable with, I am wondering if there is a bit of shifting of mindset from “ideal feature process” to “let’s get it in”.

 

With 3 teams having a blocker and at least one person who needs more time to review it was decided to set a new deadline for feedback: Monday, June 13th 2016 at 12:00 UTC. An additional meeting will be held on Monday, June 13th 2016 at 19:00 UTC.

#4-6, #shiny-updates

Shiny Updates Update 6/12

Three more pull requests were opened, 1) to add basic validation of ajax requests, 2) to swap the term Core with WordPress in updates-core, and 3) to only show the compatibility note in upgrade-core if an update is not 100% compatible.
The PR to add the ability to activate a Theme after installation was merged and the feature added.

#4-6, #shiny-updates

Shiny Updates Update 6/11

Both were requested in the design review.

#4-6, #shiny-updates

Shiny Updates Update 6/10

#4-6, #shiny-updates

Shiny Updates Update 6/9

We’ll be posting daily updates until the approval meeting on Monday.

#4-6, #shiny-updates

Proposal: More Shiny Updates

The Bleak screen of Sadness™ 😢 that users encounter when installing/updating/deleting plugins or themes is a terrible experience WordPress users. It’s not timely anymore and doesn’t reflect the values WordPress strives to adhere to. Instead, WordPress needs a simpler and more straight forward experience when installing, updating, and deleting items.

That’s why the Shiny Updates Team is proposing a merge of the Shiny Updates plugin into WordPress 4.6 💥. We’re eager to hear feedback from WordPress core contributors and users alike.

Old plugin install process

Existing plugin install process, showing The Bleak Screen of Sadness.

Purpose & Goals

The Bleak screen of Sadness™ is disruptive to user workflows, pulling them out of the context of plugins or themes, and dropping them into a screen filled with technical details that most users don’t care about or don’t understand. Shiny Updates deals with these details behind the scenes, maintaining the context of the triggered actions and leaving users with clear actions and results.

This caters to two core principles of WordPress, designing for the majority, and striving for simplicity. Users don’t really care about the internal process of installing or updating themes and plugins. Listing out these technical steps for them is unnecessary at best.

With Shiny Updates these actions also don’t require a page reload anymore, which creates a simpler workflow without context changes and lets users achieve their goals of an enhanced WordPress experience quicker.

We also revamped the whole Dashboard -> Updates page to improve simplicity and make the process of updating translations and WordPress core shiny as well. 🎉

Project Background

Whether it was through the update mechanism available under Dashboard -> Updates or the automatic updates introduced in version 3.7, WordPress has always been encouraging users to update their sites to the newest versions.

Plugin updates have been made shiny in WordPress 4.2, but now we want to extend this to other areas as well. Shiny Updates v2 improves the update process for themes, translations and even WordPress itself, as well as install and delete workflows for plugins and themes.
As of today, the plugin has been downloaded about 8,000 times and is actively installed on over 1,000 WordPress sites. We’ve gotten input from many users and core committers through GitHub and during regular meetings in the #feature-shinyupdates.

You can read more about the shiny updates flow with various visual records on make/flow, where we also shared results of the various user tests we did. Doing multiple rounds of user testing has really shaped the whole project and helped us refine the plugin and improve the overall usability of installing updates in WordPress.

Implementation Details

Shiny Updates builds upon the shiny plugin updates feature already existing in core, which basically consists of some JavaScript and Ajax callbacks for updating plugins in the background. As such, it can easily be extended by the new JavaScript parts of Shiny Updates. All new JavaScript functionality is available under the wp.updates umbrella.

Here’s it looks like in action:

In addition to that, we propose a revamped updates overview under Dashboard -> Updates. It’s simpler, more elegant, more shiny:

Shiny Updates Table

With Shiny Updates, the Dashboard -> Updates page gets a much needed overhaul

Relevant Core Tickets

Merging Shiny Updates into core would resolve a long list of outstanding trac tickets related to updates, including #31529, #31530, #31531, #31532, #31534, #31535, #31773, #33637 and #35032. All tickets related to Shiny Updates can be found here.

Remaining Issues

There are a few remaining bugs on GitHub, which will be resolved by Friday, June 3rd. Since the revamped updates table relies on plugin icons being returned by the Plugins API, the API needs to be changed as part of the plugin directory update. The new directory will launch well before the 4.6 release, so that shouldn’t be a big deal. As a bonus, this change would also enable us to fix #30186.

Contributors and Feedback

This is a proposal and is subject to revision based on your feedback. If you haven’t already tried out the plugin, please download and install it from WordPress.org or the comfort of your WordPress admin. You can review the current code and leave feedback at the project’s GitHub repository or in #feature-shinyupdates on Slack.

Thanks a lot to everyone who has been contributing to this plugin since its inception, especially @obenland for leading this project, @adamsilverstein for his numerous contributions, @mapk for helping with testing and UX, and @ocean90 for giving valuable feedback despite being super busy with leading 4.6.

So far we’ve received positive feedback from different core teams like the accessibility and design teams, and we have reached out to @drew who will review the docs once a core patch is ready.

#4-6, #feature-plugins, #merge, #proposal, #shiny-updates