Much Easier Cluster and Array Selection

[Darin.K]

There seems to be little doubt that selecting objects using the old selection rectangle is a "crapshoot" at best.  While I probably won't complain too loudly if that idea is implemented (250+ Kudos, seems plausible), I will suggest a much more modest solution to a very vexing problem for me.

Instead of new rules for selection (right to left versus left to right), I propose that LV consistently follow the existing rules.  In particular, the selection of Clusters and Arrays seems to deviate from the norm in a very annoying fashion.  If I clip just a single pixel of a control with the selection rectangle, I have selected the control.  Workable, fairly easy to swipe and select.  Now with a Cluster, for example, if I MISS just a single pixel I end up selecting the contained controls and not the cluster itself.  You get the idea, I select, grab, move, then drop only to discover that I have emptied the cluster or array which sits there mocking me. 

My proposal is that selecting a portion of a cluster or array be treated the same as every other control or decoration and select the entire object.

[GregR]

There really is valid reason for container controls (array, cluster, tab control) to behave differently. If they strictly followed the same rules then you could never drag select any of the contents of these controls, because any selection that you did inside the control would select the control. So now you can't drag select your buttons inside a tab to align them.

You could say that container controls should select anytime that you overlap their border. This still means you are treating container controls differently from other controls and you have disallowed a single drag selection from selecting things inside and outside of a container control. Similar to above, you now can't drag select the button inside your tab control and the button outside your tab control to align them.

Another point to consider is that this behavior matches the behavior on the diagram. Would you want to make the same change to structures on the diagram or would you have them be different. I favor all "things that can contain things" behaving the same and allowing them to be different than  "things that can't contain things".

I'm not claiming that our current behavior is the model of usability that all features should strive for, but it was picked for a reason. I think changing it introduces at least as many problems as it solves.

[tst]

I agree with Darin's feelings on this (and note that he only said clusters and arrays, for good reason) - while it is true that if this change is made you would lose the option to drag select multiple items, I'm pretty sure that most of the time I want to select the entire array or cluster and when I don't, I can shift select multiple elements.

It also happens quite often (especially on the BD) that I drag select and fail to do so correctly to a cluster and then moving the code causes the cluster to explode. Easily undoable, but annoying none the less.

[elset191]

I do the same thing with loops all the time, where I'll try and select the loop by click dragging, but miss all the borders.  Then of course, when I am moving the stuff, it just stretches the loops rather than moving them. 

[Dragis]

i run into this same quirk on a day to day basis as well. the way many development tools i use solve this issue is by using multiple clicks to dig into a container like a cluster. the first click anywhere on or in the container selects the entire container. clicking again will select the next level item under the click location, which may be another container. continuing to click will dig deeper and deeper. since most hiearchies i use are just a couple levels, it works well. when it's more than that, a shortcut (perhaps ctrl-click) can go directly to the element under the mouse.

[Darin.K]

There really is valid reason for container controls (array, cluster, tab control) to behave differently

Perhaps. 

You could say that container controls should select anytime that you overlap their border.

I would say this is the obvious behavior, not an alternative.  Backgrounds should never be live for clicks like that.

This still means you are treating container controls differently from other controls and you have disallowed a single drag selection from selecting things inside and outside of a container control.

IMO you have made a common operation awkward to enable a relative corner case.  As tst says, we can shift-select pretty easily in many of these cases anyways.  In 18+ years I have probably selected clusters and arrays at least 15000 times plus or minus a few thousand.  I have probably wanted to select a control outside of a cluster and one inside via click+drag probably 5 plus or minus 5 times.

Another point to consider is that this behavior matches the behavior on the diagram. Would you want to make the same change to structures on the diagram or would you have them be different. I favor all "things that can contain things" behaving the same and allowing them to be different than  "things that can't contain things".

Now you are moving away from this suggestion, but since you asked, I believe the fundamental flaw in this line of reasoning is that there has to be a once-size-fits-all selection tool.  The behavior IMO should be linked by the type of tool, so I would suggest we need at least two selection tools.  One that ignores containers, and one that does not.  It is very common in other programs where graphics are copied and pasted.   One type of tool will select an entire path if you select anywhere on it, another only selects the vertices you choose.  Very intuitive and fast, I can make very complicated selections in less time than it takes to grab an array constant with hidden index controls in LV.  I would have suggested this more general approach, but people seem to like the AutoCAD method of cramming more behavior into a single selection tool. 

(And while I am complaining, am I the only one that hates the behavior of combining selections, specifically how the intersection of the old and new selections becomes deselected.   It violates by sense of Set theory, we should be either adding or subtracting from a current selection....)

I'm not claiming that our current behavior is the model of usability that all features should strive for, but it was picked for a reason. I think changing it introduces at least as many problems as it solves.

In terms of Clusters and Arrays I am still a bit skeptical that it will introduce problems, at least to operations performed with the frequency of selecting clusters and arrays.  Some minor operations may become awkward, maybe.  Is there a concrete example?

[GregR]

Going down the road of multiple selection tools is an entirely different thing. I know there are long time users that still disable the autotool, but overall I think it has really helped usability for the vast majority of our users. Anything that moves us back toward explicit tool selection is going to have significant hurdles.

I brought up the issue of consistency largely because part of the original idea proposed "LV consistently follow the existing rules". I assumed that meant consistency was favored. I agree that the selection of items inside and outside a container is much more common for the diagram and for tab controls. It is less common in clusters and rare in arrays. So the question is which wins out? Is it better for containers to be inconsistent with themselves to better match expected usage?

As for a concrete example, I mentioned doing a drag select to align a control inside a tab with a control outside the tab. This use case can also apply to aligning things inside a cluster with things outside the cluster. For 2 controls shift click is easy. If there are multiple controls both inside and out, then the drag select is the natural operation. Another issue I have run into is trying to select multiple controls inside a cluster where there is no empty space inside the cluster to start the drag. In this case I will start the drag outside the cluster simply so I can find a spot to click. In general I think this idea would hurt usability of selecting multiple controls inside a cluster. That could still mean the change is warranted.

[Darin.K]

Multiple selection tools can easily fit into the autotool, but that is more of a distraction right now.  An interesting and important one down the road, but for this idea let me sum up my thoughts.

1.  This particular idea is for Clusters and Arrays only, not tabs, not diagrams.  The use of clusters as UI elements may be convenient, but is not their fundamental purpose.  They are datatypes with controls, indicators, constants, etc., like all other controls.  Tabs are for UI purposes only, they are strictly containers, their datatype does not reflect their contents.  They can be treated differently as far as I am concerned.

2.  You are sacrificing consistency amongst datatype controls to enable a process (multiple selection inside a cluster) which I feel belongs in the control editor anyway.  You are using a cluster after all, you should be Type Def'ing it.  Perhaps inside the control editor you can keep the current behavior.

3.  As a bit of a thought experiment compare the path you must take to shift-select multiple controls versus drag-select.  Almost identical, you just have to click a few times along the way in the first case.  Now compare the path you must take to clip the border of a cluster to select it versus enclosing the entire control/constant.  Potentially a huge win.  You can shift-click the cluster itself, but try finding that 1-pixel sweet spot a few times on a laptop.

[GregR]

You definitely have valid points and I'll even throw in an extra one for you. There is already an example of a container control in LabVIEW that works the way you suggest. Many types of refnums can contain a control (datalog, queue, notifier, user event and control refnums). These do select the entire control any time the selection rectangle touches them at all. This is very similar to the array case.

Personally I'm still on the fence about the cluster, but that is why this is a public forum. Get enough kudos and my opinion doesn't matter.