Review current plugin names and their descriptions for their accuracy and helpfulness #1046
Comments
felixarntz
added
Infrastructure
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 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. |
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). |
|
@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:
|
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 ;) |
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:
|
|
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. |
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 |
|
@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. |
|
I don't think it is sustainable to relegate every distinct feature to a separate plugin. We have to group some related functionalities into common plugins. |
FWIW with this I was mainly hinting at enhancing the plugin a little bit. There's no reason this functionality shouldn't also work for video posters (which are images, but the experience is for videos), hence Media Placeholders. Whereas the Modern Image Formats is only for images obviously. Hope that makes sense. |
That's the part I don't get. There may be modern video formats as well. I really don't see any difference between why one plugin should use the general "Media" and the other one "Image". Both equally can apply to other formats. But at the moment they don't. So in order to adequately describe what they do, "Image" is more accurate. If the scope later expands to other media, it can still be renamed (again) - but we don't know whether that'll ever happen. |
That's speaking from an engineering perspective. I don't disagree. But it was also easier from a maintenance perspective to ship all features in Performance Lab, yet here we are. We cannot make those decisions purely from an engineering perspective. There is clearly a tradeoff between UX, DX, and what we should be doing according to project leadership, so we have to balance those points. Grouping multiple features in one plugin is a no-go as far as previous conversations have indicated. |
WordPress can't do server-side video transcoding, and doing that client-side is still far away. When that becomes possible, it can be renamed to Media Formats too.
That's exactly what I am saying: we should update the dominant color plugin, hence I suggested the name. Makes sense? |
Is there an issue for that? FWIW that plugin hasn't seen any updates in a long time, and this is the first time I'm hearing about this. Unless, or until the plugin contains non-image functionality, IMO it shouldn't be using "media", just as you're saying for the "Modern Image Formats" plugin, it can be renamed once/if it has the functionality. |
I don't think there is. This was mostly a spontaneous idea. As per my other comment we could also just remove the plugin.
Again, we're saying the same thing :) Anyway, didn't wanna derail the conversation further.
So about that Optimization Detective feature IMHO it's a matter of finding the right balance for how many features to put into a plugin vs. splitting things up. |
For what it's worth, I see the Optimization Detective features more of a package deal and not individual things you would turn on or off. By activating the plugin, it detects opportunities based on client-side metrics to optimize the response which wouldn't be possible using server-side heuristics alone. Similar to a proposed Image Formats plugin, it could enable both WebP and AVIF, without needing to have toggles for the different image formats to enable. |
Based on the features you mentioned as examples in #1046 (comment), I don't see any meaningful relationship between them, except that they use the same technical foundation. Again, from a technical perspective grouping them makes sense to me, but not from a feature perspective.
This sounds quite complicated to understand for a non technical user. Hence, I don't think it's a good framing for the plugin, unless it is aimed at developers.
IMO that's a very different point on the spectrum. Both WebP and AVIF are image formats. Just as both |
|
All of the PL plugins are technical to some extent. End users who are not technical will have trouble understanding functionality in most of the plugins. PL is positioned as a beta testing plugin. But let's say Optimization Detective is split out into a plugin specifically for Image Loading Optimization. Playing this out, when wanting to experiment with content visibility or preserving space to reduce layout shift, and so on, will this mean adding additional plugins for each feature? To an end user, these are difficult to position independently as well. They are very technical. To the end user, they just want to have an optimized loading experience. They don't care about the technical specifics. How the optimization is accomplished is just an implementation detail. So for end users, I don't see how splitting into multiple plugins will make it more end-user friendly. Conversely, as you note, breaking up these functionalities into separate plugins would be complicated from an engineering standpoint since they all depend on this same underlying foundation to work. This is different from other PL plugins which are actually independent from each other: they are truly standalone. But if the initial plugin is exclusively for images, and then we introduce other plugins that are not for images, would they be made to depend on the plugin for images? That wouldn't make sense to a user either. Otherwise, do we copy the same foundational logic into each of these plugins? I think this gets overly burdensome and it isn't pragmatic. |
Regarding prefixing standalone plugins names with "PL" or "Performance Lab" on .org, as I can only see benefits and in a sense we are already re-using the same assets throughout all standalone plugins. When looking at a standalone plugin on the .org repo, the re-used assets already makes the user familiar from one plugin to another, however this is not the case in the wp admin plugin list (not in order, no common asset etc.), which is an issue for multiple reasons. Adding the prefix will fill that gap and compliment the re-used assets across all standalone plugins. |
|
Coming in a bit late, mostly I want to say I mostly agree with this:
Bundling things to create a cohesive feature-set that uses serveral strategies to do one thing well like optimizing images or optimizing embeds or optimizing the loading prioritization of the LCP element (aka Monsieur lá Detective) feels like the right balance of perspectives to me. One way of looking at this I like is - would this entire plugin get merged into core as a single enhancement? (and then no longer maintained) - if so, it makes sense to be a single plugin. For the modern image plugin, it probably makes sense to bundle WebP, AVIF - and ideally picture element support - in one plugin (without any options). For Optimization Detective the oEmbed and Content Visibility features do seem more separate, so I like the direction of making this a library the other plugins depend on. Aside: would the Image optimizer expand to include detecting other LCP elements (video and maybe iframes) and would you change the name then? I guess I feel it is more of a "Prioritization Optimizer" overall? For the prefix conversation, I do agree we should have a more cohesive User Experience which I feel this helps support. I would also love to see us revamp the feature activation UI to make it less like the plugin installer screen (and more like Jetpack). Is there already an Issue for that? |
Good point. Perhaps "Media Loading Optimization" would make more sense, so it can span images and videos. I think "Asset" would be too broad as this is not intending to optimize script and stylesheet loading. For iframes, would this fall under the scope of Embed Optimizer? |
Probably yes, good point. I remember there were some limitations in detecting iframe LCP elements, do you know if that is still the case?
What about other LCP element types? Optimizing for those feels like part of the same "feature". Here is some recent data on the LCP element types: https://almanac.httparchive.org/en/2022/performance#lcp-content-types, it seems like covering the top types are all part of one feature although images do make up 72/82% of LCP elements. I believe iframes are not included here not because they don't happen but because they aren't or weren't properly detectable in JavaScript. Also video % is miniscule, probably mostly served in iframes.
The divs are mainly containers for a background image:
I already offered my admittedly not great name suggestion: "Prioritization Optimizer" :) "Media" sounds like it excludes text? |
|
What a lively conversation 😆! It seems to me like we're conflating two quite fundamental questions into one here, which is complicating things. First, it seems like we don't have a great strategy for what constitutes a standalone plugin, which leads to disagreement about whether certain features should be bundled together and which should stay in separate plugins. From a maintainability standpoint, and a user experience standpoint, I tend to agree with this sentiment shared by @adamsilverstein on this first point:
Even so, I don't think it's easy to foresee how an initial feature might naturally expand in the future to be just one option in the service of a larger feature set. As an example, the WebP module started as a way of both supporting WebP uploads in the media library AND generating WebP intermediate sizes rather than JPEG. Once upload support landed in core, the module (now plugin) persists as essentially a toggle to turn on intermediate sizes generation. Now that AVIF support is in Core, we could create another feature plugin for generating AVIF intermediate sizes, but that seems less ideal than having a single plugin for modern image support, where we can experiment with early support for uploading new formats (e.g. JPEG XL) and provide a way for sites to serve users images that use modern formats (i.e., intermediate image generation). Already in this conversation it's clear that the API that @westonruter has been working on to be able to support optimization of asset loading based on front end data could have implications for many features in the future (asset loading optimizations, content visibility, responsive image heuristics, etc.), but those features don't necessarily relate as a single plugin unless we think of the API itself as the main feature, and the optimizations as examples of how that feature can be applied (e.g., the way some initial experimental blocks were used to demonstrate the Interactivity API). Second, even if we had clear agreement on what constitutes a standalone plugin, we don't have a convention for naming each of our plugins in a way that are consistent and provides a cohesive user experience. I think this is an easier problem to solve, given that plugin titles can change fairly easily. I would be fine prefixing all of our plugins with "Performance Lab". I don't love the redundancy that this would bring to the install UI we have in the main PL plugin (see example screenshot) but I agree with all of the other benefits this would bring to the plugins admin screen and in the main .org plugin repo. 
It would also make our individual plugin names less important because they wouldn't need to stand on their own. The downside is that we're prioritizing "Performance Lab" as the main brand umbrella under which all of our work sits. PL does have more brand equity than anything else we could use at the moment, so that's probably not a bad thing. If we were to do so, then our convention could be something like:
|
Oh yes, this is indeed the case. I'm able to get a You're right about text being a good candidate as well, although this is trickier to optimize since it potentially involves stylesheet processing and font loading. But just because it is tricky doesn't mean we shouldn't do it 😄 |
If it is about media, image or whatever else, it should be clear if possible. As a user, "prioritization optimizer" doesn't say much IMO.
With the PL plugin UI, I would prefer it be cleaner than the screenshot sent, ie. without the icons and automatically strip the "Performance Lab: " (in this context only, as we are within the PL admin screen already). |
|
Sharing my 2 cents on all the recent replies here: @joemcgill correctly pointed out that we are discussing two distinct topics here: One is whether to prefix all standalone plugins with "Performance Lab" (or another brand specific prefix). The other one is how to scope our standalone plugins (and based on that how to choose their names). While opinions differ on both, the latter seems more complex to discuss as there are more things factoring into the decision.
|
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? |
|
@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 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? |
|
@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? |
|
@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. |
|
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):
I 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 |
|
I think the slug for Embed Optimizer would naturally be 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"? |
|
Just to confirm, we are agreed on |
|
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. 😆 |
|
At first glance: Otherwise let's just start with something instead of bikeshed any longer :) |
|
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. |
|
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. |
How do we feel about "Image Prioritizer"? This would work well for fetch priority as well as lazy-loading. |
|
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. |
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:
For reference, here are our current plugin names and descriptions to review:
sizes="auto"to lazy-loaded images.Let's brainstorm.
cc @adamsilverstein @joemcgill @mukeshpanchal27 @swissspidy @westonruter
The text was updated successfully, but these errors were encountered: