search

WordPress / health-check

Health Check is a WordPress plugin that will perform a number of checks on your WordPress install to detect common configuration errors and known issues.
GNU General Public License v2.0
175 stars 55 forks source link

Designing the UX and UI #227

Closed hedgefield closed 5 years ago

hedgefield commented 5 years ago

The plugin could admittedly use a good look at the design and user experience before its merge proposal, but rather than jump in with specific cases I figured it's good to look at the plugin as a whole first, and consider what approach we want to take.

UX

The plugin is currently very functional, but that's about it. It displays information and offers tools for those who kind of know what they are doing. To make it a success, I think we need to look at a few things:

Onboarding

What happens when a user first starts using the health check, and what do we teach them?

Guided complexity

There are a lot of tools in the health check, but maybe not all of them have to be on the same level of visibility. Are there things we can make contextual, or do behind the scenes to make it simple to start but powerful when needed?

Scannability

Sort of related to the previous point, basic information should be easy to glance at. Bold numbers in visible places to give you a quick sense of how things are doing before jumping in.

Gratification

To ensure people like using the plugin, doing things with it should be gratifying. Instant (micro)feedback, red numbers turning green, smooth animations, and a feeling of progress could contribute to a pleasant experience.

UI

The last point under UX also relates to UI: things have to look nice ;) Since this might be one of the first big things added to WP core after Gutenberg, it makes sense to use the visual style they developed, as I believe was their intention. It's nice that the marketing around the Health Check previously has also used a similar style, with strong black-and-white typography and pleasing whitespace and font sizes.

Another possible inspiration suggestion was Google Lighthouse, which also has a similar feel, and does well in the gratification department.

screen shot 2019-01-07 at 09 37 48

As we go along I'll discuss details with the WP design team, but it feels like a good place to start.

Any thoughts appreciated!

hedgefield commented 5 years ago

I started off with some sketches for the status page:

I then tried a more detailed breakdown like Lighthouse, but you can't render any progress bars on metrics like 3 critical issues. How much of a percentage is that? That got me thinking about the possibility of grouping the checks differently. Instead of one big pile sorted into mustfix/shouldfix/good, could we define a few groups of checks around a specific area? Things like security, speed/performance, accessibility? Maybe just those three, I think most checks could fit under one of those. It does split critical items out over multiple categories, but in return you get a nicer breakdown of your site health, and context for what fixing those problems contributes to.

So then I riffed off of that, trying different layouts:

Here's what it looks like now, for comparison:

boemedia commented 5 years ago

Cool initiative! Happy to collaborate on this where I can. Please note that the design on this postcards is from WordCamp Brighton and initially, these were printed for that occasion. Therefore I'd discourage to work from that design.

jordesign commented 5 years ago

Super keen to be involved in this - Health Check is a great too and I strongly believe some UX and Design could make it an even more useful tool for people.

@hedgefield I think your initial thoughts are great. I'm wondering what the ideal goal for a user of the plugin is? Are we hoping to inform them, or trying to entice them into action to improve things?

Clorith commented 5 years ago

We're trying to entice them into acting with the Site Status page. Ideally we'll be able to include more action points alongside the recommendations, for example:

Of course, not everything is easily actionable from within WordPress, but those things that are, it would be great if we provided the users with a quick and simple way to fix things on their own right there and then.

jordesign commented 5 years ago

That sounds perfect - I love the idea of having link/button CTAs for issues they can address immediately. For the other things things (that aren't easily actionable) perhaps we link through to support docs with information of how/what to ask their host for etc?

hedgefield commented 5 years ago

Hi @jordesign, nice to have you!

@Clorith put it quite well already, yes, we'd love things to be as actionable as they can be. I put together a quick general overview of what I think the flow could be around solving the issues.

health check ux flowchart

To understand this it will be good to know that we plan to group the issues in three categories: critical issues, recommended improvements and passed checks. They will all three be collapsible sections, containing lists of issues with actions attached. Passed checks are collapsed by default as the user will need to take no action on those. We could consider hiding that section altogether for that reason, but it also has some useful information like PHP version etc. Maybe we should actually split those up into an info area and an action area now that I think about it, so you can really reach 'inbox zero'...

Clorith commented 5 years ago

I like the idea of "inbox zero", it's my favorite scenario whenever I look at action lists, especially when it lets me know everything is good and there's nothing I need to address, so the psychological aspect of that shouldn't be dismissed.

As for groupings, I'm open to interpretation, the approach I've taken so far has been me experimenting more so than any fixed plan, so I'll defer to your experiences in that regard.

The flowchart is perfect, and the ideal scenario I would love to reach!

hedgefield commented 5 years ago

Great! And do keep offering your view on things @Clorith, you probably know this plugin better than anyone right now 🙂

The above flowchart is specific to the actionable issue-solving, I also want to make one that is like a decision tree for the other features the plugin has, so we cover everything.

Right now, this is my list:

Are there any other things we want to include that are not there yet? Is an integration with Google Lighthouse possible? Or should we offer that as a separate resource? An accessibility checker would probably also be nice?

boemedia commented 5 years ago

I'm also thinking of checks/info on:

As or accessibility: not sure about Lighthouse integration, although it does provide a lot of info. People of Deque (from the AXE addon in the browser dev console)have been involved with A11y during WCUS contributor day, so they may be able to help out here? Pointing to a doc (the a11y handbook?) with more info on how to improve A11y as a tip could be interesting.

In general, the parts of the check could have:

As an example, see this page from commercial website auditing software that I think does it quite well. (screen shot is a year old, so could be outdated)

image

hedgefield commented 5 years ago

I did some sketches with quick wins based on the discussions so far (click to enlarge):

health check 1 status health check 2 info health check 3 troubleshooting health check 4 tools

These are the four main sections featured:

Status page

Shows a big circular status bar that calculated a site health score based on the % of 'fixed' checks, with the full list of checks below it. The checks are split out into critical issues/recommended improvements/passed checks. Each issue has a description of the problem, and a button if the problem can be fixed by pressing a button, otherwise a link to a settings page or a wp.org article for more info.

Passed checks should maybe be hidden to create an inbox zero vibe. And I was thinking we could perhaps also tag issues with the type of improvement they yield (speed/security/a11y etc), shown as a badge or color.

Info page

This is a merge of the debug information and php information page, as they both do the same thing: show a list of information about a thing. I've placed the categories of info into collapsible sections as well, which removes the need for the second set of sub navigation that was on this page, and also brings it in line with the way other pages present information.

I believe PHP was a bit of a gray area, so perhaps we could also simplify it by linking to a wp.org page (or section of the servehappy page) that explains where to find the PHP info on your hosting.

I've simplified the UX for sharing this info with a support engineer or someone else from click button > select all text > copy text > paste somewhere else to click button > get a plaintext file.

Troubleshooting page

This page probably needs the least amount of work, but I've enhanced the messaging by adding some illustrations that explain what this thing does, it's a little scary now with the sparse copy and a button that turns it on(???)

Tools page

Can stay as-is, it already has the collapsibles, and doesn't need much more flavor in my opinion. Just more tools in the future maybe!

Clorith commented 5 years ago

I like this direction, and especially your thoughts around the site status where they're grouped by severity, and a customizable badge for what area they belong to. This also makes it easier if anyone wants to hook into it, for example a host wanting to add cache status to it.

What would this look like in a core-only world, where Site Status lives by it self without the other 3 tabs, would it be the same, only without the tabs for other pages?

hedgefield commented 5 years ago

Good question, though I think the page can actually probably stay as it is in that scenario. In an ideal situation there is a check for every important item on the info page, so then if you need general site info you can just look through the passed checks section.

I've been working on some style tests of what a full page could look like. I started with a very conservative classic WordPress look, working my way up to what I imagine for a full Gutenberg styling.

You can view the design iterations here, or skip right to my favorite so far:

Left is grouped be severity and tagged by category, right is the other way around. Also, left works like inbox zero, right works like a checklist.

I chose to hide actions behind the More info, as there are very few checks that can actually accomodate a one-click fix; for most you have to do the legwork yourself, so the section contains some extra context and then a link to find out more if the user wants to. Having them all collapsed by default prevents information overload.

We can scale back to a happy compromise if the gutenberg styling is too jarring, but I must say I like that one best so far.

I'd love to hear your thoughts!

Clorith commented 5 years ago

Personally, I really enjoy this style, I agree that the "Gutenberg-like" ones are more visually inviting (and aligns well with the direction of core).

I feel like the left option, grouped by severity, gives most flexibility when taking into account potential items added through filters.

hedgefield commented 5 years ago

After presenting the design in the WP Design Meeting we got some nice feedback, the main thing being that the list on the status page is styled differently to the collapsibles. It's a choice we made on instinct, but I tried a version with the standard gutenberg collapsibles and it actually looks good too!

site health check status gut 4

I fixed the margins too, though I'm sure we'll get some more pointers out of the accessibility review.

Clorith commented 5 years ago

Excellent, this looks great!

Which fonts are used, I noticed they're not the system fonts used by default, so we'll probably want to match the fonts one way or the other. The font you looked feels warmer than the system font, which is quite sterile in comparison.

hedgefield commented 5 years ago

I've adhered to the WordPress font stack for body text, which on Mac defaults to San Francisco, which is what I used in the mockups (tiny variances in rendering perhaps). The headings font is Noto serif, the default Gutenberg headings font.

Clorith commented 5 years ago

Ahh, that would probably be it then, the header font is what I mostly noticed, so that's why, thankyou 👍

hedgefield commented 5 years ago

I connected the four pages of the mockup together in an interactive prototype to make it easy to check them out. https://sketch.cloud/s/3P4LZ/WKrlQxn/play

jordesign commented 5 years ago

Really loving the look of this - nice work :)

A coupe of things that might be kind of nitpicky, but nonetheless...

jordesign commented 5 years ago

A couple of other things I'm wondering too...

hedgefield commented 5 years ago

Good points @jordesign, thanks.

site health check status gut 4

Clorith commented 5 years ago

I do have a concern with action items on the "top level", what if there's more than one action, for example: As the tests are filterable, a host may want to add in information on how to upgrade PHP as an actionable step for the upgrade PHP, but retain the core information on why it's important which takes you to the wordpress.org/support/update-php page.

Another situation might be like the Loopback test, where the actionable item is to test without plugins or themes, and you get followup actions depending on what results that provides, but also needs the expanded area to show the response from the continued testing there. (totally get the thought though, perhaps an indicator that there's an actionable item is needed?).

As for the label colors, I've actually gone the route of providing just a fixed set of colors for the base (that we'll include) that others hooking in can keep using, like saying badge => color: red, so this is easy for us to change once we figure out what colors we want to provide by default. But I agree that they'll be considered "traffic signals" for how important something is.

hedgefield commented 5 years ago

Great considerations @Clorith, makes sense, let's keep any actions inside the collapsible. It's always good to be able to offer a little context before asking the user to perform an action. Some kind of icon to indicate actionability might be interesting to explore. And great that the colors are set up as variables, we can always tweak the values.

jordesign commented 5 years ago

Thanks @hedgefield and @clorith,

And great that the colors are set up as variables, we can always tweak the values.

I think this is good too. I feel like the colours in the most recent iteration are a lot less 'traffic signal'-ey though - I like them.

let's keep any actions inside the collapsible. It's always good to be able to offer a little context before asking the user to perform an action. Some kind of icon to indicate actionability might be interesting to explore.

Agreed that action button after context makes sense. I am interested in the idea of an icon to indication actionability though... Will that fit with the Gutenberg 'like' styling?

site-health-mockup

afercia commented 5 years ago

Please check color contrast. In the screenshots above, I see some orange and light green "label" boxes with white text that don't pass the 4.5:1 threshold.

hedgefield commented 5 years ago

Thanks @jordesign! I like your idea of making the actionability a label just like the categories, that fits nicely I think. Perhaps we should call it Quick fix? Fix available may make it sound like the other ones do not have a fix, which is not true, it's just probably not quick ;P

I've added it to the prototype and updated the failing colors. https://sketch.cloud/s/3P4LZ/dlQL4Om (Color matters can be discussed in #290)

Clorith commented 5 years ago

Quick Fix doesn't feel accurate either, if we're basing this on "does it provide any action items", since an action item may be more than just a "fix it automatically" button 🤔

jordesign commented 5 years ago

Quick Fix was a rough idea - I agree it's not quite right...

'Fix Now' implies an immediate action. I think it is OK if an immediate action like upgrading Core is different to other action items?

Clorith commented 5 years ago

What about something a bit more vague, to account for non-fix-actions as well?

Actions available feels a bit wordy, and I don't know how well it works for translations either, but some sort of variation on that would be useful I suspect?

hedgefield commented 5 years ago

Yes, it has to convey the feeling of "you can do stuff!" without also making it seem like you can't do anything about the other ones... If we want that label. We might consider we're trying to solve for showing a button here, so maybe it's okay that people have to dig in to find out what they can do? Otherwise they may also bulk the quick fixes and ignore the rest as they have to read stuff ugh.

Clorith commented 5 years ago

I'm thinking, for the first iteration at least, we'll not do anything extra, we'll leave it as is now, with a label, a badge and that's it. Users will expand it to reveal more information and actionable items.

We can then judge if there's even a need, it may be intuitive enough to just expand them for more details, and if they see there's buttons to click, it becomes clear that this is a thing, sound good?

hedgefield commented 5 years ago

Sounds good to me 👍

Clorith commented 5 years ago

This was just merged in, the two things that are still missing is:

Inbox zero, if there's no critical tests failing, the critical section isn't displayed, the same goes for the recommended section. The passed tests are hidden by default. This means if all tests pass you just get a screen with just a "Show passed tests" toggle, we discussed earlier that it would be nice to include something encouraging to indicate the user did a good job keeping on top of important tasks.

Onboarding which is in #206 and not as critical for the current window we're trying to hit with 5.2-beta1, as it doesn't relate to core, only the plugin.

hedgefield commented 5 years ago

Ah yes right! The empty inbox, was going to look at that, thanks for the reminder. EDIT: I did.

Clorith commented 5 years ago

As the new design is implemented at this point, I'm marking this ticket as closed.

Any issues that crop up relating to it I suggest should get their own tickets for visibility.