In defense of two-state theme toggles

In case you haven’t kept up on the most recent bikeshedding discussion in frontend: there’s a lively debate going on over the merits of a simpler two-state theme toggle (light/dark), vs. a more explicit three-state toggle (with dark and light, plus a third “system” option), and whether the clarity of that third option is worth the additional complexity it introduces. But let’s back up to where this discussion started, and talk a little bit more about the details and tradeoffs those two approaches, before I start weighing in on what I think is (and is not) ideal, and why. The origins of the debate A couple of weeks ago, Lea Verou published an excellent post titled Dark mode toggles: two states are enough. (Evidently, this discussion had been ongoing for a good while prior.) The post is thorough and insightful. Dr. Verou lays out her case that a two-state is enough most of the time, in the case of a switch that’s part of the main site UI. That last part’s important: In most cases, users aren’t looking for that third “system” option, and aren’t likely to find it useful. They’re just looking for the light switch. There are, of course, exceptions. For example, in a dedicated settings page, where the mental model is less “what do I want right this second” and more “what do I want this app to be like in the future?” a three-state toggle makes more sense. Dr. Verou’s post makes this abundantly clear, and I tend to agree. Aside from the binary vs. trinary discussion: I find Dr. Verou’s two-state implementation particularly clever. 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. 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. Otherwise—or should the user toggle the theme once again—rather than storing the newly selected theme (which now once again matches their OS preference), the saved preference is simply deleted, causing the site to once again default to the device preference. This is important, because a common criticism of binary light/dark controls is that they lock you into one or the other, with no way to get back to your system preference; this two-state toggle neatly avoids that lock-in. A couple of other points made in the post: With a three-way toggle, at any given time, two of the three options will do the same thing. This is a bit redundant, and creates at least some complexity by offering users more choice than they might want (or even understand; more on that in a bit). This is not a one-size-fits-all implementation. I know I’m already repeating myself here, but many seem to overlook this point. The argument for two-state is subject to context. I keep harping on that because it seems like it gets lost in the conversation. 1 The pushback against a two-state implementation—despite the aforementioned caveats and nuances—has seemed loud and severe, at least in my circles of the web. Some in the frontend community seem to feel denying users that third option is something akin to malpractice; a choice that nobody who truly cares about users could possibly make. 2 Perhaps the most visible rebuttal is Bramus’s The Case for Tri-State Dark Mode Toggles. That post does a serviceable job making its titular case (despite the irony that the site that post is published on offers no theming or theme toggle at all), so it’ll serve as my focus for addressing the dissenting opinion. Addressing the case for tri-state theme toggles Almost all arguments against the two-state toggle and in favor of a three-state option boil down to one of two concerns: Favoring clarity over simplicity; or Accounting for users who might have a dynamic system theme, which changes between light and dark mode based on time of day. The first point is valid, even if I personally believe the tradeoff is worthwhile in most cases (with the caveats already mentioned). It’s possible some users might want that choice, and it’s nice for them to have it if they do. Reasonable cases can be made both ways here, and—once again—context should affect the answer. Dynamic themes, however, seem like a bit of an extreme edge case to me. I say “edge case” because, while we don’t have data directly from Apple or other device vendors, what little we do know from independent surveys suggests a very small minority of users favor a dynamic theme. There’s good reason to think it’s likely a low single-digit percentage of users. 3 But remember: the two-state approach isn’t automatically an issue for those users. A two-state toggle doesn’t actually become a problem for users with a dynamic OS theme, except in the following case: Somebody with a dynamic theme enabled visits the site and decides to change the site’s theme manually They come back to the site later, after their dynamic theme has shifted between light and dark, and Upon that change, the theme is not what the user wants, and they want to change it again That’s a lot of conditions to build a UI around, and a user has to get through all of them before we’ve maybe got a problem. Even if we assume 10% of all users have a dynamic OS theme (which, again, is almost certainly an extreme overestimate), some portion of those users are dropping off at every step above. What we’re left with is quite likely very close to zero. And even in that case, let’s remember: the problem in question is literally one extra click, for whatever vanishingly tiny percentage of users remain at the end of all those logic gates. Now, to be clear: I do not advocate for ignoring a group of users simply because they’re in the minority. (That’s how a lot of accessibility failures happen, among other terrible outcomes.) That’s not what this is; don’t take this out of context. Some people have theme preferences for important reasons, like vision. One mode or the other simply doesn’t work for them. We should absolutely respect that. The difference in this case is: we’re not talking about something like ability, bandwidth, device power, or any other factors a user might not be able to control; we’re talking about a choice they made freely and independently. Further: we can safely assume this choice is not accessibility-related, as any user whose vision allows them to opt comfortably into both light and dark mode at varying times of the day clearly isn’t hindered by either one. (More likely, they’re merely concerned with screen brightness, or just variety.) And in a case where a small minority of users has explicitly opted in to an unusual experience, and, as a direct result of that uncommon choice, in certain circumstances, might make further choices that could cause them to encounter unexpected behavior, depending on what their expectations were to begin with—none of which is actually an issue for them, but merely a preference, resulting, worst-case, in a single extra click— Well, I have a very difficult time adding extra complexity for the other ~95% of users, based solely on that deep hole of what-ifs those users dug for for themselves in the first place. Personally: I suspect a user who wants their machine to alter the theme for them probably isn’t picky enough to change it in the first place. But even if they do, I have a hard time imagining that person being terribly surprised or interrupted simply by encountering one or the other, when they’re already used to both. Or, to put it more bluntly: I’m not sure real users actually have this problem. I think we’ve mostly invented it. Which actually brings me to my next point… “System” is unclear to many users It’s a common pitfall of human psychology that we imagine everyone thinks like we do. Finance people think everyone understands interest and investments; car people think everyone knows how to change their oil; developers think everyone obsesses over color themes. But I see little evidence of non-computer-nerd users caring nearly as much as we seem to. Many users have a preference, certainly, but I severely doubt most users think even a tiny fraction as much about theming as we do. Our curse of knowledge makes us forget not everyone knows everything we do about color themes. Many users likely don’t have any understanding of them at all. To test my theory, I asked my wife (who is not a developer, but who regularly uses a smartphone, an iPad, and a laptop) what color theme her phone is set to; light or dark. She had absolutely no idea. 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). I asked whether she has the same preference set for her other devices; she didn’t know that, either. Then I asked whether she’s ever pressed the button on a site or app to change to another color theme. She said no. Literally never. Basically: she knew light mode and dark mode both existed, and that was the entirety of her knowledge and experience on the topic, even as it pertained to her own preferences. Now, I acknowledge this is only one singular data point. I don’t for a moment pretend this is meaningful research, or imagine my wife happens to represent the majority of any user base. Users undoubtedly exist on a wide spectrum between her and, well, nerds who think about this stuff enough to write blog posts about it. (Ahem.) But still: 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! I suspect a non-trivial number of users probably aren’t even aware they have a default theme, simply because they’ve gotten so used to