Smaller Event Ref Constants

[JackDunaway]

The smaller footprint of the Local Variables in 2010 has increased usability of the IDE and readability of the LabVIEW language. Another node that could benefit from a smaller footprint is the User Event Ref Constant.

Below is some conceptual artwork on what a smaller footprint might look like. Feel free to post more concepts!

[stupidboy1121]

It's too sad. Some ideas got more than 100 kudos.

[Ray.R]

Great idea Jack.

I hope to see this implemented in the near future (ie LV2011).

I also agree that NI should take to concept and expand it to other objects that fall into the same category of wasted white space.

R

[PJM_Labview]

I like it but why did you change the background from white to yellow (I would have kept it white)?

[JackDunaway]

>> why did you change the background from white to yellow (I would have kept it white)?

Two reasons: to give better contrast with the datatype glyph, and to maintain coherence with other references and the properties/methods that act on those references. (Neither reason is particularly strong.) Below, muted yellow vs. white does not offer much more contrast on older LCD monitors (yet those with new monitors can see an appreciable difference). Also, you could argue there's no need (or worse, it's deleterious) to associate Messaging Refs with Control Refs.

It's subtle, but I'm a bigger fan of the muted yellow since it matches the background color of the Reg Events node and the Create User Ref prim. 

Why would you choose white?

[PJM_Labview]

> Why would you choose white?

I can't put my finger on it at the moment, but for some reason using yellow feel wrong.

Hopefully I will be able to come up with a more articulate reasoning in the future...

[Ray.R]

Would lime green make it better? 😄

I didn't see a problem with yellow..

[AristosQueue (NI)]

To my eyes, the yellow background skews the colors of the data types. It's subtle, but all the data types look just slightly ill, like they're having trouble digesting something.

[JackDunaway]

I don't disagree with any comments about the background color: it appears such a small area of the yellow color is highly sensitive to the monitor capabilities. One way to mitigate this problem is to make the relative size of the background larger by a few pixels by borrowing the streamlined Datatype Glyphs from the new Terminals (which was an oversight until now).

This looks better to me - comments?

[AristosQueue (NI)]

That is indeed better.

A question: This small view is useful if the data in your user event is a boolean or a plain numeric. But if it is a class or a cluster, the grid of squares or the "obj" just isn't descriptive, so I generally use the "show control" view. Do you have any ideas for making the smaller event constant that could somehow show the full type complexity?

[JackDunaway]

>> Do you have any ideas for making the smaller event constant that could somehow show the full type complexity?

No. 🙂 I don't use "show control" for constants (although I have used this for FP controls/indicators, which is outside the realm of BD improvements).

I place "Show Control" in the same category as "View as Icon" - it's better to get rid of one or the other. LabVIEW has become too permissive in allowing cosmetic configurations, and one of the tenets of UI design is to "eschew obfuscation". 😄

Look at the two following Event Ref Constants - they are functionally equivalent, but they look dramatically different. These two visual configurations could confuse even the most seasoned programmer, not to mention making the learning curve for beginners unnecessarily difficult.

As for classes, the wire appearance coming from the Constant should be enough of a visual cue to identify the class. And for typedefs, I suggested a custom wire capability, but I can understand why R&D would be hesitant to implement language features such as this that enable typedefs to become more powerful (LVOOP becomes more desirable when it's implementation contains language features/goodies not present in vanilla typedefs [mutation history, etc.]).

And most of all, every user needs to be trained that Context Help only becomes more and more powerful as experience increases! (CH shows full datatype info for messaging refs)

So, I am not opposed to creating a new Idea to get rid of "Show Control" for BD constants! Or more generically, a "fuzzy" Idea that basically says "NI should not allow as much configuration for impotent features that only increase confusion for users and maintenance for R&D"