NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
AristosQueue

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

Status: New
by Trusted Enthusiast ‎11-30-2010 09:29 AM - edited ‎11-30-2010 09:37 AM

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.

 

Coercion.png

Comments
by Knight of NI on ‎11-30-2010 09:48 AM

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>I32 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?)

by Trusted Enthusiast ‎11-30-2010 09:52 AM - edited ‎11-30-2010 09:52 AM

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

by Trusted Enthusiast ‎11-30-2010 10:10 AM - edited ‎11-30-2010 10:17 AM

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.***

by Knight of NI ‎11-30-2010 10:23 AM - edited ‎11-30-2010 10:25 AM

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

 

 

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

by Knight of NI ‎11-30-2010 10:29 AM - edited ‎11-30-2010 10:30 AM

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

 

 

by Trusted Enthusiast on ‎11-30-2010 10:35 AM

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?)

by Knight of NI ‎11-30-2010 10:48 AM - edited ‎11-30-2010 10:50 AM

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?)

by Trusted Enthusiast on ‎11-30-2010 07:04 PM

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.

by Trusted Enthusiast on ‎11-30-2010 07:37 PM

> (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.)

.

by Knight of NI on ‎11-30-2010 07:46 PM
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.
Latest LabVIEW Idea Exchange Blog Posts
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!
Idea Statuses
Top Kudoed Authors
User Kudos Count
131
72
67
59
44