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!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

Not quite as much info as the large icons, but I'm sure these can be improved...

But they nearly convey the same info..  Well... to me they do..

 

Another question that NI should ask itself is:  Who does NI want to cater to?  The novice programmers?  or the experienced programmers?  Seems like this is leading to two factions.. 😉

 

 

 

 

 

 

______________________________________________________________________
Knight of NI

(there's no "reply to" in this Ideas forum)...

 

Aristos Queue,

 

Oh... boy....  I clearly did not explain myself very well... And my last post probably didn't help.

 

There are some Icons that I would preserve the current size.  I am happy with the larger icon.  For instance:

classes, type definitions, clusters, VI refnum...   I guess I should not have proposed the smaller sizes for those...

 

Maybe I will edit the image.

______________________________________________________________________
Proven Zealot

Ray.R: In other words, you'd be ok with some FPterms being large and others being small? I'm not sure most users would vote for that. People today don't seem to generally like mixing the two styles.

Knight of NI

More like these...

 

 

 

I should have removed ^^^^^^ the cluster icon.... Although that could be debated..

I don't mind the larger icon for the cluster since it already cleaned up a large portion of real-estate.

______________________________________________________________________
Member

"Another question that NI should ask itself is:  Who does NI want to cater to?  The novice programmers?  or the experienced programmers?  Seems like this is leading to two factions.. :smileywink:"

 

OK, I will finally comment on this thread.  I think this characterization is not accurate.  As an example, I am a quite experienced LabVIEW programmer and I greatly prefer the large icons, on the grounds that they make the controls stand out much more clearly (and because I think they are more aesthetically pleasing, actually).  🙂  Moreover, since I rarely have a method with more than one or two inputs or outputs (not counting an object in/out and error in/out) block diagram space issues are not a concern for me at all.  Actually, the argument to conserve space is not relevant to me in any way.  I realize there are different views on this, but I know not all advanced programmers want small icons.  I actually like the large icons as they are.

Knight of NI

AQ:  "In other words, you'd be ok with some FPterms being large and others being small? I'm not sure most users would vote for that. People today don't seem to generally like mixing the two styles."

 

I mix the 2 styles...  The class objects and clusters use the large icons.  The numeric controls, VISA controls use small icons.  They get along well on the block diagram.

 

In the case of the class object, I edit the icon to give a clue to the name, so it is added information.  Plus as Paul seems to indicate, if the block diagram is clean, then the larger icons are not as "noisy", thus acceptable. 

 

My concern is mosly due to the fact that being a consultant, I mostly get called when the code someone wrote became a complete mess and the original author goes to another place to create yet other messes (one programmer in particular I refuse to fix his code).  The problem is that the code spans over multiple screens (up to 3 x 4) and the only way to understand the undocumented code is to shrink the code.  Although re-writing the entire application is the best solution, I still need to understand the algorithms that were written, with many large-size icons for hundreds of controls spread over the single block diagram.

 

I realize that the root cause is poorly written code.  But who is going to solve that one??

 

What is important (which was mentionned in another thread) is that the block diagram need to convey enough information so that someone looking at it can understand what it is supposed to do. 

 

On the (halarious) other side, I have seen on many occasion block diagrams spanning 2 x2 screens with a few objects taking approx 4 sq. in of real-estate.  These are 26in flat screen monitors...

______________________________________________________________________
Active Participant

"As an example, I am a quite experienced LabVIEW programmer and I greatly prefer the large icons, on the grounds that they make the controls stand out much more clearly (and because I think they are more aesthetically pleasing, actually).  🙂  Moreover, since I rarely have a method with more than one or two inputs or outputs (not counting an object in/out and error in/out) block diagram space issues are not a concern for me at all.  Actually, the argument to conserve space is not relevant to me in any way.  I realize there are different views on this, but I know not all advanced programmers want small icons.  I actually like the large icons as they are."

 

Just wanted to second paul.dct's comment.  As I've become more experienced I've noticed a tendency to a LOWER density of control/indicators and cleaner block diagrams (many more subVIs, of course).  And the controls and indicators I do have tend to be quite significant, and deserve to visually stand out on the block diagram at least as much as a subVI.

 

-- James

 

 

NI Employee

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.


Let me help R&D figure this out:

CtlsAsIcons.png

 

🙂

Having it automated would be nice though.