The thing is, it would be great to not explain this at all. Being able to flexibly change the direction of a link after the click on a pad solved a common problem many beginners had when learning vvvv. Sorry for being so annoying about it, but it really was a problem that was gone. And now it is back…
1 Like
nah, you are not annoying. I misunderstood your proposal, that’s all. It’s fine for me to search for the solution together.
2 Likes
you can test-drive a new preview where this is addressed.
1 Like
I think it is really good like that, thanks! Yet unsure, if the “switching area” of the pad should be a bit smaller. But it might be the solution to the problem @yar had with the BCP.
I think I was a bit too fast, it seems in my first test, I was lucky that it worked right away. See in the GIFs how many of my attempts to grab the link and switch it flexibly between top and bottom fail.
let’s use the 109 and the latest version for some time to understand which feels better over time. Would also like to hear from others.
When evaluating please put yourself in the shoes of trying to achieve different things and if the solution is balanced to achieve both with ease - after getting used to the gestures of course.
It’s not always about switching link direction flexibly. It’s sometimes about the opposite - can be annoying if it does as @yar was pointing out.
The gifs don’t help so much as I don’t see if you click or drag. It makes a difference, as the drag direction is taken into account. When clicking it’s not so obvious and in the 112 a click always is a both-directions link. A drag will be a one-way link if the drag was vertical. If you want to reconsider you always can come back into that area and fix your link. But yeah as I was saying earlier. The area isn’t visualized and therefore it has it’s blurriness to it.
109 is less magic in that sense.
1 Like
I just installed 112 and that is quite interesting.
I was plagued by “the wrong direction thing” during Genuary quite a bit, for instance with splicer outputs in cases where the issue didn’t make any sense like dragging a link from the splicer output but it insisting to be on the inside.
This solution for it being actively switchable while being close is good, although in 112 the area where I can switch feels rather large sometimes.
I would be fine to it being relatively small around or just over the connector, so it doesn’t feel random when one works in more crowded patches.
The “going over the pad to change direction” feels pretty intuitive, so I wouldn’t want the area too large.
I definitely wouldn’t want another shortcut… ;-)
109 feels more rigid there. Not bad, more “logical” in a way, but if the change-area is really small or just over the pad, so it needs a conscious decision to change direction, I’d be very happy with the change to it being switchable.
@chk sorry, I guess I missed to explain that in the 112 you once have to leave the area. The reasoning was that you’d typically still want to give your initial gesture some credibility and only come back if you have to.
1 Like
@gregsn How many versions of the behaviour between 104 and 112? Is it worth trying different ones?
Surprising, but so far I like the direction we’re going! Good hinting!
But I really want this behaviour to become the default not only for drag and drop, but also for click-based behaviour. It’s like I expect it when I do it “the old way” and I get very frustrated when that expectation is violated.
Is it also possible to set the type of histeresis to this distance? The “direction cancellation” distance should be proportionally smaller than the “direction selection” distance (or is this already the case?).
1 Like
I have tried version 109.
Although I feel comfortable with it (largely due to the fact that click-based behaviour is implemented by default), I tend to agree with @chk.
I think my suggestions are not fully understood. I’m suggesting hints, not bringing back previous behaviour.
Let me give you some examples.
Try using your phone upside down. When you press the buttons, you’ll notice that you can’t press them the way you used to. That’s hinting. Your taps on the screen are processed and go through a series of transformations to tell the phone where you really want to tap, not where you are tapping. There’s a lot of this hinting in interfaces, sometimes you don’t even know it’s there. For example, in the old Opera browser (based on Gecko) there was one thing I still miss. If you selected text from left to right, the text was highlighted even in links, and if you dragged up or down, the link was “pulled” to move to another field. Can you imagine my disappointment when the old browser died? I was constantly dragging and dropping links instead of copying them. More importantly, it took me a long time to figure out why this was happening.
The 112 version seems to have the most correct direction of thought. But we need to fine tune this behaviour a bit.
I like that the app tries to notice where I have clicked - at the top or at the bottom. I like that the distance of the click ‘anchors’ my decision. In fact, I’m starting to like Chk’s idea of free choice of direction when the app tries to track what I’m doing. But what about the idea that the final decision should be based on a combination of factors? If we create a semantic category of “certainty of direction”, there would be plenty of opportunity to fine-tune this behaviour. I’m sure it could be useful in a lot of places…
In fact, I suggested earlier something conceptually very similar: distance anchors the decision, direction matters.
But let’s say we don’t have “left” and “right” with pins. But why can’t we consider that I move much more east-south-east than east-north-east? Angle of movement and amount of movement can be part of the engine for making such decisions.
1 Like
To illustrate what I mean as much as possible, I ask you to look at this patch. I’ve made an example specifically to make sure that what I’m suggesting is both possible and feels right. After making this patch, I have no doubt that this is how it should be done. Yes, it looks a bit complicated, but trust me, hinting in your phones is an order of magnitude more complicated.
DirectionDetectionWithHinting.vl (162.1 KB)
DirectionDetectionWithHinting (COMMENTS).vl (170.5 KB)
DirectionDetectionWithHinting (COMMENTS) fix.vl (171.6 KB)
If you implement this algorithm, please consider some important aspects:
-
I’m not sure, but maybe recording mouse values with frame discretisation is not a good idea. It might be better to use an asynchronous loop.
-
Some values need to be fine-tuned. There are a lot of values, but it doesn’t make sense to output them to the application interface. Let’s put these values in a config file so that everyone can tune them and share their config.
-
Some values should probably not be linear and it would be good to provide a coefficient for this non-linearity. You can see that I used Tween with a quadratic curve for the visualisation - I suspect that the angle deviation (dot product) values can be modulated by this non-linearity to emphasise the angle. Perhaps the tendency coefficient could also be non-linear - a smaller value closer to the centre and a larger value further away (or vice versa, hypothesis needed).
-
There are a lot of smaller corner cases. Prepare this algorithm to interact with other aspects of patching, such as shortkeys and behaviour modification by contexts. I would immediately consider the case that one day we will have multi-input pins. The most bothersome cases are proximity of other objects, drag and drop, and navigation.
-
There is a chance that a circular detection area may not be the best idea. What if we make the click detection area rectangular or oval? But re-entry region is left circular? This was an example. Real pins have a more upright shape for entry and grip.
1 Like
I agree, this feels really good, and also illustrates very well what I mean with switching between top and bottom when hovering the pad again. I am also convinced it would work very well with both modes of “dragging a link” and “attaching a link to the mouse”.
Found a glitch
In general, it seems that there are strange triggers if you click too often. Perhaps it’s the same error. Is it worth catching the other behaviour?
6.0-0117
this was indeed a bug which is fixed now
2 Likes
@chk @yar I appreciate your feedback and will come back to you when our schedule allows me to get back on it.
1 Like
It seems that in this case what I’m trying to do is impossible, but I realized it after five attempts to do it. Probably should be considered as a visual bug.
Hey yar,
I can see that you are moving your mouse in a fast pace over the datahub you are trying to connect to, and it looks like you are frustrated, but I can’t see why you are doing this.
Please before looking into it can you record a gif that calmly shows the issue. Consider enabling this extension:
so that I can see what it is you are doing.
The above gif doesn’t tell me much…
You say: it doesn’t work four times and the fifth time it does. What did you change?
@gregsn I was trying to connect a sequence to a sequence (or a spread to a sequence, etc)
I’m mainly using click-based linking, not draging
By the way, maybe it’s worth adding a slight visual click effect?
I tried to reproduce that situation
It’s not even a bug
It’s just a UX problem
ux_spread_sequence.vl (5.9 KB)
1 Like