Plugins: Add 'Plugins' Menu Item for WordPress.com hosted sites to help users

[alisterscott]

Enhancement

During my support rotation there were a lot of users trying to find plugins in the dashboard.

I had an idea which is to add the Plugins menu option (for WordPress.com hosted sites) that shows a page with popular plugin functionality already available on WordPress.com (such as SEO optimisation, WordAds programme, social media buttons etc.)

This support page is a good place to base this off: https://en.support.wordpress.com/plugins/

It would be good to also have a place to suggest plugin functionality users would like (eg. http://www.yummly.com/ integration) and to track analytics on this page and what users were looking for.

Screenshot

[lancewillett]

This is a great way to reduce support requests and confusion between WordPress.com and WordPress.org.

[davewhitley]

I like the reasoning behind this, and I have no doubt that it would decrease those support requests.

My concern is that this sidebar item actually doesn't do anything for the user as an interface. They can't turn on/off plugins, they can't add/remove plugins. This is basically a list of features on WordPress.com. Wouldn't it be strange if Facebook's sidebar had a "Features" item, that just listed all of the things you could do on Facebook?

Ideally, our users shouldn't even be aware of Plugins — they should be just features of WordPress.com. Users wanting to upload Plugins is a symptom of the bigger problem (.org /.com confusion).

Or, we should completely embrace Plugins and add the ability to add a few. I think the old ecommerce screen was really smart in that way. I wish we had a few plugins that we could offer and upsell premium plans in this Plugins sidebar item.

If we had a concrete plan of adding the ability to activate plugins (like ecommerce) then I'd be more inclined to implement this idea as a first step.

[apeatling]

What if it did do something? I don't see any major reasons why we can't let users turn on or off plugins that we provide on WordPress.com depending on their needs. We could even do this automatically for different types of signups. For example if a new site is for a restaurant, we'd want to turn on a specific set of plugins, but maybe they don't want the "copy a post" plugin because they'd never use it and it's unnecessary in the interface.

One obvious way for users to "turn on" new plugins would be to toggle one that is only available on a higher plan, and then be offered the ability to upgrade their plan.

Users are clearly not aware of the features we offer them right now, and we are calling ourselves WordPress.com. This inherently comes with the expectation of plugins and themes, that's why we experience misunderstandings of this via support. I think if we embrace that by focusing around plugins, showing them in a list and explaining what they are then we can make a substantial difference. It also becomes a better way to organize the functionality of plans, and doesn't close the door in the future if we do want to offer the ability to upload your own.

[alisterscott]

Thanks for the the great ideas mentioned here.

I saw this issue as more of a pretotype that would allow us to quickly determine whether there's demand for WordPress.com plugins before we actually go and build plugin functionality for WordPress.com (so faking it and testing it before we make it)

[apeatling]

Agreed, just displaying a list of "plugins" we offer right now would be a great start and allow us to understand the value of this concept a little better. I would also like to see us change the way we present plans to match this thinking if it proves to be valuable.

[davewhitley]

So, I'm trying to work through this, mocking up what it would look like and how it should function. It will be helpful to visualize it. Also, trying to figure out what would be a good MVP (or pretotype!) for this; hopefully we can launch something in a week or so.

If we display a set of plugins, what should be the primary call to action, or function? With a short timeline, adding the ability to turn off/on plugins is out of scope. Here are some ideas:

1. Determine which "plugins" we currently offer in the existing paid plans and add them to this Plugins page. The CTA might be "Activate" and this would direct the user to upgrade to a paid plan. The only plugins I can think of are Google Analytics, No Ads, and VideoPress.
2. Include "fake" plugins that we don't actually provide right now (ecommerce, advanced editor, etc). The CTA would be "Learn More". A modal would pop up, explaining that "We are working hard to add more plugins. This one is not available yet." or something like that. Maybe we could be more upfront and label these plugins as "Coming soon...".
3. A combination of 1 and 2.
4. Only display the standard plugins that we offer in all plans.

Here is a mockup of number 3 (combo of 1 and 2):

[alisterscott]

Wow, this looks great @drw158

I really like the option 1: standard inbuilt plugins and upgrades with links to the plans if they are not included in their current plan. I think it would be good to also show themes under standard plugins ( something like '200+ high quality free WordPress.com Themes') and also under upgrades (something like '150+ premium WordPress.com Themes') which is enabled via the Business plan.

Also, I think it would be worth showing Podcasting Support as a separate upgrade option included in Premium or above with audio file uploads.

Would it be worth explicitly showing a list of the most popular plugin functionality under standard functionality with ✅s next to each and a link to find out more (support doc)? I had a look at WordPress.org most popular plugins combined with ours to get something like this:

✅ Akismet Spam Protection ✅ SEO ✅ Site Stats ✅ Security ✅Contact Forms including RSVPs ✅Google Integration including Google Maps ✅Automatic Backups ✅Event Calendars from Google and Eventbrite ✅Tlk.io Chat Widget ✅Twitter Integration ✅Facebook Integration ✅Instagram Widget ✅Flickr Widget ✅ Galleries/Carousel ✅Social Media Buttons and Likes ✅WebMaster Tools ✅Import/Export ✅OpenTable Reservations Widget

I am not sure on option 2 as it currently is shown. Maybe we could use this space to include a "custom/other plugins" section where the user tries to add a custom plugins to be shown a prompt like "we don't offer custom plugins at present, if you could let us know know what plugin you're trying to use so we can improve WordPress.com" (or similar) and collect this information. Alternatively a "fake" search for other plugins where we store the search terms and display a friendly message similar to the one above?

[apeatling]

Great to see the first wireframe. Here's a list of all the "plugins" that I think we currently offer: https://cloudup.com/cVezc37pNRy

Some feedback on what you have so far:

• Displaying plugins that we don't offer right now seems dangerous. It sets expectations that we may not be able to meet. Circumstances change, let's under promise and over deliver.
• I think for plugins in a paid plan, the call to action should be "Activate" that when hit offers some information about what plan you need to upgrade to in order to activate it.
• Listing all the plugins that we offer in the "Standard plugin suite" I think is really important, that has to be clear and one of the main reasons for building this. We want to lay out what you're getting regardless of plan level.
• We already have a plugins page for Jetpack sites. Should this page follow a similar pattern so you're not confused if you have multiple sites (one or more of which is a Jetpack site)? I think the current plugins page for Jetpack sites is not ideal for this, but it's worth considering.
• We also have an "All Sites" view for plugins. This kind of complicates that.
• The new list of "plugins" we currently offer is long, and I think a single column list is going to be overwhelming. What if we offered a fluid width page that expands with multiple columns depending on screen width? That could be interesting. The themes page is a good example of this.
• Since we have so many of these in the new list, it's worth thinking about how they can be grouped. There is prior art there at http://jetpack.com/features/
• I think premium themes should be shown under the themes section, and anything that isn't a plugin (like space upgrades or support levels) not shown here.

[ryanboren]

Will this advertise wp-admin experiences from Calypso? Running with the "Copy a post" example, would that be shown in Plugins even though it is a wp-admin only experience? Some plugins in this list have wp-admin provisioning ui. Their support docs are in the context of wp-admin.

[davewhitley]

Thanks all for the great feedback.

@alisterscott: I agree with Andy in that I do not think that themes should be included in this view. We should draw a line and only include things that are thought of as plugins. But, I can see the possibility of this evolving into a Plans page as some point. Maybe this page and the Plans page combine at some point down the road.

Thanks for gathering the plugins list. I agree that we could show more standard plugins. I think the key here is showing the most important, searched for, and asked about plugins. I don't want to combine all of our standard plugins into one card, but I also don't want to give the Eventbrite widget the same importance as Stats, for example.

@apeatling I'll try displaying more plugins with a different layout and grouping when appropriate. I want to give more importance to the more popular/asked about plugins.

Jetpack and All Sites view throws a wrench in the works. It gets intricate because we also don't have a Plans view for All Sites. Ideas:

1. Only show this new Plugins view if they have a single wpcom site selected.
2. In addition to idea 1, If they only have wpcom sites, then show the new Plugins view for All Sites. Links to the Plan view would force them to select a site (Could get messy. Maybe force them to select a site before they are shown the Plugins view).

I'm not sure the best solution. The point of the Jetpack plugins view is to update, add, and remove; you wouldn't do that on the new Plugins view for wpcom sites. They are pretty different structurally and functionally.

As far as the visuals, I think this design is similar to the Jetpack Plugins view in that it's a list of cards. We could make it look really similar, but maybe we should just do something completely different, since this view has a very different function.

[apeatling]

Thanks for gathering the plugins list. I agree that we could show more standard plugins. I think the key here is showing the most important, searched for, and asked about plugins.

Agreed on that, as long as it is clear and obvious that there's more plugins to look at, and that are activated. You should be able to see them all if you want to do that.

On the Jetpack/All sites side and matching that, I wouldn't worry about it at this point. Don't let those views contain your creativity here.

[davewhitley]

Gallery of multiple wireframes: https://cloudup.com/cGV9DKgjgLW

I experimented with categorizing the plugins, and just listing more plugins (gave priority to the popular ones). There are also a couple of widescreen ideas.

[alisterscott]

Gallery of multiple wireframes: https://cloudup.com/cGV9DKgjgLW

These look good. I personally like the basic list, and the widescreen list, what would the "+ 10 more essential plugins" section at the bottom of this list do? Would it link to the support doc? Do we need a "Learn more" link next to each essential plugin?

[roundhill]

Looking good, I'm excited for this. I'm wondering about the 'Active ✔️' label next to each plugin, does that imply that you can deactivate it? Since you can't I wonder if you could just put that they are active in the header of the section.

[davewhitley]

I personally like the basic list, and the widescreen list, what would the "+ 10 more essential plugins" section at the bottom of this list do?

My idea was that we would expand the full list of plugins. Some I still wouldn't include though, like the Shortlink plugin.

[apeatling]

For plugins without text below the name, how would I learn more about them? I think it's important that I can, since the primary purpose of this screen is educational.

[davewhitley]

The mockups that do not have text alongside the plugin name, I emphasized displaying the quantity of plugins rather than describing each one. I think it's a balance — do we want to list every plugin, or do we want to give more description with just a handful of the most important ones? I don't think listing every plugin along with a full description is a good option. Also, I gave more description to the paid upgrade plugins. So, what is that balance?

Reviewing these mockups again, I see that most don't have a lot of descriptive text, except for "grouped by category". Maybe for the other mockups, they could have a one-line description with a read more link.

[davewhitley]

My favorites:

• I like the "grouped by category" wireframe because it will be very maintainable, and fast to build. We don't have to update the page with every new "standard suite" plugin. The support doc could be updated to be organized by category, so there is a more direct comparison. Downsides are that specific plugins aren't visible, like Instagram widget.
• Next, I like "basic list" or "grid". Each one has room to add an additional short description for the standard plugins. Downsides are: writing and maintaining the full list/descriptions of the standard plugins.

[alisterscott]

My personal preference would be the list type with this added:

Maybe for the other mockups, they could have a one-line description with a read more link.

[apeatling]

I think it's a balance — do we want to list every plugin, or do we want to give more description with just a handful of the most important ones? I don't think listing every plugin along with a full description is a good option. Also, I gave more description to the paid upgrade plugins. So, what is that balance?

I think it's important to consider what the use cases are for building this page, and making sure what we are wireframing here helps with those use cases. If we do that, I think the direction becomes clearer.

The two main ones I have in my mind are:

1. A new user of WordPress who wants to learn about the features they have available to them.

Having a grouping of standard suite plugins for these users is probably enough, they just want to get a general overview of the features they're getting, and possible look at what higher plans offer. I doubt they want to drill down into each plugin and learn about each one.

2. A new or existing user who wants to install one of the top 50 WordPress.org plugins to add functionality.

These users are going to go to the plugins page and look to install the plugin they want. Chances are we already have this functionality available on .com, and they don't need to install the plugin at all. In this scenario clearly showing each plugin, and being able to read more about it would help persuade them that they don't need to install that plugin and move to .org. This scenario will also allow us to help guide the user to a plan upgrade if the functionality is not in their current plan level.

For the first use case, the grouping with little or no description is probably enough, but my belief is that the majority of support requests are coming from the second use case. I think for that one we need to be explicit about exposing and having some way to learn more about each individual plugin. That might not need to be on this page, but I think there needs to be some way (even through a modal) to access more details about each plugin we offer to them. Without that I fear they are not going to be persuaded that what we have on .com is enough for them, and still contact support.

[davewhitley]

Here are 3 new wireframes: https://cloudup.com/cVwVxqBg5L9

• Foldable cards: keeps the plugins organized by category, but allows the user to click the card to see all plugins in that category.
• Basic list with added descriptions: Just added descriptions on this wireframe.
• Basic list with header cake navigation: When you click on a standard plugin, it acts like the Jetpack plugin repository. You would click to go to a new page with a longer description.

I like how Slack presents their apps. Maybe we could do something similar.

[mtias]

@drw158 the last example is looking quite close to the Jetpack browse plugins page, should we just reuse those components and polish where needed?

[davewhitley]

We could, but I wasn't sure how much we could reuse. We wouldn't have the avatar or the star rating, and we'd need an additional description as well. The grid layout could work though. I don't think the header cake navigation would work well. We don't have enough info for each plugin to warrant a second view.

[davewhitley]

Quick mockup of that idea. We'd need to make sure there was an appropriate gridicon for each plugin. Not sure what should happen if you click on a plugin.

[apeatling]

We can definitely come up with enough description information for each plugin, we could even include screenshots, just like you get when you click a plugin for a Jetpack site, or on the .org repo.

[mtias]

It could include some documentation on how to use something in the future.

[apeatling]

We wouldn't have the avatar

I expect we can also come up with icons or graphics for each plugin too.

[apeatling]

@ryanboren Missed your earlier comment:

Will this advertise wp-admin experiences from Calypso? Running with the "Copy a post" example, would that be shown in Plugins even though it is a wp-admin only experience? Some plugins in this list have wp-admin provisioning ui. Their support docs are in the context of wp-admin.

I don't think we would show wp-admin functionality here, I think doing that is an overall negative to the experience, even if we don't offer it in Calypso. Something like copy a post is on the list to add to Calypso for plans, so I expect as we move through the year there will be little in terms of appealing functionality that would not be in Calypso.

[davewhitley]

To keep the scope manageable, I propose that we do this:

• Use a layout similar to the current Add Plugins page, use the grid.
• Write a short one line description for each of the standard plugins.
• Write a short description of each of the paid plugins (can be a bit longer).
• Edit the Plugins support doc so that it's organized by category.

Wireframe:

• Clicking on the view all link simply expands that area to show all standard plugins.
• Clicking on a standard plugin will redirect to the corresponding support doc.
• Clicking Activate will take you to the Plans page.

I like the idea of fleshing out each Plugin with its own "page" and screenshots, but that is out of scope in my opinion.

[apeatling]

I like the idea of fleshing out each Plugin with its own "page" and screenshots, but that is out of scope in my opinion.

Agreed, we should launch something like this before we add more details.

What would happen if I was on a higher plan and those plugins were activated?

[davewhitley]

I was thinking something like this if the user has a higher plan activated.

• Activated buttons would be green, or just borderless. Wouldn't appear clickable.
• Text somewhere stating which plan you are on.

[apeatling]

Looks good!

What about tackling the need to install a plugin? I would be concerned right now that this page could actually increase support requests. We might get more people seeing plugins, expecting that they can install one and contacting support because they can't find the button.

Is it worth having something like a simple "Install" button that show a message explaining that you can't install plugins and check the list below for the ones we offer?

[davewhitley]

Is it worth having something like a simple "Install" button that show a message explaining that you can't install plugins and check the list below for the ones we offer?

I think displaying an "Install" button might be a bit on the misleading side. I think we can explain the plugin installation issue upfront. Here are a few mockups with varying degrees of visibility:

[apeatling]

I like the blue one the best, I think it needs to stand out, generally speaking people don't read text unless it pops out at them.

[alisterscott]

I also like the blue one.

One suggestion on wording: should we say:

'Uploading and installing your own plugins is not available on WordPress.com, but we offer the most essential ones below. Learn More."

just to make it clear we offer plugin functionality just not the ability to upload or install your own?

[mtias]

Looking good!

[folletto]

Use a layout similar to the current Add Plugins page, use the grid.

:100:

Write a short description of each of the paid plugins (can be a bit longer).

One thing that I find a bit confusing in that mock is that they are not plan-related. It seems one can activate each plugin independently, instead of activating bulks of them as a plan. I'd probably group everything in blocks, each matching a plan and with a single activate button.

I like the blue one the best, I think it needs to stand out, generally speaking people don't read text unless it pops out at them.

This is actually counter- intuitive, but I wouldn't be surprised to see that an actual blue banner would be read less → banner blindness. I'd personally lean more into a top panel with a more concise text, and something maybe that is visible but not "boxed".

I'd also note that we don't use page titles anywhere, and that top card looks a lot like a title+abstract piece instead of something informative.

So... quick mock to iterate and summarize all of the above:

And probably at the bottom of that page a message saying "It's not possible to install more plugins.".

[davewhitley]

I'd also note that we don't use page titles anywhere, and that top card looks a lot like a title+abstract piece instead of something informative.

I try not to use page titles when possible, but I felt like this page needed it. Looking over it again, I think the core of what needs to be communicated is that "Plugins cannot be installed" so I think I'd be fine with removing all text except for that notice.

I like your mockup, thank you for that. I think the "can't install" message might need to be at the top, depending on how long the page gets and how many plugins we display.

Unfortunately we really only have about 5 plugins on both paid plans, depending on what we consider a plugin. Currently we only have 1 Business plan plugin. I don't think the grid layout would work well for the paid plugins. It does makes sense to somehow group them (either in a list or grid), but my only hesitation is that the Business plan will only have one item, no matter how they are grouped.

One thing that I find a bit confusing in that mock is that they are not plan-related. It seems one can activate each plugin independently, instead of activating bulks of them as a plan. I'd probably group everything in blocks, each matching a plan and with a single activate button.

My goal here is to display these plugins as separate features, and not to display them in a plan format (a redesign of the Plans page is underway, with an emphasis on "plugins"). I feel that we'd get more interest if we didn't emphasize plans on this page. But, I think your mockup rides that distinction well, so that is probably worth exploring. Even though it's misleading, I like the idea that the paid plugins each have their own activate button. Makes it seem like you are buying an individual plugin, rather than a plan.

[folletto]

I like your mockup, thank you for that. I think the "can't install" message might need to be at the top, depending on how long the page gets and how many plugins we display.

Clear. Are you thinking a message along the lines of: "WordPress.com provides only pre-installed plugins, no installation possible, to ensure maximum safety, stability and speed."?

It does makes sense to somehow group them (either in a list or grid), but my only hesitation is that the Business plan will only have one item, no matter how they are grouped.

I see the issue. Then probably the way to deal with that is to have that 3-col grid scalable to 2-col and 1-col too as needed (probably in a way similar to your mockups above).

Makes it seem like you are buying an individual plugin, rather than a plan.

I think the important bit there is to keep the header and the activation button correlated to the plan instead than the feature. :)

I would find the individual activation of a plugin incredibly misleading. I might be wrong, but really feels sending mixed signals.

[davewhitley]

Quick wireframe with feedback into consideration

[folletto]

:100:

[apeatling]

Love it

[designsimply]

I would find the individual activation of a plugin incredibly misleading. I might be wrong, but really feels sending mixed signals.

I agree. An activate button that leads to buying a plan doesn't seem right. In that case, the button should say "buy" or "purchase" or "plan" so it's reasonably clear what the button will actually lead to.

Organizing plugins by plan seems a lot more clear from a user perspective.

Uploading and installing your own plugins is not available on WordPress.com, but we offer the most essential ones below. Learn More.

What's "essential" to one user may not be "essential" to another. Suggest changing to "popular" or re-wording without a bias: "Uploading and installing your own plugins is not available on WordPress.com, but we offer a wide variety of plugins pre-installed. Learn More." cc @ranh (for a quick look at this wording if you have a min)

Would also like to communicate the benefit of plugins being maintained by our developers… we can revise https://en.support.wordpress.com/plugins/ to make that more clear. That is a really really nice benefit! cc @mashmac2 (in case you'd like to follow along and be involved in editing that doc)

[roundhill]

Would also like to communicate the benefit of plugins being maintained by our developers

Awesome idea :+1:

[davewhitley]

Agreed on most everything.

I hope to update https://en.support.wordpress.com/plugins/ alongside this launch, so that they share the same information (category, plugin name, etc.)

Would also like to communicate the benefit of plugins being maintained by our developers

This is something I haven't thought about. From the average user point of view, I don't see a benefit, and could possibly muddy the message. I (the user) assume and hope that everything on WordPress.com is maintained by the company, and does not rely on something 3rd party. An experienced user might benefit from this information though — someone who has suffered using plugins on .org that become dormant.

I think the plugins doc is a good place to push this benefit (which I think is what your idea was), but it probably shouldn't be on the Plugins page.

[dmsnell]

Hijacked by #4572

[davewhitley]

launched to a % of users https://github.com/Automattic/wp-calypso/pull/5022