The ability to add, link and position a node in one action is quite powerful, and for the positioning part you need dragging. If needed there could be a modifier key to hold before adding, to avoid issues with mis-clicks when trying to drag the node. But not needing that at all would be nice.

A bigger distance threshold should definitely be added, though it doesn't solve the whole problem. Some threshold when near other sockets may also help, to avoid adding a node when failing to connect? Maybe it also helps to check the drag direction, that it's not into the node? Not sure if all that is needed.

Further:

• Nodes that get added can be positioned so that the output socket is at the location where the dragging ended. This allows for more precise positioning, otherwise you're required to move the node afterwards unless you are good at guessing where the node will end up exactly. Though this might require lowering the distance threshold, it's a trade-off.
• The link line could remain visible while the search menu is open. Potentially the search menu could be in roughly the same place as the node would be as well.
• If there are multiple compatible sockets, the search menu could list all of them. For example Light Path > Is Camera Ray, Light Path > Is Diffuse Ray, .. . This should be a relatively change I think.

There was a debate in the original patch that a better threshold or some system to avoid misactivation might be needed.

I would consider this not too necessary to have this feature out in the wild for the general user. This could be a feature that could be added as experimental or with an Interface prop toggle for user preference.

The issues highlighted with this was socket threshold, which has no pre-highlight per Blender UX in the node editor and the socket threshold is very low - practically drag to the socket to connect. If this were to be useful and not annoying by missing a socket connection, then the socket connection threshold should be increased and a highlight on the would be connected socket should shown, giving the user expected behaviour. If no highlight, no add search menu. If the noodle is in the connection hot zone, then the search menu wouldn't trigger. The issue of misactivation (which should never be part of the UX) is another issue with connecting sockets and should be another task.

This one is I would say.. good to go, at least even for experimental.

Some insights based on Campbell and Brecht feedback:

• (Campbell) Ctrl+Click over a socket to show-up the search: as Brecht pointed, one of the strongest points of this behaviour is placing+creating+linking all in one action, so this alternative will break that freedom.
• About adding some threshold, it will add more complexity but if it's only for when you miss a socket connection (some rect area around node sockets) I believe that little one can make a big difference to improve UX.
• I really like this from Brecht: "If there are multiple compatible sockets, the search menu could list all of them.". It's something I really thought of, but for further... Not sure about complexity in adding this though.
• About this from Campbell: "...users might wonder where else Blender uses drag actions to expose some hidden functionality", I'm aware of this and it really should be threated with UI/UX team. I have some ideas like showing some little icon/text when dragging so user gets visual feedback as you can add a node from that action, but not sure about the best way it can be tackled or if it will end up into some intrusive visual feedback.
• (Brecht) About keep node link being drawn, I like it and I though of it, but as the modal has to finish and the UI block is apart from it I can't think of a not dirty solution now, but I would like to dig into it as it gives more feedback on where the node will be placed. (maybe some immediate drawing callback?)
• About adding some kind of key modifier to invoke it, I would prefer not to do that and keep it simple as possible. As for the same reason we have the powerfull and efficient CTRL+RMB to cut links but users keep using drag&drop to detach links as maybe (?) feels more handy without keyboard dependency as well as it is not a hidden feature.

About this:

"...users might wonder where else Blender uses drag actions to expose some hidden functionality"

Well, this kind of functionality has been present in UE4 since a lot of time, and no one wonder where can they drag to show up some kind of hidden menu :)

It's just a feature of the nodes, it works in shader nodes, it works in blueprint (visual programming) nodes, it works everywhere, and that's it.

While for shaders and compositing it may seem something "good" but not vital, for particles and other kind of nodes this is basic, this helps users to understand what works with what, this ease the process of learning to work with nodes, and it's a "thinking" asssistant, in UE4 is a big success, and I always wondered why Blender didn't have something like that.

I think it's important to polish the concept and reach a point where the implementation is solid, but don't be afraid for the "users may think...", in any case, let the users to test it and ask them what they think, don't assume what users may wonder, that's what daily builds are for partially, specially now with the experimental features options, which BTW make the users wonder where can the enable some more hidden functionality :)

A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor - so dragging the socket on an empty area will add a new node, from the videos linked Unity does this already.

This way it won't be a hidden-feature.

In T78919#978880, @Andres Stephens (Draise) wrote:

I would consider this not too necessary to have this feature out in the wild for the general user. This could be a feature that could be added as experimental or with an Interface prop toggle for user preference.

For these kind of simpler features we should not have them in an experimental state, but rather finish them before committing.

In T78919#978883, @Juanfran Matheu (jfmatheu) wrote:

• About adding some threshold, it will add more complexity but if it's only for when you miss a socket connection (some rect area around node sockets) I believe that little one can make a big difference to improve UX.

The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me.

• I really like this from Brecht: "If there are multiple compatible sockets, the search menu could list all of them.". It's something I really thought of, but for further... Not sure about complexity in adding this though.

It shouldn't be complex, just means that every search entry is a node + socket instead of only a node.

In T78919#979255, @Campbell Barton (campbellbarton) wrote:

A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor - so dragging the socket on an empty area will add a new node, from the videos linked Unity does this already.

This sounds good to me.

I would suggest another functionality, when u "ctrl+lftclick", for example, on the node in the search bar it will preview the node and let u choose which socket u would like to attach to it

In T78919#979503, @Brecht Van Lommel (brecht) wrote:

A dragged distance threshold seems the most important to me.

That sounds nice and easy to add. If wanted, I can try to add it so we can see it in action and make a better idea.
Also, some design into how to communicate user if node link is not valid or it is - for adding a node - based on that threshold, such as color change or just the text/icon (shows-up or not).

It shouldn't be complex, just means that every search entry is a node + socket instead of only a node.

Perfect 👍 I didn't dig into it yet, so that's why I was not totally sure.

In T78919#979255, @Campbell Barton (campbellbarton) wrote:

A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor

Great for me, I already know how to draw text, I can add it so we can give it a try.

Looks like a nice feature. One thing I noticed in the video was that the search menu would keep the last search term (standard behavior, I know), but it often wouldn't show anything because the last created node isn't valid for the new socket. It seems to me that in this case, remembering the search term is more of a hindrance than a help and I'd suggest having it show up with the search field blank each time instead so that you can immediately see all of the available node types for that socket.

In T78919#979908, @Ryan Inch (Imaginer) wrote:

Looks like a nice feature. One thing I noticed in the video was that the search menu would keep the last search term (standard behavior, I know), but it often wouldn't show anything because the last created node isn't valid for the new socket. It seems to me that in this case, remembering the search term is more of a hindrance than a help and I'd suggest having it show up with the search field blank each time instead so that you can immediately see all of the available node types for that socket.

I agree with you

In T78919#979503, @Brecht Van Lommel (brecht) wrote:

The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me.

Well, if the issue is not missed sockets, then what is it? Is it dragging a line and releasing Left-click in an open area accidentally be something that users do that commonly?
We must keep in mind that Right-Click and ESC are both quick ways of canceling any unwanted popup windows or behaviors. And that this is a behavior present everywhere in blender and something users instinctly do.
It is extremely simple, quick and intuitive for the user to Right-Click in order to close the unwanted popup, IF unwanted, and go back to what he was doing.

Dragged the line but decided you didn't want to?
Release Left-Click anywhere, knowing that the popup will appear,
Press Right-Click to exit/close it, done.

This is also the same argument for not implementing a Ctrl-Click to drag-create nodes. Why force a key-press before every operation, and instead not keep it simple allowing the user to simply right-click or press esc after only those rare unwanted accidents?
I'm very certain that people will release Left-click while dragging purposefully much much more frequently than unwillingly doing it by accident.

This threshold idea seems to be more of an arbitrary limitation for the feature than an avoidance of unexpected behavior, after all any threshold would basically impede the user from drag-creating nodes very close to the originating nodes.

I created this GIF example.

I also added in the example above a suggestion for the secondary "socket popup" which lists the socket names and colors/types (knowing the type, image/vector/value/etc, may be important).

I also reinforced the idea, discussed in the original proposal, of using the regular Shift+A menu instead of a simple Search/History menu. (Although I agree that a History is very convenient)
Sometimes navigating towards an option that you use frequently is much faster than removing the hand from the mouse in order to start typing it in the keyboard. Not to mention that sometimes you don't know or remember the name of a node or you're not sure of what you want. The regular list menu helps that.

In T78919#981552, @Evandro Costa (Arkhangels) wrote:

In T78919#979503, @Brecht Van Lommel (brecht) wrote:

The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me.

Well, if the issue is not missed sockets, then what is it? Is it dragging a line and releasing Left-click in an open area accidentally be something that users do that commonly?
We must keep in mind that Right-Click and ESC are both quick ways of canceling any unwanted popup windows or behaviors. And that this is a behavior present everywhere in blender and something users instinctly do.
It is extremely simple, quick and intuitive for the user to Right-Click in order to close the unwanted popup, IF unwanted, and go back to what he was doing.

Dragged the line but decided you didn't want to?
Release Left-Click anywhere, knowing that the popup will appear,
Press Right-Click to exit/close it, done.

This is also the same argument for not implementing a Ctrl-Click to drag-create nodes. Why force a key-press before every operation, and instead not keep it simple allowing the user to simply right-click or press esc after only those rare unwanted accidents?
I'm very certain that people will release Left-click while dragging purposefully much much more frequently than unwillingly doing it by accident.

This threshold idea seems to be more of an arbitrary limitation for the feature than an avoidance of unexpected behavior, after all any threshold would basically impede the user from drag-creating nodes very close to the originating nodes.

I created this GIF example.

I'd like to know if a threshold would impede the user from creating that node in that middle space, because he didn't drag the line far enough. Would we be forced to drag the line far away to open the popup, then after to grab the created node and put it in place?

I also added in the example above a suggestion for the secondary "socket popup" which lists the socket names and colors/types (knowing the type, image/vector/value/etc, may be important).

I used darkening to indicate which socket will be targeted, but this user proposal of having a Highlight appear around the target socket would also solve the issue.

I also reinforced the idea, discussed in the original proposal, of using the regular Shift+A menu instead of a simple Search/History menu. (Although I agree that a History is very convenient)
Sometimes navigating towards an option that you use frequently is much faster than removing the hand from the mouse in order to start typing it in the keyboard. Not to mention that sometimes you don't know or remember the name of a node or you're not sure of what you want. The regular list menu helps that.

This is very interesting..! So you're saying, if you left-click and drag out, it will do as normal, but if you let go, then it pops up and searches/creates a new one? If so, that sounds good to me I think.
Then yeah ,if you can right-click to cancel as you said, that would be good as well.

Bump, will this be implemented for 3.0? I certainly hope so! It looks practically done.