Page MenuHome

The header color of muted vs non-muted "Value" nodes is almost exactly the same.
Closed, ResolvedPublic

Description

Blender Version
Any 2.80 build.

Description
I'm not sure that this is the perfect place to report this since it's not exactly a "bug". If this is not the right place, please feel free to point me in the right direction.

See attached image to see a muted and a non-muted Value node under the current Dark theme.


Now my eyes are not perfect(they are in fact quite bad) but I'm not colorblind and I find it extremely difficult to tell the difference between those two reds. Difficult enough that this just caused me to go troubleshooting my nodes for 15 minutes only to find out one of my values was simply muted.

To avoid this from happening, the behaviour for muting should either be changed(for example turn the entire node a different color rather than only the header, or add a red cross across the entire node) or themes as a rule of thumb should avoid using red color under the Node Editor category (Except for Output nodes, since those cannot be muted afaik), and the current default themes should be changed to follow that rule of thumb:

Event Timeline

I think we should fix this by changing the color of the actual node, not just the header. The header colors already represent the node type. so we are already using header colors for something else.

Making the header color also communicate the muted state is confusing. Even if we pick different colors, it's inherently a problem if we use the same thing (header color) to communicate two different things (node type and node state)

@Pablo Vazquez (pablovazquez): What do you think? When muted, we could make the entire node red, for example?

William Reynish (billreynish) triaged this task as Confirmed, Medium priority.Jan 21 2019, 8:53 PM

Example:

Normal:

Muted:

Seems like it would solve the problem.

Mets 3D (Mets) added a comment.EditedJan 21 2019, 11:10 PM

While I think that solution would work for 99% of cases, it can conflict with the organizational purpose of the node coloring feature as it exists currently, which, admittedly, is not that commonly used.

Since 2.8 in general has been making an effort to move away from forcing the user to rely on hotkeys, I think an eye(hide) icon on the top right of the header would be fitting. The icon would be clickable and indicate when a node is muted (same as outliner object visibility eye).

Example:

This method does not work when the nodes are in a collapsed form:

Technically the eye means hidden, not muted. Elsewhere we are using the check mark icon for active vs muted.

Perhaps this could be a solution.

Here it uses both a check mark, plus opacity of the node:

Perhaps, to indicate a muted node, you can use a special overlay? You can draw it over the entire node, or only in the header:

IMO, even just making it transparent when muted is enough. The check mark does serve as an extra indicator, and would allow for the user to click it to set the state, which makes this feature a lot more discoverable.

I really like this idea, but in the options it is possible to set transparency for the background of the nodes, so in order to avoid conflicts, it may be worthwhile to add a decrease in the saturation of colors.

I think the transparency+checkbox sounds and looks pretty good! Checkbox definitely makes more sense than the eye icon.

@Vladimir (evilvoland) I don't think you can set transparency for node backgrounds so it shouldn't conflict? As far as I can see the color picker in the UI at least only allows RGB. Python API also only allows 3 values to be set.

IMO, even just making it transparent when muted is enough. The check mark does serve as an extra indicator, and would allow for the user to click it to set the state, which makes this feature a lot more discoverable.

I like the check idea, some nodes have the "preview" icon there already so it could become noisy. In that case I'd trade the Preview icon with the Enable/Disable/Mute icon.

I agree - in fact I don't even see what that icon even helps communicate in that context?

Added an entry to the UI papercuts for this: T62967

Technically it's not a bug, but more just a regular design issue/todo.