Making WordPress.org

Opened 14 months ago

Closed 13 months ago

Last modified 11 months ago

#7035 closed enhancement (fixed)

Plugin Directory: Add filters for community & commercial plugins

Reported by: ryelle's profile ryelle Owned by: ryelle's profile ryelle
Milestone: Priority: normal
Component: Plugin Directory Keywords: has-patch
Cc:

Description

The ability to categorize a plugin as "community" or "commercial" was launched at the end of last year, and many plugins have opted into these. The category shows up on individual plugins, but there currently isn't a UI to filter plugins by category.

The attached design should be used, adding navigation links to filter the current view to just the selected category.

Attachments (1)

Plugins bar.png (100.9 KB) - added by ryelle 14 months ago.

Download all attachments as: .zip

Change History (12)

@ryelle
14 months ago

This ticket was mentioned in PR #142 on WordPress/wordpress.org by @ryelle.


14 months ago
#1

  • Keywords has-patch added

This adds "Commercial" and "Community" (and "All") links to the top of the plugins grid. When clicked, it filters the current archive by the selected business model.

This taxonomy already existed as "Business model". The filter URLs already work on production: for example, all community plugins or commercial block directory plugins.

When the archive title is generated, it's "Business Model: Commercial" & "Business Model: Community" — do we want to change that at all?

The filters exist on all archives except the "beta" view, since these are likely all "community" (or eventually "canonical"?). Should they apply to "My Favorites" (see screenshot below)?

The mockups also include a "Canonical" link, which does exist on the site, but there are no plugins in it yet, so I did not add it here.

cc @WordPress/meta-design

Before After
https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/fb265e60-796f-4743-aaa0-bd4465196e83 https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/fdefcd06-b74f-4137-99e6-66ab150537a9

All community plugins (https://wordpress.org/plugins/?plugin_business_model=community)
https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/43d58075-f287-4c89-a1f6-ed0a566adb28

My Favorites — currently has the filters, but we could remove if this seems unnecessary. I removed the curation filters from favorites on the Pattern Directory, but that is a slightly different use case.

https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/549995f1-6fcd-4327-a4e9-ad31e70b83a7

The filters also apply to rosetta sites:

Arabic Korean
https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/dd2cb3d8-bd67-4179-b89b-41993265e16d https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/845e04da-2477-450b-88eb-6be92c7b0949

Ticket: https://meta.trac.wordpress.org/ticket/7035

@dufresnesteven commented on PR #142:


14 months ago
#2

When the archive title is generated, it's "Business Model: Commercial" & "Business Model: Community" — do we want to change that at all?

Maybe we can go with:

  • Commercial Plugins
  • Community Plugins

We should also probably update the copy on the filtered view before launch. They have pluralization problems:

This plugin is developed and supported by a community. should be These plugins are developed and supported by a community.

Screenshot
https://i0.wp.com/github.com/WordPress/wordpress.org/assets/1657336/dffd0e78-f63d-45fc-9339-67c51c45fbec

@dufresnesteven commented on PR #142:


14 months ago
#3

The filters exist on all archives except the "beta" view, since these are likely all "community" (or eventually "canonical"?). Should they apply to "My Favorites" (see screenshot below)?

I don't think it's necessary for that view.

jasmussen commented on PR #142:


14 months ago
#4

Looks good, thanks for working on this.

@ryelle commented on PR #142:


13 months ago
#5

I've removed the filters from the "Favorites" page, and updated the title & description on the archive pages, so those now look like this:

Community Commercial
https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/2a0c4f51-4022-4113-b561-a0cc57f2daf0 https://i0.wp.com/github.com/WordPress/wordpress.org/assets/541093/734264c5-3b8f-47bd-b3cf-177473d5b11f

#6 @ryelle
13 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 12643:

Plugin Directory: Add navigation to filter "community" and "commercial" plugins.

Fixes #7035

@ryelle commented on PR #142:


13 months ago
#7

Committed in r12643.

#8 @justlevine
13 months ago

(was directed here by the Make post to provide feedback).

I think the use of Community and Commercial as taxonomy terms is a bad approach and potentially harmful:

  1. They're broad and provide no semantic value to the directory. What is the difference between the two? Which is WooCommerce (lots of community contributions, but lead by a8c, not freemium but has paid extensions)? Which is WPGraphQL (sponsored by WPEngine, WPEngine users get premium support, all dev is on GitHub, and no feature upsells)? Which would hypothetically be WPGraphQL for FacetWP( a repo of community contributions that I voluntarily maintain, and in exchange I'm the recommended developer if someone needs some enterprise troubleshooting)? Etc etc.
  2. They are ripe for misinterperative 'virtue signaling'. Should enterprise users only install Commercial plugins (as a sign of quality), or should ecosystem advocates gravitate to Community plugins (as a sign of open source ethos)? Wherever your subconscious bias leads you, it's still wrong, because of point 1.

Instead, I strongly suggest the directory takes a semantic, user-centric approach, where the term names offer unambiguous information for a user to filter by.

For example:

  • has paid features. Unlike "Commercial", there's no bias about whether the plugin is scalable or conversly just freemium bait.
  • has paid support. Same as above. It let's the user filter by something they actually want to know, without being prejudicial.
  • accepts community contributions. E.g. does development happen in a public GitHub repo, and not just created by a single person/sponsored dev/company. This is the only concrete test of "Community" that I could come up with (edit: at least until there's an actual criteria for canonical plugins). Note: I opted _against_ has public repository since that's less user-centric)
Last edited 13 months ago by justlevine (previous) (diff)

#9 follow-up: @coffee2code
13 months ago

Any classification system is going to have its edge cases and overlaps. The more comprehensive, and thus finer-grained, you make a classification system, the more complex it becomes. The more complex, the harder it becomes to manage and the harder for users to understand.

Being a commercial plugin/theme does not preclude community contributions. Nor does being labeled as such suggest a bias or prejudice on the part of WordPress.org or the community. (You may be reading your own biases into the labels.)

"Commercial" simply informs users that the plugin/theme offers commercial upgrades, extensions, and/or support. If those are the case, then a plugin/theme can be classified as commercial. WooCommerce clearly fits into this classification and is classified accordingly. Based on your description, both WPGraphQL and WPGraphQL for FacetWP (were it available in the directory) seem very clearly to be "Community" plugins.

Currently, the classification is opt-in by the plugin's developers, so if they feel their plugin is "Community", then that's what they can request. Likewise if they feel it's "Commercial". Or they can opt not to be classified at all.

Should enterprise users only install Commercial plugins (as a sign of quality), or should ecosystem advocates gravitate to Community plugins (as a sign of open source ethos)? Wherever your subconscious bias leads you, it's still wrong, because of point 1.

Users can do what they wish with the information provided. There is no implication that a commercial plugin is of any different quality than any other plugin. It literally is just indicating that there is a commercial aspect of some form for the plugin.

We can't control people's biases. Someone could feel a commercial plugin is just going to be limited, that non-paying members might be treated as second-class users, and that it'll just constantly upsell to them. Others could appreciate that there is a business behind the plugin and that the commercial aspect makes the plugin more sustainable, more reliably supported, and that a marketplace or extensions enhances the vibrancy of its ecosystem. Any or all of those biases for either views may or may not be true for any given plugin or even generally. The "Commercial" classification doesn't inherently imply any of them.

#10 in reply to: ↑ 9 @justlevine
13 months ago

Replying to coffee2code:

I happen to agree with _most_ of what you wrote. Especially the last bit:

Any or all of those biases for either views may or may not be true for any given plugin or even generally. The "Commercial" classification doesn't inherently imply any of them.

It's the lack of a scoped definition IMO that allows any implication to be read into the taxonomy names. Which adds cognitive load and fosters implicit biases in multitudes of possible connotations, many of which of which could be easily avoided by coming at them from the perspective of "what is a user actually trying to find?".

Additionally, I do not believe that switching to a user-centric taxonomy is somehow "more complex" than the existing classification binary. I would love to see the user story for searching the directory for a "plugin/theme offers commercial upgrades, extensions, and/or support", and the other binary where someone only wants to view themes/plugins with _none of those_.

Replacing Community|Commercial, with just has paid features|has paid support (or however it's phrased), gives users the same number of choices, but in a way that address their needs more directly and with less cognitive load.

And if the Make post is correct, and these are just the first tax terms with more possibly OTW, then a user-centric taxonomy is going to scale a whole lot better than arbitrary (from the users perspective) groupings. (E.g. where do the eventual functional categories of canonical, feature plugin, or any other possible category fall on a map along with community and commercial).

#11 @cbirdsong
11 months ago

I don't know if this should be a new ticket or not, but these are functionally not filters on tag pages. When you are on a tag page (ex. https://wordpress.org/plugins/tags/optimize-images/) and click "commercial" it takes you to the untagged filter for "commercial" instead of filtering the tag as "commercial". If they can't be made to actually filter the tag then removing them from tag pages seems better than leaving them as is.

Last edited 11 months ago by cbirdsong (previous) (diff)
Note: See TracTickets for help on using tickets.