Redesign the status report and available updates pages.

[jenlampton]

As per suggestion from @Bojhan in #283 we should probably evaluate the effectiveness of the backdrop status report, and redesign as necessary.

I've added the audience - design tag, if we have anyone with user interface or design experience, this would be a good place to lend a hand :)

---

latest PR by @jenlampton: backdrop/backdrop#1836

[wesruv]

Can someone provide a list of statuses that are possible?

Is it:

• emergency/critical
• warning
• informational
• good

Missing anything?

Think we should borrow from the Recent Log messages design that we did a ways back that got merged in.

[quicksketch]

Can someone provide a list of statuses that are possible?

That's it. From theme_status_report():

  $severities = array(
    REQUIREMENT_INFO => array(
      'title' => t('Info'),
      'class' => 'info',
    ),
    REQUIREMENT_OK => array(
      'title' => t('OK'),
      'class' => 'status',
    ),
    REQUIREMENT_WARNING => array(
      'title' => t('Warning'),
      'class' => 'warning',
    ),
    REQUIREMENT_ERROR => array(
      'title' => t('Error'),
      'class' => 'error',
    ),
  );

[wesruv]

Howz about something like this:

The color coding of rows seemed like a bit much. I think a nice icon on the left can do the job better.

Wanted to pull out the short status message visually, and bring it closer to the status title. Think the 'mark' styling works pretty well, a little iffy on whether or not this is a valid use of the 'mark' style... thoughts?

[bd0bd]

Nice.

May be enlarge symbols inside icons.

[docwilmot]

yes

[klonos]

Yes, 👍 ...took a few seconds to get used to it, but it matches the rest of the admin UI better.

[Dinornis]

👍 ❤️ Great job @wesruv I like it, although slightly larger symbols inside the icons would be better.

[klonos]

Long-forgotten issue because of no assignee or label I guess. Getting this back into @wesruv's radar for when he has time 😉

[klonos]

Given the fact that we haven't settled on a specific design yet and also that @wesruv is not available lately, I thought that I might give this a try. I only aim to implement a few simple fixes without altering the current design that much. So, a few thoughts first...

1. As it is currently implemented, we have icons showing only for warnings and errors on that page. IIRC we've done this intentionally, in order to declutter the page and to take the emphasis away from the info and "OK" (status) rows. That is fine in general, but when there are only info and status rows on that page (basically when the site status is OK), then there is what seems to be an unnecessary padding on the left of the rows:

   

   ...I initially thought that this would be easily fixed by just making some padding adjustments, but the horizontal "gap" is actually created because we (unconditionally) still render the table cells that are to hold the row icons even if there are no icons to be rendered in them. So, should we reintroduce the icons for info and status messages (simple css change), or should we adapt the logic (php) so that the entire column is not rendered when there are no icons in any of the rows?

2. Here's a screenshot of a series of test rows of all types (info/status/warning/error) and also in various combinations of a) simple rows, b) rows with a short description c) rows with long description text:

   

   What's wrong here is that there is no distinction between the row title and the row text or the description, which makes it hard to read this table. We also have a big distance between the row title and the text which makes it harder for the eye. The fact that there is no zebra striping going on makes this even worse.

This can be easily mitigated if we make some small changes like making the row title text bold and have the row titles occupy only as much width as the longest of them requires in order to be rendered without wrapping in a second line:

...as you can see, having the row title in bold makes it more readable and getting the respective row text closer to the title text improves the situation a bit further. The bold title text also helps distinct the title from the description text (if there is one).

PR up for review with only the changes suggested in point 2 above. Pending decision on point 1.

[klonos]

...by the way, the PR is a quick fix to improve the situation even in a 1.6.x release. We should still keep pursuing a complete redesign of this page and also make it responsive in a next minor release.

Here's what's in Drupal 8.3 for reference:

No errors:

With errors:

Mobile:

[olafgrabienski]

@klonos I had a look at the PR and think it's a good start due to much better readability.

I'm not yet sure if I like the changes of the Status report page in Drupal 8.3, but it would really be good to make the page responsive as well. Couldn't we reach that goal simply by using div containers instead of a table?

[jenlampton]

I'm with @olafgrabienski, I'm not convinced the 8.3 redesign is a usability improvement - it definitely looks prettier, but IMHO would also be harder to use.

One thing that stood out to me as an improvement is the three boxes at the top for ERRORS / WARNINGS / CHECKED.

Also about the icons, I don't think the icons were left out on purpose, it's likely it was an oversight. I, for one, would love to see an i icon for info and a checkmark for good.

[jlfranklin]

Moving the General System Information to its own page would prevent the errors list from falling below the fold, and put the more "information only" links in their own place. My primary purpose for the Status Report page is to make sure nothing is broken or missing on the site. I'm looking for red.

Do other modules that include / require JS libraries show up in the General System Information section or down below in the "Checked" section? (Or in a fourth group?)

I haven't played with the new version in D8, but I expect those "details" links scroll you down to the appropriate section.

[laryn]

Design changes here could also be reflected on the "Available Updates" page (e.g. icons to the left, perhaps removing the colored background, etc.)

It would be great to be able to filter the status page at the top, the way Module Filter allows on module / available updates page*:

*Side note: it would also be great to have that extended filtering capability on the module / available updates page in Backdrop

[klonos]

Yeah, I'm not sure about the D8 design either (especially the fancy logos/icons etc). I just put it there for reference. The good thing is that they have the resources to do usability tests, so there must be valid reasons for the changes.

What I like is that they've put all the server environment info (versions of core/apache/mysql/php etc.) together instead of having them spread all over the place. And to be honest, grouping things by severity level instead of alphabetically does make better sense.

As for mobile-friendly, you'll notice that in the current design what "consumes" the width of the page is the row description text. We could use fieldsets that are collapsed by default (perhaps have the critical errors be expanded).

[jenlampton]

As for mobile-friendly...

Or we could add the appropriate classes to the table columns, like we do in the rest of core.

[klonos]

Also about the icons, I don't think the icons were left out on purpose, it's likely it was an oversight. I, for one, would love to see an i icon for info and a checkmark for good.

Yeah, I have already tried that @jenlampton, but having checkmarks everywhere looked kinda overwhelming ...and kinda unnecessary; especially in "all green" status:

...looks a bit better with the background color removed from the rows (font colors retained):

...perhaps if we added zebra stripping??:

[klonos]

...talking about zebra-stripping, the table in this page is not rendered through theme_table(), so we don't get even/odd classes. Seems that we are are doing custom table rendering in order to add the .merge-down/.merge-up classes that remove the border between the "combo" rows (the ones that have description text).

[klonos]

Moving the General System Information to its own page would prevent the errors list from falling below the fold, and put the more "information only" links in their own place. My primary purpose for the Status Report page is to make sure nothing is broken or missing on the site. I'm looking for red.

Yeah, under "normal" circumstances, these will remain "info" rows, but if say you move your installation to another host that has an incompatible version of php, then that will become a warning or error. What would we do in such cases? ...duplicate the status on both pages?

I haven't played with the new version in D8, but I expect those "details" links scroll you down to the appropriate section.

Yep, that's what they do. More useful on mobile and on narrower screens where the "General Info" section pushes the list of statuses further down.

[klonos]

Design changes here could also be reflected on the "Available Updates" page (e.g. icons to the left, perhaps removing the colored background, etc.)

I agree. Care to open a separate issue for that.

It would be great to be able to filter the status page at the top, the way Module Filter allows on module / available updates page*:

*Side note: it would also be great to have that extended filtering capability on the module / available updates page in Backdrop

Way ahead of you @laryn 😄 (more than two years): #503 / #978 / #980

[klonos]

As for mobile-friendly...

Or we could add the appropriate classes to the table columns, like we do in the rest of core.

Given that hiding the icon column would only give us ~14px, we only have two main columns in that table that we could hide: requirement title and requirement value. If you hide either of them, then the table stops making sense.

[quicksketch]

Latest PR has some more PHP notices showing up in tests:

exception Undefined variable: extra_section update.theme.inc:273
exception Undefined variable: base_section update.theme.inc:273

[jenlampton]

Let's keep the classes consistent

I changed the new class name to status-summary-mobile

the status-description div should be font-size: 0.9em; color: #444;

done.

can we please update the "There are security updates available for one or more of your modules or themes." text to also include layouts?

done.

Latest PR has some more PHP notices showing up

fixed.

Operations (like "run cron", "run db update" and "rebuild permissions")...

For the mobile display, I agree that we need to allow access to these links, but I don't think that we need to display the more/less description area. I tried to show all or part of it several times, with limited success.

What I came up with is an API addition: for each requirement, a new element called "button" is allowed, it's an array with two keys: title for the text in the button, and href for where it should link. Here's the updates docs for hook_requirements:

 * @return
 *   An associative array where the keys are arbitrary but must be unique (it
 *   is suggested to use the module short name as a prefix) and the values are
 *   themselves associative arrays with the following elements:
 *   - title: The name of the requirement.
 *   - value: The current value (e.g., version, time, level, etc). During
 *     install phase, this should only be used for version numbers, do not set
 *     it if not applicable.
 *   - description: The description of the requirement/status.
 *   - button: Button for performing a related action. Not to be used for links
 *      to other pages on the site, but to kick off actions directly from the
 *      status report such as "Run cron" or "Rebuild permissions". Two keys are
 *      required:
 *      - title: Text to be displayed in the button.
 *      - href: Path for the callback to preform the action.
 *   - severity: The requirement's result/severity level, one of:
 *     - REQUIREMENT_INFO: For info only.
 *     - REQUIREMENT_OK: The requirement is satisfied.
 *     - REQUIREMENT_WARNING: The requirement failed with a warning.
 *     - REQUIREMENT_ERROR: The requirement failed with an error.
 */
function hook_requirements($phase) {

This will allow us to treat the button differently than the rest of the description text, and pull it out for an easier display on mobile devices:

[jenlampton]

For buttons on errors on the status report, we could color them accordingly

Desktop:

Mobile:

[markabur]

Looks good! Red button with white text would be too alarming, so it makes sense to go with red text on white bg with a border.

[jenlampton]

Okay, so @quicksketch doesn't like the buttons (or the API addition) and made another recommendation that would require less rewriting of everything: moving the "important" links into the status value - where the link for "PHP information" is located. Here's a go at doing that:

Desktop:

Tablet:

Mobile:

[Dinornis]

I think the buttons would be okay with less padding.

[olafgrabienski]

The buttons are visually more clear but if moving the links is less problematic API-wise, it's a good idea to do so!

Looking at the mobile screen: there is no "important" link in the case of available security updates, which may confuse or scare users.

[klonos]

Yeah, I like the big, differently-styled buttons better too. But if the API addition is out of the question, oh well.

...can we at least try to make those links look like buttons in order to differentiate them from the more/less links?

[quicksketch]

Looking at the mobile screen: there is no "important" link in the case of available security updates, which may confuse or scare users.

I pushed an update that adds a link with the text "Updates available".

...can we at least try to make those links look like buttons in order to differentiate them from the more/less links?

It seems I might be in the minority here regarding the buttons. How about if we make the API expansion and buttons a separate issue and call this one complete?

[jenlampton]

How about if we make the API expansion and buttons a separate issue and call this one complete?

👍

[klonos]

...one minor nit I've noticed in the PR sandbox is that clicking the more/less link changes the width of the status-value column width.

[Dinornis]

Also, the more links disappear on screen widths with less than 734px in Safari and 720px in FireFox.
Not sure how I can trigger any status report errors or warnings.

[jenlampton]

the more links disappear on screen widths with less than 734px

Yes, this is by design. We need that whole column to disappear on mobile.

Not sure how I can trigger any status report errors or warnings.

Change the variable $udpate_free_access in settings.php to TRUE to get an error. For a warning you can install an older module or theme that has an update available (but not a security update, as that will also be an error)

[quicksketch]

...one minor nit I've noticed in the PR sandbox is that clicking the more/less link changes the width of the status-value column width.

Thanks @klonos fixed that minor issue up as well. Now the right column takes up as much space as allowed even if it doesn't need it, so when descriptions are opened it will not enlarge the column any further.

[quicksketch]

I've merged backdrop/backdrop#1836 into 1.x for 1.7.0. Let's please create new issues for follow-ups (both large and small).