Hey there! It feels wrong to sort this thread into the bug category, but there is something about the UX, that I have the impression especially beginners struggle with a lot. It happens soooo often, that they accidentally start a link at the top of an IOBox, when they actually want to send the value downstream. Are there also others who can confirm this?
I don’t really have an idea how that issue could be addressed… maybe IOBoxes could dynamically change the direction of the connection when the mouse moves up or downward the IOBox while it holds a link? Or increase the snapping area and the arrow indicator on hover?
Ideally the UX reflects the fact that both directions are still possible - e.g. by drawing the link in a way that doesn’t indicate a direction. Another option is to have it adjust depending on the mouse position.
When getting near another connectable the link should take a shape that indicates the direction of the link that would get created.
One could theoretically connect an IOBox at the bottom of the screen with an input of a node above. So the link on the IOBox adjusting to either top or bottom can only happen in the same moment when you are getting near a pin, right?
I would like to get rid of the editor before creating an IOBox, but be able to call it and then immediately continue to patch in the selected direction based on the selected type.
For example, the editor could be called after connecting to the pin. When the IOBox type is already understood (or vice versa, to clarify it). For example, I still don’t understand why the Vector4 IOBox can’t be connected to the RGBA value? But in this UX case it could be done fluently.
There’s also a very old moment with the generic type of IOBox, because the UX gets confusing - you have to create an object, then go into its settings and select a type there, which is a lot of clicks. This could be replaced by the scenarios described above and adding the ability to specify the type immediately after creating the generic box.
I’ve written about it here:
We could also use segments and some distance from the centre instead of ‘buttons’ around the circle, so that we don’t have to aim.
The next preview build tackles the original topic of the thread.
Please report your findings and please stick to this one topic.
@yar Thanks for the wonderful in-detail write-up and sketching. It’s always good to read about ideas especially when they come with nice graphics. If you want to have more ping-pong than this please open a new thread in order to not mix topics here. Thank you!
The ability to link an unconnected IOBox flexibly to either top or bottom is wonderful. It will help a lot to speed up teaching vvvv to beginners, because it is happening to almost everyone who is patching in front. So it must also happen to many of those who are trying to follow along, which means they might get lost during the course. It’s great they don’t have to care about the direction of the link anymore in the future. Thank you very much for it.
And how cool would it be to get the editor with a slight swipe to the left, for example
I’m sure tweeks of distance and behavior depending on context are needed. But this could be an interesting solution, reducing clicks and adding a new layer of flexibility.
It can also be a series of such choices. Click → patch or editor → create or connect → name or editor
“ok” or “finish” also can be a choice
Yes, often in large patches the Y position of the nodes doesn’t match the dataflow, then this feature is hindering… and the case of the gif is a bug, I would say.
