View >> Gigantic Coercion Dots (now with a variety of colors)

[AristosQueue (NI)]

We have (collectively) complained about coercion dots many times on various LV forums -- they are nearly invisible and there are three different kinds, which require different levels of concern. The problem is that there are very few pixels within a terminal and there's no space for any pattern to differentiate the three kinds of coercion (and changing colors is a problem for reasons discussed here in the Idea Exchange).

Another LV developer had an idea that I liked: add an option to view giant coercion dots. We have avoided this because coercion dots bigger than the terminal would interfere with wiring. However, many developers have a policy of eliminating all coercion dots on their diagrams. For those who have such a policy, they could eliminate the coercion dots as they work, and thus might not see any problem from such large dots. Large dots would solve lots of other usability problems that coercion dots have today.

This option could be something in Tools>>Options, but I'd rather it be something in the View or Edit menus so it can be quickly toggled on or off with a shortcut key.

These graphics are "programmer art" -- I just made the three dots look different. Please sumit alternate images for the three dot types if you have better style suggestions. I did make the three dots differ in both pattern and color so that we avoid problems with colorblindness. The type-only was a solid dot, the widening coercion is a bulls eye, and the narrowing coercion is a single ring. Any redesign should definitely take colorblindess into account.

[altenbach]

How would you qualify a DBL-to-I64 coercion? Depending on the size of the value it is either widening (I64>DBL mantissa) or narrowing (DBL range>I64 range).

(Just thinking out loud, but what if we would move the coercion dot away from the icon and onto the incoming wire, and the wire would change color at the coercion dot?)

[AristosQueue (NI)]

> How would you qualify a DBL-to-I64 coercion?

Both directions are in the "narrowing coercion" category because each type has too few bits to store all the values of the other type, although the particular crunch that occurs is different.

[JackDunaway]

How about something similar to "Show Buffer Allocations"?

I could envision the same tool for flashing Buffer Allocations, Coercion Dots, and Constant Folding. One-stop-shop memory management tool, and it fixes usability issues for both coercion dots and constant folding.

***EDIT - The reason I would like flashing is that without motion, you're still playing "Where's Waldo?", even if the game is a little easier with fat Waldo. Even better, all instances would show up in a list.***

[altenbach]

How about showing the flavor (flat, widening, narrowing) graphically, e.g. as follows:

(I am open to make them even bigger if needed)

[altenbach]

Or with a bit more contrast. We need to make sure not to conflict with the arrows of the simulation toolkit.

[AristosQueue (NI)]

If we start going outside the terminal bounds and putting it on the wire, we do need to establish what happens when the wire passes under the node. Is the coercion dot drawn on the wire at the point that it enters the node? Or is it drawn beside the terminal as if the wire had entered through a "proper" side?

(Note: I'm pretty sure I have been down this road before, discussing moving the coercion dot out of the terminal... I just can't recall what the final nail in that coffin was. It's such an obvious change, and the question of entry point occurred to me so immediately that I'm sure this has been debated in the past. Does anyone recall any such conversation on LAVA, ni.com or infoLV mailing list?)

[altenbach]

To be fair, your suggestions are also partially outside the terminal.

Placing the coercion on top of the icon also poses problems, especially with small functions. We would probably no longer recognize the function unless the coercion dots are semi-transparent.

Imagine putting coercions on the two input terminals in the following picture.

(This opens another can of worms, probably to be discussed elsewhere:

Why are there no coercion dots in this code! Shouldn't there be?)

[Darin.K]

I'll consider myself lucky that my eyesight is sufficient to spot the coercion dots as they are now.  It doesn't hurt that I tend to deal with them (usually by ignoring them), at the time of creation.

If you are looking for a way to get hit over the head with them I would consider the option of also modifying a wire's appearance if there is a coercion at the end.  Similar to constant folding, but just typing those words makes my eyes hurt, so please make it visible, not painful.  The first thing you should probably do when you spot a coercion dot is trace the wire backwards anyway, this makes it easy.

If I had to guess, I would suggest dimming the color, but I would have to see it.  Kind of a two pronged attack, the wires guide your eyes to the terminals with the coercion dots which may not need to be quite as gigantic or blinking in this case.

Side Note:  If you guys did the sensible thing, this could go into the Tools menu AND still get a keyboard shortcut.

[AristosQueue (NI)]

> (This opens another can of worms, probably to be discussed elsewhere:

> Why are there no coercion dots in this code! Shouldn't there be?)

No, there shouldn't be. The node operates on the values without coercing them first. The lack of coercion dots indicates that the assembly code generated by this node is actually able to do its work without coercion

As for obscuring the whole node, that's fine -- as I pointed out originally, the idea would only be of value to people who resolve their dots immediately anyway. If I just wired the terminal, I'm not suddenly wondering what node it could possibly be.  🙂

> To be fair, your suggestions are also partially outside the terminal.

True, but my suggestion centers over the terminal and wouldn't be expected to move with the wire, whereas the decor on the wire could create that expectation for some users.

(I still really wish I could remember the older discussion, because I'm sort of liking your decoration-on-the-wire idea, and I'm having a hard time seeing any drawbacks.)

.

[altenbach]

Also, let's remember that there are subVI connector patterns where the connectors are really tiny. Maybe that would force a size constraint to prevent a solid red wall... of course nobody in his right mind uses these patterns.