Plugin card table to replace WP_Plugin_Install_List_Table

[tellyworth]

List views in the plugin installer (Search Results, Featured, Popular, Newest, Favorites, Beta Testing) should be replaced with a redesigned list.

The new list should be a multi-column view of plugin cards, something like the wireframe example here:

​https://cloudup.com/cTRbiF0_Lla

The cards would give a more useful overview of each plugin, including banner-style images and compatibility info at a glance.

Mockups posted above. Was thinking we'd follow the width logic of the dashboard widgets, and give each container a min-width of 255px, and make the max-width percentage based. When we reach the next large breakpoint, we can show up to three columns of plugins (four seems like too many, so I'd cap at three). Once the width of each plugin hits < 400px, we should drop the buttons down to underneath the description:

Love the mockups.

I added a draft patch that implements an approximation of this. It's definitely not pixel perfect, and the CSS is a bit skittish with resizing and different content sizes. I put the download count in place of active installs because the API doesn't yet return the install count (will work on that shortly).

One thing I noticed is to do with author names and the "+ n more" bit. Sometimes the author is a company name, and not in the contributors list; other times it's a person and is in the contributors; and I found one or two where the author name is like "Jim1, Bob2", either or both of who could be in the contributors list. Not sure if it's worth some fiddly logic to handle all those cases, or if it'd be better to drop the number and just say "By Bob Smith + more".

clear .plugin-cards due different height

Nice work tellyworth. Had to fix for large screen ​http://i.imgur.com/qziUVws.png

Removed language-chooser.js diff

Very cool, love it!

Can someone tweak the styles to degrade better when reducing the screen width?

​https://cloudup.com/czm-BgeFKgI

It'd be swell if the card could "soft-wrap" better to 1 column, taking the full width when available.

Adds a media query for plugin cards to start taking 100% of the width for smaller screens. Chose arbitrary value of 782px, which is used further down for the HDPI media queries.

Oh would you look at that, "someone" could. ;)

See 28785-plugin-card-table-draft.4.diff

Results: ​https://cloudup.com/cfJGWQKTMuY

I wanted to play and see if I could set the banner as a very subtle background for the plugin-card div, when available (maybe with a white overlay, opacity 0.4 or so, to diffuse it). I don't see banners being returned as part of the query results yet though.

Wouldn't always work IRL though, since plugins devs actually layout some info in their banners sometimes, and expect the banner to be displayed in full. To be fair, they'll have to get used to not being able to do this in the future though, because said banners will now be displayed in a multitude of contexts (maybe here, in modal, on wp.org, etc). It's unlikely to be viable to ask them to provide [n] different banner sizes, all with different aspect ratios. It also "limits" our ability to play with designs (if we try to guarantee banners will be displayed in full, precisely).

Wadya think?

I wanted to play and see if I could set the banner as a very subtle background for the plugin-card div, when available (maybe with a white overlay, opacity 0.4 or so, to diffuse it). I don't see banners being returned as part of the query results yet though. ... Wadya think?

We already have plans to add in a small graphic in the next iteration, so I wouldn't worry about it.

Trying out secondary button + link styling in Screen Shot 2014-07-08 at 11.00.49 AM.png​, in place of primary button + secondary button. Better?

Better, but install should stay primary.

Tried with low banner

Replying to michalzuber:

Better, but install should stay primary.

It felt like there were way too many primary buttons on the page, which is why I switched it down to secondary. I'm not sure we need the install button on every single plugin to be primary.

I would recommend primary only due visual "call to action". Screens for 28785-plugin-card-table-draft.5.diff -> community decides ​http://i.imgur.com/DAD0Tc8.png and ​http://i.imgur.com/hQDxjue.png :) Sorry no time now to put title over banner.

Replying to michalzuber:

I would recommend primary only due visual "call to action".

I'm not sure we need that much of a call-to-action on every single plugin, though. It feels excessive. We're not emphasizing any one plugin over another, so they all have equal weight — but that weight probably shouldn't be "install every single one of these."

Having the entire card be clickable to view the modal might be a nice idea to reduce the weight of buttons. Then you could simply get rid of the "More Details" button/link and have a hover state for when you hover over the card.

Replying to paulwilde:

Having the entire card be clickable to view the modal might be a nice idea to reduce the weight of buttons. Then you could simply get rid of the "More Details" button/link and have a hover state for when you hover over the card.

That's not really touch-device friendly, though. It would also conflict with the other links in the block, making it really easy to accidentally open the details modal.

Replying to melchoyce:

Replying to paulwilde:

Having the entire card be clickable to view the modal might be a nice idea to reduce the weight of buttons. Then you could simply get rid of the "More Details" button/link and have a hover state for when you hover over the card.

That's not really touch-device friendly, though. It would also conflict with the other links in the block, making it really easy to accidentally open the details modal.

You can easily increase the touch area using negative margins (See ​http://jsfiddle.net/joshnh/FBPMX/show/) to eliminate accidental touches for the author/review links.

The entire card opening the modal/more info pane is at least consistent to how it works in the iOS App Store and feels more natural rather than hunting for a link to view more info. Not sure about Android though.

28785-plugin-card-table-draft.5-alt.diff​ cleans up the CSS to match the mockups more, switches the description to use the short description, rather than trimming the full description, and switches the 2 buttons to secondary + link, rather than primary + secondary.

This ticket was mentioned in IRC in #wordpress-dev by stephdau. ​View the logs.

Few bits of feedback:

• These cards look great! Liking it a lot.
• The phrases "{Untested|Compatible|Incompatible} with your install" don't make sense. Need to mention something to do with the version.
• I actually prefer the original mockup which included a primary and secondary button, instead of secondary button and link. "Install now" is the primary action for each plugin, after all.
• The "By" line should go on its own line to avoid wrapping and to avoid nonsensical phrasing when the plugin description doesn't end with a period.

Replying to johnbillion:

• The phrases "{Untested|Compatible|Incompatible} with your install" don't make sense. Need to mention something to do with the version.

What should it say? I agree that "with your install" is a bit ambiguous. But there's limited space. Perhaps "..with WordPress x.y.z"? That will look a bit repetitive I think.

One other thing that occurs to me:

The list views that this replaces didn't have bulk actions. But bulk install is a potential feature. And if we're to use a similar design to replace WP_Plugins_List_Table for managing installed plugins, it'll need a bulk selection tool. Any suggestions for how that should look?

What about the ​Internationalization goals for 4.0?

Relevant snips from the above post: (emphasis mine)

3) "You should be able to search from the dashboard for plugins and themes that are available in your language."

With language packs (more on that soon), plugins and themes will be able to be translated into any language. The goal would then be to have “localized” plugin and theme directories on the translated WordPress.org sites, listing just the plugins or themes available in their language. Note that even a plugin or theme without strings have a name and description that can be translated.

The plugin and theme install screens in the dashboard should similarly gain this ability. In all cases, there would be an option to expand the search to plugins/themes available in any language, of course — along with the invitation to translate them.

Core work:

"Support searching for plugins/themes in a particular language, as well as leveraging translated data fields that come through from the API response. This mostly just means sending back the site’s language to WordPress.org. It also requires UI to reveal results from any languages. We could possibly filter/hide/show on the client side, if results were not paginated."

And from ​Internationalization project updates (emphasis mine)

3) You should be able to search from the dashboard for plugins and themes that are available in your language.

This is handled on the WordPress.org side. The updated plugins screen will need to pass a new argument to filter by language, and then remove that argument if the user requests showing plugins in any language. We’ll need to hack in readme/description translation support but that’s a small API change and otherwise WordPress.org work, not core work.

Replying to netweb:

What about the ​Internationalization goals for 4.0?

Those are fair points, but I think they belong in a separate ticket.

Replying to tellyworth:

it'll need a bulk selection tool. Any suggestions for how that should look?

Hmm. I have thoughts of clicking the card to select, and highlight it when it is, but it's not an obvious call to action in and of itself.
I usually clue the user in that they can by still having a checkbox, which has the same behavior when checked, but the cards in the mockup and patch are pretty compact already. Not seeing where I'd have a checkbox.

Mel?

Replying to tellyworth:

Replying to netweb:

What about the ​Internationalization goals for 4.0?

Those are fair points, but I think they belong in a separate ticket.

Ooops, yes, I may have left out this little bit of context ;)

"Code for this is not yet in core, though the UI/UX for this should probably also be considered now as part of this ticket, rather than have two rolling tickets, two sets of mockups, and two sets of patches for the 4.0 milestone for the same UI.

EDIT: Had a look at what I listed above that should be considered for each plugin card:

1. The "invitation to translate the plugin" link, via the 'More Details' modal or front and centre on each?

2. What about each plugin card displaying the plugin locale dependant on the current view context?

Maybe some get_user_option( 'wporg_favorites' ) on each card with/without ratings?

Very nice, but there is a tab wp-admin/plugin-install.php?tab=favorites, which is more convenient for filtering out favourites. Should I need to know that when not searching in my favourites?

Replying to michalzuber:

Very nice, but there is a tab wp-admin/plugin-install.php?tab=favorites, which is more convenient for filtering out favourites. Should I need to know that when not searching in my favourites?

I agree, when you only want to see your favourites that's fine, as my design skills are challenged to say the least I thought I'd throw it up as an idea, maybe not the full 5 stars taking up all that space and just an indicator that it is.

It would be cool to be able to mark the plugin as a favourite if it wasn't already but that brings a whole new set of issues along with it as you'd have to be logged in to wordpress.org...

Replying to netweb:

I agree, when you only want to see your favourites that's fine, as my design skills are challenged to say the least I thought I'd throw it up as an idea, maybe not the full 5 stars taking up all that space and just an indicator that it is.

It would be cool to be able to mark the plugin as a favourite if it wasn't already but that brings a whole new set of issues along with it as you'd have to be logged in to wordpress.org...

Yep, nice, but with those stars it would be to much. I thought about a corner icon with one star or just some small text. Just a quick mockup made on notebook with touchpad

Ticket for showing compatibility: #28646

Links the plugin title in each card to also open the plugin details thickbox. Also adds a new filter for the details link, since devs could have filtered its value through the plugin_install_action_links filter, but the title on the link would have been unaffected.

I've submitted 28785-plugin-card-table-draft.6.diff (based on tyelle's 28785-plugin-card-table-draft.5-alt.diff) to also link the plugin title to open the details thickbox.

​https://cloudup.com/c2nRjs7bqAJ

I was also finding that the "More details" link was now too subtle as a simple link, not a button, so having the title also linked to the same might alleviate some of that concern, without overloading the page with buttons, be they primary or secondary.

Because devs could filter the details link value through the existing plugin_install_action_links action filter, but that this filter would have not affected the link on the title, I've also added a plugin_install_details_link filter while I was at it, so it can still be.

I was just testing the UX/UI, and while searching plugins, I do admit that, as michalzuber, I wished I had access to the "favorite" action in the card. My use case at the time: searching, wanted to favorite as a quick simili for a "shopping cart" or "to review" queue that I could review later.

Replying to tellyworth:

One other thing that occurs to me:

The list views that this replaces didn't have bulk actions. But bulk install is a potential feature. And if we're to use a similar design to replace WP_Plugins_List_Table for managing installed plugins, it'll need a bulk selection tool. Any suggestions for how that should look?

Bulk actions are out of scope for this — let's discuss them separately.

Replying to johnbillion:

• The phrases "{Untested|Compatible|Incompatible} with your install" don't make sense. Need to mention something to do with the version.

The version doesn't matter for a majority of users, who often don't know or care what version of WordPress they're using. What matters is knowing if the plugin is compatible with your particular install. However, I agree the phrasing is weird and maybe promises too much. We should try to find a better way to communicate the idea that the plugin should work with your version of WordPress.

Replying to stephdau:

I've submitted 28785-plugin-card-table-draft.6.diff (based on ryelle's 28785-plugin-card-table-draft.5-alt.diff) to also link the plugin title to open the details thickbox.

​https://cloudup.com/c2nRjs7bqAJ

I was also finding that the "More details" link was now too subtle as a simple link, not a button, so having the title also linked to the same might alleviate some of that concern, without overloading the page with buttons, be they primary or secondary.

Great idea! I think this is a good compromise between either doing primary/secondary or just secondary/link.

Replying to stephdau:

I was just testing the UX/UI, and while searching plugins, I do admit that, as michalzuber, I wished I had access to the "favorite" action in the card. My use case at the time: searching, wanted to favorite as a quick simili for a "shopping cart" or "to review" queue that I could review later.

This is a good idea, but I think it's a workflow we should try to optimize at another time, since it will take additional thought and research into making it work well. For now, let's try to stay focused and in scope.

Replying to melchoyce:

Replying to johnbillion:

• The phrases "{Untested|Compatible|Incompatible} with your install" don't make sense. Need to mention something to do with the version.

The version doesn't matter for a majority of users, who often don't know or care what version of WordPress they're using. What matters is knowing if the plugin is compatible with your particular install. However, I agree the phrasing is weird and maybe promises too much. We should try to find a better way to communicate the idea that the plugin should work with your version of WordPress.

What about the following, it's more human?
10 people say it works.
2 people say it's broken.

From WPorg plugin detail page (example ​http://wordpress.org/plugins/jetpack/)

In 29047:

Display plugin install results as "cards" rather than in a list table, first run.

props stephdau, ryelle, tellyworth, melchoyce. see #28785, #28646.

Replying to johnbillion:

• The phrases "{Untested|Compatible|Incompatible} with your install" don't make sense. Need to mention something to do with the version.

Totally +1. But instead of a version number what about "your WordPress version" - maybe a bit to long?

Replying to stephdau:

Because devs could filter the details link value through the existing plugin_install_action_links action filter, but that this filter would have not affected the link on the title, I've also added a plugin_install_details_link filter while I was at it, so it can still be.

I don't think this filter is necessary. plugin_install_action_links is still available like before. Also there are other screens, which are using the same link/modal, so the filter is missing on them.

This ticket was mentioned in IRC in #wordpress-dev by ocean90. ​View the logs.

In 29171:

Remove plugin_install_details_link filter, which was added in [29047].

see #28785.

28785.patch​

• Use esc_url() for URLs
• Re-use "Last Updated:" string
• i18n for "%s ago"
• _n( '%s download', '%s downloads', $plugin['downloaded'] )

---

I noticed that some plugin descriptions doesn't end with a fullstop, for example bbPress:

bbPress is forum software, made the WordPress way By The bbPress Community

Looks a bit odd, because of the capitalized "By".

Replying to ocean90:

I noticed that some plugin descriptions doesn't end with a fullstop, for example bbPress:

bbPress is forum software, made the WordPress way By The bbPress Community

Looks a bit odd, because of the capitalized "By".

Thanks, and all is good now, fixed in ​plugins:changeset:948467

This ticket was mentioned in IRC in #wordpress-dev by tellyworth. ​View the logs.

In 29219:

Plugin install cards:

• Move author attribution to its own line.
• Use esc_url() where appropriate.
• Better i18n.
• min-height for cards for a more even appearance.
• Show more cards on wide screens.
• Tighten up spacing below the filter bar.

props ocean90, helen. see #28785.

I think we're just about done with this particular ticket - the one remaining issue I'm gleaning from the comments is from johnbillion. Further issues can be dealt with in new tickets.

The phrases "{Untested|Compatible|Incompatible} with your install" don't make sense. Need to mention something to do with the version.

I agree that it doesn't really make sense - I'm less concerned about the version of WP itself, but "your install" to me implies everything about your install, which is not something we can really promise is compatible. What's a brief phrase we can use here that indicates we're talking about your version of WP?

I tried buttons for both install and details locally, by the way - did not like it very much. It turned out to be overwhelming.

How about "Works with current version", "Not enough data for compatibility", "Not compatible with current version" ?
I think it could have pieces from Compatibility from the right sidebar at ​http://wordpress.org/plugins/jetpack/
The makrup could be <span class="compatibility"><abbr title="This plugin is compatible with your currently installed WordPress version.>Works</abbr> with current version</span>

Part of the issue is that we've conditioned the term "works" to be synonymous with the "Works" meter on each plugin's page on wp.org.

If this information isn't tied to that stat, "compatible" really is the best terminology. So perhaps "Compatible with your WordPress version" would suffice.

Played with the words a bit, also with the help of ​http://thesaurus.com/browse/incompatible

• ​http://i.imgur.com/T73Km9Q.png
• ​http://i.imgur.com/pMvMRBT.png

No super fond of the good vs bad terminology, personally. I prefer ​http://i.imgur.com/T73Km9Q.png, but there's something to be said about using less technically-inclined terminology. On the other hand, this is the plugins page, which I think is fair to employ tech-oriented language, such as "untested", "unapproved", provided its target audience (admins).

plugin-card-2.diff changes the plugin card to use the same border colours and box-shadow as the rest of the admin.

I think "{Untested|Compatible|Incompatible} with your WordPress version" makes the most sense.

Replying to SergeyBiryukov:

I think "{Untested|Compatible|Incompatible} with your WordPress version" makes the most sense.

I agree, ​http://i.imgur.com/1ZRprPC.png

really great work regarding plugin search results - looking forward to v4.0 final!

It would be great if users were also able to sort the plugin results within their WordPress installation the same way as the can on wordpress.org:

Sort by

• Relevance
• Newest
• Most Popular
• Highest Rated

When looking for a plugin I mostly use the "most popular" option which I find often most usable.

Auto generated icons - rough draft

tellyworth: icons: very cool!

Have you been using Tonesque at all to define an icon color?
​https://github.com/mtias/tonesque

Note that I was told that the Jetpack version is actually more up-to-date than the GitHub repo:
​https://github.com/Automattic/jetpack/blob/master/_inc/lib/tonesque.php

I had brought it to nacin's attention, before leaving on vacation, and it could be useful on the API end to define a color from the plugin's banner, if they have one.

This ticket was mentioned in IRC in #wordpress-dev by tellyworth. ​View the logs.

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. ​View the logs.

Can we get a summary of what's left here? It would be nice to get this closed as fixed and open new tickets for anything outstanding.

I've attached a patch to #28803 which fixes the screen options.

Support default plugin icons.

Screenshot showing the latest patch in action

New patch and screenshot attached.

The CSS needs a bit of attention, and if that <br/> doesn't get replaced by someone who actually knows what they're doing it'll haunt me forever.

The default icons are SVG generated by the API. I'm working on tweaking that to set the background color as suggested by Stephdau. Also to add support for asset files.

Variation on the last patch that also supports icon-128x128.png/jpg in assets dir.

Plugin Card with Description

Plugin Card Without Description

Doh, I should get some sleep :) I just saw that patch 6 fixes the issue that I was about to mention in my screenshots. Disregard!

Replying to tellyworth:

Variation on the last patch that also supports icon-128x128.png/jpg in assets dir.

Banners also have HiDPI ​details here, should we also have icon-256x256.png/jpg ?

Refresh patch with better text wrapping.

The updated patch fixes wrapping issues with long descriptions. Here's a screenshot with a narrow screen to show how the title and description flows with the latest patch applied.

Crude support for high dpi images

28785-plugin-custom-icons.3.diff will use a high res image (256x256) if available. It'll use that one and scale down on non-retina displays.

It'd be better to select the right one using -webkit-min-device-pixel-ratio, but this is a start.

attachment:28785-plugin-custom-icons.4.diff​ improves on tellyworth's work by adding a thickbox link around the icon image, so clicking on it triggers the plugin info modal, as do the plugin title and "more details" link.

While I was at it, I'm also including a slight change in JS handling that will trigger said info modal if a user click on any part of the plugin card itself, except for what is not meant to (EG: install button and link to dev site).

Related: I opened #29279 to possibly add some padding between the tablenav actions div and the top of any list table (including specifically the plugins card table).

Forget attachment:28785-plugin-custom-icons.4.diff​: I've created a card-click specific ticket instead: #29286, independant of the icons-related work. With #29286, there's no need for a link around the image (but there can be one, for consistency).

This ticket was mentioned in IRC in #wordpress-dev by stephdau. ​View the logs.

[29569] missed the ticket.

Replying to SergeyBiryukov:

I think "{Untested|Compatible|Incompatible} with your WordPress version" makes the most sense.

Moved to #29313.

---

New tickets please.

28785-style-tweaks.diff​ makes some very minor style changes. See before/after shot above.

Some funky stuff happening between 1125 and 783px wide. Could use some more responsive styling. See above screenshot.

Replying to melchoyce:

Some funky stuff happening between 1125 and 783px wide. Could use some more responsive styling. See above screenshot.

Let's create new tickets for any remaining issues, per comment:67.

In 29587:

Equal margins for plugin icons. see #28785.

In 29597:

Only show one search form for the plugin installer.

The field dropdown now appears in the filter bar only when doing a search.

see #28785.