Do you think a 3-state dark mode selector is better than a 1-state (where “auto” is the only state)? My website is 1-state, on the assumption that auto will work for almost everyone and it lets me skip the UI clutter of having a lighting toggle that most people won’t use.
Also, I don’t know if the site has been updated but it looks to me like turntrout.com’s two modes aren’t dark and light, they’re auto and light. When I set Firefox’s appearance to dark or auto, turntrout.com’s dark mode appears dark, but when I set Firefox to light, turntrout.com appears light. turntrout.com’s light mode appears to be light regardless of my Firefox setting.
Do you think a 3-state dark mode selector is better than a 1-state (where “auto” is the only state)? My website is 1-state, on the assumption that auto will work for almost everyone and it lets me skip the UI clutter of having a lighting toggle that most people won’t use.
Auto-dark mode: a good idea but “readers are why we can’t have nice things”.
OSes/browsers have defined a ‘global dark mode’ toggle the reader can set if they want dark mode everywhere, and this is available to a web page; if you are implementing a dark mode for your website, it then seems natural to just make it a feature and turn on iff the toggle is on. There is no need for complicated UI-cluttering widgets with complicated implementations. And yet—if you do do that, readers will regularly complain about the website acting bizarre or being dark in the daytime, having apparently forgotten that they enabled it (or never understood what that setting meant).
A widget is necessary to give readers control, although even there it can be screwed up: many websites settle for a simple negation switch of the global toggle, but if you do that, someone who sets dark mode at day will be exposed to blinding white at night… Our widget works better than that. Mostly.
Is it possible that someday dark-mode will become so widespread, and users so educated, that we could quietly drop the widget? Yes, even by 2023 dark-mode had become quite popular, and I suspect that an auto-dark-mode would cause much less confusion in 2024 or 2025. However, we are stuck with the widget—once we had a widget, the temptation to stick in more controls (for reader-mode and then disabling/enabling popups) was impossible to resist, and who knows, it may yet accrete more features (site-wide fulltext search?), rendering removal impossible.
(The site-wide fulltext search feature has since been added, of course.)
localStorage to see if they’ve already told my site a light/dark preference;
whether the user’s browser indicates a global light/dark preference (this is the “auto”);
if there’s no preference, the site defaults to light.
The idea is “I’ll try doing the right thing (auto), and if the user doesn’t like it they can change it and I’ll listen to that choice.” Possibly it will still be counterintuitive to many folks, as Said quoted in a sibling comment.
Possibly it will still be counterintuitive to many folks, as Said quoted in a sibling comment.
No, this is a little different. Your approach here sounds like ours and the intuitive one (just at the cost of additional complexity).
The ‘auto dark mode’ we abandoned is where you just use step #2 there and you skip #1 (and thus, any widget or toggle which enables a reader to do anything with localStorage), and ‘auto is the only state’. The logic there is, the reader already has access to a widget or toggle to set their dark mode preference: it’s just their OS/browser, which will have some config page somewhere with various settings like ‘turn on dark mode at night’ or ‘always use dark mode’ or ‘always use light mode’. Just trust the OS/browser and use whatever setting it sends to the web page. Don’t waste the effort and screen real estate to add in a redundant widget/toggle. It’s handled already. Easier for everyone—it Just Works™!
Unfortunately, the connection between ‘a year ago when I updated my Android phone and it asked me if I wanted to use the cool new dark mode, I said yes’ and ‘this webpage I am reading now is in dark mode for some reason, and I can’t change it back to normal???’, apparently winds up eluding some readers. (This is what Said’s sibling comment is about.) It winds up being “too much magic”.
The current toggle+localStorage+auto approach, on the other hand, while adding to the clutter, does not seem to confuse readers: “the page is in dark-mode, for some reason. But I want want light-mode and I am unhappy. I see a little light-mode button. I push that button. Now the page is in light-mode. I am happy.” (And then it is light-mode ever after.) At least, I have seen many fewer (or no) complaints about the dark mode being on when it shouldn’t be after we moved to the toggle. So as far as we can tell, it’s working.
The main problem with your approach is not that it is counterintuitive (although it is, and more so than ours!), but that there is no way to return to “auto” mode via the site’s UI![1] Having clicked the mode selector, how do I go back to “no, just use my browser preference”? A two-state selector with a hidden, ephemeral third state, which cannot be retrieved once abandoned is, I’m afraid, the worst approach…
You can go into your browse’s dev tools and deleting the localStorage item, or clear all your saved data via the browser’s preferences. (Well, on desktop, anyway; on mobile—who knows? Not the former, at least, and how many mobile users even know about the latter? And the latter is anyhow an undesirable method!)
Do you think a 3-state dark mode selector is better than a 1-state (where “auto” is the only state)? My website is 1-state, on the assumption that auto will work for almost everyone and it lets me skip the UI clutter of having a lighting toggle that most people won’t use.
Also, I don’t know if the site has been updated but it looks to me like turntrout.com’s two modes aren’t dark and light, they’re auto and light. When I set Firefox’s appearance to dark or auto, turntrout.com’s dark mode appears dark, but when I set Firefox to light, turntrout.com appears light. turntrout.com’s light mode appears to be light regardless of my Firefox setting.
Gwern discusses this on his “Design Graveyard” page:
(The site-wide fulltext search feature has since been added, of course.)
IIRC my site checks (in descending priority):
localStorage
to see if they’ve already told my site a light/dark preference;whether the user’s browser indicates a global light/dark preference (this is the “auto”);
if there’s no preference, the site defaults to light.
The idea is “I’ll try doing the right thing (auto), and if the user doesn’t like it they can change it and I’ll listen to that choice.” Possibly it will still be counterintuitive to many folks, as Said quoted in a sibling comment.
No, this is a little different. Your approach here sounds like ours and the intuitive one (just at the cost of additional complexity).
The ‘auto dark mode’ we abandoned is where you just use step #2 there and you skip #1 (and thus, any widget or toggle which enables a reader to do anything with
localStorage
), and ‘auto is the only state’. The logic there is, the reader already has access to a widget or toggle to set their dark mode preference: it’s just their OS/browser, which will have some config page somewhere with various settings like ‘turn on dark mode at night’ or ‘always use dark mode’ or ‘always use light mode’. Just trust the OS/browser and use whatever setting it sends to the web page. Don’t waste the effort and screen real estate to add in a redundant widget/toggle. It’s handled already. Easier for everyone—it Just Works™!Unfortunately, the connection between ‘a year ago when I updated my Android phone and it asked me if I wanted to use the cool new dark mode, I said yes’ and ‘this webpage I am reading now is in dark mode for some reason, and I can’t change it back to normal???’, apparently winds up eluding some readers. (This is what Said’s sibling comment is about.) It winds up being “too much magic”.
The current toggle+
localStorage
+auto approach, on the other hand, while adding to the clutter, does not seem to confuse readers: “the page is in dark-mode, for some reason. But I want want light-mode and I am unhappy. I see a little light-mode button. I push that button. Now the page is in light-mode. I am happy.” (And then it is light-mode ever after.) At least, I have seen many fewer (or no) complaints about the dark mode being on when it shouldn’t be after we moved to the toggle. So as far as we can tell, it’s working.The main problem with your approach is not that it is counterintuitive (although it is, and more so than ours!), but that there is no way to return to “auto” mode via the site’s UI![1] Having clicked the mode selector, how do I go back to “no, just use my browser preference”? A two-state selector with a hidden, ephemeral third state, which cannot be retrieved once abandoned is, I’m afraid, the worst approach…
You can go into your browse’s dev tools and deleting the
localStorage
item, or clear all your saved data via the browser’s preferences. (Well, on desktop, anyway; on mobile—who knows? Not the former, at least, and how many mobile users even know about the latter? And the latter is anyhow an undesirable method!)Great point! I made this design choice back in April, so I wasn’t as aware of the implications of
localStorage
.Adds his 61st outstanding to-do item.