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

[johnbillion]

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.

[adamsilverstein]

first pass

[adamsilverstein]

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

[DrewAPicture]

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

[jorbin]

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

[adamsilverstein]

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

[johnbillion]

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.

[johnbillion]

In 31991:

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

See #31770.

[ericlewis]

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

[adamsilverstein]

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

[DrewAPicture]

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?

[jorbin]

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.

[jorbin]

In 32053:

Remove Shiny Bulk Updates

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

See #31770, #29820,

[adamsilverstein]

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,