Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spike to understand which colours would need adjusting to have a well designed dark mode #4903

Closed
1 task
Tracked by #3663
romaricpascal opened this issue Mar 26, 2024 · 5 comments
Closed
1 task
Tracked by #3663
Assignees

Comments

@romaricpascal
Copy link
Member

romaricpascal commented Mar 26, 2024

What

Create stylesheet overriding our styles as bluntly as necessary to define which colours would need changing to implement dark mode, form a design point of view.

Particular attention might be necessary around links and focus styles.

Why

This will let us indentify the scope of the colours needing to be adjusted to support a dark mode.

Who needs to work on this

Designers, potentially with support from developers and accessibility specialist

Who needs to review this

Designers

Done when

  • We have a branch where our components sport a dark mode style
@36degrees
Copy link
Member

@christopherthomasdesign is it accurate to say you're working on this one?

@christopherthomasdesign
Copy link
Member

Yes it is! Hoping to push something and write a summary on Monday 👍

@christopherthomasdesign
Copy link
Member

Sorry for the delay!

I’ve thrown a quick experiment onto a branch at https://github.com/alphagov/govuk-frontend/tree/darkmode-palette.

It largely uses the palette developed by the planet-centred design working group at GDS. I've made some tweaks to improve colour contrast, but I haven't tested every colour combination at this point.

You can probs just use the diff in that branch to see what I've changed, but here are a few thoughts I jotted down as I was going through:

  • pretty much all the standard applied colours need to be adjusted in dark mode to improve contrast if we're going to use a slightly lighter black for the background
  • I lacked a clear convention for hover states – for text links I made them lighter so they wouldn't lose contrast, or just relied on the change in border width to give affordance
  • for ‘area’ hovers like task list, that background obvs needs to still work with any text… so it may work better for it to go darker (see the accordion and task list states)
  • that isn't too different to how it works in light mode, where it goes from white to grey – as discussed, might we need a concept of govuk-area-hover-colour or something?
  • IMO inputs should have a dark background with white text and a white border – otherwise the big white input boxes jump out too much, they become the strongest visual element on a page instead of a heading or a button
  • this might need us to create a concept of an input background and border colour
  • the focus states are a bit broken in places, but I think they should stay exactly the same as in light mode – they're designed to work on all kinds of backgrounds, and I haven't seen anything that stops them from working here... the visual effect is a bit different but I think fields still look focused enough
  • colour contrast of the red ‘error colour’ needs to change - it currently fails for normal text
  • but it passes for e.g. the exit this page button, which uses govuk-warning-button-colour in its naming – if we use the error colour that I lightened for text contrast, it then becomes too pale to put white text on top of
  • I'm wondering if the GOV.UK blue should be different to the link colour in dark mode – links need to be brighter for text contrast on the dark background, but the standard blue works ok for user interface components and backgrounds... this works ok with the way we have brand and links separated in the variables atm
  • I was wondering something similar with e.g. the panel and the green we use for buttons – should they be the same or is the normal green ok for a confirmation panel?

@querkmachine
Copy link
Member

  • for ‘area’ hovers like task list, that background obvs needs to still work with any text… so it may work better for it to go darker (see the accordion and task list states)
  • that isn't too different to how it works in light mode, where it goes from white to grey – as discussed, might we need a concept of govuk-area-hover-colour or something?

This would align with my understanding for how dark modes should typically work. Dark mode shouldn't work like an inversion of light mode, but just as a darkening. If in light themes Thing A is darker than Thing B, or if Thing C becomes darker when focused, the same should be true when dark.

@romaricpascal romaricpascal linked a pull request May 13, 2024 that will close this issue
@romaricpascal
Copy link
Member Author

Forgot to tidy issues at the end of the cycle, so closing this now 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done 🏁
Development

Successfully merging a pull request may close this issue.

4 participants