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

WordPress Trac noreply at wordpress.org
Fri Apr 5 16:04:16 UTC 2019

#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:  needs-design-feedback  |     Focuses:  ui, administration

Comment (by 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

 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-

 So break it down simply, no naming names :)


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

 **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.


 * Existing installed plugins will be more visible on searches, even if
 they're normally found on the 15th page, giving smaller plugins a fighting
 * 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


 * 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.)


 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 :)

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

More information about the wp-trac mailing list