Improve UX/UI of enabling performance features via standalone plugins

[felixarntz]

After careful consideration, the new UI on the Performance Lab settings screen to install and activate the standalone plugins was not the right call from a UX perspective. It is confusing to find the UI to install and activate plugins replicated in that area, and it fails to convey the point of why it's there.

We should iterate on the UI, to focus it on features rather than plugins.

The standalone plugins are, in a way, just a technicality. Their goal is to deliver performance features to WordPress sites in advance of a potential future WordPress core merge. Therefore, we should have cards of features, rather than cards of plugins. Under the hood, clicking the "Enable feature" button would still install and activate the underlying plugin. But that shouldn't be the focus of the UI, and it doesn't make sense to have it broken down into two distinct tasks either (install and activate can happen at once).

We can take inspiration from how Jetpack solves this problem. Consider the below screenshot:

Most of the cards refer to other plugins, and they are conveniently installed and activated under the hood. In our case, we wouldn't need a "Learn more" since all that Jetpack exposes there is information on the different plans and pricing, which doesn't apply here. We can surface sufficient information right in the card.

Let's focus this issue on implementing an MVP solution that revises the plugin cards to become feature cards, with plugin installation and activation happening in the background. We can reuse the existing design where possible (i.e. no need for different branding or anything).

Note: The modules part of the Performance Lab screen UI is being removed as part of #1029. So this can be ignored here as it will be gone soon anyway.

[felixarntz]

For an MVP, I propose the following:

• Reduce the plugin cards so that they only show the following:
  • Feature name
  • Brief feature description (value proposition)
  • A button to activate the feature or, if the feature is already active, an indicator that it is active
• The feature name and description shouldn't be simply the content pulled from .org, but rather custom content that is more tailored to the user experience of what the feature unlocks. Some of the plugin names and descriptions may also work well for the feature names and descriptions, but we should reconsider each one to think whether we can make improvements. For example "WebP Uploads" may work better as something like "WebP format for images", or shorter "WebP images". Or "Speculation Rules" may work better as something like "Speculative preloading" or "Navigational preloading".
• Keep in mind each feature represents a plugin under the hood. But the plugin shouldn't be focused on in the UI.
  • We can hard-code the list of features, i.e. the name, description, and underlying plugin slug.
  • The logic to get information from wordpress.org can be removed.
• Clicking the "Activate" button should do the following (remember to check for all required capabilities):
  • If the underlying plugin is not installed, it should be installed and activated in one go.
  • If the underlying plugin is already installed, it should be activated.
• Similar to how Jetpack does it, we don't need to worry about deactivation in this screen. Active features (plugins) can simply show an "Active" indicator. Users that wish to deactivate the features can do so via the "Plugins" screen.
• The overall page heading and description need to be adjusted accordingly as well.

Here's a quick "mockup" of what I am proposing, simply done by removing HTML in the inspector (except for the content, which is still the original plugin content, unlike what I wrote above):

@mukeshpanchal27 @joemcgill @thelovekesh @ThierryA Let me know what you think!

[westonruter]

• The feature name and description shouldn't be simply the content pulled from .org, but rather custom content that is more tailored to the user experience of what the feature unlocks.

One concern I have here is that a site owner who enables a given feature on the plugin screen is not going to be aware that a given plugin was installed. If they then go to the plugin list table and see some additional plugin, they could get quite concerned since they never intentionally installed a plugin. Perhaps the success message for enabling a feature should still say "Installed Speculation Rules plugin" after they click "Activate Speculative preloading feature".

Also, we'll need to consider the case of what to do for read-only filesystems (e.g. Pantheon live environments) which cannot install plugins. How would this be communicated to users if it is only talking about features?

[felixarntz]

@westonruter

One concern I have here is that a site owner who enables a given feature on the plugin screen is not going to be aware that a given plugin was installed. If they then go to the plugin list table and see some additional plugin, they could get quite concerned since they never intentionally installed a plugin.

We could consider still showing the plugin names as is and only using a custom description. This is in fact how Jetpack does it. The titles are the exact product names, so there's less chance for confusion when you find a plugin of that name. That said, we could even consider renaming the actual plugins if we can think of more useful names for them. Nothing prevents us from doing that, only the slug cannot be changed, but that's fine.

Also, we'll need to consider the case of what to do for read-only filesystems (e.g. Pantheon live environments) which cannot install plugins. How would this be communicated to users if it is only talking about features?

I think we can handle that in the same way it is done right now, a disabled "Cannot activate" button. We could provide a general explanation somewhere there (maybe any time that the current user cannot install_plugins?), but that may also be overkill given that probably 99% of WordPress sites are not subject to this limitation and those that are are likely managed by developers in some capacity.

[thelovekesh]

but that may also be overkill given that probably 99% of WordPress sites are not subject to this limitation and those that are likely managed by developers in some capacity.

Yes, in most cases such infrastructure is managed by developers, but in today's time most enterprise sites are using such workflows, and editing the FS directly is not permitted, so I think we should also consider this possibility while working on this feature.

[joemcgill]

One concern I have here is that a site owner who enables a given feature on the plugin screen is not going to be aware that a given plugin was installed.

It's a reasonable concern. I think we can come up with some copy that is shown above the cards that explains that enabling these features will install and activate the plugins. I don't think we're trying to hide the fact that these are separate plugins, but just removing some of the friction and extra UI (like plugin ratings, links to the plugin home page, etc.) from the main screen. Even just hiding some of the current UI with CSS cleans things up pretty nicely (I like keeping the icons, but making them a bit smaller).

The main challenge is installing and activating in one-click, rather than installing and then requiring a second click for activation.

I think we can handle that in the same way it is done right now, a disabled "Cannot activate" button.

I would rather us show a link to the plugin page if it can't be installed directly, so people can at least know where to go get the plugins so they can install them via whatever process they need.

[felixarntz]

@joemcgill

I think we can come up with some copy that is shown above the cards that explains that enabling these features will install and activate the plugins.

Potentially. I'm not opposed to this, though it's worth noting that Jetpack does not explain that anywhere. As such, I don't think it's a concern that this activates plugins behind the scenes. The only place where it's weird, as raised above, is for scenarios where installing the plugins is not possible. My preference would be to only provide an explanation in those scenarios. For the case where permissions are available as usual, one less explanation is one less potential distraction / cognitive overhead.

Even just hiding some of the current UI with CSS cleans things up pretty nicely (I like keeping the icons, but making them a bit smaller).

+1, see https://github.com/WordPress/performance/issues/1031#issuecomment-1980033829. I think we should remove even the icons and the byline which don't really add value.

The main challenge is installing and activating in one-click, rather than installing and then requiring a second click for activation.

+1

I would rather us show a link to the plugin page if it can't be installed directly, so people can at least know where to go get the plugins so they can install them via whatever process they need.

I wonder whether we should just provide those links in any case. For instance, the "Learn more" that the cards currently show could be maintained and point to the plugin, or keep opening the overlay for the plugin as they do now. I think that also helps for transparency that the cards are referring to plugins, without providing an extra explanation.

To me the disabled activation button best indicates what is supposed to happen here usually and that this is not possible. As raised above, I do agree providing an explanation about it in that scenario would help.

[joemcgill]

I wonder whether we should just provide those links in any case. For instance, the "Learn more" that the cards currently show could be maintained and point to the plugin, or keep opening the overlay for the plugin as they do now. I think that also helps for transparency that the cards are referring to plugins, without providing an extra explanation.

I think that makes sense and keeps us from needing to add additional text above the cards.

One final question that I have is whether we keep the ability to enable/disable the features as part of each card, or if we only use the card as a way of helping users install and activate the features, and them expect them to manage activation from the plugins page from that point on. Seems like that's what Jetpack is doing currently (since we're using them as a reference in this conversation), but I don't think we need to mimic the same experience necessarily.

[felixarntz]

@joemcgill

One final question that I have is whether we keep the ability to enable/disable the features as part of each card, or if we only use the card as a way of helping users install and activate the features, and them expect them to manage activation from the plugins page from that point on. Seems like that's what Jetpack is doing currently (since we're using them as a reference in this conversation), but I don't think we need to mimic the same experience necessarily.

I don't feel strongly about it, but I think as a first iteration mimicking what Jetpack does here makes sense. It's easier to implement, and one less complexity to tackle. Therefore, as long as we don't find a good reason to include it, I think we should mirror the Jetpack behavior and only handle installation + activation in our cards.

For instance, if we wanted to also handle deactivation, it would raise a new question whether that button should only deactivate or also delete the plugin. Maybe not a terribly hard decision to make, but I'd still prefer to avoid this discussion and complexity at this point given Jetpack is a very popular plugin and does not include such a thing. It could always be added later if a need comes up.

[felixarntz]

After further consideration, the idea of having to maintain separate feature names and descriptions for each plugin is not great. If we feel that some of our plugin names and descriptions do not adequately describe their purpose, we're better off renaming those plugins and adjusting their plugin description accordingly. Let's think about those in a separate issue though as it's unrelated to actual Performance Lab engineering.

Based on this update and recent discussion above, here's the revised set of requirements:

• Reduce the plugin cards so that they only show the following:
  • Feature name (technically the "Plugin Name" from .org)
  • Feature description (technically the "Plugin Description" from .org)
  • A button to activate the feature or, if the feature is already active, an indicator that it is active.
  • The existing "Learn more" link that, when clicked, opens the overlay with .org plugin information.
• The plugin data displayed should continue to be pulled from .org, as it already is.
• Keep in mind each feature represents a plugin under the hood. But the plugin shouldn't be focused on in the UI.
• Clicking the "Activate" button should do the following (remember to check for all required capabilities):
  • If the underlying plugin is not installed, it should be installed and activated in one go.
  • If the underlying plugin is already installed, it should be activated.
• Remember to check for all required capabilities. If any of the required capabilities is missing for the user, the button to activate the feature should be disabled.
  • If the plugin is not installed, require both install_plugins and activate_plugin (with the plugin slug).
  • If the plugin is already installed, require only activate_plugin (with the plugin slug).
• If the current user cannot install_plugins, a "warning" admin notice should be permanently displayed on top of the screen: Due to your site's configuration, you may not be able to activate the performance features, unless the underlying plugin is already installed. Please install the relevant plugins manually.
  • This will rarely be the case, but on some setups with specific configurations it may happen, so a message like this is a decent MVP to inform about it.
• Deactivation functionality and UI should be removed. Active features (plugins) can simply show an "Active" indicator. Users that wish to deactivate the features can do so via the "Plugins" screen.
• The overall page heading and description need to be adjusted accordingly as well.
  • The heading should be "Performance Features".
  • The description should be removed.

[westonruter]

And if the capabilities are absent (or filesystem is read only), the "Activate" button is disabled with a notice explaining why? I was curious what Jetpack does here. Turns out they do have an issue specifically for this: https://github.com/Automattic/jetpack/issues/22982. It was supposed to have been fixed in https://github.com/Automattic/jetpack/pull/24884 where the activate button is disabled with a notice:

However, I found this is currently broken: https://github.com/Automattic/jetpack/issues/22982#issuecomment-1989049579.

• Deactivation functionality and UI should be removed. Active features (plugins) can simply show an "Active" indicator. Users that wish to deactivate the features can do so via the "Plugins" screen.

I think there should be a way to deactivate here, especially since some of these plugins may be experimental and a user may need to turn them off more often than a Jetpack user may need to turn off one of its features. As opposed to there being a "Deactivate" button, what about linking off to the plugins screen with that plugin being pre-searched for so it is the only one in the list? Then the user can decide to deactivate and/or uninstall on their own. This could be accessed via a "Manage activation" link or something similar.

[felixarntz]

@westonruter Regarding the permissions, definitely agree that we need to do something about them. Disabling the button when it's not possible to install the plugin is certainly the plan, as that's the minimum requirement. I'm also on board with displaying a notice somewhere on the page if the current user lacks the install_plugins capability. Maybe as a starting point, it could just be a non-dismissible "warning" admin notice, something like: Due to your site's configuration, you may not be able to activate the performance features, unless the underlying plugin is already installed. Please install the relevant plugins manually.

Regarding plugin deactivation, I'm not sold on this. The primary purpose of our screen is to drive adoption to those plugins, and the more UI options there are the more confusing it is. It's always a good idea to reduce the UI to the minimum needed to streamline UX. Deactivation links on some cards may distract from focusing on activation buttons on other cards. Of course it all depends on the functionality whether exposing it is worth it, but I think in this case it's not.

Last but not least, we can always enhance this later if there shows to be a need. But better to start with a streamlined MVP rather than providing something that's not needed and then removing it.

[ThierryA]

+1 to the planned described in the last comments. Keep short, keep it clean, not overloading with functionalities replicating what can be done on the plugins page (deactivate, uninstall etc.)

If we feel that some of our plugin names and descriptions do not adequately describe their purpose, we're better off renaming those plugins and adjusting their plugin description accordingly. Let's think about those in a separate issue though as it's unrelated to actual Performance Lab engineering.

Do we already have an issue for that? For instance I think we need to have individual easily recognizable as part of the PL suit (ala Jetpack), for example with a "PL" or "Performance Lab" prefix in the name. If that is the case, we may need to strip it from the modules name in the PL hub page (which I believe is what Jetpack does too). The striping part would be a requirement to add to this issue in this case for instance.

[westonruter]

@ThierryA Yes, see #1046.

[felixarntz]

@mukeshpanchal27 Feel free to start engineering on this. I have updated https://github.com/WordPress/performance/issues/1031#issuecomment-1989043559 to incorporate the notice in case install permissions are lacking, so we can go with the requirements from that comment for the PR.

Of course small tweaks or additions can always be considered as part of the PR and review process.