NXG, I am trying to love you but you are making it so difficult

[Neil Pate]

Why are so many things just that little bit harder in or weirder in NXG? I am trying to use it to make my first "real" application, in this case a relatively simple WebVI.

I put this list down in the hope someone can tell me I am being dumb and there is a sensible way to do these thing

• Why can I not easily branch off a wire by clicking on it somewhere? Now I have to right click and select the option to create a wire branch
• Why can I not right click on a primitive to open the sub-palette for that thing to give me similar items. I can right click and replace or right-click and insert... Example, I have an existing 2D array wire I want to get the size of, there is no way for me to right click the wire to quickly open the array palette and then drop down a Size primitive
• I have to relearn the whole palette structure as all the icons have changed. OK that is fine so let me explore a bit and poke around but I cannot keep a palette open by pinning it? (OK so it turns out I can do this if I start the browse from the left-hand palette and then weirdly click the << arrow, but I am so used to opening the palette by right clicking on the diagram). Arg, then the pop-up help covers over the next item in the list 😞
• The Align menu is so much less usable in that drab gray and single line. There was nothing wrong with the way it is implemented in Current Gen, why change this?
• The GUI is so dull in general. The colours are washed out and grey everywhere is just depressing. It sounds silly but it makes me not want to use it.
• Sorry, but MDI is not a suitable technique for anything other than the most trivial of applications.
• I like the really like the zoom but please let us pan with the middle-mouse or something similar
• Please pop open menu items as soon as I browse into them, rather than forcing me to click (looking at you Case Structure Cases and Align menus)
• Why are the icons so confusing. Please can someone explain how the picture below conveys any information that this array concatenation.

• Why can I not run a Sub VI in a WebVI? In order to test the correctness of a piece of code I have to move it out of the .gcomp to run in isolation, and this actually moves the code on disk
• What was fundamentally wrong with the Project Window in Current Gen? I have a vertical monitor that I use exclusively for displaying the Project window and it is amazing.  I don't particularly like the new implementation but at least let me undock it! I am also not really filled with confidence that as my project grows in size it will not become overwhelming (yet another reason to keep Virtual Folders)

This is just a small subset of the items I am currently struggling with. In general I am quite forgiving of new software, but I think NXG has been baking in the oven for something like 8 years!

I appreciate that NXG has not been designed for me, rather I suspect it is targeted at a whole new audience of LabVIEW developer. As such I know my muscle memory is going to be really detrimental in getting me up to speed with this new way of doing things so I am trying really hard to not let that get in the way of my journey. Something deep down just makes me worry that the essence of what makes LabVIEW (current gen) so special has been lost in translation. It just feels like too many decisions have been made by people who are not actually very familiar with LabVIEW. This makes me a bit sad as I have no doubt that a ridiculous amount of engineering effort and love has gone into NXG (and am under no illusions at the scale of the task of rewriting current gen).

All in all my experience trying to develop a non trivial (not by much though) application in NXG has further cemented my thoughts that I am going to have to stick with current gen for the foreseeable future.

That said, strength and courage to NI. I will check back again in a few years.

ps: I am really excited for the WebVI technology. Please port it to Current Gen so I can actually use it 🙂

Edited April 29, 2020 by Neil Pate

[jacobson]

1 hour ago, Neil Pate said:

Why can I not easily branch off a wire by clicking on it somewhere? Now I have to right click and select the option to create a wire branch

File > Preferences > Editor > Wiring lets you change this back to CG behavior.

1 hour ago, Neil Pate said:

• I like the really like the zoom but please let us pan with the middle-mouse or something similar

NXG gives you the hand tool when you hold the space bar instead of Ctrl+Shift like in CG. One minor improvement (my opinion) is that, in NXG, the scroll wheel will move the diagram up and down but if you shift+scroll, the diagram will move right to left (CG just scrolls up/down faster).

That's about the extent of my NXG knowledge.

[drjdpowell]

Unfortunately, rather than go "where can we make a few key changes that will significantly improve LabVIEW", they went "let's change everything!"

[BramJ]

7 hours ago, jacobson said:

One minor improvement (my opinion) is that, in NXG, the scroll wheel will move the diagram up and down but if you shift+scroll, the diagram will move right to left (CG just scrolls up/down faster).

Would be nice if NXG, like CG, would support the horizontal scroll options available on many mice these days. In NXG that is somehow bound to zoom if the Zoom Control option is set to  "Ctrl + Mouse Wheel"

if Zoom control is set to "Mouse Wheel" the scroll left/right is bound to scrolling up and down, makes no sense.

[Neil Pate]

6 hours ago, smithd said:

This is kind of an interesting concept to me and its one I've been curious about. Just based on my own anecdotal experience it seems like the thing holding labview back is less the UI of the editor and more the combination of "not a real programming language", python being the thing taught in schools, relatively high costs, limited developers and general unavailability of a great many experienced labview devs outside of a pretty insular community, and the deployment/runtime situation (labview doesn't get a free pass like dotnet, javascript, and in most cases java).

I'm genuinely curious if there is data out there which justifies the things nxg is focusing on.

Don't forget NI is a hardware sales company. LabVIEW is just the tool that allows them to sell more hardware. I suspect this is why there is such a heavy push to have hardware integration directly in LabVIEW NXG (to the detriment of the system as a whole). NI have decided to get in on the whole cloud business with SystemLink but again they have missed the point that by far the majority of LabVIEW devs just dont care about this or wont use it.

Happily, the community edition will be able to compete on price with all the other zero cost languages out there, but candidly I feel that the ship has sailed for younger devs, and those holding LabVIEW tickets are still at home putting their pyjamas.

Edited April 28, 2020 by Neil Pate

[LogMAN]

@Neil Pate Thank you so much for sharing your thoughts. I have also been playing with NXG (working through the NI online courses) for the past few days and my impression is very similar to yours. NXG has a lot of interesting and useful features that I really want to use as soon as possible but at the same time there are so many little things that either don't work, are missing or very annoying to use. At this point I'm still interested in learning about all the features of NXG, without any intention to use it for any serious application in the foreseeable future (3-5 years). Nevertheless, this is a chance for me to give feedback to NI on all those little things. With NXG 5.0 around the corner I hope they address many of the "obvious" problems in 4.0. In any case, I intend to treat it as an early-access platform rather than a released product. In my mind NXG 4.0 is really NXG 0.4.

One thing that really frustrates me is that there is no platform to suggest ideas and vote on them. The feedback system in NXG is a one-way ticket.

11 hours ago, Neil Pate said:

Why can I not right click on a primitive to open the sub-palette for that thing to give me similar items. I can right click and replace or right-click and insert... Example, I have an existing 2D array wire I want to get the size of, there is no way for me to right click the wire to quickly open the array palette and then drop down a Size primitive

You can do it from an open ended wire branch, which is one of those annoying things not intended by NI. Create an open ended wire branch, right click on the end of that wire and create the primitive you desire. You can see in the screenshot that the menu allows you to access the array palette. Not very user friendly imo, but still better than surfing the palettes on the left.

Edited April 28, 2020 by LogMAN
Remove orphan image

[JKSH]

One feature I miss dearly in NXG is the ability to create type definitions inside classes. Want a typedef'ed enum inside a class's namespace? LabVIEW CG says "No problem", LabVIEW NXG says "No can do".

For example, I could previously have multiple enums called "State" in my project because each copy is in a different class/library: ClassA.lvclass:State.ctl and ClassB.lvclass:State.ctl. However, NXG forces globally unique names for enums/clusters.

* I last checked in NXG 3.0 -- perhaps the ability will exist in NXG 5.0?

 

16 hours ago, Neil Pate said:

The GUI is so dull in general. The colours are washed out and grey everywhere is just depressing. It sounds silly but it makes me not want to use it.

I think this trend started a few years ago: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Restore-High-Contrast-Icons/idi-p/3363355

[MarkCG]

14 hours ago, smithd said:

This is kind of an interesting concept to me and its one I've been curious about. Just based on my own anecdotal experience it seems like the thing holding labview back is less the UI of the editor and more the combination of "not a real programming language", python being the thing taught in schools, relatively high costs, limited developers and general unavailability of a great many experienced labview devs outside of a pretty insular community, and the deployment/runtime situation (labview doesn't get a free pass like dotnet, javascript, and in most cases java).

I'm genuinely curious if there is data out there which justifies the things nxg is focusing on.

I remember reading somewhere that the idea behind LabVIEW was to make data acquisition as easy as creating a spreadsheet. That is anyone with some ability to use a computer and understand basic math could create something that worked for their purposes without being a programmer. Gradually more and more complexity and capability was needed and the professional LabVIEW programmer emerged, similar to how professional Excel/VBA programmers arose in the financial industry. 

But like everything the need for the professional LabVIEW programmer was a product of particular historical circumstances, and I think history has moved on. Since many big companies have invested a lot of money in NI hardware we will be some demand for LabVIEW programmers to maintain these system, but it will taper off over the decades. I think it will be like COBOL -- you'll have a few crusty old guys wading into ancient codebases to make fixes and smaller changes but no greenfield development.

I may be wrong but I think NXG is NI's last gasp attempt to stay relevant and that it will fail. The attitude in most companies I have experience with is that "not owning your source code" is a major, major problem, and I don't see that changing. LabVIEW is seen as a sometimes necessary evil only.

If NI wanted LabVIEW to stay relevant for years they would make it open-source, and keep selling hardware and software add-ons for it. But they know their business better than I do and what's good for me isn't necessarily good for them.

 

 

[Neil Pate]

4 hours ago, JKSH said:

For example, I could previously have multiple enums called "State" in my project because each copy is in a different class/library: ClassA.lvclass:State.ctl and ClassB.lvclass:State.ctl. However, NXG forces globally unique names for enums/clusters.

Yikes, this I did not know!

This was probably decided by the same committee that came to the conclusion that nobody really should be using Virtual Folders anyway. 🙄

[LogMAN]

20 minutes ago, Neil Pate said:

This was probably decided by the same committee that came to the conclusion that nobody really should be using Virtual Folders anyway. 🙄

You mean the same committee that works with Visual Studio all the time? I wonder where they get their ideas...

5 hours ago, JKSH said:

One feature I miss dearly in NXG is the ability to create type definitions inside classes. Want a typedef'ed enum inside a class's namespace? LabVIEW CG says "No problem", LabVIEW NXG says "No can do".

Yes, that is a bummer. Actually, the thing they call "G Type" serves as a strict typedef, but it is really just a class that doesn't inherit from gObject (it inherits from Void). Since classes cannot be nested in LabVIEW CG/NXG, the only way is to put both of them inside a common library.

Now, where have I seen this concept before...

[Neil Pate]

I must admit I have not fully grokked all the changes with classes and types in NXG. Last time I looked it was a mess so I just left it for a while.

Your screenshot makes me sad for a bunch of reasons. So much ugly grey except for the totally random bits of blue thrown in.

Now, lets think about the lack of consistency here.

1. On the top left the file icon has a blue background to show us it is selected, ok cool
2. So in the tree view Library.gcomp is selected, but it is not blue... ok... why?
3. The tab in the middle pane is not coloured blue to indicate it is current... ok... why?
4. On the right we have a tab structure and the Document tab which is currently selected is highlighted...

Sigh... am I the only one who sees stuff like this or am I just crazy and looking at it totally wrongly?

Why are the tickboxes in the middle coloured blue? This is so random.

 

Now, I am not a graphic designer, and I am sure that NI has done their due diligence in designing this GUI that we spend 40+ hours a week interacting with, so I will give them the benefit of the doubt (again...) but I just don't get it.

[pawhan11]

Some of my thoughts after working 6 years as 'Labview Developer'

• Popular languages like python or c# gained so much momentum, entry level is much easier than few years ago, it will get closer to LV entry level
• LV did not change much over last 6 years, things that I remember were maps, sets, vims and independent runtime engine
• paid and closed source kills any chances of becoming more popular, in my opinion it is ok to pay but for addons like ML or DSP, if i recall at some point excel addon required payment
• decline in job offers in LV, I ve seen more and more python/.net  in test eng field (at least in Europe)
• source control is terrible with binary files compared to text diffs & history available in text IDEs
• cheaper hardware alternatives like Advantech, I would never buy average PXI controller for 8k, when you can get high end workstation + Thunderbolt card + chassis
• I no longer see LV skills valuable on the market and started to do more text based programming

 

Edited April 28, 2020 by pawhan11
hundreds of whitelines

[Aristos Queue]

20 hours ago, smithd said:

based on my own anecdotal experience it seems like the thing holding labview back is less the UI of the editor

I'm genuinely curious if there is data out there which justifies the things nxg is focusing on.

Without going into anything NI confidential, yes, NI has lost significant sales opportunities because the old fashioned UI of LabVIEW 20xx does not appeal to the next generation of engineers and scientists. Redesigning the UI from the ground up was the primary mission of NXG -- incremental adjustments were considered and rejected early on. NXG's design is very much driven by data from sources such as user testing, customer feedback, and sales numbers. Any issues NXG has had getting off the ground with customers are less from going in the wrong direction and more from having so many parts that have to move in the same direction for it to work. As more parts have come into alignment, the user base is starting to pick up.

[Aristos Queue]

3 hours ago, LogMAN said:

Actually, the thing they call "G Type" serves as a strict typedef, but it is really just a class that doesn't inherit from gObject (it inherits from Void).

I'm not sure where you get that. The execution engine is the same engine that LabVIEW 20xx uses. Classes and typedefs are the same things that they've always been. The limitation of gtypes being inside classes is one I've complained about personally... it is entirely a limitation of the UI, not the underlying nature of the entities involved. Yes, both .ctl and .lvclass use the same .gtype file extension. That makes refactoring G code to change between the two a lot simpler. But what the files represent? That hasn't changed. There are still 25 fundamental LabVIEW types, of which LabVIEW class is one (NXG doesn't have sets or maps yet, which bring the total to 27), and a typedef can host any of them (except void).

[X___]

The problem with LabVIEW is, they send you a mug, but they don't make the kool-aid resupply free. And unfixed bugs after 2 decades get old, literally (my mug is fading though, which makes it "NXG", I guess).

The really exciting prospect is all these brand new bugs which will never be fixed, yeah!

Bottom line though, none of my students or colleagues will touch it with a pole if they can avoid it, and NI hardware products can be interfaced with MATLAB and python anyway, so why bother?

[Neil Pate]

@Aristos Queue, the problem is the GUI is everything. It does not really matter what is going on under the hood (although all us CG devs really appreciate the regular strides forward).

I have yet to speak to another dev who has tried out NXG and is really excited about the majority of changes that have been made. It *really* feels as though very few actual current LabVIEW devs were consulted in the process. I am sure you will say that NI have done studies and had focus groups etc etc (which I totally believe), but to me personally the new changes suck.

I have used the Digital Pattern Editor which has the same GUI framework as NXG and the MDI nature of the GUI sucks so much. All the time I need to be able to look at several different things, and MDI makes this an exercise in frustration.

 

[LogMAN]

7 hours ago, Aristos Queue said:

I'm not sure where you get that. The execution engine is the same engine that LabVIEW 20xx uses. Classes and typedefs are the same things that they've always been.

Yes, the execution system hasn't changed but the appearance did, at least from a users perspective. LabVIEW CG has a clear distinction between the two, which doesn't exist in NXG. Classes and typedefs are both represented by the same kind of object (G Type). Although their abilities and representation is different, they are represented as the same kind of thing. If you take a control in LabVIEW CG and turn it into a class, you choose "Convert Contents of Control into class" and it becomes an entirely new type. In NXG, however, you can simply add class functionality. Now, unless a typedef is a class in secret, there is no way to simply add class functionality without converting it into a class first.

Maybe I'm reading too much into it, but this is how it appears to me.

8 hours ago, Aristos Queue said:

Yes, both .ctl and .lvclass use the same .gtype file extension. That makes refactoring G code to change between the two a lot simpler. But what the files represent? That hasn't changed. There are still 25 fundamental LabVIEW types, of which LabVIEW class is one (NXG doesn't have sets or maps yet, which bring the total to 27), and a typedef can host any of them (except void).

Yes, the amount of types and what they represent didn't change and I understand the technical reasons for how they are implemented, but why use the same file extension? I work with engineers who don't know the difference between a class and a struct (and they don't care).
What I'm afraid will happen is this:

Here is the same thing in CG

For all I care, the file contents of a typedef can be equivalent to a class. I don't even mind if a typedef was a class in secret, as long as they are easily distinguishable by the end user (i.e. me). That is currently not the case.

8 hours ago, Aristos Queue said:

The limitation of gtypes being inside classes is one I've complained about personally... it is entirely a limitation of the UI, not the underlying nature of the entities involved.

That is good news. Maybe it was addressed in 5.0, can't wait to try it out. Need to wait for the VM to finish though.

[codcoder]

I like the side discussion here. About the future of LabVIEW.

I've been in the field for close to seven years now and I constantly ponder if relying my carrer on LabVIEW is a wise decision. Because I mean, I'm no junior anymore, and just as much as by chance as by choice LabVIEW has become my speciality now, and changing track is harder and harder for each year.

Last year I attended my first NI Week and to judging from NI's marketing it was clear, according to me, that they have moved away from the use case of an engineer/scientist with a benchtop instrument controlled by a Windows PC with LabVIEW. Measuring a voltage or communicate with a IC-circuit or something like that. And I can understand why. That is a solved problem and you can just as easily do it with Python/Arduino/Raspi (everybody knows atleast one scripting language these days).

A lot more focus was on (physically) big system wide solutions, mostly for testing within the semiconductor industry and radio/5G. And I guess that makes sense aswell. These are areas where hardware matter and the price point is still quite high. Perhaps their vision is that you will buy a full solution from NI in the future and only use the GUI (LabVIEW) for some small tweaks?

So where does that leave full-fledged LabVIEW developers? I don't know. As a career advice I wouldn't recommend anyone who wants to be a pure software developer to go for LabVIEW. But I honestly believe using a high-level tool like LabVIEW has its benefits like allowing you to be a domain expert in the field you are operating in while also allowing you to be a develop the stuff without having to focus too much on grit. And I hope having that combination will still make me employable.

Edited April 29, 2020 by codcoder
added stuff

[hooovahh]

Very good thread, keep up the discussion.  I just wanted to chime in on one thing with my opinion.

16 hours ago, pawhan11 said:

Some of my thoughts after working 6 years as 'Labview Developer'

• LV did not change much over last 6 years, things that I remember were maps, sets, vims and independent runtime engine

I think I understand what you are trying to say with this.  But it seems with every version of LabVIEW, NI focused on at least having a couple important bullet points with every release.  They likely have to split resources between current and NXG flavors, but just for my own categorization I made a list of features that seem important to me with each release.  Looking over the release notes of each version of LabVIEW it is clear that each year lots of work goes into each release.  Its just that some years are more packed with features I care about than other.  

2020 - Interfaces, 2019 - Maps and Sets, 2018 - CLI and Python support, 2017 - VIMs, 2016 - Channel Wires, 2015 - Right click Framework, 2014 - 64bit support in Linux and Mac, 2013 - Linux RT OS for RT targets, 2012 - Concatenating and conditional tunnels, 2011 - Silver Controls and Asynchronous Call by Reference,  2010 -  VI Analyzer and PPLs, 2009 - New Icon editor and Snippet, 8.6 - QuickDrop

Fundamentally dataflow concepts don't change, which is a good thing.  A LabVIEW developer who started on LabVIEW 8.0 could probably do programming in 2020 just fine.  They will discover all kinds of things they never had but it won't be like starting over to them.

[Neil Pate]

35 minutes ago, hooovahh said:

Fundamentally dataflow concepts don't change, which is a good thing.  A LabVIEW developer who started on LabVIEW 8.0 could probably do programming in 2020 just fine.  They will discover all kinds of things they never had but it won't be like starting over to them.

And this is another thing that makes the jump to NXG less palatable; it is like starting over.

 

Edited April 29, 2020 by Neil Pate

[hooovahh]

Using NXG I don't feel like I am starting over, but do feel like I am programming with one metaphorical hand behind my back.  I have been part of some of the hackathons NI has hosted at NI Week.  There it was important for NI to see developers using NXG for the first time, and seeing what things they could figure out on their own, and get feedback on things.  There was definitely more than one moment where I would call someone over and be like "Look I can't do this thing I always do in current LabVIEW" and they would write things down and without giving the answer they would hint that it was possible.  After a few seconds of looking in menus, and right clicking several times I would discover it is possible but in a different way. 

I don't want to sound like I am defending NXG.  I've used the web technology in a grand total of 1 project and that's it so my experience level is quite low.  And there were several times I would tell someone at NI "Look I can't do this" and they would look confused and ask why I would want to do that.  I'd then give several real world reasons I need to do that or I can't migrate to NXG.  Which probably why my usage with NXG on real projects is low.  Keep the feedback coming.  I want to hear what struggles other people are having, just like I assume NI does.

[Neil Pate]

33 minutes ago, hooovahh said:

Using NXG I don't feel like I am starting over, but do feel like I am programming with one metaphorical hand behind my back.  I have been part of some of the hackathons NI has hosted at NI Week.  There it was important for NI to see developers using NXG for the first time, and seeing what things they could figure out on their own, and get feedback on things.  There was definitely more than one moment where I would call someone over and be like "Look I can't do this thing I always do in current LabVIEW" and they would write things down and without giving the answer they would hint that it was possible.  After a few seconds of looking in menus, and right clicking several times I would discover it is possible but in a different way. 

I don't want to sound like I am defending NXG.  I've used the web technology in a grand total of 1 project and that's it so my experience level is quite low.  And there were several times I would tell someone at NI "Look I can't do this" and they would look confused and ask why I would want to do that.  I'd then give several real world reasons I need to do that or I can't migrate to NXG.  Which probably why my usage with NXG on real projects is low.  Keep the feedback coming.  I want to hear what struggles other people are having, just like I assume NI does.

hooovahh, we have been giving feedback for > 5 years. Nobody with any authority to direct change seems to be interested.

The thing I cannot understand is this... the engineers intimately familiar with LabVIEW today are the engineering managers of tomorrow. NI is pissing off the engineers of today who are the ones signing the purchase orders of tomorrow.

I never intended for this post to descend into a rant session, I am just disappointed that after so much investment by NI this is the product that has been laid on the table. There was no need to revisit change every single decision in current gen, most of the paradigms worked really well. I would literally hold captive anyone even remotely interested in LabVIEW and gush wildly over its amazingness, like a parent gushing over their favourite child. Now when people ask me about NXG I sort of blink and stare into the distance and change the conversation.

 

Edited April 29, 2020 by Neil Pate

[LogMAN]

20 minutes ago, Neil Pate said:

I never intended for this post to descend into a rant session, I am just disappointed that after so much investment by NI this is the product that has been laid on the table. There was no need to revisit change every single decision in current gen, most of the paradigms worked really well.

(Un)fortunately only someone who actually worked with CG is able to tell the difference, which makes NXG easier to sell to new customers than existing ones. Just a few clicks and you get your shiny graphs, overviews or packages. @Aristos Queue mentioned before, that NI lost business opportunities because of the old fashioned UI of CG.

16 hours ago, Aristos Queue said:

Without going into anything NI confidential, yes, NI has lost significant sales opportunities because the old fashioned UI of LabVIEW 20xx does not appeal to the next generation of engineers and scientists. Redesigning the UI from the ground up was the primary mission of NXG -- incremental adjustments were considered and rejected early on. NXG's design is very much driven by data from sources such as user testing, customer feedback, and sales numbers. Any issues NXG has had getting off the ground with customers are less from going in the wrong direction and more from having so many parts that have to move in the same direction for it to work. As more parts have come into alignment, the user base is starting to pick up.

I'm pretty sure we are not the target audience of NXG at this point. Maybe in the future. Until then we can still spend our money on CG. Really, there is no incentive for NI to listen to our complains right now and I don't expect them to. Nevertheless, I'll keep an eye on NXG and on how it evolves in the future. Until then we can share our experience and ideas here and prevent each other from regretting horrible decisions 😉

[Aristos Queue]

8 hours ago, LogMAN said:

but why use the same file extension?

Because the refactoring is so much better. I would make this change in a heartbeat in LV 20xx if I could do it without breaking compatibility.

I would differentiate the icons in the project tree, which NXG chooses not to do. Take a look at LV 2020*... interfaces and classes use the same file extension, and it is way better for refactoring hierarchies. BUT we use distinct icons in the project tree and various other places. You can read the details of this decision in the document I published yesterday about interfaces. I even go into detail about where we deliberately do NOT differentiate for end users.

* LV2020 Community Edition became available yesterday. Commercial edition will be later in May... we prioritized the CE release for all the quarantined engineers at home.

[Aristos Queue]

2 hours ago, Neil Pate said:

hooovahh, we have been giving feedback for > 5 years. Nobody with any authority to direct change seems to be interested.

The directions have changed rather radically on many points in response to user feedback. The new component system is completely redesigned twice from customer feedback, and that's another thing I definitely wish LV20xx could backport. They dropped work on interfaces to prioritize scripting because of overwhelming feedback that the scripting tools were higher priority for getting work done in NXG. (Interfaces help some large apps... scripting helped almost every developer either directly or in the tools written for others.)

I am not on the NXG team, and yet I can point to decision after decision made directly from customer feedback.