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. |
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