Repository navigation
Review current plugin names and their descriptions for their accuracy and helpfulness #1046
Description
See #1031 (comment): We should revisit our current standalone plugins' names and descriptions for how accurate and useful they are. In particular, we should consider the following:
- Plugin names and descriptions are used to describe features within Performance Lab.
- Our plugins are not products. They are features for WordPress core. As such, we should avoid plugin names that sound too much like a product / brand name, and instead simply find a good name that clarifies the feature. Example: "Optimization Detective" doesn't clarify what it does.
- Additionally, we should avoid technicalities in the name, to make them intuitive. Example: "WebP Uploads" would probably be better as something like "WebP Images" (the term "Uploads" is only used because of Media Library jargon). "Speculation Rules" should probably be something like "Speculative preloading" because the Speculation Rules API is a technical detail.
- Plugin descriptions should not mention the word "plugin". They can just start with a third-person verb (e.g. "Adds xyz" or similar).
For reference, here are our current plugin names and descriptions to review:
- Auto-sizes for Lazy-loaded Images
- This plugin implements the HTML spec for adding
sizes="auto"to lazy-loaded images.
- This plugin implements the HTML spec for adding
- Dominant Color Images
- Adds support to store the dominant color of newly uploaded images and create a placeholder background of that color.
- Optimization Detective
- Improves accuracy of optimizing the loading of the LCP image by leveraging client-side detection with real user metrics. Also enables output buffering of template rendering which can be filtered.
- Performant Translations
- Making internationalization/localization in WordPress faster than ever before.
- Speculation Rules
- Uses the Speculation Rules API to prerender linked URLs upon hover by default.
- WebP Uploads
- Creates WebP versions for new JPEG image uploads if supported by the server.
Let's brainstorm.
cc @adamsilverstein @joemcgill @mukeshpanchal27 @swissspidy @westonruter
Activity
westonruter commentedon Mar 12, 2024
Further, we discussed ideally not including WebP here either, so it would be rather "Modern Images".
To be fair, to myself, I did do quite a bit of outreach including a survey to come up with this name. Naming things is hard. Ultimately, if the feature is intended to get merged into WordPress core, the name shouldn't matter so much. (No cool name is needed for branding.) On the opposite extreme of slick branding the plugins could be named with random words, like "Apple Rain Hammer", as Glitch does. That goes too far as the names need to have association with the feature.
What matters is having a unique and concise project name that collaborators can refer to, while also having a name that end-users will be able to associate with the functionality (hopefully understood from the name itself). But perhaps this cannot be achieved in a single name. Indeed, Jetpack does not. It has multiple ways to refer to the same functionality: the name, short description (i.e tagline), and the long description. The name is short and easy to remember, and the tagline reminds the user of what it does. I think that's what we should follow as well. The names can err on the side of being generic, e.g. "Modern Images", and the descriptions can further clarify and evolve as aspects come and go while being merged into core.
Aside: I found that Jetpack CRM's plugin slug is zero-bs-crm. So we shouldn't feel shy about the slug being one thing but the name being something else (e.g. renaming WebP Uploads to Modern Images but leaving the slug
webp-uploads).Jetpack Feature Data
Raw JSON
[ { "slug": "anti-spam", "plugin_slug": "akismet", "plugin_names": [ "akismet/akismet.php" ], "name": "Akismet Anti-spam", "title": "Jetpack Akismet Anti-spam", "description": "Stop comment and form spam", "long_description": "Save time and get better responses by automatically blocking spam from your comments and forms." }, { "slug": "backup", "plugin_slug": "jetpack-backup", "plugin_names": [ "jetpack-backup/jetpack-backup.php", "backup/jetpack-backup.php", "jetpack-backup-dev/jetpack-backup.php" ], "name": "VaultPress Backup", "title": "Jetpack VaultPress Backup", "description": "Save every change", "long_description": "Never lose a word, image, page, or time worrying about your site with automated backups & one-click restores." }, { "slug": "boost", "plugin_slug": "jetpack-boost", "plugin_names": [ "jetpack-boost/jetpack-boost.php", "boost/jetpack-boost.php", "jetpack-boost-dev/jetpack-boost.php" ], "name": "Boost", "title": "Jetpack Boost", "description": "Speed up your site in seconds", "long_description": "Jetpack Boost gives your site the same performance advantages as the world\u2019s leading websites, no developer required." }, { "slug": "creator", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Creator", "title": "Jetpack Creator", "description": "Create, grow, and monetize your audience", "long_description": "Create, grow, and monetize your audience with powerful tools for creators." }, { "slug": "crm", "plugin_slug": "zero-bs-crm", "plugin_names": [ "zero-bs-crm/ZeroBSCRM.php", "crm/ZeroBSCRM.php" ], "name": "CRM", "title": "Jetpack CRM", "description": "Nurture your contacts to grow your business", "long_description": "All of your contacts in one place. Build better relationships with your customers and clients." }, { "slug": "extras", "plugin_slug": "jetpack", "plugin_names": [], "name": "Extras", "title": "Jetpack Extras", "description": "Basic tools for a successful site", "long_description": "Secure and speed up your site for free with Jetpack's powerful WordPress tools." }, { "slug": "jetpack-ai", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "AI", "title": "Jetpack AI", "description": "Experimental tool to add AI to your editor", "long_description": "Jetpack AI Assistant brings the power of AI right into your WordPress editor, letting your content creation soar to new heights." }, { "slug": "protect", "plugin_slug": "jetpack-protect", "plugin_names": [ "jetpack-protect/jetpack-protect.php", "protect/jetpack-protect.php", "jetpack-protect-dev/jetpack-protect.php" ], "name": "Protect", "title": "Jetpack Protect", "description": "Powerful, automated site security", "long_description": "Protect your site and scan for security vulnerabilities listed in our database." }, { "slug": "scan", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Scan", "title": "Jetpack Scan", "description": "Powerful, automated site security", "long_description": "Automatic scanning and one-click fixes keep your site one step ahead of security threats and malware." }, { "slug": "search", "plugin_slug": "jetpack-search", "plugin_names": [ "jetpack-search/jetpack-search.php", "search/jetpack-search.php", "jetpack-search-dev/jetpack-search.php" ], "name": "Search", "title": "Jetpack Search", "description": "Custom instant site search", "long_description": "Help your site visitors find answers instantly so they keep reading and buying. Great for sites with a lot of content." }, { "slug": "security", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Security", "title": "Jetpack Security", "description": "Comprehensive site security, including VaultPress Backup, Scan, and Akismet Anti-spam.", "long_description": "Comprehensive site security, including VaultPress Backup, Scan, and Akismet Anti-spam." }, { "slug": "social", "plugin_slug": "jetpack-social", "plugin_names": [ "jetpack-social/jetpack-social.php", "social/jetpack-social.php", "jetpack-social-dev/jetpack-social.php" ], "name": "Social", "title": "Jetpack Social", "description": "Auto-publish to social media", "long_description": "Promote your content on social media by automatically publishing when you publish on your site." }, { "slug": "starter", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Starter", "title": "Jetpack Starter", "description": "Essential security tools: real-time backups and comment spam protection.", "long_description": "Essential security tools: real-time backups and comment spam protection." }, { "slug": "stats", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Stats", "title": "Jetpack Stats", "description": "Simple, yet powerful analytics", "long_description": "With Jetpack Stats, you don\u2019t need to be a data scientist to see how your site is performing." }, { "slug": "videopress", "plugin_slug": "jetpack-videopress", "plugin_names": [ "jetpack-videopress/jetpack-videopress.php", "videopress/jetpack-videopress.php", "jetpack-videopress-dev/jetpack-videopress.php" ], "name": "VideoPress", "title": "Jetpack VideoPress", "description": "High quality, ad-free video", "long_description": "High-quality, ad-free video built specifically for WordPress." } ]Data scraped from the products directory.
ThierryA commentedon Mar 12, 2024
It is not a matter of product vs not product, it is a matter of user experience (and by the way the definition of product is subject, arguably these a products).
One talking point though is whether or not is should be an easily recognizable Suite of plugins, for example all prefixed with "PL" or "Performance Lab".
Personally, I see only benefits for users to easily recognize that it is part of the PL Suite (Plugin name length should not be an stopper here). Product or not product, the vision, the purpose, the trust, the team etc... of the PL project is applicable throughout all plugins and for it to be part of the plugins name make a lot of sense and goes a long way. My vote goes for adding a prefix!
swissspidy commentedon Mar 12, 2024
@felixarntz Is this issue for the feature names & descriptions on the PL admin screen or for the plugin repo? Because I think we should make a distinction there.
+1 to this.
In the context of the PL admin screen I see these more as individual features to enable.
We could do this kind of prefixing & grouping just in wp-admin, but not on WordPress.org — would that suffice? Not sure I like adding a prefix everywhere on the plugin repo, especially with the PL admin screen being the entry point for adding new plugins anyway.
For the PL admin screen we could start with naming like this:
Aside:
ThierryA commentedon Mar 12, 2024
I am advocating for prefixing plugin names (deployed to .org) to make it easily recognizable everywhere. By the way, it is a pretty common practice ;)
felixarntz commentedon Mar 12, 2024
@swissspidy
At the moment, it's for both. After further discussion yesterday, we're thinking maintaining separate names and descriptions just for PL is a maintenance burden without a real benefit. If we think our plugin names and descriptions do not adequately describe what they do, we should change those names and descriptions rather than working around it in "duplicated" versions just for PL. At least this is a more reasonable foundation to start with. I don't see a good reason why the plugin name / description would need to differ. They just need to be improved from what they are now, at least for some of our plugins.
Pretty much everything you have in that table sounds better to me than what we currently have for those plugins. So that supports my point above, there's no need for separately maintained feature descriptions as long as the plugins already describe the features they add. Make each description start with a third-person verb, and it'll work for both the plugin description and the feature description in PL.
I think your list is a good start to discuss the names and descriptions further. At a first glance, my only points of feedback are:
felixarntz commentedon Mar 12, 2024
Regarding the prefixing, I'm not sure. Prefixing within Performance Lab makes no sense, this you're already in the Performance Lab UI. If we decide to prefix all plugins on .org, I'd rather say that we should put logic in PL that (just for the PL settings screen) removes the "Performance Lab" prefix from the plugin name. If the names are predictable as such, that would be easy to do.
So for whether to prefix or not? On the one hand, it's great for recognizability and spreading the word of the "Performance Lab" brand. On the other hand, it may not be in line with the overarching idea of making the plugins standalone. Of course they'd still be technically standalone, but I'm not sure a strong connection with the Performance Lab plugin or brand is desirable in light of the original objective.
I'm totally not sold on either, curious to hear other opinions.
westonruter commentedon Mar 12, 2024
I disagree. It does describe what it does. It's using the client to detect optimizations. The client is the detective. It's not limited to just images, although that's what was first implemented. I don't want to pigeonhole it to just be about images. For example, it can also be used to apply
content-visibility, reserve space to improve CLS, add preconnects for embeds, or store CWV metrics as a RUM tool. Adding additional plugins for non-image aspects to me just adds overhead.felixarntz commentedon Mar 12, 2024
@westonruter But those are lots of different features. Just because they technically rely on the same infrastructure doesn't make a good reason for them to all be in the same plugin. Users that want to only test the image optimization shouldn't have to get the other features too, for instance. And if the solution is to offer toggles for the individual functionalities, we're back at Performance Lab all over again.
IMO this name and positioning is purely for technical reason and not intuitive for end users.
26 remaining items
westonruter commentedon Mar 18, 2024
@felixarntz
Here are two such non-image features for Embed Optimizer which depend on Optimization Detective:
These should land soon after Embed Optimizer launches because for embeds which are in the initial viewport, lazy-loading the embed will end up hurting LCP. The first issue would fix this and LCP would be further enhanced by the second.
So I would prefer that we get Optimization Detective out the door now as the foundational plugin (initially including the image optimization functionality). However, before we start promoting it in Performance Lab, we extract the image optimization functionality into a dependent plugin which is what we would actually promote to users. This will give more time to let the name bake. This would result in the least disruption to users because introducing a plugin dependency will cause friction in either direction we go:
For the second scenario, I just tested this and here's the flow...
First, a plugin update is available:
Update appears to be successful:
However, upon reloading the page, now the plugin is shown to be missing a dependency which is only advertised on this screen:
If I try updating the plugin via the Updates screen, there is no such warning:
So again, I request that we submit the plugin as-is with all the functionality in Optimization Detective. This initial release of Optimization Detective should be considered a developer preview (and we can indicate as much in the plugin name). We then work on creating the dependent plugin and release it the same time as an update to Optimization Detective with the additional API for plugins to extend (e.g. Embed Optimizer). Only at this point do we start promoting to users for testing. This will prevent an awkward upgrade path. WDYT?
felixarntz commentedon Mar 18, 2024
@westonruter Thanks for testing the second flow. While I think in principle the second option gives a better user experience, the lack of core's support for introducing plugin dependencies after the plugin was already installed would indeed make that experience poor as well. (It's a bummer this is not supported, I hope it'll be added.)
Based on your first option though, I'd say in this case we shouldn't market it as or call it "Image loading optimization" at all as otherwise, like you're saying, users would lose the feature when updating, possibly without knowing, which IMO would still be even worse than the additional dependency. So if we submit it as
optimization-detectivenow, let's call it that from the beginning. And we could put somewhere information like "The plugin currently also includes a feature that optimizes image loading performance, as a proof of concept for the underlying infrastructure.".I would also agree that we should not promote this plugin in Performance Lab until we have completed the split into two plugins so that it's better suited for at-scale usage without encountering any of the quirks the two "migration" options would bring.
Is that in line with what you're thinking?
westonruter commentedon Mar 18, 2024
@felixarntz Yes, exactly!
Yes, let's include this note in the readme as well as some "(Developer Preview)" in the plugin name. But perhaps do that after the initial plugin review by the plugin review team, to avoid confusion. So we can merge #1041?
felixarntz commentedon Mar 18, 2024
@westonruter SGTM!
Let's separately review and consider the actual API surface and what that could look like decoupled from the image loading optimization. It may already be there, or very close, but I want to make sure we make it a mindful effort to get that ready for potential consumption by third-party code, in terms of future flexibility and stability.
felixarntz commentedon Mar 18, 2024
Per the above, as we're going to move forward with submitting Optimization Detective with the intention of it being an API plugin and eventually having an image loading optimization plugin as well, this leads us to the following tentative list (based on #1046 (comment), with a few iterations):
auto-sizesembed-optimizerdominant-color-imagesoptimization-detectiveperformant-translationsspeculation-ruleswebp-uploadsI added the slugs for reference. As always, those cannot be changed once established, which is the case for almost all of them.
I'm personally not super happy about "Image loading optimization", I wonder if there's a more catchy or precise name for what this does. The other thing is that I find the "Performant Translations" description (which other than using a third-person verb is the same as the current one) sound more like a tagline / marketing than a description, in particular the "faster than ever before" part.
Separately, keep in mind that each of them may be prefixed with "Performance Lab" or similar, based on the other discussion ongoing here. Though that shouldn't impact how we choose the actual plugin names and descriptions.
WDYT about these proposed plugin / feature names and descriptions? @joemcgill @adamsilverstein @westonruter @swissspidy
westonruter commentedon Mar 19, 2024
I think the slug for Embed Optimizer would naturally be
embed-optimizer.For Optimization Detective, the description can be updated to omit "to improve image loading priority" since that's specifically what Image Loading Optimization would be doing (once it is split out).
As for naming that plugin, I think it's actually pretty precise already, but catchy it is not. What about "Image Prioritization" or "Image Prioritizer"?
westonruter commentedon Mar 19, 2024
Just to confirm, we are agreed on
embed-optimizeras the slug for that plugin? I don't want to submit it for review prematurely 😅felixarntz commentedon Mar 19, 2024
WFM. I don't think anyone has questioned that at any point, so we can probably submit. In any case, it's "only" the slug. 😆
swissspidy commentedon Mar 19, 2024
At first glance:
Improves accuracy of optimizing the loading of the LCP image by leveraging client-side detection with real user metrics.->Optimizes the loading of the LCP image by leveraging client-side detection with real user metrics.Otherwise let's just start with something instead of bikeshed any longer :)
felixarntz commentedon Mar 19, 2024
I think before we open any PRs to change those plugin names and descriptions for further review, the other big question is: To prefix or not to prefix? In other words, should we have "Modern Image Formats" etc. or "Performance Lab Modern Image Formats" etc?
Alternatively, we move forward without the prefixing for now. Not at all because we shouldn't do it, but because this is another decision to make, and the original purpose of this issue was to revise the plugin names and descriptions for their accuracy rather than deciding on branding.
LMKWYT.
@swissspidy I've updated #1046 (comment) with your suggestion.
swissspidy commentedon Mar 19, 2024
Let's discuss the exact prefix separately.
I assumed the prefix would include a colon or something. "Performance Lab Modern Image Formats" reads a bit weird, "Performance Lab: Modern Image Formats" would look better.
westonruter commentedon Mar 25, 2024
How do we feel about "Image Prioritizer"? This would work well for fetch priority as well as lazy-loading.
Rename plugins and update descriptions according to #1046.
westonruter commentedon May 17, 2024
Going back to the topic of prefixing the plugin names with "PL", I have an alternate proposal to use the plugin row meta to explicitly indicate that a feature plugin is coming from the Performance Lab plugin: #1222.