Redesign the status report page

Great, subscribing

Great initiative, just 2 things:
- it seems gray-and-white zebra row striping and color-coded rows do not mix too well. If light yellow and pink try to convey a message, gray and white row color feels totally random. Why "database updates" and "file system" are on white, "access", "cron", "gd" on gray? Can we make an exception and disable zebra-striping here?
- I can not wait for fresh icon replacements here, drupal 4.5 is still haunting us ;)

What are the thoughts on leaving in the green ticks for items that are ok? I agree that it could be a bit more distracting, but nothing quite beats looking down the list to see all green ticks and to know everything is running well...

- Generally, I'm in favor. This is similar to the direction we recently took the d.o project node UI...

- The status report is handled by system.module, and populated by every module that implements hook_requirements(). This isn't specific to update.module at all. Moving to the "base system" component (not sure, maybe system.module would be more appropriate?).

- I'm drawn to wretched sinner's position in #7. I had a hard time letting go of the icons *and* colors as we worked on the project UI. It's nice to have *some* indication that "everything's cool", especially on a page like the status report. Yeah, it doesn't have to SCREAM that to you in every possible way, but I agree it's nice to have something to explicitly mark that a given row is happy, instead of just having a neutral white background and expecting users to either read all the text to know it's okay, or just tune it out. If we expect them to tune out all text in a white background, that seems to set a dangerous precedent. In that case, why display it at all? :/

Tagging this beauty.

Can I ask why we are using light yellow and pink 'pastel shades' whilst normal site error messages are displayed in a vivid orange/red/green? Shouldn't we try and be consistent with the rest of the site? I find that these light shades blend in with the surrounding grey too much and it all just looks a little wishy-washy, like we are scared to alert the user to these problems so instead of plainly telling them they have a problem with a bright orange, we gently break it to them with a washed out yellow.

so, we need a developer to do the table rendering changes?

Subscribing so I can test / contribute to this tomorrow.

Marked #753764: Duplicate and incorrect error messages during install as duplicate.

In that issue, my point (besides another that has already been fixed) was: The status report and the system messages should be more consistent in their use of color. I think the consistent use of the same colors (for example: http://drupal.org/files/issues/system-status-colors-admin.png) will create a better UX. Also, when an error message is shown on the same page as the status report (screenshot: http://drupal.org/files/issues/d7-install-error_1.png) the combination of colors is just plain ugly.

On a sidenote, I'm a little surprised that #538666: Seven theme not right with the status report screen hasn't been mentioned here before. Although the focus over there is a little more on accessibility, it's basically a duplicate of this one.

This patch needs a little more work. see how the formatting is inconsistent? Some left-hand table cells are "open" and others are almost closed. See screenshot.

When dealing with the table markup the answer might be similar to what I found in #746678: Markup issue with tables (admin/appearance/update)

Also, I think someone might have brought this up before, the yellow used for warnings appears to light in IE on my screen. I have to look very closely to see a difference between the light yellow and the white on my screen. The end result is very displeasing to my eyes.

subscribing

Ok, so I'm looking at this issue & wanting to look for places where this messaging color background is being implemented. In talking to Bojhan & yoroy on IRC it seems important to look for places where the pattern is being implemented:

It's being implemented here - admin/reports/dblog
with - modules/dblog/dblog.css

It's being implemented here - admin/reports/dblog
with - modules/dblog/dblog.css

Status Report - admin/reports/status
with - modules/system/admin.css

Available Updates -
with - modules/update/update.css

And the install.php
with - ?? I'm not sure how to call up and compare those tables..

In Seven's error messages
with - themes/seven/style.css

It's also in Bartik & Garland I think:
themes/bartik/css/style.css
themes/garland/style.css

Are there others that are missing?

I added a patch here that touches on this issue http://drupal.org/node/639368#comment-3211194

Sub.

Also see #906738: Status report need identifying icons (WCAG 2.0), which does some cleanup by removing the icon on "OK" rows.

This totally makes sense.

It does not make sense to show everything in green on the Status report page. The positive state on the Status report is informational only.

So the Status report output should use the .info state instead of the .ok state for positive assertions (met requirements).

And that leads to the subsequent issue: Using a blue color for neutral information (.info state) is inane. The .info state should just be grey (or even more simple, use the theme's default table row background - but yet, provide a dedicated CSS class so that themes are able to target that special table row case, if they want).

However, implementation-wise, I'm not OK with removing the .ok CSS classes that visualize a green/good state. There are use-cases for visualizing an OK/good state; e.g., to highlight a positive state after performing an action.

I'm also a bit on the fence, whether this should be applied to the installer. In the installer's case, the green .ok state is actually used in the context of a confirmation (as mentioned above). As a user installing Drupal, it's good to see which requirements are positive and which are negative. So I'd say that requirements rows on Status report != Installer. I'm not sure whether we use the same code for both, but if we do, then this would boil down to something like this per table row:

  // Use .ok in the installer to confirm requirements;
  // otherwise .info for neutral exposure on Status report.
  'attributes' => array('class' => defined(MAINTENANCE_MODE) ? 'ok' : 'info'),

Attached patch implements just that.

Whoa, interesting - I actually had my status report open and refreshing it with this patch applied created so much more calmness.

I agree that using the blue color for neutral information is insane, we have a special signal for it being "nothing". I always thought white was neutral :). I do agree that we need to be cautious just adding this to the installer, the green is a good emotional way of signifying that they are almost there. I am open to discussing it more, because removing the green also makes it more of a "see this rainbow of things you did good and didn't".

I do think we should try to use the gray color for the left column. The scanability of this table is determined by your ability to match label on the far left in the left column to the description in the right column. By using color you create proximity, this allows the eye to use the left gray bar as a "landmark" to move down from - visually each item becomes more a "chuck" than by using no color.

Re-introduced the visualization of the vertical (instead of horizontal) table header column.

Yoroy can you give this a review?

This looks pretty good.

The only thing I'm not sure about, is the way the descriptions (e.g. under "Node Access Permissions" in Bojhan's screenshot) are displayed. IMHO the descriptions break the vertical rhythm, make the lay-out look broken and take up to much space compared to their importance. Especially the description under "Node Access Permissions" reads like a help text rather than details of a status report. Can we think of a way to make them less intrusive?

#1463956: Shorten and clean up status report messages

The actual descriptions shouldn't be touched in this issue; instead, see #1463956: Shorten and clean up status report messages.

To resolve the vertical rhythm issue (which I agree with), I'd propose to remove the colspan over the entire table width, and instead, put the description in the "right" value column only.

I.e., this: :)

Yes, thank you, much better!

Attached patch additionally fixes the vertical alignment of the icons (by removing the separate icon column and sneaking a new .icon style into core through this patch :-D)

Additionally resolved that "todo" ;) by simply switching the icon markup from DIV to SPAN.

The line spacing in those descriptions has become really tight.

I rly rly love this patch but it's back to needs work

1. .icon needs rtl styling for margin-right
2. shortcut and toolbar styling is broken

It's dangerous to touch .icon in here it is used in other places around core.
After discussion with Sun we agreed to use the pathc in #43.

I tested that one (also in RTL), and it is RTBC.
Reuploading to ensure the right patch gets pushed.

Chrome on Windows 7 and the first column is too narrow, I am not enough of a CSS guru to figure out what it is.

Re-rolled against HEAD. (Also note that this code lives in the platform-statusreport-665790-sun branch now)

Attaching a full stack of screenshots, including RTL output.

This looks ready to fly for me.

Let it fly then!

Definitely an improvement.

Re #53: What happened to the toolbar position in status-report-seven.png? Is it safe to assume it has nothing to do with this patch?

yes, that's not toolbar but admin_menu_toolbar, and I apparently did not have the position:fixed option enabled and wasn't at the top of the page when doing that screenshot ;)

OK. No further questions, your honor. :-)

Briefly discussed this with @jacine and created a follow-up issue for #1591744: Clean up CSS and markup for status report

This change should land regardless of that, as it's a definite improvement over now.

Furthermore, the removal of the default severity REQUIREMENTS_INFO/_OK from hook_requirements() should be announced and documented as a change notice.

Looks great, +1 for RTBC

Committed/pushed to 8.x.

Leaving open for the change notice.

Created the change notice: http://drupal.org/node/1600936

This issue was a great improvement in the case where your status report actually contains a warning or error.

But what about the case where everything is OK? That was barely mentioned in the comments above, and none of the screenshots either.

It seems like it might be a regression to me so I thought I'd post some comparison screenshots for comment.

In Drupal 7, your eyes scan down the list and see everything is green, which is a quick visual indication that everything with your site is OK (actually would be better in this case if the checkboxes were on each row too, but those seem to have disappeared at some point in the D7 dev cycle):

In Drupal 8, everything is white, and there is no visual indication that your site is OK. If you're not familiar with how this page works, you'd basically have to read the entire page to know that things are going well with your site:

So, I'm wondering if we should consider improving the "everything is OK" case. Possibilities include:

1. A single visual indicator somewhere near the top of the page (i.e., a single green checkbox/message saying that everything is OK). Or,
2. Each row becomes green and has a green checkbox next to it (but only in the "everything is OK" case - as soon as one row is not OK, all the OK ones lose their green color and checkbox and go back to white so that the visual focus is entirely on the things that are broken).

Any thoughts?

I agree -- "All OK" is a critical message to convey, but the status screen leaves you to infer that for yourself. We give clear feedback when you do the wrong thing but then go silent when you get it right.

Looking at the D8 screen above it's impossible to tell if any of the settings ought to change. Is the file system *supposed* to be writable? Is the "Not enabled" status for Upload progress something that needs fixing?

With that in mind, I like the idea of #2 better. A single message at the top of the screen is easy to miss, especially on small screens, and would leave me less confident about particular line items such as "Not enabled" for Upload Progress being OK as-is.

I don't think that coloring everything in green is appropriate, because as you can see in the screenshots in #65, there are status report rows that are actually not fully OK (e.g., the second to last "Upload progress" row).

If really absolutely needed, then I'd rather opt for injecting a first additional row into the table that says:

"Overall status: (OK|Warnings|Errors)"

However, I don't think we need any kind of positive visual confirmation here in the first place. The committed patch explicitly kept the positive confirmation for the Requirements pages in the installer and update.php, because in both cases, we actually want to communicate all table rows as individual steps that have to be successful. The Status report page is not involved in a user task that checks whether requirements are met; it's a pure report, which you are free to ignore.

In case the concerns are based around the discovery of warnings and errors in a potentially larger report page, then IMHO the proper answer to that would be to sort the table rows before output, so errors come first, warnings second, and everything else after.

I think this looks damn good now. I don't think there would be many users panicking because they don't see any green. Users "panic" if they see red or yellow.

Yes we could add a new line that says "OK, warnings, errors". But what colour do you give that message when there are actually errors...

I am not sure either, you have to get used to the idea that - if nothing is indicated, all is good. However I think @David is correct in stating, that might not be obvious. I am on the fence about this one, lets see what more feedback brings us :)

My 2c.. I think that green clearly indicates all is good, red clearly indicates there is an issue, and no color doesn't really give anything away. The page looks nice white (I personally prefer the look), but it also looks ok when all items are green. But I do think using green for each item to indicate that everything is ok is actually more useful to users, and it also makes them feel good in the knowledge that their Drupal setup has all checklist items passing.

@mrfelton So, the reason we removed it - and you can get that from the information in the discussion above is that by making everything "green" you introduce this "rainbow of color" this is hard to explain, but essentially creates an effect where because you are using color so extensively to communicate meaning the real important messages like errors/warnings are very hard to scan for, and if they occur the page feels visually very heavy/overwhelming. So I am not inclined to agree, with going back to the original state - because its exactly that sense of overwhelming we want to remove from this page so people actually end up looking at it.

Yes, I sort of agree with that, when you have a mixture of errors and passes the green and red clash and look pretty horrible together (not sure if I agree that the really important messages like errors/warnings are very hard to scan though - it's still bloody obvious that red items have a problem, and green ones do not). What about making all the items show as green if everything passes, and if there are one or more errors leave everything white with just the errors being highlighted in red (I think thats what David_Rothstein was suggesting in #65.2). When there are no erros on the page, that needs to be communicated to people somehow.

if nothing is indicated, all is good

At the very least, the text at the top should say this.

What about making all the items show as green if everything passes, and if there are one or more errors leave everything white with just the errors being highlighted in red (I think thats what David_Rothstein was suggesting in #65.2).

Yup, exactly. The attached patch implements that, so we can see how it behaves and are all on the same page.

I don't think that coloring everything in green is appropriate, because as you can see in the screenshots in #65, there are status report rows that are actually not fully OK (e.g., the second to last "Upload progress" row).

I don't think it actually makes sense to have "informational" messages as a separate category from "OK" messages. Either something is OK or not, and if it's not OK, it should be a warning. (If we want to additionally have a visual indicator for "here is how to make your site even better" that could be a separate indicator, but it doesn't change the fact that it's OK as is and should be fine to color it green. "OK" just implies good enough; it does not imply 100% perfectly ideal :)

So in short, I'd like to see REQUIREMENT_INFO go away entirely, since it would simplify both the code and concepts here. But that would get into some other problems, so I'm not proposing it as part of this patch.

In the particular case of "Upload progress", I think the problem there is that it's worded almost like a warning but then isn't one? Probably the module needs to decide which it is, and change the wording accordingly.

Screenshots of the above patch. The only thing that is different from current core is the first screenshot (the "everything is OK" case). The others are unchanged from what's currently in Drupal 8.

1. Status report when everything is OK (the green rows and checkboxes help you quickly scan the page and understand your site is doing fine):

2. Status report when everything is not OK (the green colors and checkboxes disappear to help you focus on what's wrong):

3. Installation requirements page (the green colors are there to indicate your progress, but the green checkboxes are not, to avoid conflicting too much with the "error" icon in the row that does indicate a problem):

1) The OK icons in the first screenshot don't make any sense to me. I also don't understand why the entire page is in green, because I did not perform any action that would need confirmation.

2) The sudden disappearance of the formerly green rows confuses me. I guess something must be wrong with them, so I better check all of the text information to be sure, and after doing so, I still won't understand why they are no longer green.

3) In the 3rd screenshot (the install/update requirements pages), I expected the OK icons from the 1st screenshot, since this is an actual task/check list.

4) The patch removes support for info status entirely, which I strongly disagree with.

OK, it sounds like people would prefer the solution in #65.1. Any thoughts on what that should look like exactly? I'm having trouble picturing it.

It's almost like a standard Drupal status message (something green with words in it that gets displayed near the top of the page) but I'm not sure a message is really the right concept here.

I would imagine its a column on the top of the table "Overall status" or something silly like that.

...if nothing is indicated, all is good

Nope, ...if nothing is indicated, you need to assume that all is good. If we needed the ok/green out of the way, then we'd better hide the ok entries completely out of view. But this then would convert this from a "status" page to a "problems" page, which is what I see one side of people suggesting here.

I've been monitoring this issue here almost since the day it got filed and I'd like to say that I really like how currently (in D7) everything is green when everything is ok. I never heard anyone complain about too much green "overwhelming" them in check lists and this is a check list (a check list in order to have your Drupal site running as smoothly as possible). On the contrary, I think that green gives people the sense of accomplishment and that it communicates that everything is running smoothly. This is a status page and we need to see everything that might matter and their respective status clearly indicated. This to me (generally as an IT admin - not only within the Drupal context) translates to red for problems, yellow/orange for warnings, gray/blue for info and green for ok.

To this end, I see the following entries as info:

- Drupal version
- DB system/version
- GD library version
- PHP version
- Web server version

Now (with the exception of GD lib) I cannot imagine a situation where any of these would be shown as either red or yellow. If that were the case, than something would be seriously wrong with the server and the site wouldn't work. So, I wouldn't be able to see the status page in the first place. I'd consider these entries purely info, have them shown at the top of the status page and group them in a neutral color (gray/blue). I believe that this would reduce the chances of having lots of various colors shown "randomly", "all over the place" and thus would prevent most of the confusion or the overwhelming feeling some complain about. So, I need to ask: is there any serious usability case that dictated that all the entries in the status page are listed alphabetically instead of being grouped together in "logic" groups?

BTW, if it were up to me, I'd even go as far as merging the "Drupal" version entry with the "Drupal core update status" one. Perhaps only then having this row in green/yellow/red would make sense.

BTW, if it were up to me, I'd even go as far as merging the "Drupal" version entry with the "Drupal core update status" one. Perhaps only then having this row in green/yellow/red would make sense.

Slightly off-topic, but yes; see #309040-10: Add hook_requirements_alter() (I think it would require that issue).

Let's do #67 / #79 then; i.e., simply a first table row that says:

"Overall status: (OK|Warnings|Errors)"

and which is colored accordingly (green|yellow|red).

REQUIREMENTS_INFO severities/rows should be ignored for the overall status condition/calculation; i.e., if there are no warnings and no errors, then the overall status is OK/green.

Furthermore, the additional row should only be generated and output on the Status report page. Not in the requirements check of the installer or update.php.

[Speaking of, this is one of the tables we want to convert to the new render element #type 'table', and doing so might be the only way to inject the Overall status row on the Status report page only [not verified].)

This issue reminded me of the output received when running tests. (x failed, y warnings, z pass) kind of thing.

My instant reaction when greeted with an all white/light grey status report is that I am unsure about whether everything is alright. To some extent the ticks down the left hand side or the "status ok" message at the top already suggested, or a message similar to a simpletest report would make things more instantly that everything is ok at a glance.

Or to put it in other words - the page needs more green.

The other thing I've noticed with the lack of green filling up the table, is the lack of contrast available for the red and yellow messages. If the green background is gone (which I fully agree with) then as #14 states, the remaining colours should be a lot stronger to stand out more.

I've mocked up a couple of really rough examples.

The first uses the same border drupal_set_message gives to error and warning messages.

The second uses the border colour for the background colour.

The colours can of course be changed so think not of how terrible/clashing they are, but rather of how much more they stand out. The status report now says "YOU HAVE AN ERROR" rather than "you may have an error but it's not going to jump out at you"

My disclaimer that I'm not a designer likely does not need mentioning.

@typhonius: IMHO the actual bug there is that Bartik uses a (dark) grey background color for all tables, which inherently deemphasizes the contrast/visibility of colored rows. I don't know why Bartik is doing that. Perhaps it's just because Drupal core contained default styles for all tables since ~2004 or so. I removed those default styles in #1813792: Remove ugly default CSS styles for table only very recently. If you'd ask me, then we should remove that background color for tables in Bartik, too. That's a separate issue though.

@sun: I agree the background in the bartik table does dilute the colour. Removing from bartik wouldn't be a bad idea at all.

Checking white background for the right side of the table:

I can't decide if the colours are still washed out or vivid enough to be seen; I think I've been staring at it too long.

Late to the game, but the Status report page just created an itch for me. Glad to see the progress being made on beautification. However I have two questions:

1. Does it really have to be in alphabetic order?
2. Can't we add a button at the top "Hide all OK items"?

To answer my own questions.

1, Yes, it would be an UX improvement if we instead of alphabetic order of all items can create logical groups of items. For example:

• Drupal Status - Core, etc
• Maintenance/security - Database schema updated, Cron status, Module/Theme status, When Backup last was run (Backup and Migrate), etc
• Third Party integration - Google Analytics, XML-sitemap, etc
• Third party libraries - The stuff in /sites/all/libraries
• Cahce info and status
• Web server features - PHP info, file system, GD library, Upload progress
• System server components - the stuff Drupal runs on (OS, database, file system, etc)

These groups needs to be static, that is - modules can't invent new groups like is done using the "package" keyword for modules.

Also, when possible there need to be info/link to the feature/module that the report item belongs to for added readability.

It should also become good practice that modules that for example adds third party integration add a report item here. Disqus is one such integration that currently does not report here. Then Media YouTube/Flicker/Vimeo etc are other good candidates to.

The items in the groups can be alphabetically listed, that OK.

2, a big switch at the top that simply hides all "green" items except the Drupal core group at the top.

Could also be complemented with a drop-down jump-list with the group names. Useful as the list will get longer on many sites as more projects does the right thing and adds a reporter here.

I think these improvements, together with those already discussed in this thread will make this page both easier to read and more useful at the same time.

Oh, and a third question:

3, How come there is no option for alerting admin about when something covered on the status report needs attention?

Currently only the version check on Drupal core and modules/themes does that here.

But that is probably better to discuss in a new issue?!

This is really a great issue because the design of the Status Report was always a "needs work", in my mind. With that said, I don't think we need to reinvent the wheel here but I do think we are going against practiced axioms of computer science by removing any indication that things are "Ok" . Green is the universal indicator on all levels that something is "Good" - Your light on your very first PC Tower, your Macbook power adapter, most other electronic devices in the world. Let me clarify that:

• I do agree that an all green status report indicating each message is of the same type doesn't make a lot of sense.
• Not so sure I agree that no indicator of "No problems found" is a good thing.

On the command line, and I'm borrowing from Symfony2 only because it's handy - if I run a check on my install I get something like this:

 OK       PHP version must be at least 5.3.3 (5.3.14 installed)
 OK       PHP version must not be 5.3.16 as Symfony won't work properly with it
 OK       Vendor libraries must be installed
 OK       app/cache/ directory must be writable
 OK       app/logs/ directory must be writable

Even when downloading packages via your favorite package managers, you get some indication of all clear via [OK] when, for example, compiling.

Now on the web UI side... again Symfony2 only because it's handy... does something like this:

GoDaddy (and other DNS providers) also provide some kind of green all clear:

I guess we should start gravitating toward some of these accepted practices and not away; Also, I'm not sure why we hate the color green. ;)

I don't think having a ton of green checks is useful but I do think a "No problems found" on the Status report at the very top would make a user a very happy camper. Don't make me think about what is in each row if I don't care. Just tell me it's fine and let me get back to my content.

The very words, "Status Report" means you're looking for a "status" -You want to know if your status is green, red, or yellow like you're used to hearing in your job every day. (Boss: "Jones! What is the status report on that project?!" Jones: "Green, boss!")

What sun proposes in #82 makes the most sense to me. Maybe not even a row. Maybe nice little flag from behind the table that is colored appropriately and reads the adjective we want to give it.

drupal_set_message could be used here to give an overall status of the system. If there are ANY errors the status is error. If there are no errors but there are warnings then the status should be warning. If there are no errors or warnings then the status can be status/green!

Perhaps the entire status table should be hidden if it's all green with an option for the user to expand and view should they require.

I initially didn't like what tsvenson said in #86 about only showing non-green items by default but the thought has grown on me. There will be absolutely no mistaking what is causing the issue then.

Me and my flags. +1 to drupal_set_message() :)

A dsm() doesn't work for me, since the process that generates the status report page could trigger status/error messages on its own, which in turn could easily lead to conflicting error messages in the messages area; i.e., one saying error/warning, and another saying "All is OK my friend." (which would be a lie in that case ;))

Good point, sun. So perhaps my flag behind the table would be a workable solution after all. I was thinking something like a little square div on the right hand top of the table. Something that would say either [OK - Checkmark] or [Warnings: 5 Found] or [Errors: 2 Found] depending on the state. This way, we only draw the user to what they need to see.

I should have some time today to roll a patch for my crazy idea.

the process that generates the status report page could trigger status/error messages on its own

Couldn't the status report include that sort of message as part of the report, in a non-confusing way? ("Additionally, there was 1 error while generating the status report: [...]"). If I am interested in the status of the site, then I am also interested in the fact that the status report generation process produces errors -- so this sort of message really ought to be a formal part of the report if possible.

Perhaps indeed the very first line of the status report is a 'system summary' which is coloured green/yellow/red depending on whether there are errors/warnings etc.

This could remain always visible with errors/warnings also visible underneath. Should the user wish to see the full report they may click something to unhide the remaining status rows.

We should align this design with the visual consistencies introduced in the new style guide: #1986434: New visual style for Seven

Now its use the new style guide.

Failed due to unrelated segmentation fault, which is being tracked down in #2226351: Segmentation fault in Drupal\image\Tests\ImageStylesPathAndUrlTest

96: 665790-statusreport-styleguide-96.patch queued for re-testing.

+++ b/core/modules/system/css/system.module.css
@@ -308,7 +308,16 @@ tr .ajax-progress-throbber .throbber {
+/**
+ * Hide elements visually, but keep them available for screen-readers.
+ * ¶
+ * This class load background, and other formats, just the text is hidden
+ * visually.
+ */
+.visually-hidden-text {
+  overflow: hidden;
+  text-indent: -999em;
+}

There is some whitespace here and I'm a bit apprehensive about adding a new class, can we move it below the .invisible class and rename it to hide-text? Just so it's not easily confused with visually-hidden.

Change class to hide-text as recommended.

1. +++ b/core/modules/system/css/system.admin.css
   @@ -188,19 +188,13 @@ a.module-link-configure {
    table.system-status-report td {
   -  padding: 6px;
   -  vertical-align: top;
    }
    table.system-status-report td:nth-child(-n+2) {
   -  background-color: rgba(0, 0, 0, 0.04);
    }
   ...
    [dir="rtl"] table.system-status-report td.status-icon {
   -  padding-left: 0;
   -  padding-right: 6px;
    }
   
   +++ b/core/themes/seven/style.css
   @@ -694,17 +691,17 @@ table.system-status-report tr:last-child {
   -table.system-status-report tr.ok {
   +table.system-status-report tr.ok:not(:hover) {
      color: #255b1e;
   -  background-color: #e5ffe2;
   +  background-color: transparent;
    }
   -table.system-status-report tr.warning {
   +table.system-status-report tr.warning:not(:hover) {
      color: #840;
   -  background-color: #fffce5;
   +  background-color: transparent;
    }
   

   We now have some empty selectors, we can just delete them now.

2. +++ b/core/modules/system/css/system.admin.css
   @@ -188,19 +188,13 @@ a.module-link-configure {
    table.system-status-report td {
   -  padding: 6px;
   -  vertical-align: top;
    }
    table.system-status-report td:nth-child(-n+2) {
   -  background-color: rgba(0, 0, 0, 0.04);
    }
   ...
    [dir="rtl"] table.system-status-report td.status-icon {
   -  padding-left: 0;
   -  padding-right: 6px;
    }
   

   We not have some empty selectors, we can delete these as well.

3. +++ b/core/themes/seven/style.css
   @@ -694,17 +691,17 @@ table.system-status-report tr:last-child {
   -table.system-status-report tr.ok {
   +table.system-status-report tr.ok:not(:hover) {
      color: #255b1e;
   -  background-color: #e5ffe2;
   +  background-color: transparent;
    }
   -table.system-status-report tr.warning {
   +table.system-status-report tr.warning:not(:hover) {
      color: #840;
   -  background-color: #fffce5;
   +  background-color: transparent;
    }
   

   Do we need to set the background to transparent? Aren't they always transparent when there is no hover?
   I think we can get rid of the text colour as well. Which means can just delete all of this CSS?

@tompagabor et al: Can you move that Seven-specific restyling patch into a new issue, please? This issue has actually seen a commit (a very long time ago) already and was only re-opened, because some concerns were raised later on.

We should actually move that follow-up discussion on exposing an overall status indicator into a new issue, too.

@sun Sure #2227401: Apply the seven style guide to the status report

Is this really still active then?

Well yhea.

Ok, then it needs a re-roll + improvements as per #101.

Done.

For the next few hours
http://s53f2f84b1518779.s3.simplytest.me/admin/reports/status

Before:

After:

Can this pattern be documented?

#2227401: Apply the seven style guide to the status report Fixing everything in this issue. I thought the other one just did Seven, but I see it did more.

Sorry Bojhan, thought this had already gone through you.

Yeah that's why I asked ;) Ah well.

Fixing title and status. The recent patches here were for something else, but there was a commit here in #61 and then the issue was reopened again in #65 to reconsider that design.

In the "your site is all OK" case, Drupal 8 is definitely still missing a clear indication to the site administrator of that fact, compared to Drupal 7.

This could be moved to a separate issue, but there is a lot of good discussion about that followup above so it's probably better to just leave it here.

There seems to be a fair amount of consensus here for a solution similar to #82 - a row at the top of the table, or some other visual indicator at the top of the page, which provides the administrator with a clear visual indication of the overall site status (OK/Warnings/Errors).

This will go into 8.1.x at the earliest.

Updated the issue summary. While this is cleaner - its not really appealing. I've added some examples of interesting status report pages.

@Bojhan it doesn't look like the examples made it in the issue summary update.

We are looking to redesign, here is some inspiration.

Those are so nice! Thanks @Bojhan & @yoroy would be great to see those in place in some form!

I prepared some fast proposals to decide what information we need/want before jumping to the visual design.

1. Quick summary with a counter for errors, warning and things that are already ok. It can be also helpful a link to the detailed list of errors/warnings/already done things (2b). In the case that there are no errors, but we still have some warnings, I would maintain the 3 counters. In the case that everything is fine, my proposal is to hide the counter component and show only a message saying that everything is ok. Do you agree with hiding the counter? And, do you agree on maintaining the 3 counters even 1 ore them is 0?

2. Summary with general system information like Drupal version, Database version, etc. Only information that is just informative. A good way to decide what information we need here could be: add only the minimum information we need to paste into an issue to explain what is our development environment. What kind of information do you think it would be interesting to have here?

3. I would suggest also a separated list for errors, warnings and things that are already ok. On small devices, we could show only the name, and open/hide it with a toggle because there are some items that have a lot of text. Do you agree on that?

These look fantastic, thanks @ckrina!

Do you agree with hiding the counter? And, do you agree on maintaining the 3 counters even 1 ore them is 0?

Personally, yes, I agree with hiding the counter if all are 0, and I agree on showing all three if just one or two is 0.

What kind of information do you think it would be interesting to have here? [summary]

I took a look at the current 8.2.x status page. Here are the items I think we should at a minimum include in this summary:

• Drupal version
• Web server type and version (one line, as it is now)
• Database type and version (could be on one line or two, as it is in your mockup)
• PHP version and memory (could be on one line or two) with link to more info
• Last cron status and link to run cron

I think the PHP extensions and PHP OPcode caching, which are either enabled or disabled, could be moved to your third section of notifications, unless it seems confusing to divorce it from the line about PHP in the summary, in which case that could live in the more info link.

I would suggest also a separated list for errors, warnings and things that are already ok. On small devices, we could show only the name, and open/hide it with a toggle because there are some items that have a lot of text. Do you agree on that?

I definitely agree on only showing the name, with an open/close toggle on small devices.

I basically agree on separate lists for errors, warnings, and a third list. But the third list is a bit more complicated than "things that are already OK." The third list really includes both:

• things that are OK (if they weren't OK, they would show up as errors)
• informational items — things like the image toolkit, the unicode library, and the search index progress; these have no "error state" to them

Contrib modules also add lots of informational items too. So I'm not sure if it makes sense to actually have four lists (I think probably not) or just be aware that we're actually jumbling two different types of things together (as we do already, of course).

But overall, I really really like this!

@yoroy Here's a few examples of contrib modules in 8.2.x:

• Google Analytics: Displays warning before it's been set up; informational notice once it is.
• Token: Out of the box, the most recent D8 version displays the following informational notice: "Token types are not defined but have tokens: $info['types']['entity']"
• Search API: Out of the box and just after installing, it displays the following warning: "The default Drupal Search module is still enabled. If you are using Search API, you probably want to uninstall the Search module for performance reasons."
• CAPTCHA: If logging CAPTCHA blockings, displays the following informational notice: "Already blocked [NUM] form submissions"

So there's a few examples from roughly the top 30 modules for D8. I can collect more if that would be helpful.

Here are some first visual proposals for the status page.
For now, the difference between them is on the "General system information". The idea is to find out if adding icons looks like a good improvement.

I think the icons are great! And if we didn't use icons, I'd prefer the two-section layout for general system info (option 2) rather than one-section (option 1) or a separate section for each item (option 3). I think the two-section layout has the right balance for scanning.

But really, I think the icons would be helpful and also make a sometimes-scary page more friendly.

The other parts all seem good, but I again just want to highlight the third section, marked "Correct" — this would be both things that are "correct" and things that are just informational. I wonder if we could come up with another label for that section.

Thank you for the feedback @rootwork! I also prefer the icons version mainly for the same reason: it makes the information more “digestible”.
I also changed the “correct” label for “checked”. Anyway, it’s completely open to suggestions.

I’ve also updated 2 proposals for the quick summary with some visual changes. One of them tries to add a visual style closer to the current Seven style guide.

The other one is to discuss the idea of having some graphics to enrich the information and make it more friendly. Going for it, I would say that we are using a “graphic” as icon in the “status” menu item in the toolbar. The problem with that is we are complicating the development.

Which one do you prefer? Graphics or not?

I've also updated a version of the status page without errors.

Looking great!

nit: The cron section should also have the link to run cron, in my opinion (i.e. don't bury that link in the more info)

I'm of two minds on the circular graphics. On the one hand, I can see how some people would interpret that as looking more "friendly." On the other, to me it just seems like superfluous noise -- the sizes of the items within the circle are only dependent on the count of notices on the status page, which doesn't really represent anything. In other words, a 100% "full" circle doesn't mean a whole lot, and a 10% "full" circle when there are 25 notices means something different than a 10% "full" circle when there are only 10 notices. And, of course, not all errors are equal in severity.

The graphics also push down the page a bit more. Aside: What does this page look like in mobile? Stacked up? If so then these graphics would really push things down.

So I guess I can be convinced, but they don't jump out at me as necessary.

On the everything's-fine status page, can we use the same graphic and checkmark as the others -- whether that ends up being the first boxed version or the percentage-circle version -- rather than the standard Drupal success message? At least in my opinion that would be better -- a big checkmark saying everything is good :)

We've discussed this at the UX team hour, and reached consensus that this is a good direction. Visually splitting information; separating basic information, highlighting the different statuses and counts, and ability to go to them.

For this to reach completion and ready for patching, we think that we need to explore a few more ideas:
- Find what could fit in the 6th box :)
- Explore placing the basic information at the top, and the "warning", "error", "checked" below this.
- Explore using one table, instead of a separated table.
- How do we deal with error states on the Drupal version, last cron run, etc.
- Design the mobile version of this page.

Here is a version using one table instead dividing by king of message (error, warning, others). To show the differences between them I’ve used the same background color that is used today for errors and warnings.
I’ve also uploaded a version without title in the table, and also without title in the Basic info section.

Here is a version of the status page without error or warnings as @rootwork suggested (thanks for the feedback!), changing the regular message with another one styled like the ones in the group error, warning + checked recap region.

Here, I’ve also added a “run cron” primary button to fit the 6th box. I would prefer to use another information instead of using a button because it’s not the same kind of information.

I’ve uploaded this other version with several explorations:
- One of the items in the Basic info section in red when there is an error related to it. I added the red background and changed the icon. It clearly shows that there is an error, but if we don’t add it there it might be confusing. And adding all the information there would break completely the design. Maybe we could convert it to a link to the error?

Here are also 2 proposals for the mobile version. The difference between them are:
- In one of them the icons in the Basic info section are hidden. It can help placing more information in less space.
- The table not speared in Errors/warnings, checked messages. I think it's better this way in mobile.
- The table does not have the title. I helps saving space also.

@prabhu9484 told me about this issue. The design is cool @ckrina, we need to change the html structure of status report page according to this design. Is this fine ? Request @Gábor Hojtsy @Yoroy, @Bojhan to confirm.

@yoroy we have requirements array in which i have got length of array 25. So we need to print that array value one by one because the order of that value are not according to design. i need your confirmation to do this?
If You want to suggest any thing else then i will try that too.

So i have submitted a patch for status report as per the status-page-665790-142-04.png. I could find all field except "checked". What does this field signify? @prabhu9484 will join the call today to clarify the patch.

yes - we created the HTML structure - wanted to confirm if it is ok before proceeding with the styling
we could not understand "checked" field - we could not find it in the array

Copied from slack for reference:

@prabhu.s: so the status report has rows currently and they may be warnings, errors, etc.
@prabhu.s: the things that are not issues (not warnings, errors, etc) SOME of them are “ok” but some of them are just informational
@prabhu.s: eg. PHP 5.6.2 is information that the system checked not necessarily ok or not :slightly_smiling_face:
@prabhu.s: it is just a check that was done and did not produce errors

We discussed this issue/patch in UX meeting today. Here's what I remember (all comments in relation to #142):

- Because it's the more frequently changing information, start with the error/warning/status summary, followed by the Drupal/database/PHP stuff.
- For mobile view, the version on the right with headings seem better, since there's something to link to from above.
- However, the "Details" links to jump down should actually be links; else they look like text descriptions just like those in the table below.
- We also discussed whether there was a need to colour the details row backgrounds and/or the headings, and decided there was not.
- The mock to change Drupal icon to a red, flaming error is actually great, but probably needs more discussion since this involves logic and we might want to have a head-to-head about what constitutes a "warning" vs. "error" for cron, for example.

On the patch itself (#146), I didn't initially understand why the change was being made from tables to divs/spans; but it was explained that this is because we want the responsive tables in mobile. I'm not actually familiar enough with the markup standards there to confirm this one way or another, so tagging for markup review.

There is a lot of copy/paste code in here, which was stated that the reason we need that is because the elements are being done out of order. 19, then 24, then 3, etc. Those numeric indexes also greatly reduce the readability of the code. I would suggest instead building the array you actually want in system_status_preprocess(), like $system['drupal'], $system['db'], etc. and then using foreach() loops to cut down on the boilerplate. This also helps prevent a scenario where 19 is database on one site but 19 is PHP on another because of different modules being installed.

+++ b/core/themes/stable/templates/admin/status-report.html.twig
@@ -15,25 +15,57 @@
+      {% if key == 0 or key == 3 or key == 5 or key == 14 or key == 24 %}
...
+      {% if key != 0 and key != 3 and key != 5 and key != 14 and key != 24 %}

How do you tell that these keys mean something special? Did you try adding a few contributed modules and seeing if indexes 14 and 24 still display what you think they do?

Thanks Gabor - as discussed inthe UX call yesterday, can you post an example code snippet we can refer to ?

So if you look at where this template is used, in SystemInfoController:

  public function status() {
    $requirements = $this->systemManager->listRequirements();
    return array('#theme' => 'status_report', '#requirements' => $requirements);
  }

which points to SystemManager:

  public function listRequirements() {
    // Load .install files
    include_once DRUPAL_ROOT . '/core/includes/install.inc';
    drupal_load_updates();

    // Check run-time requirements and status information.
    $requirements = $this->moduleHandler->invokeAll('requirements', array('runtime'));
    usort($requirements, function($a, $b) {
      if (!isset($a['weight'])) {
        if (!isset($b['weight'])) {
          return strcasecmp($a['title'], $b['title']);
        }
        return -$b['weight'];
      }
      return isset($b['weight']) ? $a['weight'] - $b['weight'] : $a['weight'];
    });

    return $requirements;
  }

So what this does is it lists the requirements results by weight. Which means their numbers can be anything. But the data is collected from hook_requirements() (if you look at ModuleHandler's invokeAll()). That is defined as:

/**
 * Check installation requirements and do status reporting.
 *
 * This hook has three closely related uses, determined by the $phase argument:
 * - Checking installation requirements ($phase == 'install').
 * - Checking update requirements ($phase == 'update').
 * - Status reporting ($phase == 'runtime').
 *
 * Note that this hook, like all others dealing with installation and updates,
 * must reside in a module_name.install file, or it will not properly abort
 * the installation of the module if a critical requirement is missing.
 *
 * During the 'install' phase, modules can for example assert that
 * library or server versions are available or sufficient.
 * Note that the installation of a module can happen during installation of
 * Drupal itself (by install.php) with an installation profile or later by hand.
 * As a consequence, install-time requirements must be checked without access
 * to the full Drupal API, because it is not available during install.php.
 * If a requirement has a severity of REQUIREMENT_ERROR, install.php will abort
 * or at least the module will not install.
 * Other severity levels have no effect on the installation.
 * Module dependencies do not belong to these installation requirements,
 * but should be defined in the module's .info.yml file.
 *
 * During installation (when $phase == 'install'), if you need to load a class
 * from your module, you'll need to include the class file directly.
 *
 * The 'runtime' phase is not limited to pure installation requirements
 * but can also be used for more general status information like maintenance
 * tasks and security issues.
 * The returned 'requirements' will be listed on the status report in the
 * administration section, with indication of the severity level.
 * Moreover, any requirement with a severity of REQUIREMENT_ERROR severity will
 * result in a notice on the administration configuration page.
 *
 * @param $phase
 *   The phase in which requirements are checked:
 *   - install: The module is being installed.
 *   - update: The module is enabled and update.php is run.
 *   - runtime: The runtime requirements are being checked and shown on the
 *     status report page.
 *
 * @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.
 *   - 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) { ... }

So there is no key to identify the important parts. You cannot tell if an item needs to be pulled into that table based on its description, value or title. I would introduce a new key here for those elements. Something like "highlight priority" => 4 where 4 is the number of the slot from the special table (assuming we numbered the slots sequentially). Or "highlight" => "database" where we name each slot based on what we want to display there and the names would correspond to the cell names. Maybe the second one is nicer.

Then the values from the SystemInfoController status() method are converted further for display in the theme preprocess hook in system.admin.inc's template_preprocess_status_report(). That function would turn the elements with "highlight" keys to its own array or individual elements with those names, eg. "database" to display in the right table cells.

That way the source tells us which target highlight the information goes to in the standard data format extended with a new key while the preprocess function places it in convenient variables for the theme to display.

I would approach it that way. Does that make sense?

Thanks @Gábor Hojtsy sound like a good plan, I have some time to look into this will let you know.

Here are the designs after the decisions made on june 28 UX meeting:

Error re-count at top.

• 3 items with error/warning/checked if there are errors. Link to each item list.
• Re-count of items checked if no errors. Link to item list. Should we add a clearer message saying “No errors found”?

General system information table with 6 pieces:

• Drupal version
• Last cron run
• Button to run cron
• Web server info
• PHP info
• Database info

List of all checked items ordered by errors/warnings/checked.

• Separated each of them by a title, that could also act as #anchor for the “Details” link on the re-count top region.
• On mobile I would collapse the description to fit the table on narrower devices.
• Collapsible groups. I proposed the collapsible behavior, collapsed by default on mobile (to have a shorter and less overwhelming page) and opened in desktop. But having everything more “ordered” means hidden in this case, so maybe more difficult to find. I remember we talked about that on the meeting but I don't remember we decided anything. What do you think about making the groups collapsible?
  • Pros:
    • Shorter and digestible page.
    • User can hide the info he doesn’t need.
    • Useful in small displays.
  • Cons:
    • Hidden info
    • Collapsed element with another collapsed item inside (item description).

No collapsible:

No errors

With errors

Mobile

Collapsible:

With errors

Mobile

I attach also the svg for the General system information table. Sumit kumar: do you still need the Illustrator files?