Site Health Check: UI glitch leads user to confuse recommended improvements with critical issues

[DavidAnderson]

I am looking at "Site Health Check" on a site with no critical issues.

In the UI, "0 Critical issues" appears briefly, and then a few seconds later disappears. This leaves "3 Recommended improvements". However, following the disappearance of "0 Critical issues", these recommended improvements are then preceded by text which suggests that they are themselves critical and require immediate action: "The site health check shows critical information about your WordPress configuration and items that require your attention."

See attached screenshots.

[DavidAnderson]

Before the disappearance

[DavidAnderson]

The ambiguous situation afterwards

[yoeridekker]

before

[yoeridekker]

After

[yoeridekker]

What about only removing the empty container and leaving the "0 Critical issues" there?

[palmiak]

That's true - that may be confusing. In my patch I've done two things:

• I've added an extra description for the "Recommended improvements" - I'm not native english speaker so it may need some tweaking
• I've tweaked the JS a bit so the headers are also hidden

[desrosj]

Moving Site Health tickets into their lovely new home, the Site Health component.

[Clorith]

I have a counter proposal, as I agree this isn't the best UX right now, but I don't think adding more descriptions to go with the headers is the right solution;

Hide the sections (with headers) by default, until at least 1 check falls inside of it. This means there's no need to hide empty ones after the fact when all is done, and means less "janking" on the screen for the user observing.

[Clorith]

47222.patch​ takes the idea of explaining what "critical" and "recommended" means from @palmiak, and expands on that slightly.

It also changes the critical and recommended sections to be hidden by default, and only shown when an item is added to each of the sections, this should avoid "UI jank" where a section is shown, and then removed. The previous logic was to wait until all async tests were completed, and then see if there were issues, if not, hide the section, which was a bit backwards.

[Clorith]

In 53950:

Site Health: Don't show issue groups unless there are items in them.

The Site Health Status screen groups issues into the categories good, recommended, and critical when displaying them to the end user.

Initially, this screen would show 0 critical issues while the checks were being performed, and then hide the group if no issues were discovered after all checks had completed, this not being an ideal user experience, as it is a better experience to show areas that have content, instead of hiding them after the fact.

This change makes the groups hidden by default, and also changes the logic to see if a group should be displayed when an item is added to the list (as opposed to the previous approach which only did this check once every single test had completed).

Props DavidAnderson, palmiak.
Fixes #47222.