Improve plugin search results with already active plugins

[joostdevalk]

Currently if you search for a plugin to do X, and X is something that a plugin you already have matches for, this is what you get:

​https://cloudup.com/c0GYNTynpF4

The disabled "Active" button there is not very useful, as it doesn't provide any context as to why that button is disabled. I'd like to propose a change: let's turn this into two separate groups of results, one that says "these plugins you already have installed might be able to help" and then a second group below that with other plugins.

In my ideal world, we'd even have an "admin search" function, where you could be taken straight to the appropriate page for that keyword. This could be useful even for WordPress core, so I'm splitting that out into a second issue: #46764.

[joyously]

Are you proposing to also change what happens when you install a plugin from the search results?
Will it move to the other section?

[gibrown]

In addition to changing how the cards are displayed we could show the end user what within the plugin is causing the match. Highlight what is matching similar to how most search results work to give the user more context about why a plugin is matching a search.

This is related to ​https://meta.trac.wordpress.org/ticket/2754

Additionally we could send the list of installed plugin slugs along with the search request and then boost those plugins. So even if an installed plugin is on the third page of results, it will get boosted up to the top because it is already installed. This would sort of personalize the results for the end user and combined with the highlighting feature should let the user know when a plugin they already have may work well.

All of this of course requires changes to the search API.

[hedgefield]

I made a few quick mockups of what this could look like: ​https://sketch.cloud/s/wwDjA/9PgPwzD

[jeroenrotty]

How will the search look for matches? Tags? Descriptions? Titles? Will anything else have any impact?

[joostdevalk]

I would literally only do this for plugins that would already be in that result set through normal search.

[nerrad]

I like the direction of this ticket. For those working on it and those stumbling on it this clarification is imo very important:

I would literally only do this for plugins that would already be in that result set through normal search.

I do not think we want to do anything similar to what Jetpack is doing for their "promotions" here.

[nerrad]

If there are installed plugins that match the search terms, what about adding a link to the top of the results that goes to a filtered view of the dashboard plugin list table for those search terms. The link could read something like "You have installed plugins that match these search terms. Click here to view". Then remove installed plugins from the search results.

[Ipstenu]

I like the mockup that separates the plugins you have from the ones you don't, though my concern is that, much like we have today, people will just ... not recognize that's something they have. We might need to go a little bolder there, but that's just verbiage.

However. This is a much nicer solution for all plugins, not just the ones that are larger. Imagine the real situation of people installing 4 or 5 gallery plugins. A stop of "Hey, you have 4 plugins that already do X." might prevent people from installing 30-40 plugins and ending up vulnerable. If they recognize that they HAVE features already available, it may reduce the overall number of plugins installed.

Also, this could be extended to things that are added to core! "Don't install that CSS customizer before you try the one in WP!"

[cathibosco1]

Why not simply add it as a "Filtered" search? "Filtered by what I have active" much better than messing up our ability to access freely all of the search results on any size screen...

Here is a screenshot:

​https://canddstudios.d.pr/Pb5Ted

[jb510]

I dislike all the mockups that separate the plugins at the top of the list.

I feel we should not allow anything that makes it look like using and existing plugin's functionality is preferable to using other plugins tailored to the functionality.

I see simple search examples like "backup" and "xml sitemaps", however what happens when the search query is "facebook". Does Jetpack get top billing because it has facebook share buttons built in? Does WP SEO get top billing because it provides for FB OG tags?

I feel a better solution would be to allow plugins to manipulate there search result card, _without_ changing the order of results.
​https://cloudup.com/cYCjug00nM2/f

That card could then be modified however the plugin author wanted, it could say "Jetpack provides share buttons including Facebook", or "WP SEO includes XML Sitemaps!".

We ought to trust organic search results, or we ought to improve them (I know they've been worked on).

The problem is top billing implicitly suggests that utilizing that plugin is a better solution than activating a new one which I find a FALSE PREMISE. I feel users are not well served by "one plugin that does 50 things poorly" over "50 plugins that each do one thing exceptionally well". We shouldn't be encouraging massively bloated swiss army knife plugins.

WP SEO provides a great sitemap feature, Jetpack does too... but neither are the "best" solution for users in many cases. Just because someone has installed a plugin that includes some functionality, that doesn't mean they wouldn't be much better of installing one of the dedicated XML Sitemap plugins.

The goal of search results should be to present _the best solution for users_.

Further, I can already see plugin devs consolidating dozens of disparate plugins into "master plugins" just to capitalize on this opportunity.

I'm totally in favor of allowing plugins to modify their own search card _without_ changing search order. I can see the benefits to that without all the negatives top line billing brings.

[joostdevalk]

Some people have interpreted what I said as changing search results, that's specifically not what I meant.

This is also not about allowing plugins to do anything. I want to solve this for all plugins, in core, and would prefer to remove the filters and hooks on this page after that.

The user flow here is:

• You want to do something on your site.
• You think none of your plugins do it, or you didn't even think about that, so you start searching for a new plugin.
• You see that a plugin you have already does this, so you use that.

OR:

• You want to do something.
• You know one of your plugins does this, but don’t want to use that.
• You ignore the section with the ones you have installed and go to the other section.

Both are valid use cases, both are badly served by the current way of showing results. What that looks like is what we're discussing here, in my mind.

[Ipstenu]

I don't believe in artificial intelligence, and I don't know how to read minds. Because of that, I do see a need for improving search results to include what plugins you've already installed can POSSIBLY meet the needs of what you're looking for.

I see simple search examples like "backup" and "xml sitemaps", however what happens when the search query is "facebook". Does Jetpack get top billing because it has facebook share buttons built in? Does WP SEO get top billing because it provides for FB OG tags?

If they're installed... Yes. With a search like 'facebook' it's nigh impossible to divine if a user means "I need facebook embeds" (which yes, Jetpack does) or "I need Facebook OG tag editing" (there's Yoast).

The problem is top billing implicitly suggests that utilizing that plugin is a better solution than activating a new one which I find a FALSE PREMISE. I feel users are not well served by "one plugin that does 50 things poorly" over "50 plugins that each do one thing exceptionally well". We shouldn't be encouraging massively bloated swiss army knife plugins.

I don't know how you expect anyone to reply to that except with "I respectfully disagree." but that isn't the point at all.

So let's throw out Jetpack for a second and think smaller.

Let's say you have installed the Official Facerange plugin. It allows you to do all sorts of things, like custom video embeds, but also customize your OG data. You've only been using the embeds and go to find a plugin to help with the OG data. You search and, ping, the search says "Hey, this plugin you already have does this."

Or what if you have a gallery plugin and want a slider add-on. If you don't know the plugin you have already includes a slider, you might install a new plugin before trying what you have.

The ultimate solve here is NOT "let bigger monolithic plugins rank higher" but "highlight for people what the plugins they're ALREADY USING can do."

[joyously]

Splitting the results into two sections (installed and not) can also hide some information.
If the user searches, and sees the installed plugin far down the list, it indicates that maybe the best plugin for the job was not chosen. But if that plugin is pulled out of the list, where it stands in relation to the other results is lost.
I'm all for marking the installed plugins prominently, but I think they should stay in the same order always, unless there are sorting options provided.
And I still wonder what you are suggesting for the plugin that is installed from the search results -- would it move to a different position after installation (ajax)?

[gibrown]

The ultimate solve here is NOT "let bigger monolithic plugins rank higher" but "highlight for people what the plugins they're ALREADY USING can do."

I like it when I agree with @Ipstenu. The user has already decided on a set of plugins. Let's not second guess that decision, let's use it. We should boost up (or just run a second search query across only the installed plugins) and display any already installed plugins.

Install count, reviews, support threads all matter a lot for the search ranking alg. But once a user has installed a plugin they have presumably already taken those into account. (I feel some desire to go on a rant that there is no such thing as "organic search results", but I will try to refrain.) Once the user has decided to install a plugin, that information seems way more important than any usage info that wp.org has knowledge of.

I don't like only boosting the plugins that appear in the first page of results, because what if the user has a plugin installed that is on the second or third page? Do we display them only when the user goes to the next page? Do we not show them differently at all? I think this gets complicated, and also, because the search alg uses things like install count it will definitely favor the big plugins.

I don't love the idea of a completely separate section of search results, but maybe we limit it to the top 3 and can have a button for expanding to show more if there are more.

I do think we should also show highlights of why a result matched on the search screen, but after thinking about it some more, that should probably be another ticket and involve a complete redesign of the search interface. Probably also better to do that on wp.org first.

Unfortunately, there is some performance downside with putting these filters/boosting on the search queries. It will mean fewer cache hits on wp.org and more having to make the extra hop to Elasticsearch. I'm not sure if there is a way around that or how much slower it will make things. I know anywhere not in N America is already pretty slow, so the added marginal delay is probably minor in comparison.

[jb510]

This is also not about allowing plugins to do anything. I want to solve this for all plugins, in core, and would prefer to remove the filters and hooks on this page after that.

I totally agree here. Plugins shouldn't be driving the show here, core should be. Because core should represent what's best for users first.

The ultimate solve here is NOT "let bigger monolithic plugins rank higher" but "highlight for people what the plugins they're ALREADY USING can do."

I agree here too. Where I disagree with this is that "anything" that puts results _at the top_ of the page promotes those plugins over others. That harms users more than it helps them.

Take this out of plugins entirely for a moment. Imagine if Google search results displayed "sites you've visited before" above all other results when you searched. Odds are you'd just keep revisiting those same sites. Not because they were better results to your query, but simple because they were at the top of the list and we all have learned the pattern of "click the first result".

All of this benefits entrenched plugins to the determinant of less popular but possibly better solutions for the user.

I totally respect the intent of "make sure users know an already installed plugin does the thing their searching for".

I outlined that I think fulfilling that in a helpful way would be for search results for active plugins to be highlighted and customizable by plugins, but that they should remain in the order they appear in search.

Core could standardize on a very visually distinct background color so they stand out boldly. To go back to these mockups from
@hedgefield ​https://sketch.cloud/s/wwDjA/GmgodAE I think the cards designs look fine, they could even be more district, I just don't want to see them at the top of the search results which isn't about Jetpack... it's about all the plugins about to be buried under a dozen others that claim to provide that functionality. Not even "may provide similar functionality".

Picking winners and losers like that is a slippery slope best avoided.

[Ipstenu]

All of this benefits entrenched plugins to the determinant of less popular but possibly better solutions for the user.

Ah, okay I see where you're going. The problem there is the reverse is also true.

For example...

1) Many times the plugin users have installed is already the rare plugin. Your proposal would make it harder to find them (say they're on page 2) and their features.

2) The odds are a plugin that is one-use specific to the search query will rank first. Because of the 'click first' conundrum, people would continue to install more and more plugins to solve a problem they've already got an answer to.

I think either way, you're going to have this problem, so the question boils down to this: Which is more important: highlighting the plugins you have or finding more plugins you don't?

Honestly, give me a beer and I can argue both sides of this. BUT. It's pretty clear the way we have been doing it (showing them inline) is resulting in people installing a larger amount of plugins than may be needed, which increases the potential for plugin/theme conflicts.

(I don't buy into the 'too many plugins is always bad!' mythos)

[jb510]

Replying to Ipstenu:

Honestly, give me a beer and I can argue both sides of this. BUT. It's pretty clear the way we have been doing it (showing them inline) is resulting in people installing a larger amount of plugins than may be needed, which increases the potential for plugin/theme conflicts.

(I don't buy into the 'too many plugins is always bad!' mythos)

I agree, both sides can be argued. I'm clearly on one side (highlight inline), but it's because I think the other side (top billing) has more cons then pros.

Just like one can argue that it is better to have 20 tightly focused plugins where you can turn 1 of them off or replace it in case of a conflict, rather than to find out you have a conflict with one plugin you are using for 20 different things around your site.

There's lots and lots of ways to look at it.

I agree that the current inline method is too subtle. Active plugins should get a more striking design to highlight they're installed. As a bonus, already installed plugins could customize their design and/or copy, as long as it stuck within the current search result wrapper.
​https://cloudup.com/cyMiUbx1_Br

I think that would go a long way to helping users, without the harm I believe top placement will bring. It also prevents things getting promoted up from the 4th or 5th page because they're not really good at what is being search for. That too avoids the otherwise inevitable "stuffing" of features that is bound to come.

[timph]

The disabled "Active" button there is not very useful, as it doesn't provide any context as to why that button is disabled. I'd like to propose a change: let's turn this into two separate groups of results, one that says "these plugins you already have installed might be able to help" and then a second group below that with other plugins.

I think it does provide context pretty directly. It says "Active". In context of all the other plugin cards that say "Install Now" or for plugins not active but installed "Activate".

I do agree they could stand out better. These are some additional thoughts on the topics discussed:

1. Whatever is decided should also remove the "Recommended" plugins tab from this area. This harms the WordPress ecosystem, and makes it nearly impossible for other plugin authors to be successful in various aspects. I think the idea of a "Recommended" tab is a GREAT idea though. This recommended tab should be driven 100% by the THEMES and PLUGINS a user has DECIDED to install and activate on their site. If they don't have any plugins, and the theme they have activated doesn't recommend any, then no recommended tab should be displayed. This is an entirely biased section, and offers no way for authors to achieve placement there. It's also clear not recommended plugins for what a user has installed or needs, it's opinionated and in many cases irrelevant suggestions. This would resolve the lack of a way for plugins and themes to recommend or require dependencies (by that I mean other packages in the WP ecosystem, which right now I call plugins, but could include blocks as this would be a new "type" of package as well). Right now plugins and themes recommend things in non-standard ways, there's constant confusion as to what can and can't be done, common questions are asked about including external .zips outside of the WP repo, and all of these things collectively make a horrible user experience. When you have a theme and 5 plugins all prompting you to install things in various disjointed ways - it's a problem. Despite the fact this is true, and known - I would not expect this to actually be considered as everyone capable of making something like this happen is firmly placed in a nice position on that page, but one day - I hope this will change. It's really a picture perfect thing that should change in core as it benefits everyone - it makes the page relevant to new users, users who are more advanced, and at the same time solves issues for developers and plugin/theme authors.

2. Installed plugins could stand out better in search results. The quick solution seems to be just add an active class for plugin cards that are installed and active. Add an inactive class to plugin cards installed but not active. Style them accordingly. This could be handled by core.

3. The whole premise of installed and active plugins recommending features based on searches contextually, that really doesn't seem like it has anything to do with core. How would core dictate in a reliable fashion to know "what" features a plugin supports reliably? This doesn't make any sense... My answer to that would just be the same as probably everyone else's: "We could provide hooks and filters allowing plugins to provide that information". These already exist. The only thing that is in place preventing any of this behavior from happening are the rules as to what plugins (and themes) can do. You can specify the features you support by adding tags, putting relevant information in your description, short description, changelogs (apparently this is a thing now too), and other fields as you see fit inside of your readme.txt file. The algorithm from the API side determines the order of the results. If your plugin is relevant to the search query, then it's returned. If it's a better match, it's ranked higher based on the criteria from that side of things. Anything done further and outside of this IS manipulating the search data for preferential treatment and/or display of this data. If it's determined that "Installed and Active" plugins should be sorted above others or separated out, this should be done on the API side, and installed and active plugins should be passed along in the request.

4. I don't think there's anything wrong with the result's data - and the only thing I glean from this so far is that everyone is in agreement that the cards could be better styled like mentioned in 1 above. There's some discrepancies with ordering, but I think 2. pretty much makes sense as to what should be expected from the API. I do think there's other ways of handling all of this, and would be interested to see some alternative ideas presented and mockups. I can't say there's better ways or worse ways, but there's not much involved to take route 2 mentioned above. Quick and painless, but it's really only a tiny visual change when there's probably more to it than that. For instance, if one of the root problems described is the fact that people are viewing the search results, and are having problems identifying the results that aren't relevant to them because they already have the items installed and activated - what actually exists today? We identified there's already some stuff present for showing which ones are installed and installed and active - and it seems like everyone is in agreement this could be more effectively highlighted. There is however an entire interface in a different view which presents nearly all the same data in a less "pretty" way. Maybe a solution could be made that combines the "Installed Plugins" and "Plugins > Add New" pages. It could have a list that persists of installed plugins, and gets filtered out by your query for searching for new ones all in the same interface. Taking the concept of the "smaller" plugin-cards shown in slack - this could be a way to combine the redundant logic between these two sections. They both offer functionality to activate, deactivate, and update plugins, they offer descriptions, versions etc. This would also align with what I think in point 1. It's not uncommon for a user's plugin menu to have submenu items added for "Recommended Plugins" or "Required Plugins" when a theme/plugin makes use of a library like TGMPA. There's a bunch of pages, slightly different UI elements on each, and it just results in a disjointed experience for end users. It would be much simpler reducing all of this for users, and having a "Plugins" page. No extra stuff needed, no additional clicks to get to views that all basically contain the same information presented in various ways. The "add new" button at the top of the "Installed Plugins" page is a weird journey for a user anyways now, and this seems to only be unique to themes and plugins "installed" pages. Both of these areas could be reduced and more effectively presented. This could also be an opportunity to start bringing forth the modern stack adopted for "major" UI changes in core. The new interface could be implemented using react, and bring more unification to the overall codebase. If anything it could help attract more people into using, learning and understanding React since this could be a feature utilizing the technology that solely exists in core outside of context of the editor. I assume given the overall roadmap of Gutenberg, this would be a beneficial direction to start driving towards.

@jb510 said:

I outlined that I think fulfilling that in a helpful way would be for search results for active plugins to be highlighted and customizable by plugins, but that they should remain in the order they appear in search.

and also:

As a bonus, already installed plugins could customize their design and/or copy, as long as it stuck within the current search result wrapper.

This already exists. All plugin cards have the plugin-card-$slug class applied. Installed and active plugins can enqueue styles in the admin area. There's filters for the search query, data that has been extracted from the readmes, etc. Not sure what else should be done to go further.

I think the only barring limitation right now is that there are guidelines and rules for what plugins(and themes) can do. You can get into overly complex style rules, plugins that take styling this area a bit TOO far, plugins that break the layout, etc. I think the current solution in place is really the best solution for plugins "customizing" their plugin cards. This is currently handled by plugins uploading their very own screenshot, which is contained to that specific area, and has size restrictions. This prevents all the aforementioned risks, keeps the results uniform and predictable, but still allows for color and life to be brought into the result. A good compromise.

The minute that you start allowing plugins to modify the actual data, is the minute someone will abuse that. Following suit with what I stated above in point 2 - any data determined for the return should be handled by the API side of things. This could get messy, and personally I think how core has it implemented now addresses most of the complications that would arise by allowing this level of modification (changing the descriptions based on query). These are some of the reasons:

1. The search query is already determining WHAT to display based on the user's input. They use their readme.txt to provide an adequate short-description 150 char or less of what functionality their plugin provides.
2. Providing customization of this, it's obvious that plugins would and could go overboard. c. This would probably end up just being a bunch of bloat in the total distribution size of plugins. If we're honest with each other, the only sole purpose of wanting to do anything beyond a description of what your product does is going to be for marketing tactics. Data like that living in the plugin after this point doesn't serve purpose. This would be like and open invitation saying "include your entire plugin's documentation inside of your plugin, don't create a website". You're going to match more queries that way, right? If you're already a major distributor, you're going to outrank everyone for virtually every keyword going that route. Small plugin authors CAN'T compete against large plugin authors. It's already pretty obvious in the directory today, and this would make it a bit worse :(

@gibrown said:

I do think we should also show highlights of why a result matched on the search screen, but after thinking about it some more, that should probably be another ticket and involve a complete redesign of the search interface. Probably also better to do that on wp.org first.

I could understand perhaps changing the description field to display the content that was matched based on the query instead of only displaying the description alone. If perhaps a query is found and matches something from a different section in the readme, or the description beyond 150 chars ect - it could display that excerpt in place.

I do think this could make the search a bit more confusing though as people are accustomed to seeing things a certain way right now. I agree with you that this would be better suited at that point in a ticket about a new search interface altogether. I also agree with the points about making sure that largely downloaded plugins aren't receiving more benefit from major changes being done. Honestly though - stepping back and thinking of the purpose of plugins, and how WordPress was designed in the first place with plugin functionality in mind - I think what @jb510 mentioned paints a more clear picture:

Just like one can argue that it is better to have 20 tightly focused plugins where you can turn 1 of them off or replace it in case of a conflict, rather than to find out you have a conflict with one plugin you are using for 20 different things around your site.

I agree with both sides of this familiar argument as they both have their completely valid reasons, but isn't this conceptually the root of what the problem is here right now? The issue REALLY isn't that the search is that bad, it's the fact that plugins with millions of users are continuously adding new features inside of their plugins. Big plugins leverage this fact because they rank higher in the results returned. The features added (JetPack seems to be everyone's favorite example offender of this) get more and more diverse, and in turn those features are in direct competition with other plugins which offer those specific smaller features. The REAL issue is that plugins are not supporting the original WordPress philosophy and direction that was intended for plugins.

It's the behavior that's still encouraged today in core with efforts like "features as plugins" for new features to add to core which serve as a single purpose single feature. Plugins are going out of scope of serving their single purpose, and the reason for doing this is because it's easier to dominate a market by putting everything into one successful product than it is to try and build 50 individual features that are successful. Let's say a major plugin were to actually break down it's feature set a bit - Problem solved, and this ticket wouldn't exist. I mean shoot - Google limits their single page result length to what, 130 chars? I'm pretty sure a 150 char description limit for a feature(aka a plugin) is more than adequate for a single search result. It's enough to describe entire products in other virtual spaces, it should be enough in this display without having to go way out of the way of what is currently done too.

[rilwis]

I don't like the idea of creating a separated section for installed plugins just by they have that functionality.

I suggest no hijacking the plugin search results at all! As the plugins (that have the functionality) already in the list. There's no need to highlight them anymore.

Another solution for that is: adding a filter for plugin description in the card that allows the plugin to show more meaningful description to users if they search for a functionality that the plugin already have.

Here is a screenshot of what I mean:

​https://i.imgur.com/b7Xr798.png

[johnbillion]

I think this separate section for highlighting the features that are present in plugins that are already installed is very elegant and would serve users well. We could shift the focus even further so it's more about the features rather than the plugins.

In addition, it would be great to surface this information regardless of whether the plugin is active or not.

That said, there's a lot of conjecture and opinions in this thread. Some UX research would go a long way to deciding whether this is the right path to take.

[joostdevalk]

This was discusses yesterday in the #design meeting and everyone liked option 3. So let's skip research and go to development.

[remediosgraphic]

What happens when you have more than one plugin or five offering the same functionality? How you filter or suggest a result (who is first). the .org repo should avoid all this or on the future when regular users look for a specific functionality (ex: security, forms, performance) they will not have real search, the actual filter is by keywords, numbers of installs and reviews. If a installed plugin have a natural presence on the results is acceptable show any suggestion, but change the logic of the search is not a good option.

[jb510]

Replying to joostdevalk:

This was discusses yesterday in the #design meeting and everyone liked option 3. So let's skip research and go to development.

This ignores a lot of people that feel promoting results above others is flat out wrong and undesirable... and vote for "non of the above" on the 3 mockups.

[markoheijnen]

Replying to jb510:

Replying to joostdevalk:

This was discusses yesterday in the #design meeting and everyone liked option 3. So let's skip research and go to development.

This ignores a lot of people that feel promoting results above others is flat out wrong and undesirable... and vote for "non of the above" on the 3 mockups.

Agree with jb510 on this as well as his opinion shared on what he thinks the design should be. I really don't like the separation and without a decent description and title only, it's to confusing for the user.

[ionutn]

Replying to cathibosco1:

Why not simply add it as a "Filtered" search? "Filtered by what I have active" much better than messing up our ability to access freely all of the search results on any size screen...

Here is a screenshot:

​https://canddstudios.d.pr/Pb5Ted

This makes sense for me, it isn't confusing and allow plugin authors to improve feature discovery.

[ionutn]

Replying to gibrown:

The ultimate solve here is NOT "let bigger monolithic plugins rank higher" but "highlight for people what the plugins they're ALREADY USING can do."

I like it when I agree with @Ipstenu. The user has already decided on a set of plugins. Let's not second guess that decision, let's use it. We should boost up (or just run a second search query across only the installed plugins) and display any already installed plugins.

Install count, reviews, support threads all matter a lot for the search ranking alg. But once a user has installed a plugin they have presumably already taken those into account. (I feel some desire to go on a rant that there is no such thing as "organic search results", but I will try to refrain.) Once the user has decided to install a plugin, that information seems way more important than any usage info that wp.org has knowledge of.

I don't like only boosting the plugins that appear in the first page of results, because what if the user has a plugin installed that is on the second or third page? Do we display them only when the user goes to the next page? Do we not show them differently at all? I think this gets complicated, and also, because the search alg uses things like install count it will definitely favor the big plugins.

I don't love the idea of a completely separate section of search results, but maybe we limit it to the top 3 and can have a button for expanding to show more if there are more.

I do think we should also show highlights of why a result matched on the search screen, but after thinking about it some more, that should probably be another ticket and involve a complete redesign of the search interface. Probably also better to do that on wp.org first.

Unfortunately, there is some performance downside with putting these filters/boosting on the search queries. It will mean fewer cache hits on wp.org and more having to make the extra hop to Elasticsearch. I'm not sure if there is a way around that or how much slower it will make things. I know anywhere not in N America is already pretty slow, so the added marginal delay is probably minor in comparison.

Completely agree with the first part, the challenge in this particular case is that it's not always the user choice ( get pre-installed by some hosts), that's why the whole part of users that don't understand what plugin does. We do have a plugin which works like jetpack, we recommended it with themes, users got it as a recommendation, but they aren't using it that much, because the initial intent to install a plugin like that was not there.

I believe that users who decide to install JetPack because is an awesome all-in-one solution backed by Automattic and would do that on purpose, would check all the features, would learn it and would not need such hints ( there is an email sequence as well), however a person who got it because it was pre-installed, recommended by another theme/plugin as a sort of requirement, won't use it, that's why usage data is low for certain features I believe. Again, I am talking just from my experience.

[jb510]

Replying to markoheijnen:

Agree with jb510 on this as well as his opinion shared on what he thinks the design should be. I really don't like the separation and without a decent description and title only, it's to confusing for the user.

There was a mockup added in the #design chat ​https://wordpress.slack.com/files/U02QJMG7R/FHM6CFZ52/image.png that adds a green "installed" label next to the title.

Rather than improving things, I think this highlights that the whole section has the potential to be confusing. Doubling up on labeling to fix it (headline and label) exposes the original flaw.

I want to make clear however, I think this proposal is an order of magnitude better than what the plugin review team allowed JetPack to do. I'd certainly support #3 over "the status quo", I just still think it's problematic and confusion to users using plugin search.

In the interest of trying to continue to be constructive in this discussion here is an alternative mockup (better then the last, but which I hope someone could iterate on and make even better) ​https://cloudup.com/c8X8mjNaY6C

[kevinwhoffman]

Can we step back from the design for a moment and think through a realistic implementation of such a feature?

If the idea is to notify users that they have a plugin installed which already provides the feature they are searching for, then it seems critical that we also point them to the relevant location to use said feature. It's not very helpful to search for a feature and be told that an installed plugin already provides it when I'm not aware of it in the first place.

The ​mockups suggest that this communication would be possible through a contextual hyperlink that points the user in the right direction, such as an appropriate settings page. It seems like plugin developers would have to add logic to their plugins that serves up the appropriate hyperlink based on the search term. Then core would have to look for those matching terms in the plugin's code in order to display the appropriate hyperlink.

Is it realistic to expect that most plugin developers would provide such contextual links, and if they do not, is the feature worth implementing if it can't fully deliver on the job it is supposed to do?

[cathibosco1]

Good points @kevinwhoffman - this is not a simple situation obviously.

In reading through the design meeting notes from yesterday and the trac ticket: https://core.trac.wordpress.org/ticket/46763

Only 3 design recommendations were discussed… There were additional mock-ups and context worthy of discussion.

I still feel strongly that this (see screenshot with green arrows please) user experience scenario is a very valid option if the need for notifying users about what their plugins are capable of functionally becomes a higher priority in this additional location within the admin.

The hierarchy issues and the consequences of them when separating the search results would be solved since we are already doing that in the tabs.

Also, it feels like this design should also be considered in context of @kevinwhoffman 's important insights by the teams.

​https://canddstudios.d.pr/Pb5Ted

[nerrad]

One thing that I think should also be considered as a part of this work is how plugins that are installed but not active fit into things. Is there validity in reminding the user that they already have a plugin installed (but not active) that accomplishes their needs?

Some other ideas:

• Merge the plugin list table and add new plugins screen into one view. The view defaults to installed plugins but the search field will return results for both the installed plugins (active and non-active) and plugins matching the query on wp.org.
• There's variations on how you could display these results for a search but one variation I'd like to see explored is that by default, the search shows the installed plugins with the results, and then a tab for "New" plugins with a count matching the results. So the _first_ view the user sees is what they have installed matching, but they can click the new tab to get the results from wp.org.

Very rough mockup: ​https://www.evernote.com/l/AAPbFGijVA9Dp7CT2q4lHZOQ0PdGOF_g5sAB/image.png

I think there's benefit to merging the disparate views for the plugin management page and improve the user experience solving many of the issues brought up in this ticket.

[mdwolinski]

I agree with @nerrad that this is a good opportunity to update the Plugin area and to combine them into one screen. Was just thinking on the same lines that he's talking about where Search will show a number under each tab that matches in the search.

However, I wonder if some standards on what the plugin authors can include in their headers that can be useful in the search so manually added/premium plug-ins benefit from the search as well.

For example

<?php
/**
  * Plugin Name: Some Plugin
  * Search Tags: Widget, WooCommerce, Media
  * Paid Search Tags: Payment Gate, Stripe, PayPal
  */

So if the feature the user is searching for is a paid upgrade for the plugin, the search results can indicate that.

[nerrad]

However, I wonder if some standards on what the plugin authors can include in their headers that can be useful in the search so manually added/premium plug-ins benefit from the search as well.

For installed plugins, this could just come from the readme.txt details in the standard format. There'd be no way for plugins to return results in the "new" tab unless they are distributed via wp.org. But we could explore a hook for plugins to return results for a special "Other Sources" tab (which I would suggest not going in the initial iteration and being explored in a separate ticket after this lands).

[mdwolinski]

Replying to nerrad:

For installed plugins, this could just come from the readme.txt details in the standard format. There'd be no way for plugins to return results in the "new" tab unless they are distributed via wp.org. But we could explore a hook for plugins to return results for a special "Other Sources" tab (which I would suggest not going in the initial iteration and being explored in a separate ticket after this lands).

Not tied to a specific way to accomplish it, but there was concern above that Premium plugins wouldn't show up in the search results and think that if one of the goals is to showcase plug-ins (active/inactive/premium) that have a feature, then there needs to be a way for those plugins not in the wp.org directory to get shown as well.

[jb510]

Replying to mdwolinski:

Not tied to a specific way to accomplish it, but there was concern above that Premium plugins wouldn't show up in the search results and think that if one of the goals is to showcase plug-ins (active/inactive/premium) that have a feature, then there needs to be a way for those plugins not in the wp.org directory to get shown as well.

Commercial/premium plugins not installed through .org can frankly do whatever the heck they want. The only gatekeeper to “good behavior” here are the plugin guidelines for the .org directory and the plugin review team’s interpretation of those guidelines. It’s why some (me included) feel .org plugins should be made to set good examples, to be the best representation of WordPress, not be given great leeway and make WordPress a mess.

If a non-org repo plugin wants to hide results from other plugins, or fake their review scores there is nothing, short of public shaming, to stop them.

[mdwolinski]

@jb510
Not sure what part of what I said you're responding to, my only point was that if I have a plugin installed, it would be nice if plugin authors had a defined way to be included in those search results as an installed plugin to show that they have whatever feature/term was searched for.

[jb510]

On the topic of active vs installed but inactive plugins.

As currently concievied it sounds like the content of the promoted result card would come from PHP code added to the plugin. Therefore, it’s only available to active plugins.

Honestly I think limiting this to active plugins seems reasonable, however I’d rather see the information that drives those promoted result come directly from .org, the same way search results do, not from the plugin’s active code.

One way to do this would be similar to what @mdwolinski mocked up above. Put this information in the plugin comment block or in the readme.txt. That has the added value of being transparent and easier to audit/police.

Something like (I’m making up links typing on a mobile device):

<?php
/**
  * Plugin Name: Some Sitemap Plugin
  * Search Tags: XML Site Map, Google News Sitemap, robots.txt
  * Installed Search Tags: xml sitemap [/admin.php?page=wpseo_xmlsitemap], open graph [/admin.php?page=wpseo_opengraph] 
  */

this could be limited to a reasonable number of terms per plugin, perhaps 5 tags per plugin, or limited to the same tags used as search terms.

[Ipstenu]

IMO the best way to encourage better behavior is to make it easier for them to achieve what happen to be shared goals.

As I understand it, our goal is this: Make it easier for users to find out that plugins they already have include the features they searched for.

A side benefit of this is that doing so will make it less lucrative for plugins to NEED to inject themselves like they have been, but TBH, the Plugin Guidelines can take care of themselves. The reality today is that we have something that is hookable and is being used questionably for a logical, and understandable, goal.

Even if we think of a plugin as being a uni-tasker (good for plugins, bad for my kitchen), a single task can have many different aspects and side-features.

So break it down simply, no naming names :)

Facts:

1. Users install a lot of plugins trying to find features they like/want/need.
2. This results in multiple plugins with noticeable overlap in provided features

Theory: The cause of this is that it's difficult to find the features as needed in the plugins they have.

Proposed Solution:

Make it more obvious that existing plugins HAVE the features by pulling installed plugins that meet the search criteria to the top of the list with a note to activate and/or utilize said feature.

Pros:

• Existing installed plugins will be more visible on searches, even if they're normally found on the 15th page, giving smaller plugins a fighting chance
• People will install fewer plugins to be happy, which will:
  • a) reduce their maintenance overhead
  • b) reduce the potential for cross-plugin conflicts
• Plugins will not need to home-brew their own promotions as much, reducing ads and clutter on admin panels

Cons:

• Existing plugins will be given greater weight even when they may not be the best solution for the user
• This may benefit larger plugins that include multiple features
• Directing users to plugins they already have, when they already cannot find the features, is frustrating
• If someone's experimenting with a lot of plugins, they will experience extra clutter

(I don't think this would change the benefit to larger plugins as much one might wish. They show up for those searches anyway right now, and they rank high because of the overall work put in to making them rank higher (more reviews, more support, better readme, etc). At least now you'd see WHY it showed up high.)

Concerns:

There have been no UX studies done on this, so we don't know if inline highliting results is better or worse than the proposed 'pull to the top.' The counter argument to this is that we've been including them inline for years, and it's demonstrably not helped. So the real question is this: Would making things in the results more visible have a larger or lesser impact than having them listed first?

There's also an importance on getting a first version of this out, as the cat is out of the bag on HOW to do this already, and more plugins will be attempting to advantage themselves. The sooner we can make _A_ solution that is easier for them, the less likely it is to be abused. Remember our lessons from internet piracy: People don't do it because they hate spending money, they do it because it's EASIER. If we made this for people, it's de facto easier and thus a lower abuse risk.

---

nb: Regarding this:

, but there was concern above that Premium plugins wouldn't show up in the search results

Premium plugins will still have to do some injection, since they won't show up on a search anyway, which is a bigger issue - should search include searching the LOCAL readme.txts? That would be a very interesting growth, and one that could benefit users in the long run, but I would call that a 'iterate later' feature and help maintain the overall ecosystem in a better way.

EVEN THOUGH we don't HAVE to care about non-org hosted plugins and themes, it's in our best interests as a COMMUNITY to consider how they would benefit. If we can make WordPress a less 90s spammy web for everyone, then I would take that as a MAJOR win. So yes, I'm going to think about them too :)

[JarretC]

Perhaps the plugin author should do a better job of explaining what features their plugin does offer so that the user doesn't have to go searching in the first place? Or if your plugin has that many features, maybe it has too many and needs to be broken up into multiple plugins? This "enhancement" will only tell current and future plugin devs that they should no longer create plugins geared toward specific ideas but to just create one plugin and add many things to it.

Why would developer Bob create "Bobs Forms" and "Bobs SEO" when he can just create "Bobs Plugins" and incorporate both of them into one plugin? 6 months down the road, he can build backups into the plugin, throw a notification into the dashboard and use his already current plugin userbase to freely advertise. Meaning that somebody that has put in their time to develop a plugin specific to backups, loses out on a potential user as that user would never search for a backups plugin in the first place.

[phpbits]

Can we step back from the design for a moment and think through a realistic implementation of such a feature?

I'm with @kevinwhoffman here, implementation comes first. How will the search tags be added by the plugin authors? Are these tags should be implemented on readme.txt? Since we are more concern on the plugins that users already have, inactive plugins should also be considered. There should be limitations for the search tags that can be included, if so how many? Guidelines for the links should be added too, will these links can be external information for the plugin features?

[mdwolinski]

Maybe we start out with a quick solution and have a couple of Trac tickets to iterate and add functionality.

I support the idea that @nerrad proposed on merging the Installed and Add New Screens, per his rough draft mockup: ​https://www.evernote.com/l/AAPbFGijVA9Dp7CT2q4lHZOQ0PdGOF_g5sAB/image.png

I believe that is a big win in usability.

When a user searches, it'll display the results in both the Installed tab and the Search Results tab.

This way the results are exactly the same as they currently are, but the user can switch to the Installed tab to see which plugins they have already installed that may provide a solution they're looking for. On the New search results, I don't think it matters much if installed plugins are still shown here, because then the user can still see where in the search results the plugin came up.

Then there can be a secondary Trac ticket that defines how Non wp.org installed plugins can be included in the search results. Again, this is not changing the New tab search results, only the Installed plugins.

Second, and this will be highly controversial, it would be beneficial to me as a user, if there was a way that non wp.org plug-in directories could be included in the search as well. I would recommend this be on a different tab. I suspect this would be implemented by plugin so the user would choose which directories they want to search.

Finally, if this all works, I would imagine the same design/merging would work for Themes as well.

Just happened to stop in the Themes area in the 5.2 beta and noticed the design change there. Not a big fan of the unexplained number badge hanging out on the left of the tab bar, but the design is similar to what I talk about. Also, their installed indicator is more prominent then the greyed out "active" button of the plugin area.

[mdwolinski]

Here's an idea on how to improve the search results for installed and active plugins. Not implying changing the search results order of them, just rough drafted the first two to show different states.