LabVIEW Idea Exchange

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

Default Option: Do NOT Place Front Panel Terminal as Icon

Status: Declined
When the Icon view as added to LabVIEW, it was a decision to make this option be default for the benefit of new users. While there are definitely strong opinions on which is better (icon or terminal), overall the feedback from new users globally are that icons are preferred until they reach a certain LabVIEW proficiency and then the environmental option in Tools>>Options is turned off. The decision to have icons as default is still valid for our users. The ability to turn this off and that this option preference will be carried over via ini file if you upgrade LabVIEW appear to be logically solutions. The issue though of converting existing icons into terminals on a larger scale than just one at a time is something R&D is currently investigating.

The default LabVIEW environment option should not show terminals as an icon. 

 

IconTerminals.png

38 Comments
joshuatree
Member

Thanks for the early morning laugh...  great picture!

 

 

Spectre_Dave
Active Participant
Please keep the small nodes as the large ICONs look amateurish
Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
Spectre_Dave
Active Participant

I never use the large ICONs and I find then intrusive and they take up a lot of real estate.

 

As for this issue with making LabVIEW easy for new users let us have two versions: LabVIEW with training wheels and a version for power users. 

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
JackDunaway
Trusted Enthusiast

Here's a candid response from a new user to all the different Terminal Icons for Booleans. The Accepted Solution turned out to be turning off the 'View as Icon' option for the Boolean Terminals.

 

While some new users may consider this feature an intuitive method to bridge the gap between Block Diagram and Front Panel, it's clear that some might assume different functionalities for different Booleans. 

 

I don't think I was even aware there are so many glyphs (and this image is not even exhaustive):

 

19707i1D9293DDCE9D5367

AristosQueue (NI)
NI Employee (retired)

> it's clear that some might assume different functionalities for different Booleans.

 

Some boolean controls *do* have different functionalities for their FP terminals. The Mechanical Action defaults to different things for different booleans.

JackDunaway
Trusted Enthusiast

>> Some boolean controls *do* have different functionalities for their FP terminals. The Mechanical Action defaults to different things for different booleans.

 

Any Boolean can be changed to any one of the six Mechanical Actions (at the risk of breaking code if you have dropped Locals and choose a Latched option). Further, any Boolean can be customized to have non-default images for each of the 4 or 6 states. The glyph is potentially unreliable and misleading for any control that has been customized.

AristosQueue (NI)
NI Employee (retired)

> Any Boolean can be changed to any one of the six Mechanical Actions (at the

> risk of breaking code if you have dropped Locals and choose a Latched option).

> Further, any Boolean can be customized to have non-default images for each

> of the 4 or 6 states. The glyph is potentially unreliable and misleading for any

> control that has been customized.

 

True. That doesn't seem to happen very much -- buttons tend to be latching, LEDs tend not to be, so definitely for the novice and mostly for the experienced user, the icon does provide differentiation. Having said that, if we back away from the associative icons, having a glyph on the FPTerminal that indicates the mechanical action I think would be useful. It is one of the aspects of seeing the icon that I like.

JackDunaway
Trusted Enthusiast

@aq wrote:

...having a glyph on the FPTerminal...


Or, having some text or the Mechanical Action glyph on the Context Help for both the FP Control and BD Terminal... I'm hesitant to start Bedazzling the FP Terminals. 😉

AristosQueue (NI)
NI Employee (retired)

> I'm hesitant to start Bedazzling the FP Terminals. 😉

 

If it has an impact on how the "public behavior" of the node, I want the node decorated. That goes for configured express VIs, primitives with options and FPTerminals. Reading the diagram should tell you what the code is doing. I don't want to decorate with under-the-hood details (such as "is this node reentrant?"). Those are things that change how the node gets its job done, not what its job is. Mech action changes what its job actually is.

PaulLotz
Member

I actually much prefer the large icons myself.  Since we use small object-oriented methods anyway, we never run out of screen space, and I find the large icons cognitively simpler to apprehend under these circumstances.  I vote to keep the large icons the default.