Clusters as a concept should only exist on the block diagram

[Mads]

Clusters can be a useful tool for the programmer. Its role is on the block diagram. On the front panel the cluster's only useful feature is better served by grouping and decorations.

-Clusters force you to have all the controls within it bundled together within a box on the front panel. A box that even interferes with keyboard navigation. If you want one of the controls to be located elsewhere, you have to choose between the usefulness on the block diagram, and the best design of your user interface. The link is just unnatural.

 I can understand the philosophy behind the current solution. It maintains a coupling between the block diagram and the front panel that is consistent with much of how other parts of the IDE works.

However, once you have established that clusters only exist on the block diagram, the need for a front panel representation of it quickly vanishes. There should be a way to get an indication on the front panel of the controls  that are bundled together. It should be obvious to the programmer that deleting a control that is defined as part of a cluster will affect the cluster on the block diagram etc., but not much is needed to achieve this really.

Breaking artificial couplings are always good, but never pain free. They break old habits. But the end result would be a more flexible and intuitive solution for both programmers and end (application) users.

[fabric]

So I guess we will need to be able to link block diagram clusters to connector pane terminals, right?

Kudos, because I like crazy ideas like this 🙂

[Mads]

Thanks fabric.

Linking the cluster to a connector pane could work the same way as it does today. Just click on any of the controls that are part of the cluster, and the connector pane will take the cluster as an input.

Here's another idea though; the connectors are really part of the code, not the GUI. It belongs more in the block diagram window, than in the front panel window (although having it in the latter as well is a nice shortcut). So the connector pane should be available as part of the block diagram, and you would link things up by clicking the terminals, not the controls (!). This has been suggested in ideas like this one - but I've never seen it defined as an idea on its own, perhaps I should post it. It could have a lif eon its own.

[PaulG.]

I find the structure limitations of front panel clusters annoying. When I call a typdef cluster and place it on the front panel I still want it in a neat little group as it is now, but no "cluster" box around it. I could move the cluster controls freely around the front panel. Yes. I like it.

[LV_Pilot]

In order not to break existing code, one could add an option to the control like "allow individual position for cluster elements". If you check it, the border disappears on the front panel and you can freely move the controls of the cluster around.

I also like the idea of being able to define the connectors from the block diagram.

[AristosQueue (NI)]

Speaking as a LV user, not as a member of R&D: No support from me on this one.

I agree with the sentiment that clusters have no place on *user visible* panels. And, as such, you should place your controls where you want them on the panel and then unbundle your cluster on the diagram and connect it to the relevant controls. If your cluster is directly on a user visible panel where you care about the layout that much, you've got way too much coupling between your implementation and your UI.

> you have to choose between the usefulness on the block diagram, and

> the best design of your user interface. The link is just unnatural.

No. You should use the best design for the block diagram on the block diagram and you should use the best design for the front panel on the front panel. Pretty straight forward. As a nice side-effect, when (not if) you modify your cluster to add an element, your carefully designed panel doesn't get blown away when LV has to update the typedef.

[AristosQueue (NI)]

Paul G: If you still want the nice cluster of controls but no box around it -- I still think that is a bad idea, putting a cluster on the user panel -- but you can do it by using the Classic Cluster. The typedef has the border, but the instance does not, like this:

[Broken_Arrow]

One of the most honest Ideas I've ever seen. Going for What's Right rather than What's Popular.

[Mads]

Aristos wrote:
"No. You should use the best design for the block diagram on the block diagram and you should use the best design for the front panel on the front panel. Pretty straight forward. As a nice side-effect, when (not if) you modify your cluster to add an element, your carefully designed panel doesn't get blown away when LV has to update the typedef."

Yes, but why not make LabVIEW smart enough to work with you on this, not against you? Your solution is that you have to manually convert between the user interface representation (separate controls whenever it is inconvenient to be locked within today's restrictions of a cluster) and the clusters you want to have on the block diagram. My solution is to keep the good part of the cluster (it is / can be linked to controls on the front panel), but remove the need to drop clusters whenever their current shortcomings get in the way (!).

To me Aristos it kind of looks like what you are really arguing for is to not have clusters on the front panel at all. That is closer to a "correct" solution in my mind as well, but lacks the (occational) convenience of the current solution. We can expand on that using this idea for example, or we can skip clusters on the front panel altogether. Today's solution is in an arbitrary middle.

[AristosQueue (NI)]

> To me Aristos it kind of looks like what you are really arguing for is to not have clusters on the front panel at all.

If we are talking about end-user visible front panels, you are correct. Clusters, classes, variants, refnums, and enums should only be on programmer-only-visible panels. They are not end-user UI elements and shouldn't be used as such. Arrays are ok if used as indicators, not if used as controls.

(Minor exception can be made for enums if you know that your software doesn't have to support localization, but even then, it still runs afoul of the late-in-development-fix-spelling-bug problem that creates tight coupling between UI and diagram; I'd rather put a ring on my end-user panel and translate it to/from the enum value on the diagram.)

Just a reminder that we're talking about my personal opinion of good software practices... in this, I am not asserting anything on behalf of the LV R&D team as a whole. This is me as a LV User saying I wouldn't want my dev team spending time on a feature that would only encourage people into bad habits. Given that LV cannot possibly autogenerate your UI from modifications you make to the cluster, the cluster data structure that is subject to change throughout development shouldn't be tied to your panel design. This is especially true since there are frequently values in the cluster that you do not ever want to show on your end user panel because they are temporary values or embedded refnums, etc.

> (separate controls whenever it is inconvenient to be locked within today's restrictions of a cluster)

Not "whenever". Always! You get better events handling, clear separation in your tab ordering, a stable UI when updating the cluster, the ability to choose to show or not show values within the cluster, localization of labels independent of your cluster, and so on.

[Mads]

Ok, I get what you are saying. I have never been a fan of the idea that we should discourage bad habits by making things less user friendly though. 

If clusters do not generally belong on the front panel they should be removed completely from the control panel (But keep the possibility to link clusters to the connector pane). If clusters are kept as an option on the front panel, it should be possible to associate controls with a cluster on the block diagram without physically having to put them into a box on the front panel.