Make WordPress Core

Opened 4 years ago

Closed 3 months ago

#47222 closed defect (bug) (fixed)

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

Reported by: davidanderson's profile DavidAnderson Owned by: clorith's profile Clorith
Milestone: 6.1 Priority: normal
Severity: normal Version: 5.2
Component: Site Health Keywords: has-patch
Focuses: ui Cc:

Description

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.

Attachments (6)

before.png (21.4 KB) - added by DavidAnderson 4 years ago.
Before the disappearance
a-few-seconds-later.png (16.6 KB) - added by DavidAnderson 4 years ago.
The ambiguous situation afterwards
Site Health Status ‹ Yoeri — WordPress.png (75.4 KB) - added by yoeridekker 3 years ago.
before
Site Health Status ‹ Yoeri — WordPress (1).png (104.3 KB) - added by yoeridekker 3 years ago.
After
47222.diff (4.1 KB) - added by palmiak 3 years ago.
47222.patch (3.1 KB) - added by Clorith 19 months ago.

Download all attachments as: .zip

Change History (16)

@DavidAnderson
4 years ago

Before the disappearance

@DavidAnderson
4 years ago

The ambiguous situation afterwards

#1 @SergeyBiryukov
4 years ago

  • Keywords site-health added

#2 @Hareesh Pillai
4 years ago

  • Focuses ui added
  • Keywords needs-patch added

#3 @yoeridekker
3 years ago

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

#4 @palmiak
3 years ago

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

@palmiak
3 years ago

#5 @msaggiorato
3 years ago

  • Keywords has-patch added; needs-patch removed

#6 @desrosj
3 years ago

  • Component changed from Administration to Site Health

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

#7 @Clorith
3 years ago

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
19 months ago

#8 @Clorith
19 months ago

  • Keywords needs-copy-review added; site-health removed

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.

#9 @Clorith
3 months ago

  • Keywords needs-copy-review removed
  • Milestone changed from Awaiting Review to 6.1
  • Owner set to Clorith
  • Status changed from new to assigned

#10 @Clorith
3 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.