"Solving a largely imaginary user goal"
unsung.aresluna.org
unsung.aresluna.org
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. Though I do miss beautifully detailed app icons and overall whimsy, in-app false affordances and leaky abstractions both give users an incorrect mental model of the system.)
Spend your complexity where it has an impact!
That's probably a half-decent summary of domain-driven design.
Some examples that come to mind: - video games with their entity-component systems; - high-performance text editors like VS Code. [1]
[1] https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
Correctness and performance are normally the top user goals.
I suspect it’s an equally imagined user goal to simplify light/dark mode settings as it is to ensure users can explicitly set “system default”.
Make it as simple as possible, but no simpler. Anything else is deceptive.
I'd also rather just select from the full tristate diagram, but their framing also makes sense to me
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.
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.
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)
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.
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.
"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. "
Why the hell were those buttons needed to be on the keyboard anyway? I swear it started with one of those imaginary "my Ctrl key is hard to reach, so I hold the spacebar instead..." scenarios.
(I don't get the "everything needs to support dark theme" thing either tbh)
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.
Except I don't see why anything needs to support a light theme.
Astigmatism is very common, and not all astigmatism is corrected or correctable with glasses or contacts. Contacts, especially, are hit-and-miss for correcting astigmatism. Toric contacts, which are weighted to rotate into (hopefully) the correct position over the eye, are sometimes too uncomfortable or too unreliable (because they rotate out of position) compared to non-toric lenses. And besides, many people use their computer or phone without their glasses on/contacts in.
Additionally, dry eyes or other eye conditions can sometimes cause similar blurring issues with light text on dark backgrounds.
So, I ask that people please do include light mode options for accessibility. Even a half-assed implementation of light mode is better than none.
(If you insist on only supporting dark mode, low-contrast dark modes tend to be a bit better for astigmatism than AMOLED/true black dark modes. I suspect this might create problems for people who need high contrast in order to make out the text, however. I haven't looked into how well high contrast system modes function these days.)
I started my career when screens were black with text displayed using green/white/amber phosphor and was used to that. I never liked the bright white UIs when GUI based OS/front ends took over (before themes became a thing).
I find the wall of bright white with black/dark text tiring to look at. Collaborating with colleagues doing screen sharing where they don't use dark themes is really jarring.
It's almost an accessibility thing for me these days.
Do not hide what the machine is doing from the user in this way, this is how so many of the bad things happen.
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?
> “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/
This is not a novelty but a built-in feature called “Auto” Appearance in MacOS, iOS, iPadOS. Similar feature exists in Android and KDE.
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.
But still, the article continues to ignore that setting, doesn’t it?
The light/dark theme toggle is for a small fraction of the people who genuinely care about controlling the theme to be "right for them" and not just whatever.
With this, there will suddenly be a bazillion frustrated users who want to force an exception to their timed dark/light mode cycle, but can't because this proposed system hides how to do that. And even if they look up how to do it, they have to either wait for a specific time of day to make their change, or they have to temporarily change their system settings in order to change the program/website-specific setting.
Meanwhile, people who don't care or don't understand will just leave it on the default and probably not even look at the settings page. And everyone is used to seeing "system default" as an option at this point, anyway.
Net effect: no benefit, and some users now upset.
Why change what isn't broken?
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.
That's a CSS @media not
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.
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.
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.
Your whole objection here hinges on you coming to that realization during the day when it's already in light mode by default. The 99.9% likelihood of "When does a user decide to go looking for the dark/light settings?" is "when the current color != the color desired. For your above scenario you'd go in there the first time you used your word processor at night. You'd flip it exactly once, and it would do what you described you want - stay light forever.
Perhaps you're the kind of nerd like me who likes poking through and tweaking every available setting of an app proactively, just for fun... and I'd expect VS Code for instance, to be optimized for "us." But the vast majority of people would never go hunting for the setting to "make it always light" at the time when it's already light. The thesis here is that, for apps not designed for developers, it's probably more valuable to not have those who aren't nearly as expert have to wonder if they're picking the wrong choice by offering a third option.
In my experience, software that is designed to work only for the most average user ends up feeling terrible for most everybody, because most people deviate from the average in one way or another, at one time or another.
It feels especially bad when the software makes assumptions about what the user wants, to the point of including a button that doesn't always do the same thing when pressed, and which doesn't even tell the user it doesn't always do the same thing when pressed.
Just look at all the complaints Microsoft gets for the way Windows constantly reverts or ignores user settings.
Or the way it feels to google a very specific set of search terms, only to receive back 20 completely irrelevant listicles that answer a statistically more likely question you didn't ask.
The improvement for them is that when they get here and see "Dark, Light, System" with System selected, they wonder "What's System?" Is System important? Will I break something if I change it from System? Is this even the right setting or is this something else? If I want it changed back to Dark later, do I need to choose "System" or should I choose "Dark"? Will this have unexpected effects on my whole computer if I choose "System" in this webpage?
> including a button that doesn't always do the same thing when pressed
The non-engineer would say the "System" one "doesn't always do the same thing when pressed" and that the "Light" and "Dark" in the 2-way control absolutely always do the same (and desired) thing: Immediately change it to Light or Dark. The side-effect of saving it as an override is, to be fair, a guess at their intent, but it's a very good bet.