Require LabVIEW R&D response to any idea over N kudos

[Charles_CLA]

NI's response to the ideas thus far appears far too sporadic. For example if you check out the top LabVIEW ideas (http://forums.ni.com/t5/ideas/v2/ideaexchangepage/blog-id/labviewideas/tab/most-kudoed) 7 of the top 10 ideas are still listed as new! Adding insult to injury the average age of these ideas to date is 1,017 days! It is ok to decline ideas but please provide us some indication that this is something you take seriously. It would appear that NI is cherry picking the easiest half dozen or so items from the list so you have a marketing gimmick to list on the LabVIEW release notes. I propose that a threshold is set and made public so that if an idea reaches a certain amount of kudos, R&D must address it, even if that means declining it.

[AristosQueue (NI)]

I agree that we could be doing a better job feeding back to the forums. That's something I'll flag to people here... we were doing a pretty good job, but most developers only review the Idea Exchange once per year, when we are considering what features to work on next, so the lag can be pretty significant, and I hadn't realized just how far we had let some of the ideas go. Of course, for some of those 200+ kudos ideas, the reply from NI is going to be, "This is a great suggestion and we will work on it when it fits the rest of the development strategy plan."

Which, of course, brings up the next topic: fast tracking an idea based solely on the Idea Exchange. I believe (and here I'm pretty sure I speak for NI as a whole) that letting the Idea Exchange dictate features to work on next would be a very bad idea.

> I like this idea. NI entrusts a group of its users (the participants here!) to

> serve as technical support for its product and, in effect, a sales & marketing

> body. The company should return the favor by allowing those users some

> input regarding the development of the product!

We already do return the favor. You do have input. Huge input. Input is not the same thing as full control.

The idea exchange is a very biased input. First of all, it is only those users of LabVIEW who are fans enough of the product to come vote. Second, it does not include any input from people who are not users of LabVIEW (no new markets, no people who tried it and didn't like it). Third, it does not do relative comparison of ideas, only "yes, I wish this were in the product". Fourth, it does not recognize areas that have 20 different ideas each with a small kudos count that collectively indicates an area that needs work. Fifth, it does not compare against all the feature requests from other sources that are not listed in the Idea Exchange.

Those last three limitations are pretty significant. Given the list of idea exchanges, we do investigate the relative worth of each of the ideas versus the other things we could be working on. We work on as many of the Ideas as we can, constrained by other sources of feature requests, developers that are available in a given release (some entire teams may be working on features 2-3 years out and are unavailable to work in a given release), and the "finishability" of an idea. Some ideas are good but require significant refactoring of the code base to even start working on them, so they ooch along, with an edit in one release, a tweak in the next, until we're finally ready to tackle the idea directly. But we're not going to mark an idea as "In Work" and then tell you, "We're guessing 5 years at least." And, yes, there are ideas in that 200+ Kudos range that have that kind of time horizon.

Now, I'm sure there's particular ideas in the list that you will say, "But this could be done by anyone in a few minutes." True, with the caveat that just about no feature requires less than 2 weeks, between design, code, documentation and testing. Even something as simple as "highlight which edge of a structure node has code hidden under it" is going to need a couple weeks to completely finish. And that means something else that didn't get worked on by that somebody in those 2 weeks. And most require significantly more than 2 weeks.

The Idea Exchange is important. It does heavily influence LabVIEW features. It just doesn't work linearly based on kudos count.

[Charles_CLA]

First, thank you for taking time to write a detailed response to this idea. It is appreciated.

"Of course, for some of those 200+ kudos ideas, the reply from NI is going to be, "This is a great suggestion and we will work on it when it fits the rest of the development strategy plan.""

That'd be great! I (and presumably others) simply want to know if the idea is being considered or ignored. I believe in order to support my idea you would have to create additional categories (in consideration, in progress, not possible atm, etc).

"Which, of course, brings up the next topic: fast tracking an idea based solely on the Idea Exchange. I believe (and here I'm pretty sure I speak for NI as a whole) that letting the Idea Exchange dictate features to work on next would be a very bad idea."

I somewhat agree, I believe NI has done a reasonably good job of improving LabVIEW over the years (especially with the stability focus in 2011-12). However IMHO, there are ideas that are good enough to warrant a distraction.

"The idea exchange is a very biased input."

I thought that was the whole idea? You should definitely give LabVIEW enthusiasts more weight on feedback. We're who is buying and recommending your product. You don't want someone who is completely unfamiliar with the product driving the changes, they have no idea where the real weakness is.

"But we're not going to mark an idea as "In Work" and then tell you, "We're guessing 5 years at least." And, yes, there are ideas in that 200+ Kudos range that have that kind of time horizon."

Why not? I think it'd be really helpful to know the roadmap of LabVIEW for 5 years in the future. We're intelligent enough to understand that and we can understand if complications arise that cause the idea to be eventually declined, it's certainly better than not knowing anything.

"Now, I'm sure there's particular ideas in the list that you will say, "But this could be done by anyone in a few minutes." True, with the caveat that just about no feature requires less than 2 weeks"

Does it really take two weeks to add error terminals to the wait function? Seriously? Before someone mentions the awful "Time Delay" function again, I'll list my reasons for not liking it:

1. Express VI

    1a. Drop on palette, edit inputs

    1b. Right-click -> View as Icon

    1c. Right-click -> Visible Items... Caption

    1d. Finally have a usuable delay that has error terminals 😞

2. Delay in seconds instead of milliseconds

"The Idea Exchange is important. It does heavily influence LabVIEW features. It just doesn't work linearly based on kudos count."

I don't think I asked that it did. If I gave that impression, I apologize. I would simply like to know that the top ideas are looked at. NI owns the product, not me and therefore has the decision rights on where they take it.

[AristosQueue (NI)]

> Does it really take two weeks to add error terminals to the wait function? Seriously?

I did say "just about none". 🙂 But even this one has notable overhead. To make it work? Probably most developers on the team would take two days, the first day to learn how the code works because very few members of the team have ever edited a primitive (we just don't do that that often these days) and another day to implement it.

Then there's a half day writing tests, filing documentation update requests. And it spills over into things like updating screenshots in the documentation and changing shipping examples to remove the existing sequnce structures.

So, no, this one is probably four days total if you count all the work from everyone involved. And yes, this is an easy one to point at and say, "Damnit, make time, NI!" I've been half tempted to do it myself. Spare moments just never crop up. But it is a rarity in the list.

[fabric]

"And yes, this is an easy one to point at and say, "Damnit, make time, NI!" I've been half tempted to do it myself. Spare moments just never crop up."

I think you should do it tonight.  If for no other reason, it would remove our all-time best example of you guys ignoring simple ideas! Think of the decline in complaints... 

[vitoi]

>The idea exchange is a very biased input. First of all, it is only those users of LabVIEW who are fans enough of the product to come vote.

Shouldn't LabVIEW users who are fans enough of the product to vote get more of a say. These are the people willing to put the effort and make time to put an entry together or vote on it or comment.

>Second, it does not include any input from people who are not users of LabVIEW (no new markets, no people who tried it and didn't like it).

I would say that features such a standard web browser user interface, LabVIEW code running on a mobile device, LabVIEW code running on a microcontroller or an inexpensive credit card sized sbRIO would all create new markets. All these ideas are in the Ideas Exchange. Polishing the IDE or cosmetic changes are unlikely to introduce new users to LabVIEW.

>Third, it does not do relative comparison of ideas, only "yes, I wish this were in the product".

Is kudos number not related to level of interest?

>Fourth, it does not recognize areas that have 20 different ideas each with a small kudos count that collectively indicates an area that needs work.>

By all means, aggregate similar ideas into a superset idea and give it the collective kudos count.

Fifth, it does not compare against all the feature requests from other sources that are not listed in the Idea Exchange.

What other sources are there? I'd like to see them.

[crossrulz]

Other sources I know of are direct customer needs through the sales reps, the LabVIEW Champions, internal roadmap.  I'm sure there's others.  But that's not the point of this idea.  The point of this idea is that we, as the Idea Exchange participants, are informed about the status of our ideas.  I would like to know that NI has seen the idea.  I would like to know if it is a major deal and will take time.  I understand there's a lot of ideas.  And a lot of them simply will not be done for one reason or another.  Just a general status update every so often would be nice.

[dthor]

I don't mind that Ideas take a long time to implement: I understand that things are much more complicated than what we can see as a public user. That's not what I'm voting for by giving Kudos to this Idea.

What I'm Kudoing is the concept behind the Idea: let the customers (Idea Exchange users) know that an Idea has been read by *someone* at NI R&D. A simple acknowledgement of the Idea is enough in my opinion.

(What would be better would be a CAR-like system, where once NI R&D reads the message they assign a public identification number, so we can track how an Idea is progressing internally, but that's a separate Idea)

[AristosQueue (NI)]

vitoli wrote:

> Shouldn't LabVIEW users who are fans enough of the product to vote get more of a say.

Yes. And you already do get more say. I don't know how else to say it. The Idea Exchange exists and it does guide what we work on. Guide, not dictate.

> I would say that features such as...

I would agree with you. NI would agree with you. We have never said we are not doing these things. We are doing them in what we believe to be the right priority.

> Is kudos number not related to level of interest?

No correlation whatsoever.

A) I can post the exact same idea on two different days of the year, one in August and one in December. The one in August will generally get more kudos. Why? Because one is new and fresh during NI Week when everyone is talking about LV and the other is posted while lots of folks are on vacation and by the time they get back it fell off the list.

B) I ask person X "Do you want feature Y?" He says, "Yes." I ask, "Do you want feature Z?" He says, "Yes." I ask, "Do you want feature Y if it means we don't work on feature Z?" He says, "No!"

[vitoi]

So, do we get feature Y, feature Z or nothing?

[GregSands]

>> I agree that we could be doing a better job feeding back to the forums.

Your own efforts to address this are appreciated.  That's why I gave this post a kudo, but not the one requiring NI to implement ideas above a threshold.