apache
AIP-38 | Add colorblind friendly color schemes
We are starting to add status colors to the new UI. Before we build out too much we should make sure to think about a11y from the get go. A lot of status colors are hard for people (particularly red/green).
-
Update our theme to always use semantic names instead of colors (ex: "error" instead of "red", "success" instead of "green)
-
Decide to use a colorblind friendly color palette for everyone, or add a user setting to switch between common semantic colors and a friendlier palette
We have 12 state colors right now, which is a lot, and leaves us with three options:
- Switch our state colors to an imperfect colorblind friendly palette for everyone. No need for settings but a lot of colors will really change: https://mk.bcgsc.ca/colorblind/palettes.mhtml#12-color-palette-for-colorbliness
Ex:
-
Add a color-blind friendly mode to allow users to opt-in to a more accessible mode
-
Use a better color blind friendly palette, but with fewer colors and the need to consolidate task states. With dag versioning, will we have Removed or just None or Skipped? Or can we move to a status/sub status model
In all scenarios, we should always try to depict state through other means than simply color.
Possible groupings with the same color but some indication that they're separate:
Pre run: queued, schedule, deferred Re do: restarting, up_for_retry, up_for_reschedule Nothing: no_status, skipped, removed, upstream_failed Failed Success Running
I think queued and scheduled are distinct enough to need different colors.
And skipped /upstream_failedcould be the same colour, but I don't think no_status/null should be in the same grouping. One has never been, the other ran and failed. Removed I could se go in either side.
3. Use a better color blind friendly palette, but with fewer colors and the need to consolidate task states. With dag versioning, will we have Removed or just None or Skipped? Or can we move to a status/sub status model
In general - great idea and kudos for making the UI more accessible for those in need!
My two cents regarding your suggestions:
- Not too bad, but some of the colors in the pallette are too similar: a. restarting - skipping b. deferred - removed
- In any case I'd make this transition optional for now (long term - maybe even user customized?).
- I think that I'd go with the first option rather than having less and too similar colors. If we go in the direction of less colors, maybe we could utilize other features like opacity/fill/shape?
+ Don't forget the dark mode :)
-
With some user testing, the 12 color palette I linked didn't help much.
-
I am definitely moving forward with a version of this. Looking at a hue rotation that let's a user shift the whole UI as they see fit: https://stackoverflow.com/questions/46553023/use-slider-to-change-image-css-filter-with-javascript/46553057#46553057
-
I need to figure out which other changes can work well with colors. I definitely like the idea of visually separating tasks that are in pending or final states. Pending can be a circle while final is more square shaped or we can animate a gradient bg for pending states.
FYI Animation is also against guidelines for accessibility - we had issue about it https://github.com/apache/airflow/issues/34019
Yes, we do allow STATE_COLORS to be edited via settings but on a deployment, not a user basis. I don't think that should exist in the browser's localstorage either. It would be great to create actual user settings we save on the db which can also include other requests like "favorite_dags".
hey @bbovenzi and the rest of the community!
What do you thing of introducing symbols instead of using colors? I've created a userscript which does just that, but it's kinda hacky, and interferes with React's Virtual DOM. It would be way better to implement something similar natively.
With this change, the default color scheme would remain, but users could switch to symbols / tweak it in their personal user settings.
hey @bbovenzi and the rest of the community!
What do you thing of introducing symbols instead of using colors? I've created a userscript which does just that, but it's kinda hacky, and interferes with React's Virtual DOM. It would be way better to implement something similar natively.
With this change, the default color scheme would remain, but users could switch to symbols / tweak it in their personal user settings.
I like the idea with icons - we just need to consider that while the enlarged mugshot look nice - especially with the details in the icons - on most screens (non retina) this will be just a few pixels. So symbols can help BUT we need to make them also visually distinguishable in todays 16 x 16 pixel raster (with the option to have more details in retina displays)
So if we go for symbols they would need to be very reduced in detail and colors and need to be distinguishable being max 14 x 14 pixels (assuming 2 pixels border to the next icon)
In case anyone missed it. We now have icons for each task state. This is implemented everywhere in the new UI except for the grid view for now.
Why was this closed as completed @bbovenzi? Because of icons? AFAICT STATE_COLORS support and documentation has been quietly removed in Airflow3.
Yes, in Airflow 3 we retired a lot of old settings when rewriting the frontend. We ran into a lot of issues of having the config having control UI elements like colors, especially for light+dark mode and various shades. We are looking to bring it back in the form of a larger theme config to allow better customization.