Dark mode switch

[mtfoley]

During stream on 7/13 (around 32mins), Brian pointed out dark mode switch in Docusaurus, as something worth exploring working into Open Sauced.

Currently dark mode theme context is tri-state ("system", "light", "dark"). Read more here. This would involve dropping the "system" state and always being either "dark" or light. Before user makes a change initial setting would be based on system preference. After that, you'd persist preference to local storage. Just off the top of my head, pros and cons would be:

Pro:

• nicer UI
• could be more deterministic about actual theme in components

Cons:

• once the user set a preference, ie clicked the UI element, it won't follow system preference anymore
• user wouldn't have a way to change back to just following their system preference

So ultimately the question is, do we need to follow system preference, other than determining state prior to the user switching it?

[0-vortex]

Would suggest changing story book dark mode to a theming implementation like in their docs - with a select dropdown; then we would have 3 working dark mode implementations across all our systems we could debate over with a visual feedback system.

Think we should enable more than 2 themes: light, dark, contrast, impaired and adaptive; leaning away from the docusaurus switch and react-dark-mode like 2way switches in general 😵

[mtfoley]

Only thing I really ran into with storybook dark mode was there was a trick to make it so theme stayed constant between canvases - I think I had to feed it a default maybe? That may work fine with what you mentioned but we def wouldn't be using the storybook dark mode UI component anymore (hence not the plug-in)

[0-vortex]

my problem with that plugin is the maintenance and forcing our storybook plugins to stay on 6.3.2 - did not think about extending the base storybook-theming example

[mtfoley]

So then at least with respect to storybook dark mode, your inclination is ditch the plug-in, find a way to use a select input in the storybook chrome to update the theme.

And then with respect to UI in opensauced.pizza your inclination is to lean toward a similar select element (3+ choices), and forget about the 2 state slider

[0-vortex]

And then with respect to UI in opensauced.pizza your inclination is to lean toward a similar select element (3+ choices), and forget about the 2 state slider

It's the only common denominator but it's based on my maintenance and collaboration bias across systems

[mtfoley]

Fwiw: https://mobile.twitter.com/kentcdodds/status/1415491278008033280

[0-vortex]

Somewhat conflicted by successful twitter posts, the over-simplification of text leads to very interpretable results - would argue that such a question requires a bit of historical context, primarily linked to system administrators switching between terminal applications (black/no background) and document-type applications (white background) - this mode was originally coined "high contrast" mode and was meant to help some specific visual impairments.

To add some (poor) references outlining more recent theming decisions:

• https://www.vedantu.com/physics/types-of-visual-impairment
• https://thenextweb.com/news/the-most-compelling-tech-tools-to-assist-the-visually-impaired
• https://monsido.com/blog/accessibility-issues
• https://www.w3.org/TR/low-vision-needs/

The articles above are not in any way inclusive, they are just first page relevant google results; multiple solutions trying to fix real world problems and evolving standards led to the present problem, where actually fixing the visual impairments translates into unusable themes or heavy refactoring of the brand colours themselves, for example the high contrast would (and should) never conform to the base brand as it is meant to exaggerate the contrast, while palinopsia suffering people will need the exact opposite, a bleaching of the contrast.

Going back on the initial suggestion with the above fragmentation in mind we can split theme switches into 2 categories:

1. brand level themes

• light (default if system is light)
• dark (default if system is dark)
• adaptive: adjust application based on time of day/night in the app configured time zone IE remote work on -8h
• system: based purely on system settings

2. visual aids for the impaired

• red/green: deuteranomaly, protanomaly, protanopia+deuteranopia
• blue/yellow: tritanomaly, tritanopia
• complete colour blindness: here is where the low/high contrast could be used

Very few applications serve a minimal solution to both 1+2, could not name an example off the top of my head and generally speaking that level of customisation requires a little bit of visual adjustment - either text explaining which users this theme is for, a corresponding label to the impairment or icons that are more easily distinguishable for the affected users. I would argue that it is impossible to define a correct solution for all these cases without professional advice and affected users' feedback.

Would maybe make sense to implement [1] in a way that enables future [2] extension, would tackle multiple themes along with a collaborative redesign effort. Happy to help with this any way it goes 🔥