Hacker News Reader

> ...in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.

The color scheme editor actually worked quite nicely up until the release of Windows 2000 [0]. After that, Windows XP introduced the "Luna" visual style (Uxtheme.dll) with inflexible, hard-coded colors. Most software developers stopped caring about color palettes, and almost all applications started using hard-coded colors in their GUIs. They tested their apps with the few skins preinstalled with Windows XP: Blue, Olive Green, and Silver.

[0]: https://imgur.com/a/sXSETJC

The thing is, one of the most long-lived built-in schemes in Windows was "high-contrast black," which revealed most color-palette errors in applications.

>Way back in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.

It was barely usable. Many developers used the colors of the default theme no matter what. Others used the Windows-supplied colors for the background color and maybe the main foreground color, then used fixed, non-customizable colors for everything else, making everything invisible or hard to see if you used anything but a white-ish background. Trying to use what we now call dark mode was a big no. At best you could replace the wallpaper by an all-black screen so you feel a little less irradiated by your crt.

It worked quite well until skinz came in fashion, a self-inflicted issue.

Self-inflicted by who?

Developers who ignored proper color-palette practices.

In case you can’t see, VerifiedReports states:

“Developers who ignored proper color-palette practices.”

Agreed. Pls vouch for the comment.

"Barely usable?" WHAT was? The scheme editor was perfectly usable, for well over a decade.

"Many developers used the colors of the default theme no matter what"

Which is what they were supposed to do, resulting in usable software that honored the user's preferences. And developers didn't have to dick around with color palettes. Win/win.

"Others used the Windows-supplied colors for the background color and maybe the main foreground color, then used fixed, non-customizable colors for everything else, making everything invisible or hard to see if you used anything but a white-ish background"

Yep, some did. And? If developers issue defective software, the OS should be degraded? What's your point here? Let's say developers somehow mess up sound reproduction: Should the OS no longer support audio playback?

PulseAudio sez hi

Exactly this. Everyone used the default, we never thought about it, and all software looked the same. As a result, everything was consistent, you knew at a glance what everything was, and you could start using it right away. I miss that era, I feel like we've regressed, not least because we no longer have those underlined keyboard shortcuts on every single UI element.

It is quite similar on the Web still: web browsers (at least Firefox) allow to set user CSS or change default colors, but some websites (the percentage would vary defending on the method used) do not play nicely with that.

Likewise on Unix-like systems: most things can be covered with GTK and Qt themes, but some GUI programs would use a different GUI toolkit, and occasional developers would assume a dark-on-light theme, setting fixed colors accordingly.

Even TUI color interfaces suffer from that: when programs use colors outside of the 16 (that are rather practical to configure) or tweak (e.g., dim, reverse/invert) those for a particular kind of theme.

An annoying thing is that in most those cases things would have been fine if the developers simply did not touch colors. Even the linked article would have been more legible if it had no CSS, with either the usual defaults or a sensibly configured web browser: now it has a text-to-background contrast ratio slightly below the minimum of 7 recommended by WCAG.

I’ve always firmly believed that the user should have ultimate control over the color, fonts, and overall design of the applications on his system. Not the developer. The developer should just be able to say “this is text” and the OS should respect the user’s chosen text color. The developer should be able to say “this is a window” and the system decides how it’s styled. Every new OS release and every new browser release, we drift farther away from that ideal. If we respected the user’s preferences, we’d have a consistently styled workspace, and all our tools would look and feel like they belonged together.

Handing all of this control over look and feel to developers was a major mistake, and we pay for it over and over by having tools we keep having to re-learn, that look and function slightly differently from each other.

Exactly. That's what made the Windows scheme editor so great.

I never had a problem building my applications in Visual Studio to respect the system color scheme.

A nice example are epub files. I've basically disable all publisher styles from my reader, especially for novels. Then you have that one file where it's all `div` in the html.

Yeah it's baffling that people see fit to override the user's text color, but then leave the background color up to chance; or vice versa. The result? Occasionally invisible text.

If you're going to set the colors of some elements, you have to set them all. It's not that hard a concept.

> Others used the Windows-supplied colors for the background color and maybe the main foreground color, then used fixed, non-customizable colors for everything else, making everything invisible or hard to see if you used anything but a white-ish background.

I blame the Developer UX.

In Visual Studio, objects might have defaulted to the system color scheme, but if you ever selected colors for your controls, the palette was a collection of hard-coded colors, not system color classes. The IDE gave no indication that by selecting a new color you were forgoing an accessible, system-derived hue, and the documentation I had at the time (Sam's teach yourself ____ in 24 hours) didn't give the kind of cookbook examples I would have needed to keep my own GUIs system-controlled.

I remember being able to change the color of every window frame, button, selector, scroll bars, and so on. For a time most people had their windows using bright colors with zero regards for good design, they just liked colors.

The same people still send emails and write documents with half a dozen differnet random font faces, colors, and sizes.

Most of the world consists of dark objects against a light field. Written letters made with a pen were dark on light for a couple of thousand years. Your scheme is the inverse one.

Yeah the hate for light mode is very badly overstated. It's fine to prefer dark mode, but that doesn't mean light mode sucks in some kind of objective way.

It's different when it's on a backlit display. Real-world objects are lit with reflected light, not with projected light straight into your eyeballs.

No, it isn't. You need to go back and look at the history of modern computers, especially personal ones. The standard color scheme was light text on a dark background. Many used white text on a dark-blue background, because it was deemed the most legible. Even after Windows dominated, Word had a checkbox in its settings labeled simply, "Blue background, white text." That setting existed well into the 2000s, and it may still be buried somewhere. Edit: Looks like it was finally removed sometime around 2016; here's one of several posts I found complaining about its removal: https://eileenslounge.com/viewtopic.php?t=36503

Computer makers and users referred to black text on a white background as inverse video. The Atari 8-bits even had a key to toggle between normal and inverse characters when typing (the Atari-logo key). It's even described in the manual: https://www.atarimania.com/documents/atari-800-computer-owne... To quote the manual: "Inverse video is text being shown in dark letters against a light background."

Then came the "desktop publishing" craze and some attempts to make video screens an analogy for a piece of paper. This fails because paper does not EMIT light. Nor is reading black text off the surface of a glaring light bulb all day a good way to work. Useful for previewing printed output? OK. For all work on a computer? Not so much.

And yet, perhaps in an effort to be "different" from character-based systems, GUIs migrated to inverse color schemes as their default (except for Apple's, which was always inverse and offered no color-scheme management... and still doesn't). Throughout all of this and into the current day, applications that focus on art, photography, and video & visual effects have implemented a so-called "dark" UI. That's not coincidence.

I've never understood the complaints about glare, I don't know what's causing other people to have that experience. They talk about screens as if they were staring at the sun, with apparently no access to a brightness control. It might be some new super-bright screen technology that I haven't encountered yet, or an epidemic of eye sensitivity, I don't know. Can you, uh, shed any light on that?

> white text on a dark-blue background, because it was deemed the most legible.

Was that really the reason, though? Where did they get that idea? I see variety in the 8-bit computers. Many booted into white or green on black, such as the Commodore PET, but the Commodore Vic-20 was blue on white. The ZX81 was black on white, the Amstrad CPC (Color Personal Computer) was green on blue.

I remember that green-screen word processors were sold as reducing eye strain, when really the reason was that green and amber phosphors were cheaper. That's incidental to the inverse video question, but it throws some doubt on the idea that it was more legible. There may have been some technical motivation.

What are you talking about in the final sentence? Photoshop, for instance, didn't have a dark UI, and as you observe, desktop publishing imitated paper, and art programs would fit into that.

> This reveals a lot about the regression in OSes. Way back in the early '90s, Windows provided a color-scheme editor. Users could set up any color scheme they liked, and all properly-written apps would inherit it and work fine.

Windows has a high-contrast settings, it turns applications and websites to black-on-white, it works reasonably well (I have it being turned on for some days now), although there are menu items and switch states that are not visible :/

Also the default themes all use black text on bright background for selection which is bad. White text on a dark color is much better but you can change that.

> it adds additional work to every UI task

It's not necessarily true, especially if you have a component library and "swappable" themes.

After an upfront investment of setting up the dark and light themes, you can just use your component library and rely on the themes. It's still an investment, but the investment is "constant" and doesn't scale with the number of UI tasks linearly, you don't need to reinvent the wheel, and come up with colors for every feature.

Of course it's a good idea to switch the themes every once in a while, to make sure you didn't miss something, but it's not a huge issue.

Feels like we traded decades of OS-level consistency for a bunch of isolated design fiefdoms

Who must now run around and laboriously (and often erroneously) overhaul their applications when the environment changes.

> properly-written apps would inherit it and work fine

It's nice when there's only a handful of UI controls and they're all system-native. Visual Basic was a godsend.

Want a custom control? Draw one using the shape tool, but then you're in for a world of pain maintaining it and handling edge cases.

Want a shadow around it? Draw a second shape and offset it a bit below and a bit to the right of your first shape. Just don't forget when the window gets resized to move/resize not only the first shape but also its shadow separately.

It's still there on KDE

Same on Mate (aka GNOME 2).