29 replies to this topic

[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 by ShaunR, 10 September 2010 - 11:56 PM.

[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 by ShaunR, 11 September 2010 - 12:56 PM.

[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 by ShaunR, 11 September 2010 - 01:16 PM.

[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]

140

奖励

Create a proper connector pane when doing Edit -> Create subVI
状态： New

Edited by huotom, 14 September 2010 - 12:47 AM.