> One of the most common UX mistakes is designing UI around the underlying data model instead of user goals.
It's far worse to give users a false mental model of the system. If the underlying system is complex, but that's out of your control, then it will create confusion and frustration in users to paper over it. Please don't do this!
That is, unless you can create a nearly leak-free abstraction. The example given in the article is anything but leak-free.
(This kind of design error reminds me of the skeuomorphism debate nearly a decade ago. Leaky abstractions and false affordances both give users an incorrect mental model of the system.)
And, if you have control of your data model, then your first priority should be designing the data model around user goals -- this is where good abstractions should live, not in the presentation layer.
Then you can align the UI closely to the data model.
(This is probably a decent summary of the core domain-driven design principles.)
Especially, don't do this for interactions that aren't core to your business. Under the real world constraints where I work, this kind of design thinking causes non-core features to explode in complexity, cost, etc.
hard agree. the issue here is that it tries to implement user goals but based on something other than asking the user and then respecting their choice. that becomes guessing at the user's goal, never confirming, and then acting on that goal anyway. the end result is that i as the user am presented with options and there's no map between what option i pick and what the behavior of the app actually is.
The most important thing is to default to the user’s system setting.
Then you (and your users) only need the toggle, if at all, for edge cases.
(If the user cares, they likely will have set system settings the way they like them, and if they don’t care to, it’s pretty unlikely your web site is special to them. It would really just be for users who care but are somehow forced to use a system that doesn’t support the settings they want, and for dev/testing.)
But I agree with the conclusion of the article. If you do have a toggle, it makes more sense to just have the two options. Users click it to say, “I want it the other way right now.” After that, it makes a lot more sense to assume they want it to keep being the way they want than not. And how do you know what that is? Because they’ve taken the time to specify that in the system settings. Or they haven’t. Because they didn’t care to. In which case you still aren’t doing something they didn’t want.
A UI where you just whack it until it does what you want (and then keeps doing it) is perfect for we tailless monkeys. One where you have to stop what you’re doing to think about your previous life choices and whether you ought to continue to make them is maybe a little too much for each web site.
I might be missing something, I read both articles and do not understand the issue with 3 options. People interact with the theme change maybe once a year or so, a tiny amount of friction in that case is a non issue if that makes it simpler for the user to actually set the theme value they want (system default, light, dark). It really feels that they started with the idea that it should be 2 options, then try to come up with an argument
Their argument is that the user almost always experiences the moment of interaction with the controls as a single decision with 2 branches, (a) the OS behavior matches my expectations and I won't change it, and (b) the OS behavior violates my expectations and I want it to be the other one.
I'd also rather just select from the full tristate diagram, but their framing also makes sense to me
> Why does every website even need to provide its own toggle in the first place?
You can use the automatic value. Some people expect to change the colors of your site without changing their system colors, but you are free to just ignore them.
> How often do people use these, really?
Most normal people don't think about it. Depends on your audience.
But usually more people use them than know how to change their system colors.
> I don't get the "everything needs to support dark theme" thing either tbh
Again, most people don't think about that. Depends on your audience.
Eh, I personally like the light theme better. But if others would decide that I too shall ever only perceive bright text on dark background, I guess I could live with that as well.
Isn't the actually-simple answer here "Pick a default. If the user agent specifies a preference, respect it."
Now there's no UX, it just does something reasonable regardless, and if the user has already opted in to color mode management, it respects their declared choice.
Users who are power user enough to want to override their light/dark mode setting per-site can use a browser extension to let them do exactly that on the websites they want to target.
Letting the system do things for the user is risky enough. Taking away the unambiguous way to turn the automatism on and off just adds insult to injury. This suggestion is not simplification, it is complication.
Personally I'm totally fine with light/dark/auto but if you really must simplify I see only two true ways:
1. Just offer light and dark. No auto. Whether auto works is out of your control anyway. Users who know and want auto have to switch manually.
2. Just offer auto on/off. Default is off and off is light mode. User who want dark mode will figure out how to configure their system.
this all seems to fall into trap of most UI design writing, where people write blog posts about what users want, what users think, and what users understand, without actually doing any user testing.
unlike everybody else in this comment section, i like the two-mode toggle. but that's just my opinion. without user testing numbers, an article saying "users like this better" is useless.
But...there is a solution that works (although it may be a bit confusing at first).
A toggle with two buttons, dark and light. Both cannot be pressed at the same time, but both can be unpressed at the same time. That's the auto mode, and the ui can be tweaked to show a little label in between or below.
In auto, none of the buttons is pressed (and preferable a small label that says auto is shown). Pressing dark/light will force that mode, enable that button and remove the auto label.
In dark/light mode, you can press the other button to enable the other state. Or you can press the current button to disable it, and switch to auto. This last one is the confusing-at-first interaction, but makes sense if you think about it (it's like saying: I want dark / I want light / I don't care)
If you have to preface an idea about its potential confusing nature, that should be a warning that it might not best serve your users.
In my opinion, the existing UI widget that solves this problem best is a plain old group of radio buttons (auto, light, dark). Two checkboxes that interact with each other and also a sometimes-hidden label is something new for users to learn and also more complex to implement and maintain.
Imagine thinking your website is important enough to have its own settings UI lol
> “Whatever the system says” is not just one extra option. It’s also one extra weird option. It doesn’t feel like the other two.
It's wrong to conflate the `prefer-color-scheme` media query with “What the system says”, meaning the OS-level dark/light option. For most people this is probably true, but I prefer sites that work this way because I use two Firefox extensions to set it globally or on a per-site basis regardless of what my OS is set to.
As a user, I find the three "dark", "light", "auto" button situation way less complex then a toggle that keeps its state only if my choice does not align with system default.
Thanks, I missed that! But then I don't understand why a seasoned designer purposely suggests that ignoring it might be good for the user, especially since light/dark theme toggle is for a small fraction of the people who genuinely care about the theme being "right for them" and not just whatever.
Even in the 1990s, developers of the HID specification knew that the keyboard pictured at the bottom of the article was wrong. They wrote in the power management spec that interface devices should conditionally send wake events, and that a dedicated wake key was not necessary. Microsoft said:
"For example, a keyboard could include a special-purpose power management button (for example, “Power”) that, when pressed during a system sleeping state, generates a wake event. Alternatively, the button(s) on mice and other pointing devices could be used to trigger a wake event. "
Imagine the user confusion when he sets the interface in light mode and a couple of minutes later this changes automatically to dark mode because sun sets.
I think this is exactly the trap of imaginaryness the author is talking about.
For this scenario to unfold the following has to happen:
1. OS is set to auto mode
2. It's late afternoon
3. User finds they have (for some reason) in the past turned on the Website dark mode (presumably in the daytime)
4. User wants it light now.
This is a pretty tortured hypothetical though. I admit as an engineer, who understands that there's a light/dark signal being passed down, and there's an ability to override that signal, I appreciate separating the "should override" control the way a "3-way" switch allows.
But I have to admit, I cannot imagine a real person getting bit in any way by the implementation the author describes. 90% of people set their OS to the "mode" they want, whether it's full-time or sun-based, and that group never even needs to touch or look at this control (We do default to auto, right?). The other 10% are most likely here because they don't understand they can set this in the OS and they apparently want to toggle to the opposite mode. They might be thinking "I want this dark mode until morning" but "we" in the website actually can't really help them with that unless we start prying into what time it is there and build our own time-based mode. So the best we can do for that user is to shift them into "latched dark mode" and let them come back (as they've demonstrated a knowledge to do) when and if they want the 'lights' back on.
I'm the first to criticize UI designers who rob users of choice in the name of minimalism -- the Alan Dye approach, but this actually screams "Designer thought hard about the actual intent of the users" to me and I like it.
You say that that this kind of thing is imaginary, but something like it must be happening when I repeatedly find that a given website/app is in the wrong mode, even though I feel like I've had to switch it before. This is not even a particularly uncommon experience when working with several apps or sites that have the choice, because it's not uncommon for one of those settings to be basically unreadable in some conditions or with font/color choices, etc.
For reasons (I work for one company, but our work is for both ourselves and sometimes in partnership with others), I often end up with two (or more) instances of certain sites and apps (like two organizational Gitlab instances). To make my life easier, I pick one to be dark and one to be light by default so I can tell at a glance "Ah, this is my corp version, and this other is for some customer". My system also uses automatic dark/light switching.
If I'm setting this up during the day, when I normally work, those external sites would easily end up with the "auto" behavior by this very poor design in the blog, when that is not my actual intent. This would result in me having to set it twice (the second time in the evening) to have my desired behavior which is a nuisance. The explicit option is better here, not whatever this silliness is in the article. [0]
At least I've read this article so sites and apps using this stupid option wouldn't be too big of a surprise to me, I'd hate to have to explain this to other people who haven't read it though. Principle of least surprise is a good thing, not something to deliberately work against like this author wants.
EDIT:
[0] Actually, this demonstrates a crucial flaw in the system's design. If I want to set the current default as the permanent setting, I have to wait until a particular time of day to do so. That's even worse than I'd previously realized. You can only set permanent light in the evening (or by changing your OS/browser settings, changing the site, and then changing OS/browser back). You can only set permanent dark during the day (without that same stupid exercise).
But this means you're "abusing" dark/light mode to signal unrelated information. If some visual customization (theme, font size, etc.) happens to allow you to do something like that, then of course more power to you, but I don't think it has any relevance to the design of the thing itself. It just seems unreasonable to me to expect designers to consider all the ways their designs could do double-duty for any given user (cf. "every change breaks someone's workflow").
I was just supplying one reason for changing it, other people may just prefer some particular site or application in light mode versus dark (and vice versa) instead of managing multiple instances of the same thing like I am. Suppose you're editing documents and your word processor has dark mode, but you want it to always be in light mode. With the described control in the article you would have to change the behavior in the evening, specifically, to get it to stay in light mode permanently (or change your system settings to be opposite your normal settings, switch it to light, and then switch your system settings back).
There is no way any one with any common sense can think that this two-choice option (one is magic, one does what you would expect; which is which depends on time of day for many users) is better than a three-choice option where each choice does exactly what you'd expect.
this is wildly anti-user and turns a preference->behavior mapping of
dark -> dark
light -> light
os preference -> os preference
into
dark -> impossible to know with just this info
light -> impossible to know with just this info
os preference -> impossible to set via the app
if you absolutely have to account for the third case, then you need an explicit option for it and should be able to tell the user what their current os preference is. all the information i need to make a decision should be present in the interface, and the underlying code should do what the fuck i tell it to, not what it thinks i meant.
> One of the most common UX mistakes is designing UI around the underlying data model instead of user goals.
It's far worse to give users a false mental model of the system. If the underlying system is complex, but that's out of your control, then it will create confusion and frustration in users to paper over it. Please don't do this!
That is, unless you can create a nearly leak-free abstraction. The example given in the article is anything but leak-free.
(This kind of design error reminds me of the skeuomorphism debate nearly a decade ago. Leaky abstractions and false affordances both give users an incorrect mental model of the system.)
And, if you have control of your data model, then your first priority should be designing the data model around user goals -- this is where good abstractions should live, not in the presentation layer.
Then you can align the UI closely to the data model.
(This is probably a decent summary of the core domain-driven design principles.)
Especially, don't do this for interactions that aren't core to your business. Under the real world constraints where I work, this kind of design thinking causes non-core features to explode in complexity, cost, etc.
Spend your complexity where it has an impact!
hard agree. the issue here is that it tries to implement user goals but based on something other than asking the user and then respecting their choice. that becomes guessing at the user's goal, never confirming, and then acting on that goal anyway. the end result is that i as the user am presented with options and there's no map between what option i pick and what the behavior of the app actually is.
There’s no better way to ruin usability than to hide how the system actually works in an effort to make it “easier”.
Make it as simple as possible, but no simpler. Anything else is deceptive.
The most important thing is to default to the user’s system setting.
Then you (and your users) only need the toggle, if at all, for edge cases.
(If the user cares, they likely will have set system settings the way they like them, and if they don’t care to, it’s pretty unlikely your web site is special to them. It would really just be for users who care but are somehow forced to use a system that doesn’t support the settings they want, and for dev/testing.)
But I agree with the conclusion of the article. If you do have a toggle, it makes more sense to just have the two options. Users click it to say, “I want it the other way right now.” After that, it makes a lot more sense to assume they want it to keep being the way they want than not. And how do you know what that is? Because they’ve taken the time to specify that in the system settings. Or they haven’t. Because they didn’t care to. In which case you still aren’t doing something they didn’t want.
A UI where you just whack it until it does what you want (and then keeps doing it) is perfect for we tailless monkeys. One where you have to stop what you’re doing to think about your previous life choices and whether you ought to continue to make them is maybe a little too much for each web site.
I might be missing something, I read both articles and do not understand the issue with 3 options. People interact with the theme change maybe once a year or so, a tiny amount of friction in that case is a non issue if that makes it simpler for the user to actually set the theme value they want (system default, light, dark). It really feels that they started with the idea that it should be 2 options, then try to come up with an argument
Their argument is that the user almost always experiences the moment of interaction with the controls as a single decision with 2 branches, (a) the OS behavior matches my expectations and I won't change it, and (b) the OS behavior violates my expectations and I want it to be the other one.
I'd also rather just select from the full tristate diagram, but their framing also makes sense to me
Why does every website even need to provide its own toggle in the first place? How often do people use these, really?
(I don't get the "everything needs to support dark theme" thing either tbh)
> Why does every website even need to provide its own toggle in the first place?
You can use the automatic value. Some people expect to change the colors of your site without changing their system colors, but you are free to just ignore them.
> How often do people use these, really?
Most normal people don't think about it. Depends on your audience.
But usually more people use them than know how to change their system colors.
> I don't get the "everything needs to support dark theme" thing either tbh
Again, most people don't think about that. Depends on your audience.
I agree with you.
Except I don't see why anything needs to support a light theme.
Eh, I personally like the light theme better. But if others would decide that I too shall ever only perceive bright text on dark background, I guess I could live with that as well.
Isn't the actually-simple answer here "Pick a default. If the user agent specifies a preference, respect it."
Now there's no UX, it just does something reasonable regardless, and if the user has already opted in to color mode management, it respects their declared choice.
Users who are power user enough to want to override their light/dark mode setting per-site can use a browser extension to let them do exactly that on the websites they want to target.
Am I missing something?
Letting the system do things for the user is risky enough. Taking away the unambiguous way to turn the automatism on and off just adds insult to injury. This suggestion is not simplification, it is complication.
Personally I'm totally fine with light/dark/auto but if you really must simplify I see only two true ways:
1. Just offer light and dark. No auto. Whether auto works is out of your control anyway. Users who know and want auto have to switch manually.
2. Just offer auto on/off. Default is off and off is light mode. User who want dark mode will figure out how to configure their system.
this all seems to fall into trap of most UI design writing, where people write blog posts about what users want, what users think, and what users understand, without actually doing any user testing.
unlike everybody else in this comment section, i like the two-mode toggle. but that's just my opinion. without user testing numbers, an article saying "users like this better" is useless.
But...there is a solution that works (although it may be a bit confusing at first). A toggle with two buttons, dark and light. Both cannot be pressed at the same time, but both can be unpressed at the same time. That's the auto mode, and the ui can be tweaked to show a little label in between or below.
In auto, none of the buttons is pressed (and preferable a small label that says auto is shown). Pressing dark/light will force that mode, enable that button and remove the auto label.
In dark/light mode, you can press the other button to enable the other state. Or you can press the current button to disable it, and switch to auto. This last one is the confusing-at-first interaction, but makes sense if you think about it (it's like saying: I want dark / I want light / I don't care)
If you have to preface an idea about its potential confusing nature, that should be a warning that it might not best serve your users.
In my opinion, the existing UI widget that solves this problem best is a plain old group of radio buttons (auto, light, dark). Two checkboxes that interact with each other and also a sometimes-hidden label is something new for users to learn and also more complex to implement and maintain.
New requirement just dropped: "Switch to light mode during more than 50% solar eclipse".
Imagine thinking your website is important enough to have its own settings UI lol
> “Whatever the system says” is not just one extra option. It’s also one extra weird option. It doesn’t feel like the other two.
It's wrong to conflate the `prefer-color-scheme` media query with “What the system says”, meaning the OS-level dark/light option. For most people this is probably true, but I prefer sites that work this way because I use two Firefox extensions to set it globally or on a per-site basis regardless of what my OS is set to.
- https://addons.mozilla.org/en-US/firefox/addon/toggle-dark-m...
- https://addons.mozilla.org/en-US/firefox/addon/darkreader/
Strongly believing it should only be two is symptomatic of the worst ideas in UX/UI. Pretty much one of those tiny steps toward "Idiocracy."
Do not hide what the machine is doing from the user in this way, this is how so many of the bad things happen.
As a user, I find the three "dark", "light", "auto" button situation way less complex then a toggle that keeps its state only if my choice does not align with system default.
Both Marcin and Lea are ignoring users who have automatic sunset-to-sunrise dark theme switching.
This is not a novelty but a built-in feature called “Auto” Appearance in MacOS, iOS, iPadOS. Similar feature exists in Android and KDE.
It’s in TFA, just a few sentences in.
Isn’t the article about how to best deal with the UI for letting the user indicate that the system should decide? Which covers your case.
Thanks, I missed that! But then I don't understand why a seasoned designer purposely suggests that ignoring it might be good for the user, especially since light/dark theme toggle is for a small fraction of the people who genuinely care about the theme being "right for them" and not just whatever.
Even in the 1990s, developers of the HID specification knew that the keyboard pictured at the bottom of the article was wrong. They wrote in the power management spec that interface devices should conditionally send wake events, and that a dedicated wake key was not necessary. Microsoft said:
"For example, a keyboard could include a special-purpose power management button (for example, “Power”) that, when pressed during a system sleeping state, generates a wake event. Alternatively, the button(s) on mice and other pointing devices could be used to trigger a wake event. "
Surely the toggle is "system setting is what I want" or the inverse?
That's a CSS @media not
Well, that's pretty damned moronic, is what that is.
Imagine the user confusion when he sets the interface in light mode and a couple of minutes later this changes automatically to dark mode because sun sets.
I think this is exactly the trap of imaginaryness the author is talking about.
For this scenario to unfold the following has to happen:
1. OS is set to auto mode 2. It's late afternoon 3. User finds they have (for some reason) in the past turned on the Website dark mode (presumably in the daytime) 4. User wants it light now.
This is a pretty tortured hypothetical though. I admit as an engineer, who understands that there's a light/dark signal being passed down, and there's an ability to override that signal, I appreciate separating the "should override" control the way a "3-way" switch allows.
But I have to admit, I cannot imagine a real person getting bit in any way by the implementation the author describes. 90% of people set their OS to the "mode" they want, whether it's full-time or sun-based, and that group never even needs to touch or look at this control (We do default to auto, right?). The other 10% are most likely here because they don't understand they can set this in the OS and they apparently want to toggle to the opposite mode. They might be thinking "I want this dark mode until morning" but "we" in the website actually can't really help them with that unless we start prying into what time it is there and build our own time-based mode. So the best we can do for that user is to shift them into "latched dark mode" and let them come back (as they've demonstrated a knowledge to do) when and if they want the 'lights' back on.
I'm the first to criticize UI designers who rob users of choice in the name of minimalism -- the Alan Dye approach, but this actually screams "Designer thought hard about the actual intent of the users" to me and I like it.
You say that that this kind of thing is imaginary, but something like it must be happening when I repeatedly find that a given website/app is in the wrong mode, even though I feel like I've had to switch it before. This is not even a particularly uncommon experience when working with several apps or sites that have the choice, because it's not uncommon for one of those settings to be basically unreadable in some conditions or with font/color choices, etc.
For reasons (I work for one company, but our work is for both ourselves and sometimes in partnership with others), I often end up with two (or more) instances of certain sites and apps (like two organizational Gitlab instances). To make my life easier, I pick one to be dark and one to be light by default so I can tell at a glance "Ah, this is my corp version, and this other is for some customer". My system also uses automatic dark/light switching.
If I'm setting this up during the day, when I normally work, those external sites would easily end up with the "auto" behavior by this very poor design in the blog, when that is not my actual intent. This would result in me having to set it twice (the second time in the evening) to have my desired behavior which is a nuisance. The explicit option is better here, not whatever this silliness is in the article. [0]
At least I've read this article so sites and apps using this stupid option wouldn't be too big of a surprise to me, I'd hate to have to explain this to other people who haven't read it though. Principle of least surprise is a good thing, not something to deliberately work against like this author wants.
EDIT:
[0] Actually, this demonstrates a crucial flaw in the system's design. If I want to set the current default as the permanent setting, I have to wait until a particular time of day to do so. That's even worse than I'd previously realized. You can only set permanent light in the evening (or by changing your OS/browser settings, changing the site, and then changing OS/browser back). You can only set permanent dark during the day (without that same stupid exercise).
This is a terrible design concept.
But this means you're "abusing" dark/light mode to signal unrelated information. If some visual customization (theme, font size, etc.) happens to allow you to do something like that, then of course more power to you, but I don't think it has any relevance to the design of the thing itself. It just seems unreasonable to me to expect designers to consider all the ways their designs could do double-duty for any given user (cf. "every change breaks someone's workflow").
I was just supplying one reason for changing it, other people may just prefer some particular site or application in light mode versus dark (and vice versa) instead of managing multiple instances of the same thing like I am. Suppose you're editing documents and your word processor has dark mode, but you want it to always be in light mode. With the described control in the article you would have to change the behavior in the evening, specifically, to get it to stay in light mode permanently (or change your system settings to be opposite your normal settings, switch it to light, and then switch your system settings back).
There is no way any one with any common sense can think that this two-choice option (one is magic, one does what you would expect; which is which depends on time of day for many users) is better than a three-choice option where each choice does exactly what you'd expect.
There are actually websites like that. It's... mostly fine, frankly, although a bit jarring.
this is wildly anti-user and turns a preference->behavior mapping of
dark -> dark
light -> light
os preference -> os preference
into
dark -> impossible to know with just this info
light -> impossible to know with just this info
os preference -> impossible to set via the app
if you absolutely have to account for the third case, then you need an explicit option for it and should be able to tell the user what their current os preference is. all the information i need to make a decision should be present in the interface, and the underlying code should do what the fuck i tell it to, not what it thinks i meant.