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.
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.. 😉
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.
"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.. "
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.
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...
"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.
