Discoverability of plugin and themes autoupdates

[francina]

The new auto updates feature for plugins and themes is very useful, but I found it was not easy to discover after updating to 5.5 beta. The feature doesn't have a place where it "pops" into users eyes. At least it didn't in mine.

Plugins

• Great: Having everything in one column
• Not so great: Not having a clear differentiator between plugins I opted in and plugins I have opted out.

Themes

• Not so great: having to go into each single theme
• Bad: having a text with the same color of the theme author name (and in smaller font) right under it.

Ideas

• Have the design team review the UI
• Have a call-out widget in the Dashboard
• Have a call-out widget in the Updates screen
• Have a call-out widget in the Theme screen, potentially with a button to bulk enable/disable
• Turn the theme "Enable/Disable Auto-Updates" into a button in the lower part of the theme modal where "Activate/Live Preview/etc..." buttons live.

[davidbaumwald]

HI @francina, and welcome to Trac! :wink: I've updated this to the Administration component.

[francina]

Hello folx
what are the chances to get some design eyes on this for a 5.5 iteration?
Thanks!

[SergeyBiryukov]

Replying to francina:

Plugins

• Great: Having everything in one column
• Not so great: Not having a clear differentiator between plugins I opted in and plugins I have opted out.

Just noticed this too.

There is also a translations aspect: while the difference between "Enable auto-updates" and "Disable auto-updates" is somewhat noticeable in English, in other languages it can be more subtle, so there's no clear way to tell at a glance which plugins have auto-updates enabled and which don't.

Some kind of a visual indicator in addition to the text would be great.

[uxkai]

Hi all,

@rolfsiebers & @thijsvanloef and I worked on this issue during Yoast's Contributor Day.

We looked at different ways of how to visualize the Auto-update setting. After some iterations, we came to the conclusion that using a switch or radio buttons with "On"/"Off" labels will probably be the best way to visualize whether this setting is enabled or disabled.

We found out that currently there is no switch component used in the current WP admin yet. (except for the switches in GB) Therefore, we wanted to try using radio buttons first. (as radio buttons are currently used in WP already)

We tried to visualize this setting with radio buttons / switches on three different places:

• The rightmost column in the "Plugins" table (where the current setting already is placed)

• The hover state of a Theme thumbnail (you can change the setting without having to go into each single theme)

When currently hovering one of the theme thumbnails, some actions ("Activate" and "Live Preview") will appear. Therefore, we thought it makes sense to add this setting there as well.

• In the Theme modal (after clicking on a thumbnail = where the current setting already is placed)

We haven't looked into bulk enabling/disabling auto-update for Themes, because we think most people will use one (or more, but not much) theme(s) and don't really need this functionality.

Please see the designs in the next comments:

[uxkai]

When hovering one of the theme thumbnails...

[uxkai]

Auto-update in the Theme modal

[uxkai]

This is how the Auto-update settings will look when using switches:

[uxkai]

Plugins table:

[uxkai]

When hovering one of the Theme thumbnails...

[uxkai]

Auto-update in the Theme modal:

[uxkai]

Please note that the radio buttons and switches are placeholders and don't have WordPress styling yet...

[francina]

Thank you @uxkai for working on this!
All the options proposed seem to "pop" and are a step forward in terms of discoverability.

I would say the next steps:

1. Buy-in from the folx working on the autoupdates (I'll bring this up tomorrow, September 8th on the dedicated chat)
2. Accessibility review to make sure we are picking the best option
3. Design feedback

I would still very much like to see this land in 5.6

[helen]

Hello - thanks for the explorations here! One request from me - could somebody take a moment and add current screenshots to this ticket as well for reference, both for now and for the future, and include both "desktop" and a narrower view.

[estelaris]

plugin auto-update mobile "now"

[audrasjb]

Moving to Upgrade/Install component for better tracking.

[ibdz]

This is a solution that I'm thinking of for the auto-update status indicators.

There is a design exploration in Gutenberg for using the blue dot as an indicator. (​https://github.com/WordPress/gutenberg/issues/19909)

[Presskopp]

What's wrong using a simple checkbox?

[hellofromTonya]

Hey @karmatosed, is this one on your needs-design-feedback review list to land in 5.6?

[karmatosed]

@hellofromTonya yes it is, thanks for raising it up.

[karmatosed]

Lots of great work from everyone. I would like to catchup here a little and find a way so we can remove the feedback label for design here. I'll split up my feedback into theme and plugin screen as although together, I think that will help frame it here.

Theme:

• I like the simplicity of the text link.
• My big question is will people know what auto-updates means in the context of this screen?
• I do wonder if it's hierarchy should be at the top, it might be but considering that is important.

Plugin:

• I would lean to style as close to themes as possible, so avoid bringing in colors or shape indications.
• I wonder about the copy for the column 'Automatic updates' and then for the enabling link. Perhaps we could have the columns say 'Auto-updates' and then the link say 'Enable' or 'Disable'/ Activate/De-activate? I am unsure which of those pairings translates better.

I would like the opportunity to review all the screens in both on desktop and mobile once those changes are considered and then look to remove the feedback label. Looking forward to seeing this move into the release. Thank you again for all the amazing work everyone has done so far.

[estelaris]

Thank you @karmatosed and @hedgefield for your input and feedback. There are 4 mockups: Theme screen for both desktop and mobile and Plugins screen for desktop and mobile

[estelaris]

There is an option to add an "update notice" as I am unsure if it applies or if there is time to add it. For the user experience, it is important to know when plugins will be auto-updated (especially for admins that work with several websites), but I am happy to discuss pro's and con's

[karmatosed]

@estelaris thank you for all your really hard work and gentle response to feedback on this. I think we're in a good place to move into development here. As everyone working on this knows, updates is a bit of a path, but this is going to be a great step on that road.

It's important to note that the text treatment should be the same along with placing on both mobile and desktop, so whilst I think one mock looks like it uses bold, let's avoid that in the development along with checkboxes without marks. @audrasjb just looping you in here as this is ready to move and I am going to remove the feedback keyword from design for now. Once there is a patch, we can hop back in and give input.

Using a checkbox does bring some cognitive weight with multiples of the same interface, but after a discussion around this the accessibility gains and adaptions we can do in the text we have found a middle ground. That doesn't mean this shouldn't be explored in future versions of auto-updates, but let's get this into the beta!

Again, thanks everyone involved in getting this here.

[hellofromTonya]

Tammi notes that we have an agreed design for this ticket. Ready for patch.

[apedog]

I would on the mobile view add an hr tag (80% width?) above the checkbox. The auto-update option is part of the WP installation. While all that's above that (view details, description, links etc.) is part of the plugin.

Above is a quick and dirty Photoshop edit - so the padding/margins are off.

[karmatosed]

Thanks for the mockup and a quick version is great to convey those thoughts. For me, I would prefer without the extra hr as it feels like it removes it from the container. If the issue is it's too clustered to the top content, maybe adding more space over bringing that in would solve the problem?

[apedog]

Removing it from the container (partially - separator does not go full-width) is the idea.
Auto-updates are installation specific user "actions". While everything above it is "immutable" - plugin specific - Details, descriptions, etc.

In an ideal world auto-updates would be lumped in with Activate|Deactivate actions. But as was discussed during initial development of this feature, "Activate" and "Enable" are too similar (and in some languages are the same) so the decision was to have auto-updates in a separate column.

Anyway, this separation is what guided my thinking/feedback/comment.

[apedog]

Also - For future reference (when closing this ticket):
I'd like to voice my preference for a switch instead of a checkbox for auto-updates, Once the switch pattern is integrated into core. Obviously blue instead of green - as was mentioned above.

This will not happen for 5.6 but it should in later versions.

[hellofromTonya]

In today's scrub, decision was made to punt this ticket to Future Release as there's just not enough time and resources to get it done and tested.

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.