[wp-trac] [WordPress Trac] #46763: Improve plugin search results with already active plugins

[WordPress Trac]

#46763: Improve plugin search results with already active plugins
-------------------------+---------------------------------
 Reporter:  joostdevalk  |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui, administration
-------------------------+---------------------------------

Comment (by 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.
 The "add new" button at the top of the "Installed Plugins" page is a weird
 journey for a user anyways, 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:

 a. 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.
 b. 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46763#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform