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

 


@seeker169 wrote:

 

initInfoSpectraSpectragram

initInfoSpectraLofar

 


 

initIn...gram

initIn...ofar

--
Tim Elsey
Certified LabVIEW Architect
NI Employee

I just found this suggestion. What a fantastic idea!

David Staab, CLA
Staff Systems Engineer
National Instruments
Active Participant

A strong ANTI-kudos if it means that terminals wont be very visually distinct from local variables or references.  I want it to be immediately obvious if local variables, and thus potential race conditions, are in play.    

 

-- James

PS> I greatly prefer icons, but do see the potential value of standardization one way or the other on that issue.  

Trusted Enthusiast

@drjdpowell wrote:

A strong ANTI-kudos if it means that terminals wont be very visually distinct from local variables or references... but do see the potential value of standardization one way or the other on that issue 


Yeah, the big take-away here is standardization. Feel free to suggest alternate designs.

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

@drjdpowell wrote:

A strong ANTI-kudos if it means that terminals wont be very visually distinct from local variables or references.  I want it to be immediately obvious if local variables, and thus potential race conditions, are in play.


I can't see that it makes any difference for race conditions whether I'm using a local variable or the terminal.  A race condition presumably requires more than two accesses of a variable, so whether one or none of them is the terminal itself shouldn't matter.  Or am I missing something here?

 

Perhaps the proposed design (which I like!) would make it more difficult to locate the terminal, but they're not always easy to find anyway without "finding" them from the front panel control/indicator.

Active Participant

 


GregS wrote:   I can't see that it makes any difference for race conditions whether I'm using a local variable or the terminal.  A race condition presumably requires more than two accesses of a variable, so whether one or none of them is the terminal itself shouldn't matter.  Or am I missing something here?
If I quickly look at a VI and see only terminals, I can exclude the possibility of several types of structures using locals.   If I see a local (or "Value" property node, reference, etc.) then I know that something more complex is going on than just simple input/output, and thus need to look into it in more detail.  Your right, it takes at least three accesses to make a race condition, but it is never obvious exactly how many accesses there are, and even many two-access uses of locals (as "wireless" cross-diagram communication methods) are less than clear.  Most VIs shouldn't be using locals or references, and I want the few that do to immediately stand out.  Having terminals visually distinct from locals and control references is an advantage in code readability.
Active Participant

Yeah, the big take-away here is standardization. Feel free to suggest alternate designs.


Are you sure you want an enforced standard?   Icons are the current (non-enforced) standard and have been for years, but I doubt you're using them.  The one enforcement I'd like to see is the prevention of the ability to move the label more than a short distance away from the terminal (and the same limit on labels of other items like VI's and primitives).  As long as it's clear what object the label is labeling, I don't mind where it is, and find the ability to move it around an advantage to code readability.

Trusted Enthusiast

@drjdpowell wrote:

Are you sure you want an enforced standard? 


Yep. Smiley Wink

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

I asked a question on LAVA, "Feelings on Icons for Terminals", and they've convinced me NOT to to be in favor of forcing them all to use icons. 

 

Active Participant