Updates UI: offer multiple variations of available updates nags to highlight older updates

[jeherve]

Today, when an update is available for one of your plugins, for Core, or for a theme, the update notice is always the same:

• It uses a single and consistent color across the different wp-admin screens.
• The update messager remains the same until you've update the plugin/theme/core.

While that works, I wonder if there could be an opportunity to better emphasize the need to update things on your site.

Google Chrome comes to mind: its update warning is first green, then turns yellow and then red to highlight the need to update.

I wonder if WordPress could do something similar:

• If an update has been available for less than a month, have the notice displayed the way we display it today.
• If that update has been available for 2 to 3 months, have the notice turn more yellow / be more of a warning.
• If that update has been available for more than 3 months, have the notice turn red.

We may even want to be more granular there; core security releases would be red right away for example.

Somewhat related: #33374

[jeherve]

Display of update notices in Google Chrome

[audrasjb]

Thanks for the ticket.
Self assigning, I'll raise it during the next #core-auto-updates meeting

[audrasjb]

Small accessibility heads up: color is not enough, we need to modify the message too. Or at least to provide a screen reader text to pass the information in another way than the color :)

Adding accessibility focus to make sure this point is taken into account.

[pbiron]

For some site admins this would probably just be seen as "noise", but I think for another class of admins this would be very useful.

That said, there will be some complications around implementing this:

• suppose a site is running v2.3 of My Plugin and the most recently released update is v2.4. What we'd really need to know is not when v2.4 was released, but when the version after v2.3 was released (e.g., v2.3.1) because what we'd want to convey is how out of date v2.3 is
• the Updates API can only reliably give us info on when an update was released for things hosted on .org. Yes, premium plugins/themes could provide that info when they hook into the API, but we couldn't rely on them doing so. Which means we'd probably have to store a transient whenever an update becomes available (with the date/time that update was detected) and use that transient to determine that color coding

Also, I've added the needs-design keyword.

[jeherve]

Replying to pbiron:

For some site admins this would probably just be seen as "noise", but I think for another class of admins this would be very useful.

Yes, that can be tricky. Ideally, I think it should replace the existing notices, not add on top it. I see it as a redesign / refactor of the existing notices (which are always the same, regardless of how old / critical the update is) to provide additional information when possible.

• suppose a site is running v2.3 of My Plugin and the most recently released update is v2.4. What we'd really need to know is not when v2.4 was released, but when the version after v2.3 was released (e.g., v2.3.1) because what we'd want to convey is how out of date v2.3 is

Indeed. We'd have to start from the version installed on the site, not just the latest release of the plugin.

[jeherve]

Replying to audrasjb:

Small accessibility heads up: color is not enough, we need to modify the message too. Or at least to provide a screen reader text to pass the information in another way than the color :)

Yep, that's a good point.

An additional element that came up in discussions earlier today is that we could also leverage the Site Health component here. It should / could be possible to link from the update notice to the Site Health if folks want to find out more about available updates, and why their notices are green / yellow / red.

[juliobox]

suppose a site is running v2.3 of My Plugin and the most recently released update is v2.4. What we'd really need to know is not when v2.4 was released, but when the version after v2.3 was released (e.g., v2.3.1) because what we'd want to convey is how out of date v2.3 is

My idea is to keep the date from the first update encountered.
Let's say I'm running a v2.3 and a 2.3.1 is available on 1st jan.
Then, 1 month later, still not updated, a new v2.3.2 is up.
I'll be warned to update from 2.3 to 2.3.2 with a timing of 1 month and not 1 day.
Only when I update, my counter for this plugin is reset.

---

Regarding the design, like @jeherve said, we have to use the current noise and not add more.
So, what do we already have:
1/ in adminbar with the "update" dashicon + total number of updates
2/ admin menu on index.php, entry "Updates" with the red bubble with the total number of updates
3/ admin menu on plugins.php, entry "Installed Plugins" with the red bubble with the number of updates
4/ admin menu on themes.php, entry "Themes" with the red bubble with the number of updates
5/ Notices with "WordPress vx.x.x is available! Please update now."

So we can reuse everything, we can just modify.

Here comes my ideas:
0/ First (yes I use 0 for first, I'm a dev you know), we could change the usual red color depending on how many days the update is available. Let's say "blue for < 7 days", "orange for < 21 days" and "red > 21 days", we can change that, not a big deal now.
1/ in adminbar the background of the menu entry could be colored like said in 0/ and a mouseover displays the most critical timing. Ho, the color will match the most critical update, so if I have a plugin update since 1 day and a core since 16, it will be orange. see 54265-adminbar.png
2,3,4/ change the color to match the most critical update timer
5/ More accurate message and color. see 54265-notices.png