Node Completion

Get it, it’s like Code completion. I know, not quite the same thing, but catchy.

From this thread came an idea of warnings if a node would never, could never execute due to lacking input connections.

I think this could be more broadly thought of as ‘node completion’

For example, at this very moment I’m using Make Text Field, and it wasn’t working. I had forgot to connect the Window.
The Window is all the way at the end of composition. And for almost all Vuo compositions, and certainly for all compositions initially, there is only one window.

So, Vuo could suggested connecting this automatically, (and nicely hiding the cable), if possible.
If multiple options are available, it could offer those.
If not possible, it could show warning.

Here’s a first pass at the UI.

1 Like

nice work @keithlang!

I call these kinds of usability suggestions sandpaper. They take the friction out of using Vuo for users of all levels. But importantly it’s also an Onboarding type of feature. IMHO Vuo would benefit with a few more onboarding ideas like this.

Vuo has become easier to learn and use over time without doubt, even as the code under the hood has become more complicated. As is often the way with software, architecture, design, writing, simple on the surface means more work under the surface to achieve the elegance simplicity desired.

To me some small nonintrusive prompts like this could really help novice and intermediate users learning to use nodes for the first time, while also adding UI/UX improvements for Vuo ‘old hands’ like yourself.

Thanks @useful_design

Perhaps this could be wrapped into something that includes a compact Fire on Start.

‘Sandpaper’ is one metaphor, but I think it’s more crucial. Without input to some nodes (often at the beginning of a composition) the entire composition won’t do anything. But there’s nothing in the Vuo app that would indicate that there’s anything wrong…the Composition Loader will happily launch and display black.

@keithlang — Sorry for the belated reply. There are so many good ideas encompassed in this proposal that it goes beyond the scope of a feature request. I’m converting this page to a discussion, with the possibility to break it down and branch more specific feature requests.

Maybe we could think about a first step that would be a useful starting point and a manageable size for a feature request.

One possible first step would be to show warnings for nodes that won’t do anything because they don’t have any incoming events or any trigger output ports.

Or another possible first step would be to provide a more convenient way to make common connections — right-click on a port and get some options, e.g. if it’s a Time port then connect to an existing Fire on Display Refresh node in the composition.

Or there are other possibilities. If there’s one mistake / missing connection that stands out as being particularly common or hard to diagnose, maybe we could start with that.

Thoughts?

1 Like

I second this notion of what jaymie said, being able to right click a node port and choose to connect to existing node or create a new connection from the node library. it would help when using a node that has generic types that has not been connected to anything. for instance add input 2D point or 3D point to a make points along line node. this node doesn’t know what its inputs are until its connected to another node down stream where it can get its data type from.

equally being able to right click an output port and add a connecting node from the library might be useful behavior. if you right click the make text field node it gives a list from the library for change to a different node. something like this behavior for the node port might be useful. if not at the least be able to right click and connect to an existing node in the composition graph. or like * jaymie* said add fire on display refresh or other common node to a time port. I suppose right clicking and choosing from the node library would make a pretty long list but maybe not for some nodes can only take one type of output.  

I would vote for showing warnings, since Vuo currently has no ‘compile errors’. There are increasing versions of this this, but if we can say, in some cases, a node definitely will never run, then that could be incredibly useful. We could build from there, for example guiding the user with suggestions, making Required ports visually different, etc. etc.

1 Like