Do you wish "Create SubVI From Selection" worked better?

[Aristos Queue]

Darren Nattinger (he of Darren's Nuggets fame) and I need your help.

Darren is known for writing useful VI plug-ins for LabVIEW. I've had a history of creating hooks in the C++ code for calling plug-in VIs. He and I both dislike the current behavior of the Create SubVI From Selection feature. It doesn't know about the config token for preferred connector panes, it doesn't put error terminals at the bottom and class/refnum terminals at the top, it sometimes names a control "error out" and an indicator "error in", and the panel isn't laid out as clean as we might like. These are all things that could be fixed in the C++ code, but spare developers are always hard to come by, and Darren already has some G code for doing this work. Thus it made sense for the two of us to work out an interface from C++ to G to improve Create SubVI From Selection. In our spare time, we've found the right place in the C++ code to hook, figured out the data that needs to go across the interface, and gotten the code pretty close to finished. Once we knew it was going to work, we asked for permission to add it as a feature in 2011.

That's where we hit a problem we cannot solve alone.

As many of you have heard, LabVIEW 2011 is focusing on being a stabilization and performance release. Very few new features are being let in the door. The one gate that new features have is the Idea Exchange. The feature has to be limited in the amount of code it has to touch. It has to avoid performance degradation. And it has to be something customers clearly want. We can show two of those three requirements, but not the third. Without the third, the feature does not meet the goals for LV 2011, so even though Darren and I have the new callback hooks largely ready to go, the code cannot go in.

This makes us sad. I mean, it makes perfect sense -- we have to have standards, and limiting the features for this release is important -- but it still makes us sad.

"Create SubVI" is an area of LabVIEW that many of you have asked me about over the years, hoping that LV could do a better job. Darren and I really want to see this feature go into LV 2010, and we're pretty sure that there are enough of you out there that would like to see it too. If we could get the Kudos on the idea up so that the idea is in the top 15, we will be able to make the argument that this is a feature that users strongly want. Now, not every idea with high kudos is automatically blessed in the 2011 release, but with enough Kudos, we think we can get permission to proceed.

There are 3 ideas on the idea exchange that are all affected by this idea, but let's focus on the one that has the highest kudos already:

Create a proper connector pane when doing Edit -> Create subVI

As of right now, that's got 79 kudos. To make it into the top 15, we need 160 kudos, or almost exactly double what it has right now. I think this is an idea whose time has come. If you agree, please contact your friends. Make peace with your enemies. Call your mother. Encourage them all to take a moment to go vote for this idea.

If you're super ambitious, there are two other related ideas that would also be aided by our feature. You could go vote for them too. But focus on the big one first!

Provide a way to define the default connector pane

Edit >> Create SubVI: Tweaks

Help make Mercer and Nattinger unsad! Help improve Create SubVI! Vote now!

[jgcode]

... Make peace with your enemies. Call your mother....

lol

(I called my mom and she said "Hi!")

[Norm Kirchner]

So all we're talking about here is having the hooks added and possibly Darren's code or ours should we choose, right?

If you code monkeys force me to 4224 instead of 5335 and tag .ctl or .lvclass on the end of all of my controls more than you already do, I'm going to take my pikachu down to the 3rd floor and demonstrate some hand to hand knife fighting moves on him.

http://twitpic.com/2c6s2s

[ShaunR]

So all we're talking about here is having the hooks added and possibly Darren's code or ours should we choose, right?

If you code monkeys force me to 4224 instead of 5335 and tag .ctl or .lvclass on the end of all of my controls more than you already do, I'm going to take my pikachu down to the 3rd floor and demonstrate some hand to hand knife fighting moves on him.

http://twitpic.com/2c6s2s

Don't forget all the documentation

Edited September 10, 2010 by ShaunR

[Ton Plomp]

Help make Mercer and Nattinger unsad! Help improve Create SubVI! Vote now!

Allright I voted, however I think that NI should not only implement the easy ideas from the Idea Exchange.

Basically all the ideas implemented are 'low hanging fruit', I would be ashamed to name those new 'changes' as the major upgrade feature (as NI is currently doing).

Ton

[ShaunR]

Allright I voted, however I think that NI should not only implement the easy ideas from the Idea Exchange.

Basically all the ideas implemented are 'low hanging fruit', I would be ashamed to name those new 'changes' as the major upgrade feature (as NI is currently doing).

Ton

Oh, I don't know. I think some of the changes are really useful (like clusters as control-type icons). But they all seem to be cosmetic changes. So whilst I like the idea of a cleaner diagram, I would (as I think you are suggesting) prefer to see the more meaty ones implemented that enhance the program rather than the prettiness of the diagram.

Or maybe that's a sign in itself. That we are having to spend too much time making diagrams "look" good instead of making functional code.

But I think Aristos' suggestion is an excellent one (and long overdue). I use it a lot and it would save be bags of time.

I'm in the same boat as jgcode so I'll have to create 3 more accounts and hire a medium

Edited September 11, 2010 by ShaunR

[jgcode]

I'm in the same boat as jgcode so I'll have to create 3 more accounts and hire a medium

Do you want to be friends?

Basically all the ideas implemented are 'low hanging fruit', I would be ashamed to name those new 'changes' as the major upgrade feature (as NI is currently doing).

I agree, that they should not sold as major upgrades. (unless warranted).

But I don't think NI was promoting the 2010 release as: individual ideas = individual major features.

IMHO the major feature was the Idea Exchange itself and how NI has a strong (web based) mechanism in place for collecting customer feedback that is cycled into the product releases.

The new changes were just evidence of this.

At the end of the day, we (the customers) voted for (most of) those features - democratically speaking.

[ShaunR]

Do you want to be friends?

OK. Added:D

I agree, that they should not sold as major upgrades. (unless warranted).

But I don't think NI was promoting the 2010 release as: individual ideas = individual major features.

IMHO the major feature was the Idea Exchange itself and how NI has a strong (web based) mechanism in place for collecting customer feedback that is cycled into the product releases.

The new changes were just evidence of this.

At the end of the day, we (the customers) voted for (most of) those features - democratically speaking.

Indeed. The really astounding (is that the right word?) aspect of it is that NI REALLY DO listen to thier customers and the changes are the evidence.

Edited September 11, 2010 by ShaunR

[Yair]

Stability and performance are great, but do they have to come at the price of features? Many of the suggestions in the exchange are relatively simple ones and I assume NI could say "OK, we want LV 2011 to be mainly more stable, but we also want it to have some features, so we're going to invest N developer time on doing some of the more simple requests". I assume NI is already using this logic, but N does NOT have to be a small number. If N is large enough, then this feature should be able to make it in relatively easily (and without knowing internal details or looking through the exchange too closely, I still contend that N could probably be high enough to implement at least 20 of the relatively simple ideas there without endangering the overall stability goal, including this one, although I could obviously be completely wrong).

Also, you can probably count the kudos for the two ideas together. I assume there's some overlap, but you don't have to tell the managers that.

[gyc]

So all we're talking about here is having the hooks added and possibly Darren's code or ours should we choose, right?

If you code monkeys force me to 4224 instead of 5335 and tag .ctl or .lvclass on the end of all of my controls more than you already do, I'm going to take my pikachu down to the 3rd floor and demonstrate some hand to hand knife fighting moves on him.

http://twitpic.com/2c6s2s

Nice pics you got there!

What's about the "popcorn tweets"??? Sounds like a great fun...

Where can I see (a video of) this demo???

[Daklu]

Stability and performance are great, but do they have to come at the price of features?

Yep. Time is a limited resource. An increase in one area requires a decrease in another.

Granted in this particular case where the code is already done there is less of a hit. To merge it into the main branch probably requires someone to develop tests, probably a code review, and maybe someone to act as PM to manage the process. Less time to be sure, but still time that they could have spent working on stability. I'd like to see some new features, but I'd like more to not have LV crash on me half a dozen times every day. If NI decides they need to devote all their dev time to stability issues, I'm okay with that.

Many of the suggestions in the exchange are relatively simple ones

Whenever I have a customer tell me their change request should be simple the alarms go off. The request might be simple, but implementing the request often isn't. As a rule they get to tell me what they want; I get to tell them how long it will take to implement. (Sometimes when I give them an estimate they decide they don't really need that feature after all.)

Also, you can probably count the kudos for the two ideas together. I assume there's some overlap, but you don't have to tell the managers that.

Absolutely! Here's hoping Mercer and Nattinger can "market" the idea successfully. (Though in reality I'm sure NI already has some method for combining similar ideas.)

[Yair]

Yep. Time is a limited resource. An increase in one area requires a decrease in another.

...

...

Yeah, yeah, blah, blah, blah. I know all that. I guess I deserved that for writing a post mostly full of hot air and stuff that NI already knows, but I needed to get it out there, just on the off chance that it might be heard. Besides, I still want NI to implement my feature requests.

Though in reality I'm sure NI already has some method for combining similar ideas...

Don't be. The Lithium system is far from knocking me off my feet with amazement, and it wouldn't shock me if it didn't have anything other than the Duplicate status.

[Black Pearl]

Don't be. The Lithium system is far from knocking me off my feet with amazement, and it wouldn't shock me if it didn't have anything other than the Duplicate status.

The 'community' is even weaker, but much better polished. And a lot of succesful open source projects use ugly bugzilla web services. I wouldn't judge from what we see to what 'they' see.

Well, we all know that the LV programmers community is cool, despite scrapy ways of communication.

Which brings me to a fundamental 'flaw' in the IE system. You and me as users just see a very small portion of the complete code. We are power users, don't forget, so we already discuss 'stability' and 'performance' while I guess most ideas are on the level 'add a button to do X in Express VI Y'.

I make pretty complex measurement equipement and I'd like to have the customers questioning the 'though stuff' (how do you implement error propagation, what about the PID controller, how is your internal messaging system designed ...) but in 99% of the cases I get 'I want a cancel button here', 'I want a plot legend there' and I want a 'comment field in this dialog'.

If the only mechanism to develop LV further would be the pure IE exchange, we will all be talking about the good old times of Express VIs when LV didn't look like facebook. If we implement a class, we would need to invite the method vi's as friends and then go on the method to accept the invitation; instead of Icons they would all have Avatars double the size of an express vi ..

Felix

[ShaunR]

I make pretty complex measurement equipement and I'd like to have the customers questioning the 'though stuff' (how do you implement error propagation, what about the PID controller, how is your internal messaging system designed ...) but in 99% of the cases I get 'I want a cancel button here', 'I want a plot legend there' and I want a 'comment field in this dialog'.

That's because it doesn't matter how you did it. As long as you did it on-time, on-budget and to spec.

Reminds me of a cartoon I once saw where there was a really long paragraph of an engineer explaining how they did something (he was chuffed to bits). The other man said "Yes. But does it work?" To which he replied "No"

[Yair]

Which brings me to a fundamental 'flaw' in the IE system. You and me as users just see a very small portion of the complete code. We are power users, don't forget, so we already discuss 'stability' and 'performance' while I guess most ideas are on the level 'add a button to do X in Express VI Y'.

That is only a flaw to a degree.

The IE has two functionalities - it allows users to log requests and it allows NI to gauge the general interest in those requests.

While the requests can be of any level, in practice you can't really offer "heavy" features, as you can't describe them simply and most users can't understand. Just ask Daklu what happened to his ideas.

So, you're left with the "light" features. Some of them are pure fluff (although I have read every single post on the IE and I can say it's not nearly as many as you seem to think), but many offer significant improvements, useful polish, or both. These are perfectly legitimate.

Also, I should point out that as a customer I DON'T want to design the feature. That's what NI is paid to do. Once the basic idea has been put forth it should be up to NI to figure out how much work it will be, how easy it will be to integrate, etc.

While considering these when submitting an idea can be useful, it's definitely not a requirement and can't be.

[Black Pearl]

Well, my specs usally say:

10. software: customized software wirtten in LabVIEW.

Yep, no more. And I can live with it. The customer hase to design the feature (write more detailed specs) and at some point I can say 'that's out of scope/budget/...'. This seems to be a completely different situation that NI has, but in parts, it isn't.

Once I have a feature completed and go on to the next customer, all change requests are pure cosmetic.

Well, both situations are completely different. So I try to put it in a much higher abstraction level.

I think that a correctly working software only gets (by request) two kinds of additions:

* new features (so completly new from the scratch, as add-on)

* cosmetic changes (like a cancel button on a dialog)

and this mechanism is user (customer) driven.

but seldom (never)

* improving a sub-feature (performance optimization, Edit->Create SubVI)

* adding a subfeature (e.g. support for abstract classes in LVOOP)

Because this can only be judged by the developers and sometimes the power users; never management or new customers (-> marketing).

Felix

[Norm Kirchner]

I still contend that N could probably be high enough to implement at least 20 of the relatively simple ideas there without endangering the overall stability goal, including this one, although I could obviously be completely wrong).

I would bank on the latter....just saying

[ShaunR]

Well, my specs usally say:

10. software: customized software wirtten in LabVIEW.

Yep, no more. And I can live with it. The customer hase to design the feature (write more detailed specs) and at some point I can say 'that's out of scope/budget/...'. This seems to be a completely different situation that NI has, but in parts, it isn't.

Once I have a feature completed and go on to the next customer, all change requests are pure cosmetic.

Well, both situations are completely different. So I try to put it in a much higher abstraction level.

I think that a correctly working software only gets (by request) two kinds of additions:

* new features (so completly new from the scratch, as add-on)

* cosmetic changes (like a cancel button on a dialog)

and this mechanism is user (customer) driven.

but seldom (never)

* improving a sub-feature (performance optimization, Edit->Create SubVI)

* adding a subfeature (e.g. support for abstract classes in LVOOP)

Because this can only be judged by the developers and sometimes the power users; never management or new customers (-> marketing).

Felix

Were a bit off topic. But I'm going to steam ahead anyway since I don't think it'll last long otherwise I would have started a new thread.

We must have the same customers . Its pretty much what I get (initially). Only my approach is for me to write the spec over a series of sit-downs (hand-holding). That way I can include stuff in the spec that perhaps they hadn't considered, but important to their operational situation (back-up and data storage is a common one they overlook). It also means I get a very good picture of the customers "minds-eye" of what they expect the system to be like. I usually also try and get one of their technical people to be actively assigned to the project then you get out of a lot of the "status reporting" 'cos thats his job

Your thoughts about what constitutes a change (and therforre the customer incurrsa cost) is identical to mine. However, you sneakily said "correctly working software", which, is normally the bit that starts arguments. And it needs to be extremely well defined right at the start of the project what and how testing will be done by both parties to ascertain its "correctness". I would go 1 further and say "correctly working system! I take the (some may think draconian) view if its not working "correctly" then its not completed and therefore not released to the customer (expecting customers to do alpha and beta testing is a cop-out). V1.0 is the first time a customer will get the system and Its very rare you will find an up-issue that is a bug-fix release in either software, hardware or mechanics.

[Daklu]

If you code monkeys ... tag .ctl or .lvclass on the end of all of my controls more than you already do, I'm going to take my pikachu down to the 3rd floor and demonstrate some hand to hand knife fighting moves on him.

Please, do whatever it takes to get them to stop. I thought it was just me that didn't like it...

I guess I deserved that...

Yep, you did.

Yeah, yeah, blah, blah, blah.

And I deserved that for taking the bait.

The Lithium system...

What is the "Lithium system?"

Just ask Daklu what happened to his ideas.

They rot on the vine, never having received the loving attention of the community or an NI sponser. (Except for configurable quick drop shortcuts, which Darren kindly took care of.) Out of 17 ideas I've posted, only 4 have received more than 10 kudos and none received more than 20. (Not that all of them deserved kudos...)

I've given up on posting any significant language advancement ideas on the IE, simply because I know it won't get any kudos and that will give management leverage not to implement it. If I lobby for it on Lava or NI's forums it might get someone's attention at NI and they can rally internal support for it while avoiding the dreaded IE mark of death. That's my hope anyway...

[huotom]

奖励

状态：

Edited September 14, 2010 by huotom

[Aristos Queue]

I've given up on posting any significant language advancement ideas on the IE, simply because I know it won't get any kudos and that will give management leverage not to implement it. If I lobby for it on Lava or NI's forums it might get someone's attention at NI and they can rally internal support for it while avoiding the dreaded IE mark of death. That's my hope anyway...

I like to point out to various and sundry constituencies within NI that a teeny tiny handful of customers ever asked for object oriented programming. We never got a field sales engineer reporting "My customers could really use some better encapsulation." But we got tons of requests for the compiler validating the VIs marked as not-top-level in LLBs weren't called outside of the LLB. We never got requests for inheritance, but we have many requests for more code reuse.

R&D is fairly aware that the big changes -- the ones that shift the paradigm of LabVIEW, like the Event Structure or the IPE or OO -- are not common user requests. Putting them on the idea exchange is not a bad thing. That still gives us a place to discuss a new idea in the public forums, and it can provide a one-stop-shop for all the ideas we've considered over time. For example, I don't expect my source code control meta language idea to ever rack up high kudos, but I put it on the Idea Exchange to archive it and to allow the few folks that could envision that idea to comment on it. I probably won't ever work on that idea, but maybe someone on my team will at some point. Anyway, I still like that aspect of the IE, and I hope that the "reach for the stars" and the "hey, I can dream, can't I?" ideas still get posted there.

[ShaunR]

like the Event Structure or the IPE or OO -- are not common user requests.

I think you'll find that a way of handling Events was being called for for quite some time. Not necessarily an event structure but a way of handling UI events as all the other visual languages could.

[Daklu]

I like to point out to various and sundry constituencies within NI that a teeny tiny handful of customers ever asked for object oriented programming.

I know. That's why I still have faith some of the grander ideas may still come to fruition.

We never got a field sales engineer reporting "My customers could really use some better encapsulation." But we got tons of requests for the compiler validating the VIs marked as not-top-level in LLBs weren't called outside of the LLB. We never got requests for inheritance, but we have many requests for more code reuse.

As a Labview end-user I often have a hard time explaining what my *goal* is and tend to focus on asking for a *specific implementation.* Maybe it's a problem all users have. My customers are always telling me *how* to do something that they think will meet their goal, only to find out afterwards that it doesn't quite work out the way they thought it would. Ironically, I'm pretty good at drilling down and figuring out customer requirements when I'm the developer... I just suck at it when I'm the customer.

R&D is fairly aware that the big changes

That doesn't surpise me at all, but I'm glad to hear it anyway. You're programmers so you understand what we're asking for and why it doesn't get more support on the IE. Here's the questions I'm wondering about:

- Does R&D have the authority to put language features on the map that add new functionality when marketing wanks are crying that an Express vi to randomize the front panel color scheme just hit #10 on the IE? (Yep, my biases are showing... sorry.)

- Which department owns the IE? It's a device to solicit customer feedback so my guess is marketing or product planners, but maybe not. I suspect neither of those groups are particularly concerned about the minority of advanced programmers who see a need for major feature additions. And when it comes down to deciding between the random color Express VI with 78 gazillion kudos and interfaces with 9 kudos, are interfaces even going to show up as an option on the slide deck.

Putting them on the idea exchange is not a bad thing. That still gives us a place to discuss a new idea in the public forums, and it can provide a one-stop-shop for all the ideas we've considered over time.

Old ideas drop off the community radar and don't get any action. Do they stay on NI's radar? Sure it provides a one-stop shop, but if product planning is just dashing in to grab the latest sugar-coated idea featured on the end cap, the old ideas will forever sit in the back gathering dust. There will always be ideas with way more than 9 kudos. How often is the entire list scoured and evaluated?

Anyway, I still like that aspect of the IE, and I hope that the "reach for the stars" and the "hey, I can dream, can't I?" ideas still get posted there.

I don't mean this to be a rant against the IE. I really do think it's a good idea and NI's commitment to focusing on the customer is admirable. It's just frustrating as a user to see relatively minor changes shoot to the top of the chart while the ideas that truly expand what we can do with the language go nowhere. You have the advantage of knowing how seriously an idea is being considered. As far as the rest of us are concerned, we often don't have any insight into what effect (if any) the idea is having on the direction the language is going. (Unless it happens to be one of the few ideas that gets picked up by NI.)

[Yair]

What is the "Lithium system?"

The NI forums (and IE) run on a platform developed by a company called Lithium. I was referring to the fact that the IE was a relatively new product and it seems considerably unpolished. I don't know who else uses the IE module, but it seems that our usage of it has been pushing it "over the limit" and since we managed to do that so easily, I wasn't particularly impressed with the system.

You [AQ] have the advantage of knowing how seriously an idea is being considered. As far as the rest of us are concerned, we often don't have any insight into what effect (if any) the idea is having on the direction the language is going...

I think that's an excellent point. I have mentioned to various NI people in the past that it would be useful if the whole process had more transparency and user involvement, but it maybe it's time to pick up that cause again (although I should point out I'm not too optimistic, due to business considerations, etc.).

[Daklu]

it seems that our usage of it has been pushing it "over the limit"

Really? I hadn't noticed. ('Course, I don't go there very often...)

(although I should point out I'm not too optimistic, due to business considerations, etc.).

Yeah, me neither. Actually I agree with their reasons for not opening up feature planning. I just wish it was different. And since "world peace" ideas get no love, there's little motivation to post them.

(In spite of that, hope overrode logic once again and I posted another world peace idea I've been lobbying AQ for.)