In discussion with some others about organization and grouping nodes in flows, I realized I had two specific annoyances when working with them... thought I should actually mention it here and see if there's any appetite for a change.
When I click on node in a group (without selecting the group first), it selects the entire group, even though the intent is to manipulate the NODE I'm clicking on. Im constantly accidentally dragging stuff around because of this that I didn't intend to. Would be nice if it could identify that I'm clicking on the node, and not trying to select the group...
In contract, when I click just on blank space in the group, but NOT on a node it just does nothing. It seems more intuitive that clicking on said empty space would actually select the GROUP in this case?
I don't know how click/drag selection interacts with those, so there might be some good reason for this that Im not catching, but thought I'd ask and see if this makes any sense.
Yes it's too easy to drag groups around accidentally.
IMHO the ideal actions are:
Click on a node selects the node.
Right click on a grouped node offers "Select group" as an option
Click on a group border selects the group. (same as now)
Click on empty space deselects everything. (same as now)
The basic model here was to mimic things like powerpoint which select the group on click... as we thought that users would be familiar with that interaction... I'm sure this could be changed if there was a good consensus on what the better interaction should be.
(don't forget ctrl-z will undo any accidental moves)
It makes no sense to me that click/double click actions are different if a node is in a group.
Simplifying my list above I suggest
Actions should ignore the existence of a group except
Right click on a node offers "Select group".
Click on group border or title selects whole group. As now.
Double click on group border or title opens group config. As now.
As Dave said, in many applications that support grouping, the group becomes the thing you interact with first and you have to go 'into' the group to interact with its contents.
There are other applications that do it the other way - even when grouped, you can still interact with the contents directly.
I knew we wouldn't satisfy everyone with whichever approach we took.
But feedback is useful - and thank you to @i8beef for starting this thread and enabling others to express their view on this.
In those applications is everything inside a group? It is the fact that, for example, double clicking a node has a different effect depending on whether it inside a group or not, and whether the group is already selected, that I don't like.
I made that point when groups first appeared, but it didn't get any traction with others, if I remember correctly.
I love the grouping functionality, and it makes a lot of things better for sure! These are more annoyance, and, yes, I've learned to live with them (and am well aware that "Undo" works because of how often I accidentally move stuff ), but figured if we never give feedback on this you'd never know how if the design choice works or not for everyone.
As a developer, I cant say I wouldn't have gone with a similar approach to "select group first, and then interact", as I'm sure that simplifies some of the interactions by segregating the contexts... especially when you have groups inside groups, etc...But as a USER I think the paradigm I'm more familiar with is
If I click on any object in the hierarchy directly, my INTENT is interacting with that specific object... I actually find it JARRING that ISNT the model here, though Im unsure why I feel trained to that expectation already instead of how its designed... I feel like I've interacted with plenty of apps that do that, but cant come up with an immediate example.
Selecting the group by EITHER (a) clicking anywhere inside it (but not another object inside it) or explicitly (b) clicking the border (like now). This one I could see having implications for click/drag, or selecting lines between nodes or something, so open to ideas on that one...
I would think with group selection for instance if I have a group inside a group, if I click anywhere inside the CONTAINED group, but not on a node in it, that it should select that internal group, but if I click anywhere in the OUTSIDE group without clicking anywhere inside the internal one, it'd select the outside group.
Basically a paradigm of "the thing I clicked on, no matter where it exists in the hierarchy, is what I am intending to interact with".
I’m glad it’s not just me that finds this totally non-intuitive!
There are many potential ways around it, but personally, if I click on a node, regardless of whether it’s in a group, I’d want that node to move and not the entire group.
Maybe it’s something that should be set in a preferences option then, so people can choose their preferred behaviour?
Given the overwhelm feedback in this thread, plus I don't really see anyone supportive of the current behaviour, then we should look at changing the behaviour.
Can't say when that'll happen, but it is on the radar.
), but figured if we never give feedback on this you'd never know how if the design choice works or not for everyone.