Block Diagram Terminals Improvement

[JackDunaway]

I continually find myself fussing over the "configuration" of terminals. There are many permutations of icon/condensed view and label alignment, yet little consensus thus far for a standard.

My goal is to convince you this: Having different "flavors" of terminals does not make LabVIEW easier to understand or more "customized" to your preferences or learning style. Instead, it creates a source of confusion for new users to identify these Block Diagram components, and creates a hassle when it comes to formatting new or existing VIs to "your style". And no more label gymnastics trying to fit what should be a  into a  or a .

Just a few Common Terminal Configurations:

1. Default Alignment - Not too bad, but not so great for stacking terminals vertically
2. Block Diagram Cleanup Tool - Interesting choice of label alignment...
3. CTRL+Space then CTRL+T - This is the "best" style, but it falls short in correctly aligning label in Icon View (arguably of inconsequence, since Icon View is not "best" style)
4. The "Rogue Drag" alignment - Now where'd that label go?
5. The "Monk" alignment - Everything has to be perfectly snapped to center
6. The "There's a 'Size to Text'??" alignment - AKA - "This is what happens when I open your VI on my system" alignment
7. The "Don't Stop - Believing - Hold on to that Feeeeling" label - I can't let go of LV 4.0 or Power Ballads
8. The "But it takes up too much BD space - I'm'a remember what it's called" guy - or worse - "Neat, terminals can all have blank labels!!"

Oh yeah, and to add to the confusion of configuration permutations, we have some more ingredients:

Many Ideas - some very popular - have hinged around Terminal Configuration. Respectfully, I think they should all be supplanted by this Idea. The goal here is to eliminate even the need for a configuration:

1. Default Option: Do NOT Place FP Terminal as Icon
2. Separate label locations for Controls and Indicators
3. Lable Position Options
4. Add a setting to allow different label positions for controls and indicators

The prelim artwork is an attempt for an information-dense, easily-recognizable, same-footprint, attractive alternative to the current terminal configurations. It offers no display configuration, always showing the label for the sake of self-documentation. It was designed to complement the Improved Control References and the New LV2010 Local Variables. I would envision being able to double-click on the integrated label in order to rename the node.

For completeness, here's what an array would look like. Or perhaps, one of the array alternatives on the Redesign Terminals Idea that focuses on the inability to clearly show array dimensions with the currently implemented terminal:

Finally, you're not voting for my artwork, you're voting for this concept: Standardize terminal configuration to make it non-configurable, robust against self-documentation SNAFUs, and universally recognizable. Just like the zero-config behavior of the Local Variable, we want a what-you-drop-is-what-you-get Terminal.

[Neil.Pate]

I like your suggestion, but think you are going to face massive uphill struggle to get this implemented.

My coding style is as per your suggestion, with the labels horizontally inline with the terminals, but in perhaps 1% of the time I am a bit short of block diagram space and move the control label somewhere else. This is only really for very special situations where the control in mention is (for some reason) not on the very left left of the BD, but tucked "inside" the diagram for some (usually good) reason.

[JackDunaway]

---

@nrp wrote:
... you are going to face massive uphill struggle to get this implemented.... My coding style is as per your suggestion, with the labels horizontally inline with the terminals, but in perhaps 1% of the time I am a bit short of block diagram space and move the control label somewhere else

---

I'm going to raise you to 5-10% of the time (I'm a GUI guy). I try to fit a control terminal into the "middle" of some tight code and consequently have to do some Label Tetris. But think about Control References and Local Variables - you don't have a choice but to make room since you can't change their shape.

Yeah, it's an inconvenience to no longer have the ability to mutate the terminal appearance any more to fit into squirmy positions, but the long term benefits overshadow any "tight space" arguments.

And, with the new terminal lodged in the middle of the code, it's more prominent than the current terminal.

[crossrulz]

Honestly, my favorite part of this idea is the fact that you are removing the stupid "View Terminal as Icon"!!!  It also annoys the heck out of me when I see terminal labels all over the place.  I have an RCF (for 8.6) to set all of my labels to the side center (just like #3 above), which makes it easy for me.  But it would be so much better not having to worry about it.

[altenbach]

Jack, thanks for the nice writeup. (We talked about thing quite a while ago and I never got around to it.)

The "view as icon" could be retained, though, it would just look even bigger with the integrated label. 😮

The control name is such an integral part to the code logic that the label:

• should always be visible in order to not obfuscate the code
• should always be near the terminal for the same reason

Integrating the label into the terminal seems like the natural thing to do to solve both these issues! 🙂

I still would retain the option to hide the label, and the terminal would look the same as now.

[GregSands]

I like this.  To my mind, the design is even "nicer" and more readable than the new Local Variable design.

It does however lead to a natural question for me, which is, why do we need Terminals at all?  Would it be possible for everything to be a Local Variable, i.e. a "link" to the data contained by a FP Control/Indicator?  The only distinction I can see (though maybe I'm missing something fundamental) is that the Terminal is a BD analog of the FP object, so things like changing properties/representation are only possible on the Terminal.  However all of these operations are really modifications of the FP object, and not related specifically to the BD.  One issue that may be confusing is how to handle deletion, but apart from that, it seems to me conceptually simple to merge Terminals and Local Variables.

[JackDunaway]

>> To my mind, the design is even "nicer" and more readable than the new Local Variable design

Thanks!

>> why do we need Terminals at all?

Alright, let's see if I can completely butcher the concepts and the terminology:

Well, something needs to define the directionality of the data with respect to the scope of the containing VI - is it an input or output to the VI? Locals can be both read and written for both controls and indicators, so one Local would have to be the "Master Local" to define the ultimate directionality of the data on the ConPane interface. If a FP object was defined as an output (indicator) on the connector pane, yet the BD only contained Read Locals, you'd have a guaranteed Default Data output. Also, the Read Locals would be meaningless, outputting Default Data as well (assuming no parallel VI server Value, Value (Sgnl), or Ctrl Val Set monkey business).

Not to mention, latching Mechanical Actions on BOOLS are incompatible with multiple BD data accessors.

Not to mention, inplaceness and inlining.

I had the same thoughts as I was designing the terminals, and had a little time to think through this question. My goal of the whole Terminal proposal was to basically make it look and act just like a Local Variable (which currently is better behaved in the IDE [read, no-config]), except give it some shading and a datatype glyph so it's clearly the "Master Local Data Accessor".

Hence, Terminals.

[Dragis]

thanks for putting this together. i would agree with other comments here that having the consistency between the various similar terminals would outweigh the slight decrease in sizing capabilities. kudos from me.

i find it interesting that you left the data type icons on these nodes but didn't put them in any of the other similar ideas (e.g. references). to make things even more consistent, perhaps we should put the type glyphs on the locals, globals, and references so the only difference is the various small left-size glyphs? 

[GregSands]

Maybe I'm treating this a bit simply, but isn't the directionality a property of the FP object and connector pane, rather than anything on the BD (therefore no need for a "Master Local" except as a visual indication)?  And isn't the object (Control/Indicator) simply a placeholder for some data?  So any access to that (Terminal or Local Variable) should be able to be optimised as easily for inplaceness and inlining etc.

Latching Booleans was one property I hadn't thought of, but perhaps it's just time that anachronism was rethought 🙂

[GregSands]

Further to that (and now I'm pushing things :-)) why is there even any distinction between Control and Indicator?  User interaction could be defined on the FP object (starting with the Disabled property), directionality could be defined on the ConPane which could possibly even allow objects to be "both" read and write!  i.e. connected twice on the ConPane, one with input status, and one with output.  That's probably a lot more difficult, though might be possible if any such object was scalar or only accessed through an In Place Element structure.

[Neil.Pate]

Jack,

I missed the bit about being able to hide the label.

Then I definitely want this idea!

One suggestion, I know you said your artwork was just for show, but I would prefer the label for controls to be to the left of the data type glyph (and on the right for indicators as you have it).