WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#31770 closed enhancement (maybelater)

Shiny Updates: User may get no visual feedback when bulk updating plugins

Reported by: johnbillion Owned by: jorbin
Milestone: Priority: normal
Severity: normal Version: 4.2
Component: Upgrade/Install Keywords: ux-feedback needs-patch
Focuses: javascript, administration Cc:
PR Number:

Description

Currently the UI feedback after bulk updating a bunch of plugins on the Plugins screen is sub-optimal. If all the plugins you're updating are below the fold, there's no UI feedback at all. Even if they're not, there's no visual confirmation near the button you've just clicked.

We should consider adding a confirmation message the same as the one you get without shiny updates. And scroll the user to the top of the screen post-update.

Attachments (4)

31770.diff (2.6 KB) - added by adamsilverstein 5 years ago.
first pass
31770.2.diff (2.5 KB) - added by adamsilverstein 5 years ago.
bulk-updates-pre-4.2.mp4 (2.9 MB) - added by ericlewis 5 years ago.
31770.2.mp4 (1.4 MB) - added by ericlewis 5 years ago.

Change History (26)

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

@adamsilverstein
5 years ago

first pass

#2 @adamsilverstein
5 years ago

  • Focuses javascript added
  • Keywords has-patch dev-feedback added; needs-patch removed

In 31770.diff:

  • First pass at notifications for plugin updates and failures
  • Inserts hidden elements for error and success messages at page top
  • Clones these elements and adds plugin name to string
  • Currently the ajax callback returns only the plugin slug, we should get/pass the actual plugin name. For now, I am capitalizing the slug and prepending to the success/failure string; so on upgrade of Jetpack, the success string becomes 'Jetpack updated successfully.'
  • Does not include dismissible admin notice code from #31233; if this code flies, we can easily refactor it as a function and add here

#3 @DrewAPicture
5 years ago

  • Owner set to johnbillion
  • Status changed from new to reviewing

@johnbillion: Can you please review the latest patch from @adamsilverstein and see if that meets with your expectations?

This ticket was mentioned in Slack in #core by kraft. View the logs.


5 years ago

#5 @DrewAPicture
5 years ago

  • Keywords 4.2-strings added

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#7 follow-ups: @jorbin
5 years ago

  • Keywords changed from ux-feedback, has-patch, dev-feedback, 4.2-strings to ux-feedback has-patch dev-feedback 4.2-strings

I do not like the idea of scrolling to the top automatically. We shouldn't take over a users browser like that.

#8 in reply to: ↑ 7 @adamsilverstein
5 years ago

Replying to jorbin:

I do not like the idea of scrolling to the top automatically. We shouldn't take over a users browser like that.

Agree! Removed scroll in 31770.2.diff ; would be nice to make the notice dismissible now that we have #31233, might have to refactor the JS a bit :)

#9 in reply to: ↑ 7 @johnbillion
5 years ago

Replying to jorbin:

I do not like the idea of scrolling to the top automatically. We shouldn't take over a users browser like that.

This is no different to the current behaviour with a server-side redirect.

Feedback is potentially off-screen at the moment because the user's scroll position can be anywhere.

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#11 @johnbillion
5 years ago

In 31991:

Introduce a string representing bulk plugin update success, ready for string freeze. Not used yet.

See #31770.

#12 @DrewAPicture
5 years ago

  • Keywords 4.2-strings removed

#13 @ericlewis
5 years ago

  • Summary changed from Better feedback after bulk updating plugins via shiny updates to Shiny Updates: Better feedback after bulk updating plugins

#14 @ericlewis
5 years ago

  • Summary changed from Shiny Updates: Better feedback after bulk updating plugins to Shiny Updates: User may get no visual feedback when bulk updating plugins

@ericlewis
5 years ago

#15 @ericlewis
5 years ago

Let's review where we've come on bulk plugin updates in the 4.2 dev cycle from a user experience perspective.

attachment:bulk-updates-pre-4.2.mp4 is a screen recording of what bulk updates look like pre-4.2 (or for users without JavaScript enabled). There is a very clear user workflow - you click the bulk action "Apply" button, and are taken to a new page that is giving you feedback about the updates. There's verbose logs a user can drill down into to see "Oh, that plugin I selected to bulk update was at its current version so it didn't need an update. Got it."

attachment:31770.2.mp4 is a screen recording of what bulk updates look like with the patch attachment:31770.2.diff applied. In this worst-case scenario, a user will click the Apply button, and nothing will happen immediately. The page will start to jump down curiously. If the user scrolls up they will see admin notifications with brief notes on the update process for each plugin. All plugins that were up-to-date and didn't need an update will report the update "failed".

If a user is updating just one plugin, making that update via AJAX (i.e. "Shiny") is an improved user experience. The user doesn't get pushed into to another page to see the feedback log for one update, List Table context is retained, and the user can continue operating in the Plugins page.

In AJAX-ifying the bulk update process, I don't think there's a clear user experience gain. Bulk updates can be a hefty process and comes with an unknown quantity of feedback / logging data for a user to sift through (e.g. 100 plugin updates). Forcing a document-reload to a log page is a tried-and-true user experience. Unless we're introducing something that is at least as good (if not better), let's not do it.

Relatedly, our update notifications UI is firmly rooted in document-reloading form submissions (showing the user a message at the top of the page).

#16 @adamsilverstein
5 years ago

I agree the user experience could be made better! I also think an ajaxified bulk update experience could work better than the current form submission approach.

What would an ideal ajaxified bulk update experience be? maybe:

  • Scroll to top (@jorbin: just one scroll event, right when you click the button)
  • Indicate updates in progress bar 'x of y', spinner
  • Success/failure bars with details links matching existing update screen

#17 @DrewAPicture
5 years ago

  • Keywords needs-patch added; has-patch dev-feedback removed

My vote would be to keep the inline update links in the Updates table, but retain the existing bulk update experience with the page refresh and verbose output.

The ajaxified experience for bulk updates just doesn't seem ready enough, and frankly, I'd kind of like to see some user tests to back up the best approach.

What would we need to do/remove to get back to the old bulk updates experience while retaining the inline updates links?

#18 @DrewAPicture
5 years ago

  • Owner changed from johnbillion to jorbin

#19 @jorbin
5 years ago

This ticket highlights that bulk updates don't quite work in the current ajaxified way. Luckily, the bulk experience doesn't benefit as much from being shiny. As such, I am removing ajaxified bulk updates. Version two can include a user tested approach to this.

#20 follow-up: @jorbin
5 years ago

In 32053:

Remove Shiny Bulk Updates

Bulk updates don't need to be ajaxified so let's revert.

See #31770, #29820,

#21 @jorbin
5 years ago

  • Milestone 4.2 deleted
  • Resolution set to maybelater
  • Status changed from reviewing to closed

#22 in reply to: ↑ 20 @adamsilverstein
5 years ago

Thanks for pulling that out. Would love to continue working on the bulk mode for a future release.

Replying to jorbin:

In 32053:

Remove Shiny Bulk Updates

Bulk updates don't need to be ajaxified so let's revert.

See #31770, #29820,

Note: See TracTickets for help on using tickets.