-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve UX/UI of enabling performance features via standalone plugins #1031
Comments
For an MVP, I propose the following:
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! |
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? |
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.
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 |
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. |
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.
+1, see #1031 (comment). I think we should remove even the icons and the byline which don't really add value.
+1
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. |
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. |
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. |
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:
|
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: Automattic/jetpack#22982. It was supposed to have been fixed in Automattic/jetpack#24884 where the activate button is disabled with a notice: However, I found this is currently broken: Automattic/jetpack#22982 (comment).
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. |
@westonruter 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. |
+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.)
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. |
@mukeshpanchal27 Feel free to start engineering on this. I have updated #1031 (comment) 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. |
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:
![Screenshot 2024-03-05 at 7 19 07 PM](https://cdn.statically.io/img/private-user-images.githubusercontent.com/3531426/310349453-c9d063ca-05f1-41db-adb8-24659e98fa1a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjI5MzIxMDIsIm5iZiI6MTcyMjkzMTgwMiwicGF0aCI6Ii8zNTMxNDI2LzMxMDM0OTQ1My1jOWQwNjNjYS0wNWYxLTQxZGItYWRiOC0yNDY1OWU5OGZhMWEucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgwNiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MDZUMDgxMDAyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTgxNjU0YTMxYTVlMjRkYjJmZDI4NDFkMTU2ZjdlMGQwNjc5MDFiYzNiOWE4ODhkN2JiYzQ0Y2U4NjVhNTQ1OCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.lGAYuPpgfMeXFxrHDn3HAYyL0_lFAJqBpmlCLln03zQ)
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.
The text was updated successfully, but these errors were encountered: