I don't like dark mode. There are always lots of apps and websites that haven't adopted the color guidelines, so I'll frequently be snapping from dark black/grey to bright white, which is even harder on my eyes than just white all the time. Turning down screen brightness is better I think.
I really appreciate when an OS, app or site implements dark mode.
My OS comes by default in dark mode, I use VSCode with a dark theme, I set dark mode in apps that support it (twitter, reddit, gmail, etc). I have 2 monitors side by side (2560x1440 and 3440x1440) and it's really a lot of light to take in when there is no dark mode available.
I like to read a lot during night time, and it was hard not to get burning eyes after a couple of hours.
But I learned about toning down screen brightness as to not get headaches, then I learned about Redshift which it's been a real life---or should I say eyes?---saver.
In don't like dark mode because I find it slower to scan a large section of code and recognise some pattern I'm looking for.
The last time I mentioned this I got some downvotes so what I will say is that perception is one of the areas where just because someone may be one of the few to experience a phenomenon doesn't mean that they are incorrect. It's subjective!
In most cases just switching the color scheme will slow you down. So going by that, if you spend enough time in dark mode, switching to light will also be slower.
Also, you can't just reuse the same colors for syntax highlighting in dark mode. Saturation needs to be turned down compared to light mode or everthing looks like a mess of colors.
Companies can also easily forget lessons previously learned. For example, Firefox's old dark theme was light grey text on dark grey background. Their current default dark theme is blazing white text on dark grey background. It's far less pleasant on the eyes.
My main annoyance these days is that Office doesn’t let you invert the colors of a document as a display option. You have to actually change the background and text colors of the document.
I wish operating systems had a feature to invert the colors in a single window/app, as a fallback for when an application doesn’t have a dark mode.
I've tried Dark Reader and a few other similar extensions and found that they caused my fan to regularly spin up (2017 MBP, running Brave browser). Am I doing something wrong, or is this a common experience?
For years a new Chrome window would flash white regardless of any extensions or settings. Following the issue it seemed to almost be fundamental to how rendering is done. Does it still do that?
On the other hand it's not as easy to adjust brightness on desktop monitors so I appreciate having the option either way.
Software brightness control on desktop monitors is something I've wanted for a while. Closest thing I've seen is a monitor with a built in light sensor that has the option of auto adjusting independent of the computer.
It has long been possible to adjust the brightness of monitors through software. The trouble is that laptop displays and external displays do it in two different ways, and the external monitor one is pretty much unknown and unused by normal software.
Taking my laptop as an example: Windows has two APIs for adjusting screen brightness, one of which only works for the internal display and one of which only works for external displays; and sadly the brightness keys on the laptop are uninterceptable and I have not come up with any way of linking the brightnesses either. I went hunting and settled on some old freeware called ScreenBright which I can invoke from the command line, so that now I just run `b 0` for night time and `b 40` for most of the day (and up to 70% in certain seasons—but 100% is pretty much always too bright where I use my external displays). Since I arranged that workflow, I have also written a tiny Rust program that interacts with the APIs directly which could replace it.
>and sadly the brightness keys on the laptop are uninterceptable
This doesn't seem to be true for most laptops. The ones I have used show a OS graphic when you turn the brightness down similar to the volume. Have tested this using linux on a dell xps and a macbook.
Unfortunately both still do not adjust the brightness of external monitors.
On my previous laptop I ran Arch Linux with i3, and handled the XF86Brightness keys myself. But at present I’m using Windows, and I haven’t found any means of intercepting the keys: Windows handles them in some way that prevents me from handling them myself.
Is this still not common? I have an Apple Cinema Display from 15 years ago and it has both hardware brightness controls (on the right edge), and software brightness control (keyboard f-keys, labeled as such on Apple keyboards).
It's been a very long time since I used a monitor with any sort of rotating dial.
The trend for decades now has been to have buttons only, and often there's a menu you have to navigate through in order to actually get to the brightness settings. It's a real hassle on many monitors.
So I configure light mode (black text, white background) everywhere, then I use NegativeScreen for Windows to invert colors.
Bonus: you can also setup a transformation matrix to convert all brightness to red, giving you a red-on-black mode for use at night.
This is the only reliable way I know to get a perfect dark mode everywhere (in outlook, terminal, notepad...) as many apps don't support dark mode or have some half-assed support, but all of them have light mode now that the start menu also has light colors support
(One exception on android: samsung browser get special mention for its dark-mode that applies to all pictures)
Could you clarify what this means on a monitor? It looks great in photos, but if I have light text on a dark background, I don't want to replace that with dark background, dark text, and a halo between the two.
More broadly, my experience is just that I can accept higher contrasts in dark-on-light than the reverse. TextEdit light is 0 on 255, and I find it slightly harsh in some lighting. TextEdit dark is only 255 on 30, and even that's enough to be consistently annoying. Sublime's ~248 on ~40 is way more usable for me.
Thanks, interesting! I think I misunderstood the initial comment as somehow back-lighting the inside of a window to highlight text, which confused me.
Now that I see what you mean, this is definitely better - the grey-on-black windowing of the original link is far less clear than backlighting each pane.
It's a lovely picture, but I can't help but feel that a concrete example with actual windows would be more informative. Do you do this? Can we see a screenshot of your desktop?
I don't know about Apple-land, but if we're going for generic advice, I'm in favor of black on mobile, because it not only doesn't ghost purple on AMOLED screens, it saves battery life in a very visible way.
It also looks extremely weird if you look at the screen from too much of an angle. Almost like a negative, but not really reverse colours. Maybe anti-solarized.
A while back, I remember people were writing subtle watermarks that took advantage of that effect. Straight-on everything looked normal. On a wide enough angle, the logo was pretty unmistakable.
They only do this because the iOS UI uses darkening to indicate depth, with no alternatives for dark mode - it has to be something other than pure black or there's nothing to darken. It's a band-aid.
Well you can have "Shadows" in dark mode, though they would have to be shadows made of white or light grey rather than black at least that is how I usually do it.
Not sure how you would accomplish this in IOS, never done IOS development.
Shadows in dark mode is an interesting design topic.
Experimenting quickly gets to you 'inconsistencies' with well-known principles that work in light mode, otherwise simply the 'full color scale' so to speak. It goes to show that light/dark mode cannot be a symmetry, it's a chiral* transformation of the color space.
[* chiral is my way of saying it's like left/right, the two spaces do not map directions the same, e.g. "from object color towards absence of color", what we call a shadow, should theoretically remain the same direction in any "mode"; e.g. a 'lighter shadow' feels unnatural, and feels more like a 'highlight'.]
My personal take is that dark mode lends itself very badly to using black as the 'normal' / background color; it produces too much contrast if you want colors to be decently saturated, and doesn't leave any room 'beyond' (darker than back is impossible) for things like shadows or a "depth effect".
Thus dark grey is the way to go usually; and most of the usual rules of 'light modes' apply (shadows to black, highlight 'lighter', invertable selections etc; the only meaningful remaining changes are thus related to fonts, whose 'Light' parameter l becomes its complementary k in the n-bit range (typically k = 2⁸-l). And you'd usually slightly darken or desaturate colors in general to reduce contrast for eye comfort.
You essentially retrieve a 'full color scale' space to work with, you're no longer bound to >50% light for anything that should be visible.
It's a really interesting topic, I find. Speaking as programmer with no design background nor particular talent. (just a demanding taste for aesthetics I guess)
Not sure how iOS does it either, since shadows are not the best in dark mode, Android has opted to use lighter shades for the upper layers when in this mode.
Basically if you use pure black for the background, it will be #000000 if elevation = 0 and get slowly lighter from there for each dp of elevation.
Lots of varied, interesting opinions in this thread. For fans of dark mode, there is a Firefox extension that lets you customise colors of every element, and process the CSS in different ways. Been using it for a few years now, and I prefer it to the Dark Reader extension that Firefox recommends.
Using such pre-created styles is a lot faster, easier, and more convenient than manually customizing each and every element by hand yourself.
Knowing how to do that is, of course, a good skill to have when you actually do want to do something custom for which a pre-rolled style does not exist or when existing styles do something you don't like.
How about don't use blue text against a black background? Blue is the hardest color for our eyes to focus on and, personally, I do find it harder to read blue text on black than, say, gray on black.
After Apple announced Dark Mode, I called up the dev who builds my startup's iOS app. We already had some dark-mode-like features in the app, but with this I was excited to make it global. Then he told me that if we want our iOS 13 users to be able to have a Dark Mode that is tied to the iOS 13 flag, users who are on iOS 12 or earlier. This killed the idea for me — I don't want to force people to upgrade from 12 to 13 (which has many bugs still), and I certainly don't want to cause problems for people with devices that are not supported by iOS 13.
I really wish Apple made it possible to give access to this feature without cutting off a significant portion of iOS users (including pretty much all schools, which are critical for us). Existing users can't upgrade, but new purchasers wouldn't be able to download at all.
I don't think this is true... Apps below iOS 13 won't be able to use the new system-defined UIColors, yes, and users below iOS 13 can't change to the dark-mode using a switch in the Control Center, yes.
But you've been able to change the "user interface style" for view controllers since iOS 12 [0]. And you've been able to add UIColors to asset catalogs that change depending on that setting since iOS 12 as well.
I'll be honest, I haven't tried this myself. But either this works or Apple's documentation is wrong.
Some apps (Narwhal) give the option to have a dark mode for iOS 12 as well as a UI switch to "Sync night and iOS dark Mode". This is nice because you could give it to pre-ios13 apps, while allowing for ios13+ to have it permanently dark or sync with the global ios setting.
Building out a dark mode in your app has been readily possible for a long time now. You could've done it years ago.
But you like the idea of it being "global"? You mean, integrated with the rest of the OS, so that when the OS is in dark mode, your app is in dark mode? And you somehow want Apple to introduce that feature without introducing a new version of the OS? How does that work?
Yes, global in the sense that it ties in with the OS flag. I understand that they have to release a new version of the OS to make that possible, but the understanding conveyed by my dev (who may be mistaken) is that we cannot enable this feature without making the app incompatible with prior versions of the OS. Others have indicated that we can in fact do this, which would be great. I've run into enough odd upgrade-forcing-functions recently on iOS/MacOS that what my dev reported seemed believable (if disappointing).
Let's be honest, dark mode is only necessitated by the whole flat design trend which uses glaringly bright whites and stark interfaces.
The flat design trend is so tired, it never looked good, and it promotes bad UX/UI. That has always been my opinion and it has grown only stronger as more bandaids like 'dark mode' are slapped onto it.
Flat Design is really "Swiss Design" or "International Style", which came about mid-twentieth-century. The usability issues are typically around lack of affordances – e.g., how do I, as a user, know what's tappable if everything is flat. Using color very intentionally is one approach.
Dark mode is an accessibility issue. Yes, flat designs can exacerbate the issue – white space being a primary design pattern – but having a dark mode version of something would still be desirable, even if we went back to skeuomorphic design.
Let's not forget there were many light, medium, and dark interfaces before the flat design trend took over UI, but since those pre-flat interfaces were almost always built around usability rather than some stark design theory, they were user friendly, worked, looked fine, were obvious, and were almost never harsh on the eyes.
> Let's not forget there were many light, medium, and dark interfaces before the flat design trend took over UI, but since those pre-flat interfaces were almost always built around usability rather than some stark design theory, they were user friendly, worked, looked fine, were obvious, and were almost never harsh on the eyes.
This might be sarcasm, but if not:
Some highlights of counterexamples include...
The Office Ribbon
Winamp
Windows Media Player
Kai's Power Tools
QuickTime Player 4
Geocities websites
Flash websites
While I have always been skeptical of "flat" designs, I'm not so sure that "dark mode" is a bandaid. I think it's something needed on its own, but flat designs just happen to be caught up in the mix.
White-background designs are really just a hold-over from design approaches developed for paper. Whereas white is a default color for paper, it never was on CRTs, and isn't on OLED displays either. The design choice was mostly an implicit (or habitual) emulation of paper.
There are both hardware and ocular reasons why dark backgrounds are advantageous on screens, particularly mobile OLEDs. Power consumption, eye fatigue, contrast, durability, etc. We need to make some of these changes regardless of artistic design style.
You may be right that dark modes are advantageous for some people, but please don't assume that this is true for everyone.
In particular, dark modes may become more difficult as you get older. I'm 67 and I have a great deal of trouble reading text in a dark mode.
There is a physiological reason for this, and if you do any photography using manual aperture control you may be familiar with it. Very high quality lenses should be sharp whether the iris is wide open or stopped down. But mediocre lenses have trouble wide open and give better sharpness stopped down to a more narrow aperture.
As you get older, the lenses in your eyes are not as good as they were when you were younger. There is a benefit in sharpness to have your irises stopped down instead of wide open.
Light modes accomplish this. The background light naturally triggers your irises to stop down, resulting in a sharper and more detailed view.
Dark modes encourage your irises to open wider, reducing your visual acuity.
Of course many people do enjoy dark modes, so there will never be a way to please everyone! But please consider not making dark mode your only mode.
Normally the thing that prevents higher refresh rates in PWM is the time constant. Considering OLED has a response time of a few microseconds. You could probably get away with a 1-2 kHz strobe without adding a noticeable amount of blur.
What I want to see is higher refresh rates to avoid apparent blur from sample and old.
Terminals and IDEs predated flat design by decades, and yet darker themes have always been around for those. I really don't think dark mode is merely a response to flat design.
Terminals have almost always been dark mode. MS DOS is a great example of a very popular OS that was fully dark mode. Or any installation of Unix or Linux without a window manager. Tying it to flat-design just sounds like a lack of familiarity with the history of computer interface design.
I really miss Kaleidoscope. No OS theming system I’ve come across since has been as smooth and all-encompassing — WinXP/Win7 msstyles and the various themeable bits in a Linux desktop come closest, but still fall short because they’re often incomplete and using them is a multi-step process.
With Kaleidoscope, you just double-clicked the scheme file in the Finder and _everything_ was themed, from window frames to buttons to fonts to icons, and there were practically no limits to what scheme designers could do. There were a lot of impractical schemes, sure, but they were creative, fun, and personal in a way computer UI hasn’t been in ages. Just take scroll through the tweets of this Kaleidoscope twitter bot for a taste: https://mobile.twitter.com/kaleidoscopemac
