Installer is not very usable in Claro

The installer is missing a steps component that could reused outside of the installer. Work is underway here: https://www.figma.com/file/NpZUAp8BEkMJvm5gKBCDBB/Claro?node-id=16505%3A... .

Init patch, but mostly done i guess..
Some colours on figma are different than we have in color css-variables.

Preview after patch.

Fixing test cases!

Claro uses .form-item__description instead of .description for description_classes in form-element.html.twig

Not sure if it's the correct way but removing it from core/tests/Drupal/FunctionalJavascriptTests/Core/Installer/Form/SelectProfileFormTest.php fixes the failed test in #13

Applied patch #16 .The new look seems nice and futuristic.Including screesnhot

RTBC

#16 works fine
RTBC + 1

Would #2030027: Use the Drupal software logo in the installer be in scope of this design or should that be done entirely independent of the theme?

@Gábor Hojtsy yes, I'd say this should be a requirement for this issue. Since the redesign is still in progress, I'll move this back to Needs work.

1. Patch in #16 sadly no longer applies to 9.2.11, 9.3.x, or 9.4.x

  - Installing drupal/core (9.4.x-dev 68b67f8): Extracting archive
  - Applying patches for drupal/core
    https://www.drupal.org/files/issues/2020-09-10/3085219-16.patch (3085219 - claro installer)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2020-09-10/3085219-16.patch

I've added tag Needs reroll for this.

2. Drupal 9 sites with Seven theme disabled do not use Claro theme on /update.php

Drupal confusingly tries to use the frontend theme instead of the admin theme on /update.php when the hardcoded 'seven' theme is disabled. This could be filed as a follow-up bug, to fall back to the current admin theme when the hardcoded default theme is not installed.

The workaround is to implement maintenance-page template in your frontend theme OR... to explicitly add $settings['maintenance_theme'] = 'claro'; in settings.php

The patches on this issues should update the fallback theme in _drupal_maintenance_theme() to use Claro. This is a must-have for making Claro the default admin theme (from #3167121: Make Claro the default admin theme).

3. Even f you force Claro theme via settings workaround, you see a broken layout on /update.php

This problem is present both with and without the patch on this issue. This could be considered a stable blocker, based on just how broken Claro currently looks on this page.

4. The proposed designs in the Figma file (linked in #21) have not yet been picked up yet to include the Drupal logo, as requested in #20, so this still needs more work.

However, if core admin theme contributors agree with point #3 above, perhaps this issue could re-focus around a 2-phased commit approach, whereby we un-break the design, using the current best design as work in progress, get that committed, and then work on the continued design effort with the Drupal logo. Thoughts?

Re-uploading broken image which expired from my previous comment.

Here is a re-roll of #16 (solving #24.1)

• It also solves #24.2 by setting the fallback theme to Claro in _drupal_maintenance_theme().
• It also solves #24.3 by adding a float to the main container.
  

    .layout-sidebar-first ~ main {
      float: left;
      margin-left: 4rem;
    }
    [dir="rtl"] .layout-sidebar-first ~ main {
      float: right;
      margin-right: 4rem;
      margin-left: 0;
    }
  

• It also reworks some of the style changes (so there is not a 1-to-1 mapping with the patch in #16 due to several underlying stylesheet changes that make several things no longer required, for example, this hunk is no longer needed:
  

  /*
   * Override of .layout-container, which is conflicts with
   * layout/system-admin--layout.pcss.css
   */
  @media all and (min-width: 48em) {
    body.install-page .layout-container {
      margin-right: auto;
      margin-left: auto;
    }
  }
  

• It also replaces hex colors with color variables in maintenance-page.pcss.css .
• It also introduces some consistency to the font sizes and font weights as depicted in the main Figma design from where the initial patch started.
• It also introduces some improvements to the "Pending updates" lists on /update.php/selection page.
  

  /**
   * Pending updates list customization for update page.
   */
  .item-list h3 {
    font-size: var(--font-size-h5);
  }
  .item-list > ul {
    margin-left: 0;
  }
  

• It was tested locally on a clean Drupal 9.4.x-dev installation, both the /install.php as well as the /update.php pages (screenshots to follow).

Screenshots after:

+++ b/core/themes/claro/css/base/variables.css
@@ -11,12 +11,13 @@
+  color: #E5E5E5;

+++ b/core/themes/claro/css/base/variables.pcss.css
@@ -28,6 +28,7 @@
+  color: #E5E5E5;

+++ b/core/themes/claro/css/theme/install-page.css
@@ -11,37 +12,52 @@
+
+:root {
+  color: #E5E5E5;
+}
+

+++ b/core/themes/claro/css/theme/maintenance-page.css
@@ -10,16 +10,26 @@
+:root {
+  color: #E5E5E5;
+}
+

Whoops this snuck in by accident. Fixed.

Ugh. My apologies... I forgot to remove the unnecessary hunk mentioned in bullet point 3 on #26...

Fixes Drupal check error:

83:5  ✖  Expected "counter-increment" to come before "border-radius"   order/properties-order

I've applied patch #30 to a fresh install. One detail I've noticed is on the very first screen of a fresh install when the browser is auto-detecting a system language != english

At first i thought it might be an exclusive issue with Safari 13.1.2 which auto detected german as my default system language. Because the latest Firefox was showing the first screen correctly. But in Firefox the auto detection of the default language is broken and it defaults to english. When i manually switch to any language other than english I get the same result like in the screenshot.

And one thought which might be probably out of the scope of this issue. but if the installer detects a none english system language and switches the selection to it you still have the title (Choose language) and the description underneath the select box, as well as the button and the sidebar elements in english. For none native speakers that step might be already demanding and i am uncertain that everyone might understand everything there properly. Something that was brought up in the following issue as well: https://www.drupal.org/project/drupal/issues/3050502. But would it make sense to reduce the number of strings for the first installer page and just display the title, the select box, the explanatory description and the save and continue button and provide a translation for each language available in the list? so the user getting a screen completely translated into the his/her/them language (before the according po files for the selected language are getting downloaded)

Two more details I've noticed (went on testing to finish the install with Safari 13.1.2)

1) In step 4 the width of the progress bar is exactly the width of the the text string above. that way the progress-bar is quite jumpy and turbulent.

2) In step 6 configure site the same happened like in step 1 (i've selected english for the install proces)

3) And one last detail. I've checked /update.php. In contrast to #24.3 the layout isn't broken but somehow a mix of Claro and Seven design elements it looks like
.

Revisiting the logo question asked by @jwilson3 on slack. I don't think the logo need to be in this redesign, it should be in its own issue. Whather the logo is shown is dependent on whether we consider the updated thing "Drupal", which depending on the distribution being run may or may not be the case. Let's not include that in the scope here, its not currently shown on the update page either.

Re the update.php being already broken problem, how common is Claro forced from settings.php? Who would face that update.php? If anyone using Claro would face that then it would be an important bug (major at least) on its own, not here. Otherwise I think if the redesign is going in good shape, we can tackle both at once here.

how common is Claro forced from settings.php?

Good question! Is there any real way to know this with stats gathered by Drupal.org? Eg comparing: Drupal 9 installs vs Drupal 9 installs with Seven theme enabled vs Drupal 9 installs with Claro theme enabled?

Who would face that update.php

The problem can really be summarised in terms of likelyhood that folks are using Claro or Gin (Gin has 11,000+ installs). I would expect some percentage of those using Gin/Claro to want to disable Seven theme as it wouldnt be used for literally anything at that point, but if they DO and they use /update.php — the page is broken, necessitating the forced maintenance theme from settings.php. And unless you've taken the time to find this issue or figure out that that workaround fixes the issue, many folks might just re-enable seven theme ¯\_(ツ)_/¯ . This is all just conjecture though.

I can't speak for anyone else, but I found this bug by checking a production environment quickly via the web to see if there are any pending updates on a site using the Gin admin theme with Seven disabled.

Re #31 and #32:

Thank you for the manual review. Clearly the float with max-width on the main column is not enough, and the 2-column layout needs another look. Maybe flexbox or css grid... or have a look at how Seven theme does it. If I have time at the end of this week, I'll have another go, but if someone else wants to pick this up, go for it!

uh forgot to upload the last image in #32. and another detail i forgot to mention on the update.php page the verify requirements string has a too low color contrast with 2,24.

I've wanted to check and test something in the redesigned installer. I've tried to apply the patch provided in #30 to a fresh install with the latest Drupal 9.4.x-dev version. But the patch doesn't apply anymore (in my previous tests a few weeks ago it was applying without any complaint). Probably needs a reroll.

I've opened a merge request as git was able to merge the last patch automatically.

Still Buggy

• The width of the installer progress bar reported above is still narrow.
• Once a page has messages (such as errors on the database credentials page or the above warning), the entire main content area renders below the steps. I replicated this in Safari 15.
• The password strength indicator width is incorrect (which I think is a separate issue, so probably not a blocker here)
At narrow widths (portrait tablet-ish), the messages and text fields overflow their container. As well, description text is too close to the edge (see "Use an address")

Yes. Your first two points would be resolved by having another look at the 2-column layout approach (note this ticket is still in NW, since my last post outlining the problem with the layout approach I took):

the float with max-width on the main column is not enough, and the 2-column layout needs another look. Maybe flexbox or css grid... or have a look at how Seven theme does it.

My apologies for not being able to pick this back up recently. Super busy at the moment, so any frontender could feel free to have a try at fixing this.

#3279640: Standard install profile uses Olivero for update.php is making a very small set of changes to make update.php usable in Claro so that 9.4.0 can be released as that has made claro the default admin theme for Standard.

Discussed this with @lauriii and we agreed this has now become a critical issue as we want to be able to remove seven in Drupal 10 so we need the installer to use Claro by default and we need to use it in _drupal_maintenance_theme().

Discussed with @andy-blum and he doesn't want to discourage others from working on this

Hi @andy-blum. I tested your MR and it definitely fixed the layout issue! Thanks for knocking that out! It wasn't so easy for me to do a code review, because there wasn't an interdiff, so I decided to create a new MR on latest 9.4.x that contains separate commits for each patch on this issue starting from #10, through #30 and then cherry-picking in your commit from your MR on top so that I could get a clean interdiff (due to the reroll and code changes being in one single commit).

Interdiff between #30 and #47 (after the rebase):

1d7e50303ea1eca6285c1f136c297a5122c75148 3085219-47: Fix layout bugs
diff --git a/core/themes/claro/css/theme/install-page.css b/core/themes/claro/css/theme/install-page.css
index 3b2fd74790..41c8f07f75 100644
--- a/core/themes/claro/css/theme/install-page.css
+++ b/core/themes/claro/css/theme/install-page.css
@@ -18,6 +18,10 @@
   background-color: #dedfe4;
 }

+[dir="rtl"] .install-page {
+  background-position: right top, 50% 50%;
+}
+
 /**
  * Password widget
  */
diff --git a/core/themes/claro/css/theme/install-page.pcss.css b/core/themes/claro/css/theme/install-page.pcss.css
index e60248df55..11b19dfc56 100644
--- a/core/themes/claro/css/theme/install-page.pcss.css
+++ b/core/themes/claro/css/theme/install-page.pcss.css
@@ -12,6 +12,9 @@
   min-height: 100%;
   background-color: var(--color-gray-100);
 }
+[dir="rtl"] .install-page {
+  background-position: right top, 50% 50%;
+}

 /**
  * Password widget
diff --git a/core/themes/claro/css/theme/maintenance-page.css b/core/themes/claro/css/theme/maintenance-page.css
index cc01cead94..d8a1147334 100644
--- a/core/themes/claro/css/theme/maintenance-page.css
+++ b/core/themes/claro/css/theme/maintenance-page.css
@@ -197,6 +197,14 @@
   [dir="rtl"] .layout-sidebar-first {
     float: right;
   }
+
+  .layout-sidebar-first ~ main {
+    float: left;
+  }
+
+  [dir="rtl"] .layout-sidebar-first ~ main {
+    float: right;
+  }
   /* Positioning sidebar & content */
   main {
     float: left; /* LTR */
diff --git a/core/themes/claro/css/theme/maintenance-page.pcss.css b/core/themes/claro/css/theme/maintenance-page.pcss.css
index f5931f310b..0bad0eb214 100644
--- a/core/themes/claro/css/theme/maintenance-page.pcss.css
+++ b/core/themes/claro/css/theme/maintenance-page.pcss.css
@@ -189,6 +189,14 @@
   [dir="rtl"] .layout-sidebar-first {
     float: right;
   }
+
+  .layout-sidebar-first ~ main {
+    float: left;
+  }
+
+  [dir="rtl"] .layout-sidebar-first ~ main {
+    float: right;
+  }
   /* Positioning sidebar & content */
   main {
     float: left; /* LTR */

There are a couple code issues:

+[dir="rtl"] .install-page {
+  background-position: right top, 50% 50%;
+}
+

I'm not entirely sure why this is still here, since there is no background pattern or image.

@@ -175,6 +188,14 @@
   [dir="rtl"] .layout-sidebar-first {
     float: right;
   }
+
+  .layout-sidebar-first ~ main {
+    float: left;
+  }
+
+  [dir="rtl"] .layout-sidebar-first ~ main {
+    float: right;
+  }
   /* Positioning sidebar & content */
   main {
     float: left; /* LTR */

It seemed odd that these two pieces were moved above the comment "positioning sidebar & content".
And there is already a main { float:left } so this additional code isnt necessary.

In testing in the browser, I noticed the margin-left on the main was causing unnecessary whitespace on the maintenance page display, which doesn't have the sidebar first, so I refactored the code a bit so that the entire section in install-page.css reads better.

While stepping through the different commits, I noticed somewhere along the way there was a position:absolute that got removed from .task-list .is-active:after { and realized this should have completely broken the styles. Except that it appeared to not have any effect. I think in Seven, this code was used to make the right angle > but now that we have rounded corners, this is easy as part of just the container, so this entire code can be removed. Additionally, testing on extra long text shows that there is no right-padding which could look bad, and could easily be improved, I suggest using the same 1rem to pad the side that contains the rounded corner.

Before:

After:

New MR here: https://git.drupalcode.org/project/drupal/-/merge_requests/2268/commits

I've just tested update.php creating a couple hook_update_Ns with very long title, and a thrown error and noticed some issues with the display, which looks unthemed:

Before:

After:

/**
 * Testing an update which throws an exception and has a long 80 character name.
 */
function user_update_9404() {
  throw new \RuntimeException('really long error message with a path /path/to/file/name/alsdkfjalskdfjalksdjflaksjdflkasjdflkasjdflkasjdfasdfasdfasdfasdf.php');
}

I did extensive testing already for testing #47 including responsive (desktop and small screen) on install.php, update.php (under various scenarios including successful and error messages), and homepage as anonymous user in maintenance mode with drush sset system.maintenance_mode 1 and $settings['maintenance_theme'] = 'claro'; in settings.local.php

Things are looking good, but since the last changes are mine, this needs more review by others.

I've pushed this forward as much as I can for now and probably will not be able to come back to this soon. Passing baton back to Andy (and/or others) to code review latest MR and do some in-browser testing.

https://git.drupalcode.org/project/drupal/-/merge_requests/2268/commits

This all looks really good, moving to RTBC.

Attached is a .zip of screenshots with the following structure:

screenshots/
├─ installer/
│  ├─ english/
│  │  ├─ desktop/
│  │  ├─ mobile/
│  ├─ deutsch/
│  │  ├─ desktop/
│  │  ├─ mobile/
├─ maintenance.png
├─ update/
│  ├─ english/
│  │  ├─ desktop/
│  │  ├─ mobile/
│  ├─ deutsch/
│  │  ├─ desktop/
│  │  ├─ mobile/

desktop screenshots are 1080x720, mobile screenshots are 420x720

I've also revisited the issue and tested MR2268 in Safari 13.1.2 on MacOS. First I can also confirm that most of the points i've brought up in the comments get fixed with the current state of the MR. Thanks to @andy-blum for all the work. awesome! :)

• The issues in #31 with the main content being moved to the bottom got fixed.
• The changing width of the progress bar mentioned in #32.1 got fixed as well. same as the styling mix between Claro and Seven design elements in #32.3

There is one color contrast related issue that might still require some work and one detail i've noticed while rechecking:

• the color contrast for already finished steps mentioned #36 has still a too low color contrast. With a font-weight of 500 and a font-size of 16px it is considered a regular text. That way a contrast ratio of 4,5:1 would be required while the font color used (#919297) has a ratio of 3,1:1.
• The current step in the sidebar gets highlighted with a light blue background (#E4EDFF). It basically signifies the current active step /state. So i am not sure if it wouldnt be necessary to have a contrast ratio of 3:1, the current ratio is 1,2:1 against the adjacent background colour white.

And two additional observations and comments:

• i've narrowed down the browser window for the first time in the installer and noticed that the current step is displayed in the wizard with 2/6. Currently it is not styled at all it is just plain text. @lauriii mentioned that there is design work done on the steps component in #9 which provides a more visual approach than plain text. What is the current state and should that be moved to a follow up issue? (wanted to mention it that it doesn't slip through).
  And on the other hand from the perspective of a screen reader user there is no context for 2/6 by a label or some extra text. Would it make sense to exchange 2/6 with something like Step 2 of 6 in general? that way it would be more clear to screen reader users as well as sighted users on smaller viewports.
  Or would it make sense even to adjust the page title as well so that the title of for example the page Select an installation profile page | Drupal is changed to Step 2 of 6: Select an installation profile page | Drupal (the other pages of the install wizard changed accordingly)?
• I've noticed that the issue i've created in the context of the user profile pages applies to the configure site screen when entering a password for the admin user as well: https://www.drupal.org/project/drupal/issues/3272325 . this is issue is out of the scope for the redesign the installer issue but i wanted to note it for reference

I am not sure if it is ok to set the status of the issue back to needs work. was a bit hesitant at first but at least the point about the color contrast of the steps names might justify it. therefor i set it back to needs work for now. in case the points mentioned are more suitable for followups or not of an issue then sorry in advance and please move it back to RTBC again (just dont wanted to hold up a critical issue unnecessarily - but at least bring up the observations :/)

The current step in the sidebar gets highlighted with a light blue background. ... I am not sure if it wouldnt be necessary to have a contrast ratio of 3:1 ... against the adjacent background colour white.

Fairly certain that the blue background doesn't need to have a specific contrast ratio to the white background, especially given the active step also has a higher font-weight

Would it make sense to exchange 2/6 with something like Step 2 of 6 in general? ... Or would it make sense even to adjust the page title as well

The issue with this is the additional width of the characters would cause some overflow/stacking on the mobile sizes. Maybe we could do something with visually-hidden text though? I do like the idea of updating the page title as well, but I think it would need to be both-and rather than either-or.

I am not sure if it is ok to set the status of the issue back to needs work.

Perfectly fine! I'll try to get into this in the next few days.

We reviewed this issue at #3280390: Drupal Usability Meeting 2022-05-20.

There were two key recommendations from the discussion.

1. We discussed the perspective of someone who does not speak English.

The language select page is the very first page in the installer that is presented, so for those people who do not speak English, they need to choose the language they are most comfortable with. The problem is that everything else on that page, including the submit button is written in English, and that does not change when the language selector is changed. Only after the user has proceeded to the next step in the installer would the language change to their preferred language. So if the user doesn't speak English, they might have trouble navigating to the next step in the installer.

The recommendation is to explore this further and potentially have the first step in the installer dynamically adapt to the language the user chooses in real time. This however we did not feel should block the issue and we agreed that it would be best explored and addressed in a follow-up issue.

2. We discussed the installation steps progress component. A number of problems with this were highlighted:

• It works fine for large desktop screens, but does not scale-down well on small screens and mobile devices.
• It does not accurately reflect the effort involved at each step, it implies that all steps have equal weighting/effort. Consider that the language selection step is a single form input, however the final site configuration form has many more fields on it; The installation step is just an automated progress bar, while the database connection form could be seen as daunting to novice users.
• If the site is configured as a distribution and/or has the database connection already configured, after selecting the language the user is jumped forward by one or more steps in the process. This sudden jump could be confusing to the user as they could reasonably wonder what happened to the previous steps that they were expecting to see.
• It does not work well for profiles/distributions that insert additional steps into the installer through branching logic or part way through. For example, a profile/distro can arbitrarily add additional steps to the installer and those could be added based on conditional logic in previous steps. This could result in the user moving through the various steps and suddenly more steps are added that they were not expecting to see.

All of these issues taken together highlight some fundamental problems with the installation steps component, all things considered it shows that at best the component is not particularly useful, and at worst it's potentially misleading.

The important thing to remember here is that the installer is essentially just a multi-step form (also referred to as a "wizard"). With that knowledge we can take the lead of already established patterns and best-practice for multi-step forms. For example, the GOV.UK Design System - widely regarded as one of the leading design systems for government digital services - provides some well-evidenced and well-researched patterns for multi-step forms.

We refer to the GOV.UK "Check a service is suitable" pattern and the GOV.UK "Check answers" pattern. There are two key things to highlight here, firstly the "Check a service is suitable" pattern does not show the steps up front, instead it relies on the "Check answers" pattern to provide a summary; Secondly, by not showing all of the steps up front it facilitates conditional branching and arbitrary steps to be added as the user progresses through the multi-step form. Following this pattern would address all of the concerns previously mentioned.

To that effect, our recommendation is that we follow the GOV.UK "check a service is suitable" pattern, and simply drop the installation steps component. Additionally, it may be wise to introduce the "Check answers" pattern. However, like with first recommendation we were happy for these to be addressed in follow-up issues and not to block this issue if that is the most sensible option.

As an additional recommendation, following the patterns previously mentioned, it may be worth reorganising some of the steps to break up the larger forms into more smaller steps. In the GOV.UK example they recommend asking one question per step. Now, we might not need to have a step for every field, but for example the final configuration step may benefit from being split up into multiple steps. Again, this does not need to be addressed here, and could be addressed in a follow-up issue.

For more reading on that topic we refer to an article by the Nielsen Norman Group: Wizards: Definition and Design Recommendations.

Thanks,
-Aaron, on behalf of the UX meeting.

Meeting attendees: @AaronMcHale, @Antoniya, @benjifisher, @rkoller, @shaal, @simohell, @worldlinemine.

@AaronMchale:

Thanks for summarizing the discussion of the usability meeting.

The issue for the meeting (link in #60) will have a link to the recording.

I encourage people to follow the links in #60. As a teaser, here is an image borrowed from the "Check a service is suitable" reference:

The title of this issue, "Redesign Installer", is rather broad, and the suggestions in #60 make sense in that scope. I notice that this issue is a child of #3066007: Roadmap to stabilize Claro, which suggests that the intended scope might be just the visual design of the installer. If so, then most of the suggestions in #60 are out of scope for this issue.

There is one part of #60 that had strong consensus at the usability meeting and could be implemented as part of a visual redesign of the installer: remove the summary of steps from the installer. As #60 points out, steps may be added or skipped, so the summary may be inaccurate and confusing. We felt that this is a case where "less is more" applies.

Thanks Benji for the additions in #61!

Just to follow on from #60 and #61, as I forgot to mention in #60 that during the meeting we also discussed how other common software installers and out of box experiences work, for example on iOS and Windows they essentially follow that pattern described in #60 and #61, they do not provide an up-front set of steps, as again those experience also have branching steps/logic.

Thanks,
-Aaron

@AaronMcHale & @benjifisher thank you (and the rest of the UX reviewers) so much for going through this and making recommendations. I do think they're great ideas and, personally, I think they're worth implementing, but as benji points out, this particular issue is scoped to claro's look-and-feel updates, to make the installer thematically match claro instead of seven.

I'll refrain from making any follow-up issues or adding to-dos here until we've had our weekly claro/olivero meeting in #frontend on drupal slack.

Looks like we had some accessibility review in #55, so removing that tag.

Following the #frontend slack meeting on May 24, it looks like the UX improvement recommendations will work best as followups. This issue is dedicated to the look and feel of the installer, but isn't changing any structure or process. We'll create 2 followup issues to discuss and plan how to update the language on the first page of the wizard as well as potentially removing the steps from the installer.

Follow-up issues created:

#3283369: Installer does not update language of "select language" step

#3283371: Remove steps from installer

So if we remove the steps in a follow-up issue, it would not make sense to do any design work on them in this issue, I'm assuming then that is the plan? Otherwise, we'd end up with design and implementation effort going into the installer steps, only for them to later be removed.

> it would not make sense to do any design work on them in this issue [...] Otherwise, we'd end up with design and implementation effort going into the installer steps, only for them to later be removed.

The work has already been done to adapt the style of the steps from Seven look and feel to Claro look-and-feel. I don't think anyone was planning to take the current look-and-feel any further than what has already been comped in Figma and implemented in the patches on this issue to date.

It feels like scope creep to even consider removing the steps in the context of this issue. An effort like that needs to go through several gates including UX and design considerations for both the install.php as well as update.php which would also be affected by the removal of steps. I'm even not sure of further implications of a fundamental change like that beyond the scope of one single admin theme to any custom admin theme (eg some distros have themes that override these install pages).

The issue title could probably be dialed in, because the scope needs to be reigned in to support the current issue: re-skinning the install/update/maintenance page, which is the fundamental task that is blocking us from making Claro the default theme. I think continued design evolution and UX overhaul and improvements was already mentioned above that it would be done in follow-ups.

The work has already been done to adapt the style of the steps from Seven look and feel to Claro look-and-feel. I don't think anyone was planning to take the current look-and-feel any further than what has already been comped in Figma and implemented in the patches on this issue to date.

Okay that's fine, no objections from me then.

It feels like scope creep to even consider removing the steps in the context of this issue. [...] The issue title could probably be dialed in, because the scope needs to be reigned in to support the current issue: [...]

Yes I agree, ensuring this issue has a very clearly defined scope would be helpful, otherwise it also risks not actually getting done.

Setting to Needs Work. The MR above states that this isn't mergable. I tried to bring it up to date (and was able to merge it), but I am having issues pushing.

The test failure looks like one of the random ones.

I'm going to start to review this regardless.

Hmmm.... now it says it is mergable. Re-queuing tests and setting back to NR

I'm still in the process of reviewing this, but wanted to add this in here first.

The installer page doesn't indicate the active step when the user is in forced colors mode, and should also indicate a boundary of the UI.

The boundary issue could be fixed by adding a transparent border.

There are a couple ways to fix the step issue:

• Add a chevron using the <li>'s :after pseudo-element
• Make it underlined
• Transparent border
• ???

You could qualify those under the forced colors media query, but you'd also want to use IE11 compatible -ms-high-contrast, since we still support that.

Outside of the issues above, I couldn't find any problems! Great work, it looks wonderful!

I tested this in Chrome, Firefox, and Safari, at narrow, medium, and wide viewports. Because the CSS is doesn't utilize any modern properties, I don't really anticipate this looking improper on any other supported browsers.

I also tested this using multiple languages, including arabic (at least I think it was) to test out RTL, and spanish. It looked and functioned perfectly.

Once we get the issues above fixed, this should be good to go.

FWIW, playing around in devTools, setting a transparent border on the .layout-container and the .task-list .is-active seems to do the job really well, and doesn't require any media queries.

I found one more accessibility issue.

At mobile widths, the task list is hidden by CSS. However, the <h2> heading, and <aside> are still accessible to assistive tech. Instead of hiding the .task-list <ol>, we should hide the entire <aside>

The actual changes look good. Some minor nits about the format of the comments, and we also need to re-compile the CSS.

I'm not sure why we're getting custom commands failed. I recompiled the assets, and the commit-code-check.sh script has no errors for me locally.

Can you re-run the yarn install ?

I'm still having issues pushing to this specific MR. You need to merge in the latest 9.4.x, and then recompile the CSS. You'll see the change then.

Forgot to hit the "Get Push Access" button. Just pushed up the changes.

OK! Change look good. I'm re-RTBC-ing this!

3085219-10.0.x branch needs review

I reviewed the 3085219-10.0.x branch and it looks good to me. I checked the new styling in both Chrome and Firefox, desktop and mobile. Screenshots are attached. Marking RTBC.

One more minor issue with the D10 branch. You're including the variables file within the maintenance page CSS, which you don't need to do since CSS variables are not transpiled in Drupal 10.

This also needs a release note.

Responded to the feedback on MR

This introduces some changes to the Claro maintenance page which was implemented based on designs in #3085212: Redesign maintenance page. Are these changes intentional?

Before:

After:

In Claro this still needs to be imported because we are not loading the variables.css in libraries.yml

Yeah we are, you can see it at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/clar...

#91: 👍 Not sure how I missed that earlier 😅

I removed the CSS variables from being added.
I started working on removing the styles from affecting the maintenance page, but more work needs to be done.

The maintenance page styles are unnecessarily mingled with the install page. We can fix this, but it will take more time than I have today.

1. We should move the "Task list & step indicator" over to install-page.pcss.css. This isn't seen on the maintenance page.
2. There is a lot of .layout-sidebar-first ~ main code that affects the width of the maintenance page that is install-page specific. We also need to move this over, and qualify this to the .install-page selector.
3. In fact, the maintenance-page.pcss.css has the .install-page CSS selector at lines 128 and 135. These probably shouldn't exist within this stylesheet.

I noticed this stuff too @mherchel, but shouldn't all this be moved to a follow-up?

IMO, thinking about this all as a design system perspective, this layout is just another generic layout that could be leveraged by other custom admin UIs which could optionally support a sidebar first. And as such, I'd propose removing reference to "maintenance-page" and "install-page" for all page framing and layout styles, and come up with a generic name for this type of a ui takeover splash-screen layout. Then, any maintenance-page specific or install-page (or for that matter update-page), could all be separated out to their respective page-specific css files).

Yeah, I'm really indifferent about it. IMO the new maintenance page styling looks fine, and I'm not sure many people will see it.

I'll leave that up to the framework managers.

Changes should be good now. Please review.

crap. I screwed up the 9.x branch by merging in 9.4.x. I can't seem to recover from this.

I think i screwed it up more by merging in the 9.5.x branch. Evidently this issue is set to 9.5.x and but the branch is still 9.4.x

I'm giving up and unfollowing this issue. Merge request are so frustrating for me.

sorry @mherchel :( I feel your pain. Probably this doesn't help at all now... but I generally try to go the rebase approach first it just keeps all the commits close together and cleans up the git history... but it can also have lots of pitfalls if it doesn't rebase cleanly. a rebase is actually a lot more akin to a traditional drupal patch reroll fwiw.

At the end of the day, making the version on the issue match with the MR is still really hard to get right.

@jwilson3 could you edit the merge request and change the target branch to be 9.5.x please? only the person that created the merge request is allowed to edit it at the moment. I was looking to help with the rebase issues but first the base branch needs to be updated.

@javi-er: I've set the base branch to be 9.5.x and i see the following message:

Merge blocked: fast-forward merge is not possible. To merge this request, first rebase locally.

Going to try my hand at a rebase on 9.5.x

I see another MR 2359 with additional changes from andy-blum and mherchel based on 10.0.x, from around #86 and it appears to include a single commit containing the bulk of the changes from the MR 2268 based on the 9.4.x branch, so I'm not entirely sure where things are at this point, if MR 2268 was abandoned in favor getting this onto 10.0.x branch. But I see this issue is still on the 9.5.x Please advise if I should continue work on a rebase on 9.5.x or if the issue needs to go to 10.0.x branch.

Yes, we still want both MRs

Thanks @jwilson3, I rebased the branch manually, both MR are green now. Moving it back to "needs review".

I took screenshots of the 9.5.x MR (2268) via DrupalPod and the 10.x MR (2359) via SimplyTest.me, in both desktop and mobile. Zipfiles attached.

Apologies there aren't screenshots for every step; in some cases they proceeded too quickly for me to get them. Nonetheless the pages look the same as the designs above.

Separately I took screenshots from each of the maintenance pages when the theme is set to Claro given comments in #90.

9.5.x:

10.x:

It all looks good, and I would have RTBC If there was not a translation issue that sneaked in the JS :/

Good catch @nod_! Made the string translatable.

I'm not sure that's a thing we can do at the install step. That text probably needs to come from the PHP directly, because at install time the locale module is not enabled and that's where JS translations happen.

I'd remove that part from the patch and open a follow-up to improve, otherwise this might get stuck on this and hold up a big amount of work.

Moving that to a follow-up. Tagging so that I remember to create the follow-up later.

Works for me, thanks!

Follow-up opened: #3298298: Improve installer step UX for screen readers.

need reroll

Committed 748dd31 and pushed to 10.0.x, 10.1.0 and 9.5.0. Thanks everybody!