3 ms·

Color themes seem like a brilliant idea until hit the point where your custom control needs this one extra distinct highlight or background color to convey stat

Color themes seem like a brilliant idea until hit the point where your custom control needs this one extra distinct highlight or background color to convey state. Then you're out of luck. You only have bad options left: opt out of system theming and enforce your own or hardcode a color (or put it into the settings dialog) and accept that it breaks with any non-default theme out there because no user will take time to look at the settings and fiddle with the colors. Either way, any usability benefit from good default themes (e.g. high contrast themes) is pretty much gone.

anoncake 7y ago
Or you use the extra distinct highlight or background color the system theme specifies.
- gmueckl 7y ago
  That is not enough. What if I need three clearly distinguishable background colors to convey different states for list entries?
  - anoncake 7y ago
    Then you should fix your app so it can be used by color-blind users. Aside from that, you should use distinguishable background colors A, B and C specified by the system color theme. It's more likely that its designer has considered accessibility issues than that every single app developer has.
    - gmueckl 7y ago
      Have you looked at the set of colors that is actually defined by a theme? That is my point: I would use these colors gladly if they were there. They aren't.
adamzochowski 7y ago
There are two solutions to this: 1) use offset colours, like specifying to move 10% in Hue off the theme colour. 2) specify all foreground + background colours and admit that this is special and won't conform to any user or distro theming
- gmueckl 7y ago
  Number two is the enforced theme I was tslking about. Offset colors can be problematic for a number of reasons. The main one is that you don't know if the color that is generated that way has the right amount of contrast to each of the other colors it appears with and that the end result is something that is visually pleasing.
  - adamzochowski 7y ago
    As an application developer I want for my users a consistent experience, irrelevant of OS or distribution. I understand that. But, as a user I want for my experience consistent on my os, irrelevant of that different apps are written by different people on different setups. I want consistent icons, I want menus that follow same convention, I want to change text colours and sizes. The biggest issue is that developers don't want to follow gnome checklist. Instead of that, they hardcode colours and behaviour. They go heavy into 'it works for me'. And then have audacity to complain that world doesn't bend to their will. Here is a gnome checklist. I wish the open letter stated how their application follows the checklist and was broken by a distribution so that the checklist now includes fails. https://developer.gnome.org/accessibility-devel-guide/stable/gad-checklist.html.en https://developer.gnome.org/accessibility-devel-guide/stable...
    - yellowapple 7y ago
      I have a strong feeling that if custom themes are breaking apps, then those apps are almost certainly in violation of one or more of tables 2-4, 2-5, or 2-6.
      - gmueckl 7y ago
yellowapple 7y ago
If you're reliant on color to convey critical information, then your app is by default already much harder to use for colorblind users. Anyone who feels one needs these extra specific colors really ought to rethink the core design.
derefr 7y ago
There's nothing stopping a graphics toolkit from following the lead of Bootstrap and having N different "semantic tints" with names like "primary", "danger", "done", "busy", "paused", etc.; where the theme designer then gets to define, for their theme, what color "primary" or "danger" will be—but ensures that that color coherently means only that semantic idea throughout the theme. (So if they create a theme where "danger" is blue, then the window close caption-button should have a blue background, the delete-permanently icon should have blue as its primary, etc.)
- gmueckl 7y ago
  That may be the right approach. But desktop toolkits don't do this.

anoncake 7y ago

Or you use the extra distinct highlight or background color the system theme specifies.

gmueckl 7y ago
That is not enough. What if I need three clearly distinguishable background colors to convey different states for list entries?
- anoncake 7y ago
  Then you should fix your app so it can be used by color-blind users. Aside from that, you should use distinguishable background colors A, B and C specified by the system color theme. It's more likely that its designer has considered accessibility issues than that every single app developer has.
  - gmueckl 7y ago
    Have you looked at the set of colors that is actually defined by a theme? That is my point: I would use these colors gladly if they were there. They aren't.

adamzochowski 7y ago

There are two solutions to this: 1) use offset colours, like specifying to move 10% in Hue off the theme colour. 2) specify all foreground + background colours and admit that this is special and won't conform to any user or distro theming

gmueckl 7y ago
Number two is the enforced theme I was tslking about. Offset colors can be problematic for a number of reasons. The main one is that you don't know if the color that is generated that way has the right amount of contrast to each of the other colors it appears with and that the end result is something that is visually pleasing.
- adamzochowski 7y ago
  As an application developer I want for my users a consistent experience, irrelevant of OS or distribution. I understand that. But, as a user I want for my experience consistent on my os, irrelevant of that different apps are written by different people on different setups. I want consistent icons, I want menus that follow same convention, I want to change text colours and sizes. The biggest issue is that developers don't want to follow gnome checklist. Instead of that, they hardcode colours and behaviour. They go heavy into 'it works for me'. And then have audacity to complain that world doesn't bend to their will. Here is a gnome checklist. I wish the open letter stated how their application follows the checklist and was broken by a distribution so that the checklist now includes fails. https://developer.gnome.org/accessibility-devel-guide/stable/gad-checklist.html.en https://developer.gnome.org/accessibility-devel-guide/stable...
  - yellowapple 7y ago
    I have a strong feeling that if custom themes are breaking apps, then those apps are almost certainly in violation of one or more of tables 2-4, 2-5, or 2-6.
    - gmueckl 7y ago

yellowapple 7y ago

If you're reliant on color to convey critical information, then your app is by default already much harder to use for colorblind users. Anyone who feels one needs these extra specific colors really ought to rethink the core design.

derefr 7y ago

There's nothing stopping a graphics toolkit from following the lead of Bootstrap and having N different "semantic tints" with names like "primary", "danger", "done", "busy", "paused", etc.; where the theme designer then gets to define, for their theme, what color "primary" or "danger" will be—but ensures that that color coherently means only that semantic idea throughout the theme. (So if they create a theme where "danger" is blue, then the window close caption-button should have a blue background, the delete-permanently icon should have blue as its primary, etc.)

gmueckl 7y ago
That may be the right approach. But desktop toolkits don't do this.