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!)
IIRC my site checks (in descending priority):
localStorageto 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
localStorageitem, 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.