4 ms·

I think we should separate ideas/proof of concepts that were in the field and presented as having potential, and implementations that are largely adopted and re

by hrktb 6y ago

I think we should separate ideas/proof of concepts that were in the field and presented as having potential, and implementations that are largely adopted and reliable. There will always be a lag between the two, and it won’t just be ‘reinventing the wheel’. I had a look at CORBA and it was horrible in many ways. Interestingly it’s something that works and is proven at large scale but nobody would want to have it for small/middle scale non enterprisy applications, and it might not even be a good idea at large scale depending on what properties are valued. In no way I’d see kubernetes with services as a worse version of it, we didn’t choose it just by ignorance or hype. Same with “dark mode“ on win 95. Most programs couldn’t even properly handle text sizes, it was a i18n nightmare that was just brushed under the carpet. Changing text and background colors was the same, with some apps somewhat working because they Mostly relied on default widgets, and a mess of unusable apps on the side that just had text colors baked. You had a better chance to have it work by plain inverting all colors through the accessibility settings. To be fair it’s still partly a mess now, but we are in a way better situation that in Win95 , it is understood at an application level, it actually makes sense now.

pjc50 6y ago
You could have "dark mode" in Windows 3.0. Provided programs used the standard widgets and the correct "named" colours, everything would pick up the colour changes from the operating system.
AnIdiotOnTheNet 6y ago
How on earth can anyone think that each application having to individually implement support for a bespoke "dark mode" is a better situation than having more granular controls in the OS and applications just follow the UI guidelines is beyond me. It's bullshit like that that makes me want to leave IT forever.
- TeMPOraL 6y ago
  It's probably the unfortunate consequence of a typical software vendor's perspective. There's a deep conflict between the interests of users and software vendors, a conflict for control over presentation. It's blindingly visible on the web, and half the reason it's in such shitty state it is, but it also applies to desktop software. The problem is that for a vendor, application's UI and UX are marketing space, and they want total control over "user's journey". For the user, UI/UX are things that stand between them and the work they want to get done, so they want it to be effort- and bullshit-free. For non-tech-savvy users this implies "consistent with all other software they use"; for power users, this means "able to be altered or removed" - but both of those viewpoints require vendor to not have the final say about presentation. In context of dark mode, an OS-level control over UI styling is a user-friendly feature. Unfortunately, it got defeated by vendors who want the UI to be their branding space, and now they have to begrudgingly add dark mode themselves. EDIT: see also https://news.ycombinator.com/item?id=24918296 https://news.ycombinator.com/item?id=24918296 upthread, it seems to be a quite accurate description of what will happen if we let the vendor side win.
- gmueckl 6y ago
  How on earth is the same set of UI icons supposed to keep their readability against vastly different background colors? If you want to do a proper job of that, your application needs to become aware of dark mode anyway and ship with a separate set of icons. Yes, in terms of raw flexibility exposed to the user, customizable color schemes look great on the surface. They work to some degree, but fail utterly for a wide range of cases in practice. Not having them is progress after a fashion because it means giving up on an flawed idea. I will admit, though, that it is not easy to see why it is flawed when you haven't tried to design custom controls that have to convey more state than can be expressed using the standard OS colir palette.
- hrktb 6y ago
  It’s because reality is complicated. Most people don’t want “dark mode” as a pure accessibility feature in the sense of “whatever color scheme is fine as long as it’s dark everywhere”. That’s the reverse color feature in most OS. Instead I/they want dark themes but with pleasing colors, adjusted depending on the screens and the widgets, having sane defaults for content that is usually supposed to be white, with exceptions. Yes, that’s a tall order, it’s context dependent, and we might actually want to decide app by app if the dev did a good job and/or if dark mode makes sense, and sometimes change the theme in the app because it’s otherwise not great. We end up in a patchwork of apps following dark mode and others not, with different themes applied that might not be triggered by the system. For instance I use youtube, reddit and editing apps in dark mode only, while the rest of the system is in light mode. As you say it could be handled by the system in a super granular way, but it would add that much more complexity, and I actually chose the exact themes to be used in most of these apps, so centralization wouldn’t help anyway.

by hrktb 6y ago

pjc50 6y ago

You could have "dark mode" in Windows 3.0. Provided programs used the standard widgets and the correct "named" colours, everything would pick up the colour changes from the operating system.

AnIdiotOnTheNet 6y ago

How on earth can anyone think that each application having to individually implement support for a bespoke "dark mode" is a better situation than having more granular controls in the OS and applications just follow the UI guidelines is beyond me. It's bullshit like that that makes me want to leave IT forever.

TeMPOraL 6y ago
It's probably the unfortunate consequence of a typical software vendor's perspective. There's a deep conflict between the interests of users and software vendors, a conflict for control over presentation. It's blindingly visible on the web, and half the reason it's in such shitty state it is, but it also applies to desktop software. The problem is that for a vendor, application's UI and UX are marketing space, and they want total control over "user's journey". For the user, UI/UX are things that stand between them and the work they want to get done, so they want it to be effort- and bullshit-free. For non-tech-savvy users this implies "consistent with all other software they use"; for power users, this means "able to be altered or removed" - but both of those viewpoints require vendor to not have the final say about presentation. In context of dark mode, an OS-level control over UI styling is a user-friendly feature. Unfortunately, it got defeated by vendors who want the UI to be their branding space, and now they have to begrudgingly add dark mode themselves. EDIT: see also https://news.ycombinator.com/item?id=24918296 https://news.ycombinator.com/item?id=24918296 upthread, it seems to be a quite accurate description of what will happen if we let the vendor side win.
gmueckl 6y ago
How on earth is the same set of UI icons supposed to keep their readability against vastly different background colors? If you want to do a proper job of that, your application needs to become aware of dark mode anyway and ship with a separate set of icons. Yes, in terms of raw flexibility exposed to the user, customizable color schemes look great on the surface. They work to some degree, but fail utterly for a wide range of cases in practice. Not having them is progress after a fashion because it means giving up on an flawed idea. I will admit, though, that it is not easy to see why it is flawed when you haven't tried to design custom controls that have to convey more state than can be expressed using the standard OS colir palette.
hrktb 6y ago
It’s because reality is complicated. Most people don’t want “dark mode” as a pure accessibility feature in the sense of “whatever color scheme is fine as long as it’s dark everywhere”. That’s the reverse color feature in most OS. Instead I/they want dark themes but with pleasing colors, adjusted depending on the screens and the widgets, having sane defaults for content that is usually supposed to be white, with exceptions. Yes, that’s a tall order, it’s context dependent, and we might actually want to decide app by app if the dev did a good job and/or if dark mode makes sense, and sometimes change the theme in the app because it’s otherwise not great. We end up in a patchwork of apps following dark mode and others not, with different themes applied that might not be triggered by the system. For instance I use youtube, reddit and editing apps in dark mode only, while the rest of the system is in light mode. As you say it could be handled by the system in a super granular way, but it would add that much more complexity, and I actually chose the exact themes to be used in most of these apps, so centralization wouldn’t help anyway.