Kudos value in the Idea Exchange

[GregSands]

Q: What is the value of a Kudo in the

Idea Exchange

?

A: Not much.

I've made an interesting observation.

Roughly a month ago, two ideas were proposed within a day of each other. My suggestion was that

Error Wires should be placed under other wires

, and Darin suggested that the

Read/Write status of property nodes should be determined by how you wire them

. Both ideas were fairly straight-forward, both are coding-related, both had a simple image and clear explanation, and as of now, both have attracted about the same number of comments (12 vs 16) and kudos (65 vs 70). I haven't fully compared the kudos, but it appears there's even about the same number of NI voters and "high-rank" voters for each.

However, and I don't think it would be just my opinion, Darin's idea is infinitely more useful and valuable than mine. It's an idea that would allow faster and easier programming, and be a noticeable improvement. Whereas error wire layering - it would be "nice" if it was implemented, but it's just cosmetic, not a game-changer. Yet they've attracted about the same number of kudos.

So I can now understand when AQ and other NI reps say that popularity of an idea is a pretty poor indication of its value.

PS - go vote for

Darin's idea

if you haven't already.

[crelf]

Q: What is the value of a Kudo in the

Idea Exchange

?

A: Not much.

...AQ and other NI reps say that popularity of an idea is a pretty poor indication of its value.

It's not a highly-weighted attrubte that drive the implementation of an idea (I think that much is obvious), but that doesn't mean it's not important.

[Darin]

Thanks for the plug. I can offer a few thoughts:

Like most things, I think the Idea Exchange has stages:

1. The IE is going to revolutionize LV.

2. The IE is going to transform LV.

3. The IE is going to alter LV.

4. The IE is going to change LV.

5. The IE is going to have an effect on LV.

6. The IE is going to have a small effect on LV.

7. The IE is going to have no effect on LV.

I think we are headed down the list but I won't publicize where I think we are now.

As to the Kudos weighting I can offer the old parable about the pious man on his deathbed who kept praying to win the lottery. Finally after a few weeks pass and he hasn't won, he questions his faith and asks God "Why have you foresaken me?" At that point God asks "Could you at least help me out by buying a lottery ticket?" No matter how small the chance of getting your idea implemented it is certainly improved by posting the idea.

Personally I have given up on winning the beauty contest, instead I hope I plant a seed in a developer who someday works on a given feature and manages to toss it in there. Even this may not work, I have one idea which for many months had plateaued at 8-9 Kudos. Three of those were Jeff K., AQ, and Darren, Yair may have even been a straggler in that group. If support of the (un-?)holy trinity was not enough, what is?

Finally, since no good deed goes unpunished I have attached a VI which will move all of your error wires to the back. I once had a need to do something to all of the error wires (and it was certainly not moving back ), but it was easy to adapt.

MoveErrorWiresToBack.vi

Edited December 12, 2012 by Darin

[Darren]

Hey, neat! Your way of determining if a data type is an error cluster...

...is quite a bit simpler than the way I do it:

Sorry to get off-topic, but I always like to recognize cleverness when I see it. The only time your way would run into trouble is when the variant is a cluster containing a non-I32 numeric type:

In this case, since Variant to Data will convert any simple numeric type into any other simple numeric type without error, your way would determine that the cluster was an error cluster, but my way would not. Incidentally, this code that I use for determining if a type is an error cluster is located here: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Check Type If ErrClust.vi.

[Darin]

The only time your way would run into trouble is when the variant is a cluster containing a non-I32 numeric type:

In this case, since Variant to Data will convert any simple numeric type into any other simple numeric type without error, your way would determine that the cluster was an error cluster, but my way would not.

That gives me a new idea, perhaps there should be an option to throw an error (or warning) if a coercion takes place. Now if only there was some way to let NI know I had this idea....

[Darren]

If I need the *value* of the variant, and I know it's an arbitrary simple numeric type, I'll always just cast it to an EXT with Variant to Data and go on my way, because I don't really care what specific numeric type it is. But if I need the *type* of the variant, I'll use the VariantDataType VIs (located in vi.lib\Utility\VariantDataType) because they give me that handy type enum. Since I've long-established that dichotomy for about a decade now, I guess that's why I never thought to do the error cluster type check your way.

[GregSands]

Just out of interest, I've kept tracking these two ideas.

 

My suggestion was that Error Wires should be placed under other wires, and Darin suggested that the Read/Write status of property nodes should be determined by how you wire them. Both ideas were fairly straight-forward, both are coding-related, both had a simple image and clear explanation, and as of now, both have attracted about the same number of comments (12 vs 16) and kudos (65 vs 70).

 

The current score is 119 - 110, an entertaining basketball game, albeit with poor defence!  What's interesting is that (a) there was only a small kick to the ideas after posting here in mid-December, and (b) they still appear to be fairly synchronized in their popularity.

 

[Daklu]

I'm glad this post got bumped.  I missed it the first time around, but I've done my duty and kudoed Darin's idea.

 

 

Like most things, I think the Idea Exchange has stages:

 

I agree with that, with the minor clarification of that being the progression of public perception of the idea exchange.  I'm not sure people inside NI ever thought it was going to revolutionize Labview.  I suspect they always considered it to be exactly what it is:  one of many tools for obtaining feedback from the user community.

 

 

Personally I have given up on winning the beauty contest, instead I hope I plant a seed in a developer who someday works on a given feature and manages to toss it in there.

 

Same with me.  The ideas that generate the most kudos tend to be on fluffy side.  (i.e. Changing the boolean constant.)  Don't get me wrong, I hugely prefer the new constant over the old one, but it doesn't fundamentally change what we can do with Labview.  I'd prefer to see more meat and less sugar in the top kudo list.

 

 

I have one idea which for many months had plateaued at 8-9 Kudos.

 

Only one?    I consider it a victory when one of my ideas reach double digits.

 

 

I have attached a VI which will move all of your error wires to the back.

 

Lovely, thank you.  I prefer them to be behind everything else but rarely take the time to do it manually.  I did make minor changes that turns it into a Project menu item if you drop it in the <Labview>Project folder. 

 

(I still get that annoying front panel pop-up-and-immediately-disappear when I use it, but whatever... it works.)

 

 

 

Just out of interest, I've kept tracking these two ideas.

 

Did you collect the data manually or do you have code to scrape it off the web?

Move Error Wires To Back.zip

[GregSands]

Did you collect the data manually or do you have code to scrape it off the web?

 

Dodgy code that runs very slowly and will break if NI changes their layout!  Now if they had an API to some of their online data...

[Darin]

As a matter of fact there is an API to access the Lithium data, but you would have to be some kind of geek to be using that to analyze trends on the idea exchange.

If such a geek did exist, I am pretty sure he would tell you that projections have my idea ahead of yours 180.12 to 151.66 after two years time. Of course that geek's predictions tend to be better when the tail is not disturbed too much.

That geek would probably also be very happy if the property node idea were implemented. In fact, I am pretty sure he would think it is a great idea.

Edited March 22, 2013 by Darin

[hooovahh]

As a matter of fact there is an API to access the Lithium data, but you would have to be some kind of geek to be using that to analyze trends on the idea exchange.

If such a geek did exist, I am pretty sure he would tell you that projections have my idea ahead of yours 180.12 to 151.66 after two years time. Of course that geek's predictions tend to be better when the tail is not disturbed too much.

That geek would probably also be very happy if the property node idea were implemented. In fact, I am pretty sure he would think it is a great idea.

...

...

 

(but seriously cool)

[GregSands]

As a matter of fact there is an API to access the Lithium data

 

So does the Stig Nerd want to share?  I did try hunting for one but my Google glasses were malfunctioning...

[Aristos Queue]

I have not tested whether the type testing or the following is better performance, but my tweak below fixes the undetected coercion problem.

 

[GregSands]

My suggestion was that Error Wires should be placed under other wires, and Darin suggested that the Read/Write status of property nodes should be determined by how you wire them.

 

... projections have my idea ahead of yours 180.12 to 151.66 after two years time. Of course that geek's predictions tend to be better when the tail is not disturbed too much.

 

Of course I forgot to check after 2 years, but it's coming up 3, so where are things at (tweaking the tail once more)?  Well my cosmetic Errors idea has actually pulled ahead of Darin's useful property node idea 176-168, thanks to a surge mid-last year for some unknown reason.  Despite that, the chances of either actually being implemented is still about the same, which is probably best approximated by .

 

Edited March 8, 2016 by GregSands

[Darin]

My idea is dead in the water because it requires real effort on the part of NI.  The good news for your idea is that it probably would make a nice addition to the right-click menu in LV15+