I had no idea people had so strong feelings about theme toggles. I know some applications offer the choice, but I imagined it was because a small set of developers took it as a fun challenge to implement. One of my banking apps has a theme toggle. I look at that app twice a month to see if I need to rebalance the savings portfolio. It doesn't need a theme toggle. Clearly, the toggle is just the result of a scheduled "fun sprint" in between real work. Right?
But this article implies a theme toggle is table stakes for new development, as implied by the parenthetical:
> (despite the irony that the site that post is published on offers no theming or theme toggle at all)
Like... is that something a website should do? Does this come from a bubble, or have UX people in the industry more broadly moved past "should we provide a theme toggle" into "what is the optimal shape of the theme toggle we obviously must have"?
Maybe I'm old, but I don't expect developers of things to produce multiple themes to suit different preferences. It seems like a complete waste of their time. That time could better be used to improve functionality, fix bugs and stability, or increase behavioural tracking for more specifically targeted advertisements.
Most OSs provide theme toggles by default, thus it has conditioned people to also expect it from websites.
Arguably, I personally loathe it when the site has no dark mode cough Amazon cough as I'm doing some late-night shopping on the bed and the screen blinds my eyes with the white background.
theme toggles may be considered as table stakes depending on accessibility rules in jurisdiction and various other decisions one has made regarding the website.
Honoring the dark/light color scheme set on the device might be a requirement in some cases (I haven't seen a straight answer about it for the EAA) but it is a good accessibility practice.
Including a toggle in an app/site UI so users can choose to not use their device setting is an extra.
> Clearly, the toggle is just the result of a scheduled "fun sprint" in between real work. Right?
As someone who worked on banking software, absolutely not. It was not fun sprint thing, but actual requirement. We would not do it otherwise. We did not do fun sprints. And if we did, we would pick things are the ones that have less maintenance issues related to them (because you then have to keep both versions forever).
How common is offering a dark mode outside particularly programmer-y/designer-y spaces?
We'd like to but don't currently offer it because it would be a fairly involved undertaking - we have a lot of images that would need to be updated with corresponding dark versions to not look out of place.
As far as I'm aware though we've only received a single request for such a feature, and that request was wildly over the top exclaiming that out site lit their eyeballs on fire.
Generally I don't care if the third option is there or not, but one place where “system” is useful is when the preference is in an app and saves to my profile. I usually use a light theme on desktop but dark on mobile. Though TBH if the toggle is in easy reach it is no hardship to flick it one way or the other.
A common gripe I have isn't the toggle, but that people often don't test both states, neglecting the one that they don't personally use, so elements creep in that are difficult (or even impossible) to read/see in one of the options because of contrast problems. If you are going to have both options, please test both options. Not having my preference is less annoying than being offered my preference but it not actually being usable.
As a side note, this is the ultimate light/dark mode implementation: https://tonsky.me/
>Under the hood, rather than explicitly toggling between “light” or “dark”, it toggles between falling back to the system setting, and the opposite of the system setting.
Not sure I like this. Suppose my system is in dark mode because of low battery, but I want to read a page in light mode, so I change it. The next time I open the page with full battery (and thus system light mode), the page will render dark again...
> Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her.
Sounds like a good reason to make it automatic then, because if users have to find your state toggle in some hamburger menu, they're not going to use it if they don't even know the system has a theme applied.
Everyone thinking about 2-state vs. 3-state controls is automatically honoring the device's color scheme setting. The controls are an extra to let users choose to not use the device setting on a particular site.
Rather than each site making its own design for such a control, I wish browsers would make it a per-site setting users could use.
However, we should go a step further and provide a framework of UI elements that can be used consistently to create a uniform and accessible interface and they could even be pre-compiled into native controls for more efficient...hold on a gosh darn minute...
I read this up until the monospaced use of the term `localStorage`, which for me (Firefox on Android) got rendered with a white background but did not invert the font, making it unreadable without highlighting it. I don't think I'm interested in someone's take on light versus dark theme if they don't seem to actually know how to make their own website work right with dark theme.
Another firefox user and over the years occasional reader of linked site. I don't believe that was ever the case the background of that word was 2b404e not white.
Josh takes great pride in hos work and I doubt he would miss such a thing, also checked of maybe he made a change between you posting and now and no https://github.com/josh-collinsworth/joco-sveltekit no such change regarding styles
Okay, let's be concrete: I don't think the word after "permantly in" is readable, and I don't believe you would find it readable either: https://imgur.com/4WKHQ9J
Maybe it's not technically "white", but I don't think that's a particularly strong rebuttal to my point.
I posted the screenshot in a reply to the sibling. The skill issue seems to me to be on the part of the web development that led to dark mode themed like that.
> Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her. (Interestingly: she herself was surprised to find out she’s actually been looking at dark mode this whole time without even realizing it).
My wife’s phone has been in dark mode since before I married her, but most of the apps she cares about either don’t support dark mode (at least on her version of Android, older Samsung) or she has manually chosen light mode. The system preference and ability to swap it at night time or whatever is thus a bit of a mockery. (I mentioned it once, but didn’t change anything.)
If the site defaults to system (which isn't guaranteed), very few people will need the toggle, at which point it can be omitted, or at least hidden deep in settings, and there is no need to put so much thought into its design.
> That is: rather than saving either a light or dark theme preference permanently in localStorage, Dr. Verou’s implementation stores your preference only if that preference is different than your device setting. In that case, the site saves whatever theme that happens to be.
Ironically enough, with the dark mode CSS, the inline code span is unreadable.
I hate frontend devs that think of themselves smarter than their users and try to be smart about stuff. Just show me the available states, thank you very much.
If users don't know/understand something, you don't help them by hiding it even further from them. Do your part in educating them by simply exposing them to the concept.
This isn't rocket science, just a switch with three states.
Empower your users! Not make yourself the arbiter of features.
Having a light mode and a dark mode as the target of the setting, makes it impossible to use a light area versus a dark area to meaningfully suggest visually which one is selected. This stymies the designer completely, apparently.
Default to system, use two states, and integrate the toggle in a top level UI context as a single icon that flips between sun/moon. Putting it deep in a menu is what creates all this pretentious hedging because we're subconsciously worried about the user not being able to get to it.
There is a weird appeal to authority randomly added at the end of the article. Just because someone with a PhD has an idea on what may be good for users doesn't prove it actually is. Such a decision should be grounded in user studies and telemetry.
I started using computers in the era where customisation and user preferences were “allowed” by software companies. Think the Windows 98 or even Windows 7 theme dialog vs modern Windows. I personally reject this seemingly forced binary choice of light and dark.
Because of this for my site I have four themes, light, summer sunshine, forest, and dark. I’ve seen some sites where the theme is an RGB colour picker even.
In regards to the article, that’s a lot of consternation and frustrating statements about toggles and tri-state toggles. A simple button with a dynamic icon works well as soon as you want to cycle through more than two choices.
Why are UI people so determined to make apps as opaque and unusable as possible?
> rather than explicitly toggling between “light” or “dark”, it toggles between falling back to the system setting, and the opposite of the system setting.
Absolutely NOT.
> this unavoidably indicates that some number of users don’t even know what their system theme is—or might not even understand what “system” means in the first place!
Especially these people should NOT be given two state setting that depends on something third they do not know about. Yes, some people do not care about dark vs light setting. Let them not care.
I had no idea people had so strong feelings about theme toggles. I know some applications offer the choice, but I imagined it was because a small set of developers took it as a fun challenge to implement. One of my banking apps has a theme toggle. I look at that app twice a month to see if I need to rebalance the savings portfolio. It doesn't need a theme toggle. Clearly, the toggle is just the result of a scheduled "fun sprint" in between real work. Right?
But this article implies a theme toggle is table stakes for new development, as implied by the parenthetical:
> (despite the irony that the site that post is published on offers no theming or theme toggle at all)
Like... is that something a website should do? Does this come from a bubble, or have UX people in the industry more broadly moved past "should we provide a theme toggle" into "what is the optimal shape of the theme toggle we obviously must have"?
Maybe I'm old, but I don't expect developers of things to produce multiple themes to suit different preferences. It seems like a complete waste of their time. That time could better be used to improve functionality, fix bugs and stability, or increase behavioural tracking for more specifically targeted advertisements.
Most OSs provide theme toggles by default, thus it has conditioned people to also expect it from websites.
Arguably, I personally loathe it when the site has no dark mode cough Amazon cough as I'm doing some late-night shopping on the bed and the screen blinds my eyes with the white background.
theme toggles may be considered as table stakes depending on accessibility rules in jurisdiction and various other decisions one has made regarding the website.
Honoring the dark/light color scheme set on the device might be a requirement in some cases (I haven't seen a straight answer about it for the EAA) but it is a good accessibility practice.
Including a toggle in an app/site UI so users can choose to not use their device setting is an extra.
> Clearly, the toggle is just the result of a scheduled "fun sprint" in between real work. Right?
As someone who worked on banking software, absolutely not. It was not fun sprint thing, but actual requirement. We would not do it otherwise. We did not do fun sprints. And if we did, we would pick things are the ones that have less maintenance issues related to them (because you then have to keep both versions forever).
How common is offering a dark mode outside particularly programmer-y/designer-y spaces?
We'd like to but don't currently offer it because it would be a fairly involved undertaking - we have a lot of images that would need to be updated with corresponding dark versions to not look out of place.
As far as I'm aware though we've only received a single request for such a feature, and that request was wildly over the top exclaiming that out site lit their eyeballs on fire.
Generally I don't care if the third option is there or not, but one place where “system” is useful is when the preference is in an app and saves to my profile. I usually use a light theme on desktop but dark on mobile. Though TBH if the toggle is in easy reach it is no hardship to flick it one way or the other.
A common gripe I have isn't the toggle, but that people often don't test both states, neglecting the one that they don't personally use, so elements creep in that are difficult (or even impossible) to read/see in one of the options because of contrast problems. If you are going to have both options, please test both options. Not having my preference is less annoying than being offered my preference but it not actually being usable.
As a side note, this is the ultimate light/dark mode implementation: https://tonsky.me/
Am I missing something? I get black text on a yellow background, and no apparent toggle...
It isn't as obvious as it used to be, no longer looking like a switch. Click the sunlight icon in the top right. Also, it doesn't work well on mobile.
>Under the hood, rather than explicitly toggling between “light” or “dark”, it toggles between falling back to the system setting, and the opposite of the system setting.
Not sure I like this. Suppose my system is in dark mode because of low battery, but I want to read a page in light mode, so I change it. The next time I open the page with full battery (and thus system light mode), the page will render dark again...
Yep. This is why my three-state-toggling site has a local-storage setting for just that reason --- inspired by others’ writings and codes:
https://www.brycewray.com/posts/2024/01/its-tri-state-switch...
The options are:
* Automatically Follow the system theme
* Lock in the opposite of the current system theme.
If you change a page to light while the system is dark, that page will render light forever. (Or at least until you change the setting again)
> Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her.
Sounds like a good reason to make it automatic then, because if users have to find your state toggle in some hamburger menu, they're not going to use it if they don't even know the system has a theme applied.
Everyone thinking about 2-state vs. 3-state controls is automatically honoring the device's color scheme setting. The controls are an extra to let users choose to not use the device setting on a particular site.
Rather than each site making its own design for such a control, I wish browsers would make it a per-site setting users could use.
That's basically @media (prefers-color-scheme: dark).
However, we should go a step further and provide a framework of UI elements that can be used consistently to create a uniform and accessible interface and they could even be pre-compiled into native controls for more efficient...hold on a gosh darn minute...
I read this up until the monospaced use of the term `localStorage`, which for me (Firefox on Android) got rendered with a white background but did not invert the font, making it unreadable without highlighting it. I don't think I'm interested in someone's take on light versus dark theme if they don't seem to actually know how to make their own website work right with dark theme.
Another firefox user and over the years occasional reader of linked site. I don't believe that was ever the case the background of that word was 2b404e not white. Josh takes great pride in hos work and I doubt he would miss such a thing, also checked of maybe he made a change between you posting and now and no https://github.com/josh-collinsworth/joco-sveltekit no such change regarding styles
Okay, let's be concrete: I don't think the word after "permantly in" is readable, and I don't believe you would find it readable either: https://imgur.com/4WKHQ9J
Maybe it's not technically "white", but I don't think that's a particularly strong rebuttal to my point.
skill issue
I posted the screenshot in a reply to the sibling. The skill issue seems to me to be on the part of the web development that led to dark mode themed like that.
> Despite spending hours a day looking at her phone, she literally had to check it to find out what her default color theme is; it’s that invisible to her. (Interestingly: she herself was surprised to find out she’s actually been looking at dark mode this whole time without even realizing it).
My wife’s phone has been in dark mode since before I married her, but most of the apps she cares about either don’t support dark mode (at least on her version of Android, older Samsung) or she has manually chosen light mode. The system preference and ability to swap it at night time or whatever is thus a bit of a mockery. (I mentioned it once, but didn’t change anything.)
If the site defaults to system (which isn't guaranteed), very few people will need the toggle, at which point it can be omitted, or at least hidden deep in settings, and there is no need to put so much thought into its design.
There should not be a toggle on the website at all.
> That is: rather than saving either a light or dark theme preference permanently in localStorage, Dr. Verou’s implementation stores your preference only if that preference is different than your device setting. In that case, the site saves whatever theme that happens to be.
Ironically enough, with the dark mode CSS, the inline code span is unreadable.
I’m interested if the average user really cares about it all that much for web apps and blogs etc.
Some apps I’ve used in dark mode long enough it would be weird if it switched. But new things I use I don’t really go looking for it.
I hate frontend devs that think of themselves smarter than their users and try to be smart about stuff. Just show me the available states, thank you very much. If users don't know/understand something, you don't help them by hiding it even further from them. Do your part in educating them by simply exposing them to the concept. This isn't rocket science, just a switch with three states. Empower your users! Not make yourself the arbiter of features.
Having a light mode and a dark mode as the target of the setting, makes it impossible to use a light area versus a dark area to meaningfully suggest visually which one is selected. This stymies the designer completely, apparently.
It's not that complicated.
Default to system, use two states, and integrate the toggle in a top level UI context as a single icon that flips between sun/moon. Putting it deep in a menu is what creates all this pretentious hedging because we're subconsciously worried about the user not being able to get to it.
There is a weird appeal to authority randomly added at the end of the article. Just because someone with a PhD has an idea on what may be good for users doesn't prove it actually is. Such a decision should be grounded in user studies and telemetry.
I started using computers in the era where customisation and user preferences were “allowed” by software companies. Think the Windows 98 or even Windows 7 theme dialog vs modern Windows. I personally reject this seemingly forced binary choice of light and dark.
Because of this for my site I have four themes, light, summer sunshine, forest, and dark. I’ve seen some sites where the theme is an RGB colour picker even.
In regards to the article, that’s a lot of consternation and frustrating statements about toggles and tri-state toggles. A simple button with a dynamic icon works well as soon as you want to cycle through more than two choices.
It annoys me to not be able to reset a preference so I always give the third option: for light/dark and for the language.
Why are UI people so determined to make apps as opaque and unusable as possible?
> rather than explicitly toggling between “light” or “dark”, it toggles between falling back to the system setting, and the opposite of the system setting.
Absolutely NOT.
> this unavoidably indicates that some number of users don’t even know what their system theme is—or might not even understand what “system” means in the first place!
Especially these people should NOT be given two state setting that depends on something third they do not know about. Yes, some people do not care about dark vs light setting. Let them not care.
I think I'd just separate the two things:
``` Theme ( ) Light (•) Dark
[x] Follow system Dark — currently controlled by system ```
When "Follow system" is on, the theme choice is greyed out.
Feels simpler to me, and it scales better if themes ever become more than just light/dark.
I used the Selenized color scheme once and it indeed came in four variants: light, dark, white and black.
One may also think about a grayscale theme, perhaps.
Indeed. Or shorter: “auto”
Better idea: Style sites absolutely as little as possible and leave it up to the user's agent.
Too much of the web is like old MySpace where every designer is trying to express their style instead of Twitter where content is the focus.