WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9849 closed enhancement (fixed)

Tweaks/Improvements for Manage Plugins page

Reported by: demetris Owned by: janeforshort
Milestone: 2.9 Priority: normal
Severity: normal Version: 2.8
Component: UI Keywords: has-patch close
Focuses: Cc:

Description

I see two issues in the Manage Plugins page as it is now, especially in view “All”.

  1. The colour for the background of active plugins clashes with the default colour scheme (and also tortures my eyes).
  1. Now that actions are again visible by default, there is clutter.

I attach a tentative patch with some ideas, along with screenshots from before and after. What the patch does:

FOR PROBLEM NO 1

I’m not good with colours, so I just put a gray (f5f5f5) in there.

FOR PROBLEM NO 2

  1. I removed the Edit link. (If you MUST edit plugin files (and lose your modifications in the next update) you can go through Dashboard › Plugins › Editor, or simply get the files locally and edit them with a proper editor.)
  1. I reduced “View Site” to “Site”.
  1. I reduced “Version:” to “Ver.”
  1. I reduced “By:” to “By”.

I also put a separator between the version part and the author(s) part.

As an added bonus, by removing one control statement, my patch makes the Manage Plugins page faster. :-)

Attachments (5)

t9849-manage-plugins-tweaks.diff (2.3 KB) - added by demetris 6 years ago.
Visual tweaks for Manage Plugins page
t9849-manage-plugins-before.png (163.2 KB) - added by demetris 6 years ago.
Manage Plugins page before the tweaks
t9849-manage-plugins-after.png (150.2 KB) - added by demetris 6 years ago.
Manage Plugins page after the tweaks
t9849-20090524-plugins-BEFORE-notes.png (135.1 KB) - added by demetris 6 years ago.
t9849-20090524-plugins-AFTER.png (87.1 KB) - added by demetris 6 years ago.

Download all attachments as: .zip

Change History (34)

@demetris6 years ago

Visual tweaks for Manage Plugins page

@demetris6 years ago

Manage Plugins page before the tweaks

@demetris6 years ago

Manage Plugins page after the tweaks

comment:1 @dd326 years ago

Jane is going to be taking a look at some other ways for the plugins rows.

But i do agree its cluttered, Personally, I'd like to see the actions hidden again, and the version being moved into the title column perhaps greyed a bit.

See also: Ticket #9833 (new defect (bug)) - Update Plugin Browser table to 2.7 style columns

comment:2 @Denis-de-Bernardy6 years ago

I fully agree with DD32 on this one.

comment:3 @demetris6 years ago

On the hiding? If it matters, I’m neutral on this (or rather, I’m undecided).

What worries me is that this part of WP does not receive enough attention. We shouldn’t be having this discussion AFTER the first public beta.

comment:4 @Denis-de-Bernardy6 years ago

better now than after it's officially released, though.

comment:5 @scribu6 years ago

I also think that the action links should be hidden again.

If the comment action links are hidden and users aren't complaining about that, I'm sure they can also handle plugins with hidden links. It would also be more consistent.

comment:6 @scribu6 years ago

  • Cc scribu@… added

comment:7 @Denis-de-Bernardy6 years ago

yeah. plus, it's inconsistent atm. inconsistency is very bad in a UI.

comment:8 @ryan6 years ago

  • Owner set to janeforshort
  • Status changed from new to assigned

comment:9 @ranchnachos6 years ago

I'd like to weigh in on this issue if I could.
Personally, I like the color scheme of the Manage Plugins page. I think changing it to a gray color or similar would be dull.

As for the action links, the only thing I don't agree with are "View Site" and "Edit". View Site is not necessary, that's why the header of the admin has your website name linked to your domain URL.
Edit is also unnecessary, if you need to edit plugins you should just edit locally and re-upload or edit via FTP.

Everything else should stay the same as it was in 2.7

just my .02

comment:10 follow-up: @janeforshort6 years ago

We made a list of style changes over the weekend, about half of which just haven't finished being implemented yet. Should be soon, I believe. I think Ryan decided to go beta before the last style piece so that we could get more functional testing on the new stuff rather than hold off for a few things like color and such, since those types of things often get updated between beta and final launch anyway.

comment:11 in reply to: ↑ 10 @janeforshort6 years ago

In addition to the alignment changes already in place, the style changes that will be tried first (coming from 2.7 style team), so it's on record:

Instead of using background color to designate active, we'll get rid of default background colors altogether, as they are a remnant of 2.5 design. Instead, will differentiate by fading out the inactive plugins a bit using faded text and/or italics to indicate that they are 'grayed out.'

Align action links to bottom of row rather than appearing directly under plugin name.

Change the display style of update notices so they fall within the actual plugin container, reducing confusion about if updates are for plugin above or below row. This change has some backward compatibility things that need to be looked at, so exact implementation will depend on that. Add Update action link when update notice is in effect.

The visit site is for the plugin site, but you're right that the language is confusing. We could move that link to appear after the author link and make it say 'Visit plugin site' for clarity.

Add some additional spacing between version and author; too cramped.

Add column for WP version (works with up to) if possible.

Delete link turn red on hover instead of persistent color.

comment:12 @ryan6 years ago

(In [11389]) Move visit plugin site link from actions to meta. see #9849

comment:14 @ryan6 years ago

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

comment:15 @demetris6 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I think [11422] is a step in the wrong direction.

For one thing, 888888 on ffffff falls short of the WCAG2-AA contrast requirement. (Maybe some subtle differentiation in background color will be necessary in the end to make things work well there...)

There is no reason WP (or WP.org for that matter: see recent changes in WP.org style) should fall short of such easy requirements.

Later today or tomorrow I’ll add a comment with some other issues I see in the Plugins page as it is now.

comment:16 @demetris6 years ago

Contrast is OK now (r11447).

Styling for the update notice is improved too.

I still see some issues or some parts that can be improved. See notes on the BEFORE screenshot.

<http://core.trac.wordpress.org/attachment/ticket/9849/t9849-20090524-plugins-BEFORE-notes.png>

<http://core.trac.wordpress.org/attachment/ticket/9849/t9849-20090524-plugins-AFTER.png>

I think that the Edit links deserve special mention. Here is why I suggest to remove them:

  1. Few people use them. So, the extra visual and informational load is not justified.
  1. Even if many people used them, WordPress should discourage editing of plugin and theme files, not encourage it. What will happen when users lose all their modifications in the next plugin update?
  1. WordPress is a tool to *publish content*. It’s not an IDE or a PHP playground. So, a code editor has no place in it in the first place. (And if an editor like this is needed for some reason, it should not be displayed prominently all over the place.)

comment:17 @ryan6 years ago

Last time we removed edit links, we faced a revolt. Since several 2.8 features relate to improving editing (codepress and function lookup), I think they should stay.

comment:18 @demetris6 years ago

I said in a recent thread in the wp.org forum (<http://wordpress.org/support/topic/269201>) that WP needs a clear sense of purpose and direction. This issue here is a good instance of what I meant:

Why does a publishing tool need a built-in code editor in the first place?

Not only is the code editor unnecessary (at least for the self-hosted variety of WP); it also works against two great strengths of WordPress:

  1. Easy, hassle-free extensibility and customization
  1. Easy, hassle-free updating

Between action hooks, filter hooks and child themes you can do whatever you wish with WordPress without touching a single line of core/plugin/theme code. But use the code editor, which invites you to mess with updatable files, and then the automatic updater—another strong point of WordPress into which so much work has gone— will delete everything in the next update without a warning.

Something is not right in this scheme!

At this stage in WordPress’ evolution, the code editor seems like a left-over from antiquity. If for some reason it’s not desirable to remove it entirely, then, at least, its presence should not be prominent.

As for people revolting, if people think they need a built-in code editor to customize their WP site, then maybe we should try to do a better job at explaining what the strong points of WordPress are.

comment:19 @Denis-de-Bernardy6 years ago

Huh? WP has a code editor? Oh... you must mean that thing I systematically remove so that end-users don't freak one. Seriously though, +1 to dropping the bloody mess.

comment:20 @ryan6 years ago

Edit links are not being dropped from 2.8. Arguments to drop them from 2.9 should be made on the hackers list. I, personally, don't care for the editing stuff, but many people do.

comment:21 @Denis-de-Bernardy6 years ago

is there anything still pending in this one? or can we close as fixed?

comment:22 @demetris6 years ago

Changeset 11517:

http://core.trac.wordpress.org/changeset/11517

... is a regression:

First, the non-white background, which creates a highlight effect, should be used for active plugins, not for inactive ones.

Second, gray is not good as a background colour for notices. The rest of the WP UI displays notices on a yellow background (which is also the colour most commonly used in other applications).

Also, bolding the whole notice looks bad, and the issue of changing font size within the notice remains.

Compare the current style with the AFTER screenshot I attached 10 days ago:

http://core.trac.wordpress.org/attachment/ticket/9849/t9849-20090524-plugins-AFTER.png

Patches available upon request. :-)

comment:23 follow-up: @azaozz6 years ago

  • Milestone changed from 2.8 to 2.9

Think this is a good candidate for a community challenge solution.

comment:24 in reply to: ↑ 23 @Viper007Bond6 years ago

Replying to azaozz:

Think this is a good candidate for a community challenge solution.

Not a bad idea, but I vote we leave it similar in styling to previous versions until we come up with a community selected result. Because as of right now, it's not apparent at all which plugins need upgrading from the "All" list.

comment:25 @demetris6 years ago

In my opinion, this should be a blocker for 2.8. In particular, the two issues I focused on in my last comment:

  1. Now we highlight inactive plugins, instead of active ones. This does not make sense.
  1. Now we display upgrade notices on a gray background, while the rest of WordPress and the rest of the world use yellow for such notices.

I don’t think these two issues should wait for a design contest. They do not present any serious challenge. Even *I* could fix them. :-)

comment:26 @Denis-de-Bernardy6 years ago

+1 for blocker on this one. we should at least apply the patch over at #10054 to highlight plugins in need of an update.

comment:27 @Denis-de-Bernardy6 years ago

  • Keywords close added; 2nd-opinion removed

suggesting we close this one as fixed, and open new tickets as needed after the community feedback thingy Andrew and Jane mentioned.

comment:28 @janeforshort6 years ago

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

Going to go with Denis's suggestion and close this ticket as fixed (it was 2.8 and we're in 2.9 now), and open a new ticket for plugin management screen UI. Will follow Andrew's suggestion and make it a design challenge open to the community so we can see how many brilliant ideas can help with this issue.

Note: See TracTickets for help on using tickets.