LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Block Diagram Terminals Improvement

Status: New

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 22120iFF5D2D358A179035 into a 22124i47B01DC3554D8D28 or a 22122i534509B41D018E18.

 

Just a few Common Terminal Configurations:

22102iC18AB09CA35049A6

 

  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:
22100i5704DD0516745EAB
 
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.
 
22112i4F5D7F09801CC176
 
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:
 
22114iE4253941BD5748E5
 
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.
Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
31 Comments
Active Participant

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.

_________________________
All your base are belong to us.
Trusted Enthusiast

@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.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Knight of NI

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Knight of NI

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.


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
Active Participant

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.

 

 

Trusted Enthusiast

>> 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.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Active Participant

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? 

Active Participant

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 🙂

Active Participant

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.

Active Participant

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).

_________________________
All your base are belong to us.