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
G-Money
NI Employee (retired)
Status changed to: 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.
Ray.R
Knight of NI

Sorry to read that this idea was declined  😞

 

At least, if it was possible for LabVIEW installer to detect what the setting was in previously installed version and keep that setting in the new installation, it would be better than changing the default setting after the installation is complete..

G-Money
NI Employee (retired)

Ray,

 

I agree. I wish there was a way that LabVIEW could copy over the LabVIEW.ini file from one version to another when upgrading to a newer version on the same computer. All the environmental options are saved as tokens in the LabVIEW.ini file and this would setup the new LabVIEW with the same settings. 

 

I could see issue coming from ini tokens that lose support between versions but I think it would be to hard to check against some table to see if they are still valid before copying them over. I think this feature could help get rid of that extra step of having to change the environment around right when you install a new version.

Ray.R
Knight of NI

Maybe I should propose that as an idea.. It would not have to copy all the ini file settings, just the ones which are not default.  In other words, it could keep track of environment changes and re-do them during the next installation.

Ray.R
Knight of NI

Believe it or not, there are still discussions and controversies over these icons..

 

 

Other that the 1.23 I do not see any additional information that the larger icon brings over the smaller one.  I'm sure if "new" programmers didn't see or know about the larger icon they would not miss it.  Plus, with wikipedia, they'd learn the differences between various types by doing a simple search on "dlb" (for example).  Or they could be lazy and ask in the forum "what does the orange dbl icon mean?"  And then we'd provide a long winded explanation of the differences in the data types.

 

I would still kudo this idea.

 

inf Kudos Jack!

AristosQueue (NI)
NI Employee (retired)

Ray R. wrote:

> I'm sure if "new" programmers didn't see or know about the larger icon they would not miss it.

 

If you have a survey of new users or other data set to contradict the existing NI findings, please share it. Our finding was that more new users had no idea what those FPTerms meant, even after the association with the panel was explained, and enriching them with glyphs that reflected what they had just seen in the palettes helped them learn the association. It isn't about learning what the DBL means. It's about learning the entire terminal's relationship to the front panel control.

 

As I explained before, the information carried by the icon increases the more advanced your datatypes become. Here are cases where the icon carries more information:

 

FPTerms.png

 

 

The availablility of both terminal styles has turned out to be a bigger problem than was originally expected. I agree that it would be good to get rid of one of them... just not the one folks on this list would choose. 🙂 

Darin.K
Trusted Enthusiast

What is missing in AQ's comparison is the Label, which when chosen well conveys considerable information (and fits more naturally with the smaller view IMO).  Ideally we would adopt a form of Hungarian notation for the Label and use concise captions on the FP.  (Not really, that is one of the reasons I minimize staring at the source code of Windows Apps).

 

A simple, possible alternative to bloated icons would be to have an image of the control appear in the Context Help window when hovering over a terminal (size limit of course).  A more elegant alternative IMO would be to have a way to flash the FP with the control highlighted if you did some special click on a terminal.  Think Windows 7 taskbar where you can hover over a thumbnail to see a Window which goes away when you leave.  Instead of doing Find Control or Double-clicking and completely losing your place, you just catch a glimpse of the FP to remind yourself what the control is, then get back to wiring.

JackDunaway
Trusted Enthusiast

Darin brings up a good point about Labels, and I agree they're an important aspect of recognizability. Like AQ, I agree it would be good to only have *one* style of terminal, and hopefully that one style would have an integrated label and a good icon and a net smaller footprint. In other words, just improve the information density and remove configurability of the terminal.

 

Ray.R
Knight of NI

AQ,

 

I get your point.  Maybe it's because my mind interprets the context in which the smaller icon is used that I know what it really is. 

 

I like what Darin is proposing.  I would propose the same or something similar.  What would be wrong from modifying the smaller icons to be more "precise".  Maybe a picture will be worth a 1000 words.

 

In other words, if the benefit from the larger icon is that it conveys a bit more info, why can that same info not be put into a smaller icon?

AristosQueue (NI)
NI Employee (retired)

> In other words, if the benefit from the larger icon is that it conveys

> a bit more info, why can that same info not be put into a smaller icon?

 

We probably could pack the information more tightly, except for all the existing features that already have 32x32 icons.

 

The icons for typedefs are 32x32. Clipping those doesn't necessarily yeild something unique or meaningful. For classes, we could just use the library icon, which is normally just a banner, but there's no guarantee that it is just a banner -- users are free to use the whole icon, a slice down the left or right edge, etc.

 

The conpane of a VI refnum is 32x32. Try reducing that down and you rapidly lose terminals. Getting down small enough to fit in the small FPterms means even the 4x2x2x4 conpane is illegible.

 

We could probably find a way to create reduced size versions of the glyphs for the basic front panel controls, but they would lose some of their fidelity and the relationship from the FPTerminal to a front panel control decreases if the FPTerminal icon isn't the same as the icon in the palettes.