Colorblind accessibility discussion

[epicEaston197]

This discussion started from issue #1947 this discussion is a continuation of this issue

here's a quote from the issue i mentioned

from Frooxius

a lot of the stuff proposed here aren't really settings and there's not a single actionable item from this.
Once we figure out what concrete changes and additions to make, we can make those into distinct issues.

[ColinTimBarndt]

A super quick and dirty mockup I made of a potential improvement for both colorblind users and also just generally improving protoflux learnability

I'd recommend using color blindness simulations instead of simple black/white filters. Those issues can be partially improved by changing the palette depending on the dichromacy of the user. Monochromacy (black and white) is very rare while Prot-/Deuteranomaly is fairly common, especially for male users. Additionally, a second channel should be used (e.g. shapes of inputs or a texture on the wire).

Second channels are one recommendation made by the Accessible Player Experiences (APX) guidelines (also quoted by the paper I referred to).

[epicEaston197]

from Frooxius

What we were wanting to do for types that I think would be better approach is to introduce unique black & white patterns for each common type, which would be displayed there.

I think unique black and white patterns would suffice along with some color palette modifications

[ColinTimBarndt]

Quoting @Frooxius:

The mockup only works for this particular node, because it doesn't have any outputs, but it will not work for lots of others, which already use the space you used for the type to have labels for the output connectors.

I believe that second channels would fix this issue. They're already used for higher-dimension types like int3 (the lines on the connector). Maybe a simple (procedural) texture could be generated for each type.

[ColinTimBarndt]

I think unique black and white patterns would suffice along with some color palette modifications

I see, we were typing this concurrently 😂. I agree.

[JackTheFoxOtter]

Adding the type name to the sockets on the nodes makes sense, but it probably can't be under the label, that won't work if the node has an output socket on the opposite height.

Just putting "<name> (<type>)" on every socket label might be the easiest to implement.

[shadowpanther]

This might also overencumber the text for some compound types.

[ColinTimBarndt]

Here's my WIP designs that I came up with. These could be added to the wires as a repeating background.

Inkscape SVG

From top to bottom:

• Int Design 1 (integer wave)
• Int Design 2 (binary counter)
• Float Design 1 (Bèzier wave)

I think it's not necessary to make the subtypes (float vs. double, int vs. long vs. short vs. byte) differentiable by pattern as they rarely mix and currently have the same colors in the game (when clamped to 255 by non-hdr screens).

[VirgilCore]

I really like the pattern idea

[ColinTimBarndt]

Hardcoded colors can be seen here: https://wiki.resonite.com/Module:ProtoFlux_Type_Color
Basically every common type is hard-coded.

[Banane9]

I like the idea of representing the discrete vs. fluid nature of ints and floats as square waves and continuous waves respectively. Perhaps the bigger ("more precise") ones could have more steps. So bool could be just alternating light / dark, while bytes, ints, and longs get increasingly more "steps" in the wave. For short / float / double, it could be represented by the frequency instead 🤔

[epicEaston197]

Beyond color blindness accessibility this is just a really nice visual change overall

[JackTheFoxOtter]

Beyond color blindness accessibility this is just a really nice visual change overall

It would have to be an option, because I wouldn't want this on for myself. I think it would mainly just make the code a lot messier to look at for me.