Node Editor display/Modifier state interaction

This is regarding the Node Editor behavior that prevents the node editor from displaying the node network if the node Modifier is not selected/active. I’m cutting and pasting from my longish post on BA. The core issue is: UI inconsistency and user experience, not whatever programming internals are causing these issues (iow, deal with it, that’s your job):

Users can see networks, and attempt to select them, in the Node Editor header dropdown list, even though it is not actually possible to select them because the Node Modifier is not active.

This is inconsistent with the established Blender philosophy of “hide it when not appropriate” (which I profoundly disagree with) – if the dropdown cannot display a selected GN network because of the selection state of the Modifier, it shouldn’t display the network dropdown AT ALL.

Showing the network establishes an expectation in the user that it should be selectable, but it is not. There it is, you can click on it, but nothing happens.

A better approach would be to “ghost” the network listing if the appropriate modifier is not selected. This alerts the user that, yes, the network is there, but something isn’t lined up, “what could it be?”. It prompts or cues the user to examine the state of the app.(footnote)

Another approach would be for the app to be helpful and on first use, the app goes ahead and activates the GN Modifier.

A concurrent issue is the redrawing order of the Node Editor window: say you’ve got 2 modifiers, a GN modifier and a Solidify modifier. If you choose them successively, nothing happens in the Node Editor window until the mouse travels over to it. The user is doing something, but nothing is happening. This is not useful: messages or whatever should be sent to the GN editor window when a Modifier is selected to cause it to update. Whatever plumbing is going on behind the scenes shouldn’t affect the user experience – when the user does something, something should happen then, not when they happen to pass their mouse over every open window “just in case”.

(footnote: IMO the Blender philosophy of “hide it when not appropriate” is a big part of why users continue to find the Blender UI difficult to learn: functions disappear and reappear leading to confusion. Use of GHOSTING instead of hiding would lead to a more stable, predictable UI, while cuing the user that "yes, you’re in the right place, but not in the right state to use this feature.)

1 Like

It’s great that you’re offering suggestions on how it could work better, however you’re shooting yourself in the foot when writing things like

I hope you get a positive response but you didn’t set things up very nicely

(otherwise I completely agree about your proposal)

3 Likes