godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.15k stars 97 forks source link

Tweak editor node icons to be distinguishable without relying on color (colorblind-friendly) #794

Open Calinou opened 4 years ago

Calinou commented 4 years ago

Describe the project you are working on:

The Godot editor :slightly_smiling_face:

Describe the problem or limitation you are having in your project:

While I'm not colorblind myself, we should try to make the editor as accessible as possible. A significant part of the population is colorblind.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

Colorblind users may have a hard time distinguishing different editor node icons, especially if they're used in the same scene. This is particlarly noticeable with "primary" nodes such as Node2D, Node3D and Control.

In https://github.com/godotengine/godot-design/issues/54, starry-abyss posted screenshots of the editor with various colorblind simulation modes:

Click to expand ![2020-01-23_20-50](https://user-images.githubusercontent.com/11571820/73009759-3196d480-3e22-11ea-9bdd-ea6a45a602e4.png) ![2020-01-23_20-36](https://user-images.githubusercontent.com/11571820/73008808-64d86400-3e20-11ea-8032-50f83711fc99.png) ![2020-01-23_20-36_1](https://user-images.githubusercontent.com/11571820/73008822-686beb00-3e20-11ea-9c69-c6e90c3d779d.png) ![2020-01-23_20-51](https://user-images.githubusercontent.com/11571820/73009771-36f41f00-3e22-11ea-8015-c637d99a2c8c.png)

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

This proposal is intended to gather design ideas. We should find subtle, but noticeable ways to distinguish 2D and 3D node icons. Distinguishing resource icons as well is a plus, but is not required for this proposal to be fulfilled.

Perhaps changing the node colors could improve the current situation without requiring changes to icon designs. However, keep in mind not all colors may be usable with a light editor theme due to contrast rate requirements.

Feel free to suggest icons (either by uploading a SVG or just a mockup) :slightly_smiling_face:

For reference, here's a non-exhaustive list of node/resource icons which are only distinguished by their color (click to view at full size):

image

(Disregard the DirectionalLight3D icon in there, I accidentally left it in.)

If this enhancement will not be used often, can it be worked around with a few lines of script?:

No, as the engine must be recompiled to change editor icons.

Is there a reason why this should be core and not an add-on in the asset library?:

Editor icons can't be replaced by an add-on.

Keywords: accessibility, a11y

Zireael07 commented 4 years ago

For most blue-red pairs, i.e. 3D-2D, maybe a small 2 or 3 ("D" optional :P ) in a corner would do the trick? The biggest problem will be the four generic circles (Node, Node2D, Spatial = Node3D and Control)

dalexeev commented 4 years ago

@Zireael07 The icons are quite small. Perhaps it is worth adding a digit near an icon? And add an option to the editor settings to disable this.

200505-2

Calinou commented 4 years ago

@dalexeev Drawing indicators outside the icons would likely be complicated to implement, as we're drawing node icons in multiple places (not just in Tree).

dalexeev commented 4 years ago

@Calinou In other places, this is not so important. And where it could be important, other icons are shown.

200505-4

Another variant: make a filter in the Tree by node type.

200505-5

Drawing indicators outside the icons would likely be complicated to implement

It just seems to me that redrawing so many icons is also difficult, but for artists.

Calinou commented 4 years ago

One of my ideas was to add a triangle in each node icon's corner depending on the type. For instance, 2D nodes could have a triangle in the top-left corner, 3D nodes in the top-right corner and Control nodes in the bottom-left corner:

3×3 triangles

Node icons with 3×3 triangles

4×4 triangles

Node icons with 4×4 triangles

However, we won't always have enough space to add a triangle (especially in icons like Sprite). We could workaround this by making the triangles "dig" into the filled space for such icons.

Someone also suggested flipping the 3D icons horizontally and making sure all icons are asymmetric somehow (so there's always a visual difference).

dalexeev commented 4 years ago

This will create visual noise (which cannot be disabled). And how often do you have to mix nodes of different types within the same scene?

Zireael07 commented 4 years ago

@dalexeev: This might be true for doing things in-editor , but remember that Godot also has a remote scene tree. Most games will mix 2D and Controls or 3D and Controls, so they will both show up in remote scene tree.

My main project makes use of the 2D-in-3D trick demonstrated in the official demos, however, so if effectively mixes all three node types (3D + Controls + some 2D nodes for 2d-in-3d and for faking pivots that Controls don't have...)

dalexeev commented 4 years ago

It seems to me that the problem is exaggerated:

200802-1

If people really need it, then we can add this option in the settings:

200802-2

Calinou commented 4 years ago

@dalexeev Tooltips require the user to hover the node for a significant amount of time, which can slow down the user's workflow.

Also, displaying the name permanently in a faded-out color isn't currently possible given what Tree currently exposes. Moreover, it wouldn't work if the node name is too long to display the node type besides it.

It seems to me that the problem is exaggerated:

This is why I'd like to have feedback from actual colorblind people at some point :slightly_smiling_face: I'm just doing guesswork myself.

dalexeev commented 4 years ago

Why 2D is left and male, and 3D is right and female? Where did these associations come from? If you make these icons gray, remove the labels and shuffle them, will you be able to guess which one is 2D and which is 3D?

You are using too many traits (left-right, up-down, horizontal-vertical, and even masculine-feminine). Sorry, but even the solution with 2 and 3 dots in the corner of the icon looks better and more logical.

P.S. This picture will haunt me in my nightmares:

dalexeev commented 4 years ago

Also, displaying the name permanently in a faded-out color isn't currently possible given what Tree currently exposes.

@Calinou Are these icons also part of the Tree? Or is it still possible to modify the line?

Calinou commented 4 years ago

@dalexeev Indeed, those icons are also part of the Tree.

rambda commented 3 years ago

Maybe flat design for 2D, Skeuomorphism for 3D, but this will be a lof of change.

jordanlis commented 3 years ago

I think the solution brought by @noidexe is one of the best : add 3D look to the icon when it's 3D. Sounds logical to me. The other alternatives requires to understand the intention of the author of the solution (adding square to the icon, etc.) so it's bit like giving the information without telling what it means ; this sounds not great to me.

Calinou commented 3 years ago

I think the solution brought by @noidexe is one of the best : add 3D look to the icon when it's 3D. Sounds logical to me. The other alternatives requires to understand the intention of the author of the solution (adding square to the icon, etc.) so it's bit like giving the information without telling what it means ; this sounds not great to me.

Unfortunately, giving 16×16 icons a 3D design is more likely to make them look unrecognizable than anything else. It's pretty much impossible to snap points to a 16×16 pixel grid this way.

Edmier commented 2 years ago

This is why I'd like to have feedback from actual colorblind people at some point 🙂 I'm just doing guesswork myself.

Actual colorblind person here (moderate-strong deuteranomaly), I agree that the icons could use further differentiation but I've had no issue at all telling these colors apart. Red and blue are far enough apart to where they avoid pretty much all colorblind issues.

Here is an okay enough visual with population percentages to further my point:

The red, blue, and tan colors being used are as far as you can really get from each other. Colorblind issues arise more when these colors get closer together as you can probably imagine. The most common offenders are reds, greens, and browns that can blend together more easily.

I want better and clearer icons, but where we are now is perfectly fine color-wise. My brother who has a more severe deuteranomaly agrees, as well as a friend with a strong case of protanomaly. Of course, this varies on the individual level and I should not be taken as a single source of truth for this but here's my input.

Of course, if these color values could be changed in editor themes that'd be great too but that plus clearer differences seems like the ideal here.

forge18 commented 1 year ago

I just wanted to chime in here. I know a lot of people don't believe this is a big issue, but I just had a moment where I thought a Node2D in my scene tree was a Node. This was due to color being the only differentiating factor between the two icons. Thankfully someone on Discord pointed out what I wasn't able to see.

Looking back, I know there are other ways of seeing if it was a Node or Node2D, but when you are in the midst of coding, being able to get information at a glance without having to dig is very helpful.

The icon is missing some form of visual context that isn't color. Adding a small 2 next to the circle for a Node2D and a 3 next to the circle for Node3D would help a lot. It would definitely be appreciated.

paulloz commented 1 year ago

Hi, this definitely needs to be handled.
I have pretty strong deuteranomaly, and e.g. I'd need to squint pretty damn hard to see a difference between those two. image I almost never work in 3D, so I never encounter the red icons, but this is definitely an accessibility issue. The proposition in this comment definitely goes in the right direction.

P.S.: On the contrary, this one is absolutely uncalled for.

Edmier commented 1 year ago

I want better and clearer icons, but where we are now is perfectly fine color-wise.

Coming back to this because of the recent activity. I'm not sure why I made such a blanket statement like this. I want to clarify that I think the current color scheme is fine, but it would still be much better off with different icons. (and that seems to be the consensus here as well)

I still believe the colors themselves are already about as distinct as they could be. So just tweaking values wouldn't be enough. Different icon shapes so as to not rely on color are the best way forward here.

The only hurdle besides designing them that I see with that though is just how small the icons are currently, the differences should be as clear as possible, but UI design is tricky.

Regarding this:

If people really need it, then we can add this option in the settings:

200802-2

While I don't appreciate the sentiment that this idea was proposed with, and I see that it's not a straightforward thing to add, an editor setting to display the name of the node like this is a good change to go along with the icons being altered. People might want this regardless of colorblindness or not, it's just an informative and optional label. Might help with people learning the engine and the node names as well.

I would rather propose that the node type is displayed underneath the name though, to remove concerns about text length.

paulloz commented 1 year ago

I'm not exactly sure how we handle the svg icons at the moment (i.e. are the colours baked in?). But another potential solution could also be to have the three colours for 2D/3D/UI configurable. It's not ideal since it requires active configuration steps from the user, but it'd help.

AThousandShips commented 1 year ago

Colours can be modified based on the theme, at least some have replacements and are replaced when rasterising the icons

dalexeev commented 1 year ago

POC of an addon:

@tool
extends EditorScript

func _run() -> void:
    var image23 := preload("res://23.png")
    var bc := get_editor_interface().get_base_control()
    var theme := bc.theme
    var new_theme := theme.duplicate()
    for icon_name in theme.get_theme_item_list(Theme.DATA_TYPE_ICON, &"EditorIcons"):
        if ClassDB.class_exists(icon_name) and ClassDB.is_parent_class(icon_name, &"Node"):
            var texture: ImageTexture = theme.get_icon(icon_name, &"EditorIcons")
            var image := texture.get_image().duplicate() as Image
            var new_texture := ImageTexture.new()
            image.crop(22, 16)
            if ClassDB.is_parent_class(icon_name, &"Node2D"):
                image.blend_rect(image23, Rect2i(0, 0, 6, 8), Vector2i(16, 0))
            elif ClassDB.is_parent_class(icon_name, &"Node3D"):
                image.blend_rect(image23, Rect2i(6, 0, 6, 8), Vector2i(16, 0))
            new_texture.set_image(image)
            new_theme.set_icon(icon_name, &"EditorIcons", new_texture)
    bc.theme = new_theme
    print("Done.")

nlupugla commented 1 year ago

Can we not put the little 2 and 3 inside the circle, combining both of the leading approaches suggested here?

For control, maybe a little mouse pointer icon inside the circle?

I have no art skills so I'll leave the visuals to your imagination :)

vPumpking commented 1 month ago

I suggest an alternative to what's been said earlier by vagabondzero: using distinct variations of each base node: Node Node2D Node3D Control

or maybe an alternative with the number of axis (x, y or x, y, z) on the node2D and node3D icon Node2DAlternative Node3DAlternative

(not too sure about it though, as it looks like clocks) and then each node icon would have his base node type in a corner, except those inheriting only from Node, because they have no display Like this: SpriteSheet Sprite2D Sprite3D Button

or: Sprite2DAlternative Sprite3DAlternative

obviously those aren't perfect and I'm still thinking about the right spot and size, especially seing how the button turned out but I think that's a good compromise

vPumpking commented 1 month ago

but in this case I also think we should find an alternative design to Node3d, it looks like a one-way street sign

Meorge commented 1 month ago

I see there were some discussions about varying the icons via horizontal flipping or gender appearance, but I'm not sure if that would make sense since it wouldn't be easily understandable as "this is 2D, that is 3D". Placing a 2 or 3 outside of the icon is definitely more understandable here, but the current screenshots the numbers seem a bit thin and hard to read, and may also be pushing the icons themselves off-center.

I was thinking of something similar to vPumpking's approach with the number of axes, but possibly having the icon resemble 2D and 3D axes more directly. I can't produce a prettier mockup right now, but my thought was something like this for 2D icons:

and something like this for 3D icons:

For the cases like the CharacterBody2D/3D where this appears as a "sub-icon", I think it'd improve readability to not have the Node2D/3D/Control circle around it.

tumblewed commented 1 month ago

Alternative: Node Control Node2D Node3D

This design 'counts' up from 0 to 3 points inside the circle, ranging from Node, Control, Node2D, and Node3D. I think the added line in the Node3D icon distinguishes it better as it imitates the 3D gizmo (mentioned above), so the association is more apparent than using a vertical or horizontal line.

I think this convention works nicely on its own, but it may not be easy to translate to the rest of the icons if you wanted to maintain consistency.

Example with RigidBody: RigidBody3D RigidBody2D / Bigger3D Another2D

I used a circular cutout in the bottom right to put markers for the node types, and as you can see (or not!), at 16x16 this is barely noticeable. The left set uses the line convention I mentioned, and the right set uses a numbering convention ('2' & '3'). Also, some icons already make use of cutouts in the corner, so they would have to be redesigned completely just to use this system. For those reasons, I do not think changing the node icons (at least in this way) would be a valid approach.

If possible, I think adding something in-engine next to the icon as previously suggested is the best solution. The basic Node types' icons could still be changed to what's mentioned above, however, as that change would be feasible.

Meorge commented 1 month ago

I think this convention works nicely on its own, but it may not be easy to translate to the rest of the icons if you wanted to maintain consistency.

I definitely agree, based on the RigidBody example you provided. The two left icons are pretty much exactly what I was envisioning in terms of design (no circle around the line shape), but I can see here that they don't stand out very well.

More space could be cut out from the main icon to let the sub-icon stand out more, but that would also reduce the amount of space for the main icon to convey its information.