Stop hiding important information about how LV nodes are working! Seriously. Everywhere.

[Intaris]

We're witnessing more and more requests to stop LV hiding important information from us.  In One direction we want to be able to know (and some want to break code) if structures are hiding code.

Others want LV primitives to give visual feedback as to how they are configured, especially if that configuration can have an effect on what's being executed or how it's executed.

Examples include (Please please feel free to add more in the comments below)

Array to cluster (Cluster size hidden)

Boolean array to number (Sign mode hidden)

FXP simple Math (Rounding, saturation and output type hidden)

SubVI node setup (When right lcicking the subVI on the BD and changing it's properties - show FP when run, suspend and so on)

Sub VI settings in general (Subroutine, debugging)

I know there are already ideas out there for most of these (and I simply chose examples to link to here - I don't mean to leave anyone's ideas out on purpose) but I feel that instead of targetting the individual neurangic points where we have problems, I would like to acknowledge for NI R&D that the idea behind most of these problems (Some of them go much further than simply not hiding the information, and I have given most kudos for that) is that hiding information from us regarding important differences in code execution is a bad thing.  I don't mean to claim anyone's thunder.  I only decided to post this because of the apparent large number of ideas which have this basic idea at heart.  While many of those go further and want additional action taken (Most of which are good and should be implemented) I feel the underlying idea should not be ignored, even if all of the otherwise proposed changes are deemed unsuitable.

My idea can be boiled down to the fact that ALL execution relevant information which is directly applicable to the BD on view should be also VISIBLE on the BD.

As a disclaimer, I deem factors such as FIFO size and Queue size to be extraneous factors which can be externally influenced and thus does not belong under this idea.

Example: I have some Oscilliscope code running on FPGA and had the weirdest of problems where communications worked fine up to (but not including 524288 - 2^19) data points.  As it turns out, a single "Boolean array to number" was set to convert the sign of the input number which turned out to be completely wrong.  Don't know where that came from, maybe I copied the primitive when writing the code and forgot to set it correctly.  My point is that it took me upwards of half a day to track down this problem due to the sheer number of possible error sources I have in my code (It's really complicated stuff in total) and having NO VISUAL CLUE as to what was wrong.  Had there been SOME kind of visual clue as to the configuration of this node I would have found the problem much earlier and would be a more productive programmer.  Should I have set the properties when writing the code initially, sure but as LV projects grow in complexity these kinds of things are getting to be very burdensome.

[tst]

The problem is that this idea is so general it becomes meaningless. Obviously, not everything can be visible at once, and so you're left with defining what the "execution relevant information" is. I don't know how to do that. For example, some might argue that the size of "Array to Cluster" is not that critical, because as soon as you come to interact with the cluster, its size becomes obvious.

[Intaris]

I'm aware it's a very broad idea but nonetheless, it's an important aspect which deserves to be addressed in its own right.

I'm aware that if you click on everything on the BD you'll eventually find out what you need to know but one of the reasons for LV's existence is the ability to "at a glance" work out what a program should be doing.  As time goes on there are more and more functions which get added without being given their due graphical representation on the BD.  I would certainly count "Array to cluster" as one of these issues.  I feel it's not good practise to hide information which is important to the underlying data being passed around.

I also would like labels on wires to actually give information ont their data (moving the cursor ovwer each wire is extremely tedious) so that a lot of problems can be found more easier.

It's all about access to the actual code in front of our eyes.

[Intaris]

Another example is the "case sensitive" or "Case Insensitive" match or a case structure.  Not obvious unless you actually right-click on the structure.

[altenbach]

For some reason you did not mention express VIs, which are the most serious offenders in this respect. 😄

I agree that all this information should how somehow be visible on the icon, but there is often really not enough space and it would be problematic to remember the significance of each pixel. But yes, kudos for getting this discussion started.

(Maybe it could be shown in the context help window with all non-default settings bolded? How about a tip strip?)

[Intaris]

Express VIs?  What are those?  Hmm, Maybe I should take NI certification more seriously......

Seriously though.  The discussion is the target.  There is no idea here to implement exactly....  Not directly anyway.

Spoiler

Or maybe there is, but it's HIDDEN!

[fabric]

What about a visual indication if a node has a non-default configuration? In most cases that would be enough to steer us towards the context help, or VI properties, or whatever...

[johnsold]

1. I think this is an important topic which needs to be discussed.  Thank you for raising the general issue.

2. The non-default suggestion by fabric may be a good compromise.  Perhaps something along the lines of the flag that typedefs get overlaid on the original glyph.

3. The individual topics are good places for detailed discussions of specifics for those items. It may be that a universal solution is not feasible, and in some cases undesirable, but this broad look can be used to raise sensitivity to the overall problem.

Lynn

[Intaris]

Lynn, you've grasped completely the motivation behind this idea.  Why can't I kudos your comment.....?

[M_Peeker]

I also see this as a problem, so kudos for raising it as a general idea. If it has a general solution, that will have to be a compromise, and fabrics may very well be a good one. I would like to add that the actual configuration information should be visible together with the help text in the context help window.

[Daklu]

Kudoed the general idea.  LV hides too much important information in configuration dialogs and nested right click menus.  I doubt it's possible to change the icon meaningfully to uniquely identify each non-default setting.  I think fabric's suggestion for a graphic overlay when a non-default property is chosen is a good idea. 

Many IDEs have a properties windows that shows and allows changing all the properties of the selected element.  What if we had one of those that operated similarly to the context help window?  Even better if it subtly highlights the properties that have been changed from non-default values.