Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#28785 closed task (blessed) (fixed)

Plugin card table to replace WP_Plugin_Install_List_Table

Reported by: tellyworth's profile tellyworth Owned by:
Milestone: 4.0 Priority: normal
Severity: normal Version: 4.0
Component: Plugins Keywords:
Focuses: ui Cc:

Description

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.

Attachments (26)

plugin-card-list.psd (2.9 MB) - added by melchoyce 10 years ago.
plugin-card-list.png (289.6 KB) - added by melchoyce 10 years ago.
28785-plugin-card-table-draft.diff (8.7 KB) - added by tellyworth 10 years ago.
28785-plugin-card-table-draft.2.diff (9.7 KB) - added by michalzuber 10 years ago.
clear .plugin-cards due different height
28785-plugin-card-table-draft.3.diff (8.7 KB) - added by michalzuber 10 years ago.
Removed language-chooser.js diff
28785-plugin-card-table-draft.4.diff (8.8 KB) - added by stephdau 10 years ago.
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.
Screen Shot 2014-07-08 at 11.00.49 AM.png (62.8 KB) - added by melchoyce 10 years ago.
28785-plugin-card-table-draft.5.diff (9.1 KB) - added by michalzuber 10 years ago.
Tried with low banner
28785-plugin-card-table-draft.5-alt.diff (9.2 KB) - added by ryelle 10 years ago.
28785-plugin-card-table-draft.6.diff (9.6 KB) - added by stephdau 10 years ago.
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.
28785.patch (2.8 KB) - added by ocean90 10 years ago.
plugin-card.diff (787 bytes) - added by paulwilde 10 years ago.
plugin-card-2.diff (784 bytes) - added by paulwilde 10 years ago.
Screen Shot 2014-07-29 at 9.42.57 pm.png (111.7 KB) - added by tellyworth 10 years ago.
Auto generated icons - rough draft
28785-plugin-default-icons.diff (1.9 KB) - added by tellyworth 10 years ago.
Support default plugin icons.
Screen Shot 2014-08-15 at 2.21.49 pm.png (186.8 KB) - added by tellyworth 10 years ago.
Screenshot showing the latest patch in action
28785-plugin-custom-icons.diff (2.2 KB) - added by tellyworth 10 years ago.
Variation on the last patch that also supports icon-128x128.png/jpg in assets dir.
Screen Shot 2014-08-15 at 0.42.29.png (55.1 KB) - added by BandonRandon 10 years ago.
Plugin Card with Description
Screen Shot 2014-08-15 at 0.42.45.png (36.6 KB) - added by BandonRandon 10 years ago.
Plugin Card Without Description
28785-plugin-custom-icons.2.diff (2.7 KB) - added by tellyworth 10 years ago.
Refresh patch with better text wrapping.
Screen Shot 2014-08-20 at 9.03.55 am.png (131.6 KB) - added by tellyworth 10 years ago.
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.
28785-plugin-custom-icons.3.diff (2.9 KB) - added by tellyworth 10 years ago.
Crude support for high dpi images
28785-plugin-custom-icons.4.diff (4.0 KB) - added by stephdau 10 years ago.
28785-style-tweaks.diff (432 bytes) - added by melchoyce 10 years ago.
jetpack-before-after.png (116.5 KB) - added by melchoyce 10 years ago.
Screen Shot 2014-08-22 at 10.50.38 AM.png (191.2 KB) - added by melchoyce 10 years ago.

Change History (98)

#1 @melchoyce
10 years ago

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:

https://i.cloudup.com/5iZ0FBsOO0.png

#2 @helen
10 years ago

  • Focuses ui added
  • Milestone changed from Awaiting Review to 4.0
  • Type changed from enhancement to task (blessed)

#3 @tellyworth
10 years ago

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

@michalzuber
10 years ago

clear .plugin-cards due different height

#4 @michalzuber
10 years ago

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

@michalzuber
10 years ago

Removed language-chooser.js diff

#5 @stephdau
10 years ago

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.

@stephdau
10 years ago

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.

#6 @stephdau
10 years ago

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

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

Results: https://cloudup.com/cfJGWQKTMuY

#7 @stephdau
10 years ago

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?

Last edited 10 years ago by stephdau (previous) (diff)

#8 @melchoyce
10 years ago

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.

#9 @melchoyce
10 years ago

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?

#10 follow-up: @michalzuber
10 years ago

Better, but install should stay primary.

@michalzuber
10 years ago

Tried with low banner

#11 in reply to: ↑ 10 @melchoyce
10 years ago

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.

#12 follow-up: @michalzuber
10 years ago

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

Version 0, edited 10 years ago by michalzuber (next)

#13 in reply to: ↑ 12 @melchoyce
10 years ago

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

#14 follow-up: @paulwilde
10 years ago

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.

#15 in reply to: ↑ 14 ; follow-up: @melchoyce
10 years ago

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.

#16 in reply to: ↑ 15 @paulwilde
10 years ago

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.

#17 @ryelle
10 years ago

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.


10 years ago

#19 follow-ups: @johnbillion
10 years ago

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.

#20 in reply to: ↑ 19 @tellyworth
10 years ago

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.

#21 follow-up: @tellyworth
10 years ago

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?

#22 follow-up: @netweb
10 years ago

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.

#23 in reply to: ↑ 22 ; follow-up: @tellyworth
10 years ago

Replying to netweb:

What about the Internationalization goals for 4.0?

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

#24 in reply to: ↑ 21 @stephdau
10 years ago

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?

Last edited 10 years ago by stephdau (previous) (diff)

#25 in reply to: ↑ 23 @netweb
10 years ago

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?
  1. What about each plugin card displaying the plugin locale dependant on the current view context?
Last edited 10 years ago by netweb (previous) (diff)

#26 @netweb
10 years ago

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

https://i.cloudup.com/YtsZXJNPfw.png

#27 follow-up: @michalzuber
10 years ago

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?

#28 in reply to: ↑ 27 ; follow-up: @netweb
10 years ago

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

#29 in reply to: ↑ 28 @michalzuber
10 years ago

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 http://i.imgur.com/nsqTNJl.png

Last edited 10 years ago by michalzuber (previous) (diff)

#30 @helen
10 years ago

Ticket for showing compatibility: #28646

@stephdau
10 years ago

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.

#31 follow-up: @stephdau
10 years ago

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.

Last edited 10 years ago by stephdau (previous) (diff)

#32 follow-up: @stephdau
10 years ago

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.

#33 in reply to: ↑ 32 ; follow-up: @melchoyce
10 years ago

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.

#34 in reply to: ↑ 33 @michalzuber
10 years ago

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/)
http://i.imgur.com/23NPInQ.png

#35 @helen
10 years ago

In 29047:

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

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

#36 in reply to: ↑ 19 @ocean90
10 years ago

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?

#37 in reply to: ↑ 31 @ocean90
10 years ago

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.


10 years ago

#39 @ocean90
10 years ago

In 29171:

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

see #28785.

@ocean90
10 years ago

#40 follow-up: @ocean90
10 years ago

  • Version set to trunk

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

#41 in reply to: ↑ 40 @netweb
10 years ago

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.


10 years ago

#43 @helen
10 years ago

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.

#44 @helen
10 years ago

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.

#45 @michalzuber
10 years ago

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>

#46 @DrewAPicture
10 years ago

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.

#48 @stephdau
10 years ago

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

#49 @paulwilde
10 years ago

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

Last edited 10 years ago by paulwilde (previous) (diff)

#50 follow-ups: @SergeyBiryukov
10 years ago

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

#51 in reply to: ↑ 50 @michalzuber
10 years ago

Replying to SergeyBiryukov:

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

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

#52 @harmr
10 years ago

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.

@tellyworth
10 years ago

Auto generated icons - rough draft

#53 @stephdau
10 years ago

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.

Last edited 10 years ago by stephdau (previous) (diff)

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


10 years ago

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


10 years ago

#56 @DrewAPicture
10 years ago

  • Keywords dev-feedback added

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.

#57 @paulwilde
10 years ago

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

@tellyworth
10 years ago

Support default plugin icons.

@tellyworth
10 years ago

Screenshot showing the latest patch in action

#58 follow-up: @tellyworth
10 years ago

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.

@tellyworth
10 years ago

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

@BandonRandon
10 years ago

Plugin Card with Description

@BandonRandon
10 years ago

Plugin Card Without Description

#59 @BandonRandon
10 years ago

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!

#60 in reply to: ↑ 58 @netweb
10 years ago

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 ?

@tellyworth
10 years ago

Refresh patch with better text wrapping.

@tellyworth
10 years ago

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.

@tellyworth
10 years ago

Crude support for high dpi images

#61 @tellyworth
10 years ago

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.

#62 @stephdau
10 years ago

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

#63 @DrewAPicture
10 years ago

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

#64 @stephdau
10 years ago

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.


10 years ago

#66 @SergeyBiryukov
10 years ago

[29569] missed the ticket.

#67 in reply to: ↑ 50 @ocean90
10 years ago

  • Keywords dev-feedback removed
  • Resolution set to fixed
  • Status changed from new to closed

Replying to SergeyBiryukov:

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

Moved to #29313.


New tickets please.

#68 @melchoyce
10 years ago

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

#69 follow-up: @melchoyce
10 years ago

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

#70 in reply to: ↑ 69 @SergeyBiryukov
10 years ago

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.

#71 @nacin
10 years ago

In 29587:

Equal margins for plugin icons. see #28785.

#72 @helen
10 years ago

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.

Note: See TracTickets for help on using tickets.