Draft: Colour filter hint in Settings Portal #1177
Conversation
|
Side-note: For Libadwaita + greyscale, I have a few design ideas that I'll share in the coming days when I have time to design them. |
|
In my research here what I heard was the folks probably want this to be a separate setting and not tied into whether they use assistive filters. Especially in collaborative or support environments this can make things actually worse because what they see on screen is not what everyone else is seeing. For example a person with protanopia may have a concept of what they consider to be green and what they consider to be red and if they're using an assistive filter they may be able to communicate with team mates with some degree of accuracy that "this is a red button" even if they're not seeing exactly what someone else is. But if their interface is changed completely they won't be able to have that common communication with others. I'm not sure about other platforms but iOS has a separate "different without color" binary setting that is completely independent from color assistance filters |
|
I mean, my idea for application implementation was more-so to add subtle changes to accomodate for the shaders, such as destructive action maybe getting a subtle texture up top, akin to the unstable application header texture, in Libadwaita and/or added fallback icon for additional denotation, but yeah fair point. |
|
I think generally we should be pushing the defaults to not rely solely on color to communicate information. If something like adding an icon or a texture is beneficial to folks with color deficiency maybe we should just do that for everyone all the time? |
|
I mean, yes, but there again there might be edge-cases, such as the aforementioned games context, that may still provide merit for providing a hint irregardless. It all comes down to implementation on the application's side, at the end of the day, and I really don't see 100% of applications willing to accommodate deciding to accommodate anyway without knowing a colour filter is in use. |
|
-1 for exposing color filter settings to clients
|
Right so this is exactly the kind of potentially collaborative case where the folks I spoke said they explicitly didn't use options that were designed as color assistance because it made their experience worse. Opting someone into a different interface just because they're using an assistive tool is not what they're expecting. So a hint here should be explicit about its purpose both so it feels deterministic for the people using it and so that app developers know exactly what it should do |
From what I've heard, I think it's more the other way around. Folks with color vision disabilities seem to largely be more interested in assistance that meets them at the severity of their disability and not like immediately jumping to segregated experiences unless their disability absolutely requires it to function |
|
I think this needs a lot of discussion and it's not entirely clear to me how desktops should handle it, so I'm not assigning any particular milestone for this. |
|
Just want to be clear here: In advance, @swick how best would a redesigned version of this draft be changed to accomodate for your feedback? Besides a rename, would it remain the same but without the "higher contrast" options, or alternatively become a generalised "I am colourblind" boolean? I'm assuming the former, but thought I'd ask first. |
It should describe the kind of color vision deficiency that a user has: no red, no green, no blue, no color or reduced contrast. One could argue that a strength would also be helpful but I think we should start with a minimum and if there is need for it we can add it later. |
Interesting. I guess this is also a problem with apps switching to a very different mode instead of being designed with CVD in mind and then only having to adjust slightly. Either way, keeping them separate and not exposing the active filters gives the user more control while keeping the implementation complexity at a minimum. I think we agree here. |
|
The problem is that if an app has its own things to adapt to the user's vision, then it should logically know if a filter is active in order to disable it, but then the user indeed has no control . Perhaps the app should report back to the system whether it has its own adaptations, so that the user can choose to enable or disable a color filter for a specific application? Besides, shouldn't the application also know the severity (since it was mentioned) to know if it has the necessary adaptations? |
|
For a reference on games using this setting, DOOM Eternal provides colorblind filters in-game. It would be a perfect example of a slight possibility of games using this setting. |
|
I'll admit - I forgot about this PR entirely since my last message. Unfortunately I'm going to be busy until Friday, because gotta do more assignments (my free time before doing that just ended), so won't incorporate the feedback just yet, BUT if there's more feedback to be given here, do provide it in advance... and I'll try not to forget this time when I'm free again to rebase it and incorporate everyones' feedback. |
|
Accent colors have landed which is great, but it doesn't change signal colors such as red for no and green for yes. The CVD information could be very helpful for this. Is this something we could do on the libadwaita side @alice-mkh? |
|
We heavily discourage use of colors for that without secondary indicator. So if you see something like that in apps - e.g. a red for error without an icon - file bugs. |
|
Sure, and that's a good thing! But wouldn't it be better if we even re-colored the red/green indicators to orange/blue instead for people with red-green blindness? |
|
Orange/blue make no sense semantically. They don't just need to be different, they also need to make sense. Would a colorblind person even recognize blue as an error, rather than, dunno, a hyperlink? And then you also have icons and illustrations, which wouldn't match those colors anymore. If you really want to recolor things, you'd be better off with a compositor wide filter IMO. Then it's also clear in context what blue means - as opposed to randomly blue messages in some apps. |
|
The filters are far from perfect and from what I've learned, most people only turn them on occasionally. I'm also not asking random apps to re-color this but rather libadwaita, so that the colors can be learned. |
|
Would be nice to have some data about how many people use blue/orange colors in other OS too. Surely those filters aren't perfect - but what would make a toolkit doing the same thing suddenly better? |
That the toolkit can choose where to apply it. The compositor will re-color everything, including images and videos etc. They will look differently, even to people with CVD (and the same kind of CVD) because each person has slightly different sensitivity curves which implies different strength and different perception. So when the CVD isn't extreme, one might prefer to experience images and videos without the extreme re-coloring of the filter and only use it when something is not legible. When you just re-color semantically important UI elements, you get a legible UI while not destroying the perception of images and videos. |
|
Do we have any data on filter usage at all? Anecdotally I'm not aware of anyone using them ‘seriously’, and whilst excluding ‘images’ may increase their usefuless it also opens a whole new can of worms — What's an image? are icons an image? what if the image is a scan of a document vs a photo? does that still make sense to exclude? Recolouring controls seems confusing more than anything, especially when our UIs shouldn't be dependant on colour feedback in the first place. |
|
Sorry, but this is about recoloring very specific UI elements (i.e. we would have a list of things it would affect rather than a list of things it would not affect) and color is an amazing indicator making it much easier to see what's going on at a glance (but one which should not be relied upon alone). |
|
While still being a huge headache for app developers. Unless there's clear data that people need/use an option to change color, I don't think it's happening at least in libadwaita, sorry. |
|
How is that a headache for app developers? |
|
The same way as not knowing what any other color is gonna be is a problem. Except instead of 1 color (accent color) you now have an additional 4 (error/warning/success/destructive). This also encourages people to use color-only for differentiation, instead of being forced to add other indicators. Anyway, I'm gonna stop replying here - this is unproductive. I will only consider further input from colorblind people. |
|
There are filters to simulate color blindness and there are gnome shell extensions which do have them. Try it out. |
|
That tells me nothing, I'm not colorblind. Forgot to unsubscribe, sorry. |
That's why you should use the filter to simulate color blindness. |
|
@swick: I agree that decisions for GNOME components need to be discussed in the GNOME space and come back here if there is anything to add here. I believe you should consider that it will also be difficult to manage an interaction between accent color and color blindness colors (maybe that's one problem raised by Alice?) compared to having to style the UI with only color blindness colors (i.e. no different accent colors for people with color blindness). |
|
Sorry but I think I agree with Alice that this is probably a dead end. Generally apps shouldn't be relying on only color as an indicator. They might make use of color in addition to a label or icon Practically, buttons with style classes like suggested or destructive aren't presented in a grid with a bunch of other buttons as shown in the OP. In dialogs for example you only ever use either one of either destruction or suggested but not both in the same dialog. So even in grayscale you'll see that one of the options is much darker or much lighter than other options and in combination with the labels you can infer that something about this option is different from the other options, so I don't think this is particularly a problem. I think this proposal would lead to apps doing things that are non-deterministic. "Tell apps that I have protanopia" could mean anything for how those apps decide to handle that information. I can't honestly see games listening to or doing anything with this setting either tbh. And like I said before, in collaborative environments a segregated experience is often worse, not better. So I think I'll probably unsubscribe here too, sorry! |
|
Hi! Got here form the libadwaita:gnome.org matrix room.
|
|
That one should not rely on color alone as indicator is obvious and consensus but doesn't preclude further improvements. |
|
Okay so as far as I can see, there isn't general consensus on this yet, at least not enough to justify it being a pull request. If people are still interested in discussing and pushing this forward, please open a discussion in the Discussions tab and link to this PR. I'll go ahead and close this, but this is not a rejection of the idea. At any time, if more consensus is reached, please feel free to reopen or open a new PR. |
Unlike the high contrast one, this one is a draft because I know Desktop Environments like GNOME don't yet have a concrete idea about the design they would prefer for this, the colour blindness filters they want to expose, etc.
As such, I expect this MR to thoroughly change before it exits Draft status, and for it to take forever to even exit Draft status.
Fixes #647, #1151
Introduction
Colour blindness is a prevalent problem, and Operating Systems in the XDG-compliant space are starting to realise this and accommodate to those suffering from such issues with their sight. So far, elementary OS and KDE Plasma have implemented colour filters for the colour blind users, by means of compositor shaders. However, this implementation has a design limitation that this pull request sets sight on allowing a fix to be made for.
Details
A new key on the settings portal,
color-filter, would be introduced into theorg.freedesktop.appearancenamescape. This key currently consists of all colour blindness filters implemented by elementary OS, as well as accommodating for greyscale, however more filters could be added at a later date to this pool of values.As aforementioned, this is largely inspired by elementary OS's implementation of their colour shaders, although this design may always be changed to accommodate for the requests of other Desktop Environments.
This hint is designed with being paired with colour shaders in mind - applications should only use this hint to adjust their user interface for the current filter.
Additionally, greyscale is made available here to allow implementations of greyscale shaders, such as elementary OS's, to be officially recognised as shaders that applications should account for.
Brown Monotone was originally considered as a shader, here, however this is easily supplemented by allowing greyscale to be redshifted.
Cases for colour filter hints for applications
Libadwaita
Libadwaita has a high reliance on colours to denote certain types of buttons, however if colour blindness filters are not accounted for, on certain colour blindness filters the denotation can end up being too similar to be uniquely identifiable.
This would obviously especially be the case on greyscale filters, where colours are just not usable for denotation, period.
If Libadwaita applications were able to know a colour filter is in use, they could then adjust themselves accordingly to better take advantage of the limited, or non-existent, colour pool.
Games, such as Geometry Dash
While not native so not able to yet leverage this standard if merged, I'd still like to use Geometry Dash to illustrate a gaming context for why applications would want to know about the current colour filter.
Before 2.2, one of the biggest aspects of Geometry Dash's gameplay, the portals and orbs, were similarly denoted by colours only. However, after concerns for colourblind players, the upcoming 2.2 update adds the option for colourblind players to add symbols to portals and orbs to allow denotion without colours (this would obviously be useful on greyscale filters, too).
If games are able to know which colour filter is in use, such as via this hint, they could technically automatically enable such optimisations, in their gameplay, for audiences using these colour filters.
Acks
This may be a draft currently, but to save George the effort, using the acks list from #815