LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
JackDunaway

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.
31 Comments
AristosQueue (NI)
NI Employee (retired)

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

 

nrp's modification would be very important if the labels can be hidden and shown -- when the label hides, you want the type glyphs to stay where they are and end up with a nice aligned set of terminals.

altenbach
Knight of NI

Maybe there should be an additional option to limit the length of the embedded label.

 

I sometimes have over-sized, multi-line labels that would probably not very compatible with this idea. The solution would be to show only the first n characters (or pixel equivalents) on the terminal, while the full label only shows when hovering over the terminal as a tip strip. The visible part could end in ".." or some special glyph to indicate the display truncation.

 

My scenario: If you only show label or caption, the label can be kept short and the caption can be "wordy" on the FP (e.g. to mark the various columns of a 2D array as one long caption string). However, I have used the caption for this and at the same time the label to also label the various rows as a multi-line string, making the label really messy when shown on the BD. (Yes, I could use free labels and grouping, but I like to use the built-in association for simplicity).

 

Hiding the label on the BD is one solution, but it still would be nice to show the first n characters for clarity.

RayFarmer
Trusted Enthusiast

Actual I would just be happy if the default setting to use the Icon was changed to use the terminal. Your suggest seems to use up more space on the diagram than just leaving it alone.

 

regards

Ray Farmer

Regards
Ray Farmer
Dragis
Active Participant

 


@altenbach wrote:

Maybe there should be an additional option to limit the length of the embedded label.


or perhaps a horizontal resize handle that let's us change the width just like we would any other string-like control? this would also make the terminal respond to the resize cleanup buttons. labview would have to be smart about how it truncates the text so it stays as readable as possible.

 

CrystalTech
Member

Sorry, no Kudos from me.  The movable label allows me much more flexibility when I have a tight space.  Your "Associative Array Out" is a great example of a label that needs to be placed efficiently.

Sometimes I even make the labels compressed and Taller as shown below to fit a diagram.

 

Associative

Array

Out

<control>

 

(A border around this label helps)  I like Options over Restrictions.  What you propose is restrictive.

altenbach
Knight of NI

> The movable label allows me much more flexibility when I have a tight space ...

 

If space is really tight, you can choose "name format...no names", which would also hide the embedded label.

 

Do we possibly need an option to make all this optional with a right-click option "embed label"? Defaults to off for legacy VIs to retain the old look, but defaults to ON for new VIs? (Settable with a preference).

 

 

dthor
Active Participant

Just for the record, I like the way terminals on the BD are currently; I don't think they need to be changed. And just so people don't think I'm just stubborn, I really like the current (new) Local Varaible change and the proposed Property/Invoke node changes.

 

I like the current BD Terminals so much because they fit exacly in the default block diagram grid: 16x16 pixels. I guess I'm just in love with everything being arranged with the grid. I have some coworkers who don't use the grid-snap and I think their diagrams look quite ugly.

 

My vote is to keep at least the terminals a fixed size: 16x32 pixels (the icons are 32x32). Hell, As much as I love the new smaller Boolean Constants, it bugs the hell out of me that they are not 12x12! (same with the "Empty String" and others...) I must have OCD or something.

Ray.R
Knight of NI

I would like to simply see the icons dissappear altogether.  Only have terminals.

As for the label, I don't mind the current ones.

Marc Blumentritt
Member

I like all your ideas about the redesign of controls and refs.

 

But concerning icons of controls: in one case I use "View as Icon": type defs. I want to see, which controls are type defs and I want to now which type def this is. The idea to combine label and icon is OK, but icons should not completly dropped.

CLD
seeker169
Member

I think the only thing worse than including control labels in the icons is including them in the icon and then truncating them. 

 

Including labels in the icon removes all flexibility with label placement.  Just because there's a (more-or-less) agreed upon style, doesn't mean it's the best style for all uses.

 

Truncating is bad, too, for those of us who occassionally remember to use descriptive labels for our controls.  If I had, for instance, a couple clusters called:

 

initInfoSpectraSpectragram

initInfoSpectraLofar

 

my guess is I wouldn't be able to tell the difference with a truncated name.  And the thought of having to run my mouse all over my BD in order to figure out which controls are where, does not seem to make for very readable code.  Likewise, having to create a caption for each of those truncated labels to take the place of the label I can't read all of anymore.  Not very efficient.