Opened 4 years ago
Last modified 4 years ago
#50623 assigned enhancement
Discoverability of plugin and themes autoupdates
Reported by: | francina | Owned by: | audrasjb |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.5 |
Component: | Upgrade/Install | Keywords: | has-screenshots needs-patch |
Focuses: | ui, accessibility, administration | Cc: |
Description
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.
Attachments (21)
Change History (54)
#2
@
4 years ago
Hello folx
what are the chances to get some design eyes on this for a 5.5 iteration?
Thanks!
#3
in reply to:
↑ description
@
4 years ago
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.
#4
@
4 years ago
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 setting of the Auto-update functionality. 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 if this settings is enabled/disabled.
We found out that no switches are used in the current WP admin. (except for the switches in GB) Therefore, we wanted to try using radio buttons first. (existing WP component)
We tried this setting with radio buttons / switches on three different places:
- The right 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's logical 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 not much) theme(s) and don't really need this functionality.
Please see the designs in the next comments:
#6
@
4 years ago
Please note that the radio buttons and switches are placeholders and don't have WordPress styling yet...
#7
@
4 years ago
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:
- Buy-in from the folx working on the autoupdates (I'll bring this up tomorrow, September 8th on the dedicated chat)
- Accessibility review to make sure we are picking the best option
- Design feedback
I would still very much like to see this land in 5.6
This ticket was mentioned in Slack in #core-auto-updates by francina. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#11
@
4 years ago
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.
#12
@
4 years ago
- Component changed from Administration to Upgrade/Install
Moving to Upgrade/Install component for better tracking.
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
4 years ago
#15
@
4 years ago
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)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
4 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
4 years ago
#19
@
4 years ago
Hey @karmatosed, is this one on your needs-design-feedback
review list to land in 5.6?
This ticket was mentioned in Slack in #design by hellofromtonya. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-auto-updates by estelaris. View the logs.
4 years ago
#23
@
4 years ago
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.
@
4 years ago
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
@
4 years ago
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
This ticket was mentioned in Slack in #core-auto-updates by estelaris. View the logs.
4 years ago
#25
@
4 years ago
- Keywords needs-design-feedback removed
@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.
#26
@
4 years ago
- Keywords needs-patch added
Tammi notes that we have an agreed design for this ticket. Ready for patch.
#27
@
4 years ago
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.
#28
@
4 years ago
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?
#29
@
4 years ago
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.
#30
@
4 years ago
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.
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
4 years ago
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#33
@
4 years ago
- Milestone changed from 5.6 to Future Release
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.
HI @francina, and welcome to Trac! :wink: I've updated this to the Administration component.