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.