UI improvements for 2.9 bulk plugin/theme updater (esp. success/fail msgs)

[jeremyclarke]

I just tried the bulk plugin upgrades in WP 2.9 rare. It worked well but the experience of seeing so many copies of the upgrade message made me think that it could be much more effective visually at communicating the results without too much extra work.

Here's how it looks now:

Problem

While this is informative it is obviously super-spartan in design while also taking up a ton of space on the screen. When it was just one plugin/theme at a time I was willing to ignore the simplicity, but with 11 in a row it gets pretty intolerable that it not only fails to communicate the relevance of the messages its outputting, but also forces me to scroll a ton to see all the output.

I felt like I had to read through all 11 sets of messages because the success message had no special style. It looked just like all the others, so if there was a failure message I had to assume it would also look like the rest. Needless to say reading all that is a terrible user experience and WP could do a lot better. The output reads like a log of information that should be hidden by default, and maybe it should be.

Solution

EASY: Add .updated and .error to <p> tags

The simplest fix would be to add a css class to the success/fail messages so that they stick out. The obvious choice and one that would involve no new styling is to use the existing .updated and .error classes from the /wp-admin/css/global.css file. I tried them on my list and it works fine on the <p> tags the messages are wrapped in. The .updated ones look yellow, so after seeing one you could scan down the page to see that all messages are yellow.

Make Success/Fail messages bigger

The final messages should be much bigger than the rest of the text for each plugin, and the other messages should probably not have so much margin on them. As it is each line is its own <p> and as such has 1em of margin on top and bottom. If they were instead seperated by <br /> tags they would be just as readable (they currently have line-height:140; anyway) and I can't think of a "semantic" reason why this log output should be considered paragraphs that outweighs the need to conserve space.

Use the actual plugin's name

The success/fail message should state the name of the plugin, as in "Contact Form 7 Successfully Upgraded" instead of "Plugin Upgraded Successfully".

When you are reading a list with many plugins it would help greatly to differentiate the messages. The current system feels very vague: nowhere in the message is the title of each plugin mentioned. If the actual plugin name would be complex/resource-intensive to determine then the filename of the core plugin file (i.e. contact-form-7.php) should be shown instead, most people would be able to figure out which plugin it was based on the filename.

Link back to Core Upgrade screen at end of list

This may already be planned, but at the end of the list, after the "Disabling Maintenance mode." message (which should also be removed, not really useful to users) there should be a link back to the /wp-admin/update-core.php file. As it is its very unclear what to do after upgrading your plugins, and giving the user a direct link to the next step just makes sense.

Hide log output entirely with JQuery and only show upon request

I think this is the real killer solution. All messages but the final success/failure one should go in a div that is hidden by jquery by default, but can be shown by clicking a 'more info' link next to the success/failure message.

For most people this would mean a string of messages informing them that each of their plugins was successfully upgraded. Easy to look at and look through to make sure there was no problems. If there is a problem they can find out what it is easily or actual error messages can be displayed by default.

I think this might be how it should always have been. The current system feels a bit by-developers, for-developers. Normal people just want to know that it was upgraded or if there were problems.

Implementation

I looked through the /wp-admin/includes/class-wp-upgrader.php file to see how this was accomplished but haven't actually written a patch yet. It seems like the messages themeselves are being generated by the show_message() function from /wp-admin/includes/misc.php. That function doesn't have options for adding classes to the <p> tags it produces nor does it allow for other formats. Maybe we could modify that function to do more? Add in $before, $after, $css_class and $format parameters? I think they would be useful in a lot of situations where you're showing messages.

Otherwise I think it's reasonable to use a seperate display system for these upgrader messages that accounts for the importance of differentiating between log messages and success/fail messages.

If someone would be willing to commit a patch if it was done a certain way please say so and I'll try to make a patch that satisfies your demands. IMHO there's a good chance that ryan or whoever did most of the work on the upgrader could hammer out these changes in no time though ;)

Screenshots

.updated and bigger font for success msg

Here's how it looks with just the addition of .updated to the success messages along with an increase in the font size of .updated and switching to <br /> or removing the padding from the rest of the output. The font size increase would involve wrapping the whole upgrader output in a class or id like #updater-output, which IMHO is a very sensible choice that would match the rest of wp-admin. The CSS to increase the font size would then be

#updater-output .updated {font-size: 16px;}	

hide output with jquery, use plugin names and add button at bottom

This one is uglier but shows what I mean about hiding most of the log output and using the actual plugin names. Note how many more messages can fit on one screen and consider how useful the hidden messages are to 99% of users. Compared to the current design this one can show 8 plugins worth of messages instead of 3(!)

[ryan]

A patch would be most welcome. Making the UI less ugly definitely needs to be done before 2.9 releases. :-) This looks like a good direction.

[nacin]

With 2.9 string-frozen, most of this can't be done unless an exception is made. And if that's the case, I'd be all for taking jeremyclarke's proposals and turning them, today, into a patch.

[nacin]

Fully implementing this will require a number of rather substantial changes to the upgrader classes, aside from string changes as well. I'm thinking early 3.0.

[markjaquith]

Yeah, as much as I dig what Jeremy is mocking up, we've already pushed 2.9 back, and we're in our second beta.

[nacin]

Adds rudimentary "Go back" link.

[nacin]

Patch attached to add a "Go back" link (an existing string), the lack of which was really bugging me. Hoping for a commit for 2.9 then a bump back to the 3.0 milestone.

[ryan]

I think that would have to go in the skin somewhere or attached to a filter to be friendly to those who might be reusing that class. Proposing we live with the ugly for 2.9 and make it pretty in 3.0.

[hakre]

Replying to nacin:

Patch attached to add a "Go back" link (an existing string), the lack of which was really bugging me. Hoping for a commit for 2.9 then a bump back to the 3.0 milestone.

Please open a new ticket for this and put your patch there. I think it got dropped from 2.9 because the whole ticket was shifted to 3.0.

[nacin]

No, it got dropped because it belonged in the skin and is better to tackle in 3.0 with the rest of this ticket.

I've been slowly working on a patch for this. It requires some decent changes to the way the entire upgrader works though, or at least the skins that implement it, so it's taking some time figuring out how to minimize the changes and the impact.

[dd32]

so it's taking some time figuring out how to minimize the changes and the impact.

I would write a new skin, and pass that to the upgraders instead. The skin would only output the in-between HTML needed, so no headers, no footers, just the status update and/or javascript required once that upgrade occurs.

[dd32]

nacin: I'd be willing to write up the patch if you've got something to start off? (ie. HTML/CSS), Thats assuming you cant work out how its currently done :)

Setting to needs-patch due to the attached patch adding the code in the 'wrong' place, and no patch for the larger issue of the styling.

[hakre]

This still needs a patch. IMHO it looks good what suggested but until now it's only a suggestion. Any chances to get more input here. Nacin? dd32?

[nacin]

dd32 is working on a new bulk upgrade skin and I'm working on a new UI to go with it.

Improvements can then be ported to the other upgrader skins as appropriate.

[hakre]

Related: #11629

[jeremyclarke]

Looking back at this after working on the Settings API error reporting ( #11474 ) I realized that a big part of what is needed is better support for automatic display of errors from WP_Error, and the current state of show_message() as part of the problem.

Tons of detail in #12254 about my proposed solution. I think if a patch was committed to solve everything mentioned in that ticket then it would make the solution to this ticket much easier.

[dd32]

nacin has been bugging me for awhile to get the skin finished.. I should have some time this weekend for it, I'll attack it then.

[nacin]

(In [13476]) Add link to dashboard after core upgrade. props Simek, fixes #11629 see #11232

[dd32]

(In [13602]) First scrape at new UI for Bulk plugin upgrades. See #11232

[dd32]

(In [13686]) Bulk Theme Upgrades. See #12528 See #11232 for Bulk UI

[dd32]

Both the Bulk Theme and Bulk Plugin upgrades now use this same skin, should mean its more consistent throughout.

Things to note on the skin:

• Individual status updates (downloading.. unpacking.. etc..) are hidden, and only shown via Javascript in the event of a failure (Or the user clicks the Javascript link)
  • Still works with non-js, just doesnt give step-by-step feedback, Main error is still reported.
• Ugrade process is wrapped in an iframe
  • This gives the user instant access to the menu, should hopefully prevent the issues seen in the past of a blank white screen whilst waiting for upgrades to finish.
    • Some kind of feedback is needed, A paragraph of text explaining this, or a spinner at the top of the page perhaps? Maybe a spinner after the Object name in the list? (Updating Theme ThemeName (1/3) <spinner>)?

[Daniel Koskinen]

After spending a minute waiting for the uploader to finish when it had actually already finished, I suggest the wording should be subtly different at the end of the bulk uploader.

In "Disabling Maintenance mode…" the three dots at the end suggest that something is still going on. Add a "Done!" at the end or some kind of final confirmation that upgrading is finished.

[dd32]

Some text at the start of the process is also needed to explain the process and that it may take awhile to finish.

[ocean90]

Related #12828

[scribu]

Related: #13320

[ocean90]

Spinner and start/end message

[ocean90]

Back to 3.0. Some start and end text should be in 3.0.

[dd32]

(In [14819]) Provide some Before/After strings for Bulk Upgrades, Add a spinner whilst a upgrade is in process, Remove scrollbars on update iframe. Props ocean90. See #11232

[dd32]

Remaining issues:

• Needs an "Actions:" at the end to be consistent with the single upgraders (ie. Return to Updates, or similar)
• Strings may need to be fine-tuned, Currently (changed from ocean90's patch)
  • Before: The update process is starting. This process may take awhile on some hosts, so please be patient.
  • After: All upgrades have been completed.

[ryan]

(In [14820]) Minify. see #11232

[demetris]

Replying to dd32:

Remaining issues:

• Needs an "Actions:" at the end to be consistent with the single upgraders (ie. Return to Updates, or similar)
• Strings may need to be fine-tuned, Currently (changed from ocean90's patch)
  • Before: The update process is starting. This process may take awhile on some hosts, so please be patient.
  • After: All upgrades have been completed.

For After I would prefer something very simple, like:

All done!

For Before I am not sure we need a message.

Also, I am not sure about the spinner — sorry, ocean90! :-) — Personally, I find the spinning irritating and I would again prefer something very simple, like an ellipsis.

[johnonolan]

UI/UX: This looks great all round, no changes or additions from me.

[ocean90]

Video of the upgrade process with the spinner: ​http://screenr.com/Ayp

[jeremyclarke]

+1 for leaving the spinner in. It looks great, makes sense and avoids the frustration of staring at a screen where nothing is happening.

The style seems the same as the one that goes off when you save a widget, so I don't see why we would use a different style of 'loading' icon in this situation.

[jeremyclarke]

Also: Was there a reason we passed on a button at the bottom of the output to lead back where the user came from (or just back to the updater)? That seems to be the biggest remaining issue to me.

[johnonolan]

Is that not what the left-nav is for?

If I finish approving all my comments and I hit "update" I don't want to be returned to the comments screen after updating.. there's nothing else for me to do there. I also don't want to be returned to the original updates screen, because I just updated everything and there's nothing for me to do there either.

[dd32]

(In [14879]) Add Actions to the end of Bulk upgrades; Remove Spinners and instead show the individual upgrade steps (Then hidden upon completion for bulk upgrades). See #11232

[dd32]

Pretty sure thats all the 3.0 things here to be dealt with.

I've removed the spinners, I didnt particularly like it, I'd rather just know where in the process its up to (As most people using the upgrade functions already will be used to), So i've made it display the upgrade steps, and then hide them when it moves onto the next plugin (so as not to clutter the screen more)

Made a quick screencast to show the current process: ​http://screenr.com/y7A

Also, Sorry, I've missed the comments here in the last half hour, Too tired and missed them..

It looks great, makes sense and avoids the frustration of staring at a screen where nothing is happening.

I was thinking of consistancy with what users are already used to, Whats the point of having the steps output if the user cant see them.. Kept frustrating me i couldnt see where it was hanging up on.

Is that not what the left-nav is for?

Once again, I was going after consistancy with the other upgrade screens. Some people will want to return to the updates screen for example, Done the plugins, now the themes, etc. Or may have only updated a select few of the plugins.

[jeremyclarke]

Replying to johnonolan:

If I finish approving all my comments and I hit "update" I don't want to be returned to the comments screen after updating.. there's nothing else for me to do there.

In WordPress after a bulk comments operation is completed you are redirected back to the comments page and shown a message about the results of the bulk update. That is exactly how it should work because there are many things you are likely to want to do there, such as continue your work on other comments. You may also want to make sure that there is nothing else that needs to be done with regard to comments before you move to another task.

Just because someone performed a bulk operation on several objects doesn't mean they finished everything, and it is always better to lead people back to something they at least recognize as part of the menu structure than to leave them in dead-end limbo with a text success message.

Replying to johnonolan:

I also don't want to be returned to the original updates screen, because I just updated everything and there's nothing for me to do there either.

One common case where this system gets shown is when you go to Upgrade and before updating WP you do a bulk upgrade of your plugins. In that scenario the user starts toward a goal, updating WP, and is lead to a dead end after the plugin bulk upgrader. Yes they could go to the updater again manually, or just wait until they see the update nag again, but a button that leads back to the updater makes perfect sense here. It gives the user a next action they can take.

If they know for sure that the updater isn't what they want then they don't have to press the button/link, but if they're not sure what to do next clicking that button is a good idea. They will be brought back to the general updater screen where they can be informed that nothing else needs updating (or maybe that core wp still needs updating)

[johnonolan]

In my opinion it's a mistake to make assumptions that a user will be confused by something and thereby create additional UI elements (read: clutter) based on an unproven premise.

[jane]

I agree with Jeremy that providing a link back to where they came from would be best. Our standard is to keep you on the screen you've been working on, but in this case it's a little weird because when you click update, we don't show you the update status on the same screen, we take you to another one, so to keep as close to our standard as possible, we should give you a link back. At some point in a future version, it would be worth looking into changing that and having a layer slide open above the main screen content/below the header with progress bars (in general, prefer progress bars to spinners in all cases, as spinners do not actually give user any information and can just as easily be a sign that something is hung up indefinitely).

Personally I think taking away the details and replacing with the success message feels jumpy and the messages disappeared before they could be read because the update went fast. That makes the user feel like they may have missed something. I'd rather do Jeremy's first suggestion of just highlighting the success message to stand out more as an alert. When we're not a day before RC, in the next version, I'd support redesigning the update process but the confusion of show/replace when you don't have time to read the text is more of a problem than having to scroll if you're updating a lot of plugins. It's not like updating 20 plugins at a time is a frequent activity for any one average user. In future version, we should move to progress bars with the status messages.

[jeremyclarke]

Replying to johnonolan:

In my opinion it's a mistake to make assumptions that a user will be confused by something and thereby create additional UI elements (read: clutter) based on an unproven premise.

I don't think that one button or link at the bottom of a page of text output constitutes clutter that is worth being afraid of. It will not conflict with any other UI in its area because there is nothing else there except diagnostic output that will almost never be needed.

Also this isn't really new UI as it would bring the bulk updater in line with the single-plugin updater, which ends its output with:

Actions: Activate Plugin | Return to Plugins page

So maybe a link in that style would be best:

Return to Updates

[dd32]

(In [14919]) Revert back to spinner on bulk upgrades. See #11232

[dd32]

(In [14920]) Tweak String language to match language used elsewhere. Props Jane. See #11232

[dd32]

Closing this as fixed, I've added the Actions, and reverted back to the spinner, The text is consistent with other screens, This should be enough for 3.0.