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

[hooovahh]

Thanks for the info-labview quote, the decline of Silverlight and NI's inability to pivot is a shame.  Especially when posts by NI on the forums hinted that HTML5 features would replace Silverlight tools.  I interpreted that as being transparent to the users of their systems.  Like update to the newest version of MAX and all the tools that did use Silverlight have been replaced with their HTML5 equivalent tools.  We are 5 years after that post, and it is a shame that remote front panels still use a technology so unsupported.

Also you do know those last two links are April fools jokes right?

[Neil Pate]

1 hour ago, hooovahh said:

Thanks for the info-labview quote, the decline of Silverlight and NI's inability to pivot is a shame.  Especially when posts by NI on the forums hinted that HTML5 features would replace Silverlight tools.  I interpreted that as being transparent to the users of their systems.  Like update to the newest version of MAX and all the tools that did use Silverlight have been replaced with their HTML5 equivalent tools.  We are 5 years after that post, and it is a shame that remote front panels still use a technology so unsupported.

Also you do know those last two links are April fools jokes right?

Yes but the last two links are what make this tragically ironic...

[X___]

1 hour ago, hooovahh said:

Also you do know those last two links are April fools jokes right?

Luckily the context of the emails they were embedded in made it clear and pointed this out to the overly graphically oriented. But thanks for checking.

[smithd]

For those of you not using any of their remote systems (rt pxi, crio, or slsc): silverlight is still alive and well technically extant in the WIF.

you have to use internet explorer because no other browser supports the silverlight plugin, but thats still better in many cases than trying to find a remote system in MAX.

[JeffP]

First of all, hi everyone and thank you all for the feedback. I really do appreciate it, and I want you to know that I generally read these threads even if I don't always participate. Stephen also periodically sends threads to me and the other relevant product owners.

I am the product owner responsible for G language in LabVIEW NXG. There are other product owners responsible for other aspects of LabVIEW NXG and the related technologies. Our role in LabVIEW R&D is to advocate for the user within the development team. We am ultimately responsible for making sure the functionality we add to the product is valuable to our users.

That being said - I don't want to oversell my role. As the product owner (which we have started calling productization lead because I don't actually own the product) I don't set the priority of which functionality we invest in first - that is decided by our planning organization, but I work closely with them and have a lot of input into that process. It is the responsibility of planning to identify high level workflows and investment areas, and it is the shared responsibility of the product owner and development team to design and build solutions that satisfy those requirements. 

There is a lot of good feedback here, much of which I was already aware of, and much of which predates my role existing. I want to take the time to properly address the different points in this thread - so expect some follow up posts from me next week, but first I just wanted to introduce myself. 

Jeff Peacock

[Neil Pate]

Thanks Jeff. All of us here just want NXG to be awesome, so anything we can do to help get it right (in our opinion) I am sure we will do.

[drjdpowell]

Jeff, what is a good place for NXG feedback?   There is a beta forum here, but it is extremely quiet.  

[JeffP]

So first I want to acknowledge some areas we could have done better. I have been involved in a number of discussions around what our migration strategy looks like, and the biggest gap we immediately identified is a lack of clear external messaging, so that is something we are looking to address. I have talked to all different kinds of users, and in a relatively short discussion we are able to align on whether or not NXG is ready for their use case. That is great, but you should be able to make that determination yourself by looking at public documentation, it should not require a call with me or a frustrating session of attempting to migrate an application. NI has tried to provide this in the past with the LabVIEW roadmap, but it doesn't have enough detail for you to make a high confidence decision. For example, it is not possible to differentiate between functionality that is not complete yet versus functionality which was intentionally omitted or intentionally changed.

We have also not done a very good job of explaining the background of specific decisions - which leads to some of the feedback in this thread where it seems like we have changed everything for no reason. Certainly I can point to some changes which were mistakes, and generally speaking we have the flexibility to undo those changes, but many of the bigger changes were intentional, designed, tested changes which we believe are an improvement. We intend to do a better job of publicly documenting those decisions.

It is hard to overstate the reorganization efforts that have happened within NI over the last couple of years. Last NIWeek Eric Starkloff talked about how we were organizing the company around business units instead of around products, and that has had broad reaching impact, but we were making major shifts in the way we built products in the last couple of years anyway. Like many of the large software companies we have been shifting to a user-centric development model where we actively try to bring the user into the development process instead of thinking we know what they need and developing in secret. A good example of this shift is the introduction of the product owner role in NI R&D, a role focused on ensuring we are delivering the right value to our users. Both the product owners and product planners have long histories of working with LabVIEW, so you should not feel like the decision makers working on LabVIEW NXG are completely detached from LabVIEW - in many cases the decision makers for the two products are the same. There have definitely been teething pains with this shift, but we are getting better at it. I saw several comments about feeling left out of the decision process, and there are certainly some valid concerns, but I would also point to the level of engagement over the last few years where the product owners and product planners have attended and solicited input at the CLA summits, GDevCon and NIWeek. We also have quite a few targeted user engagements when we are working on defining features and workflows. We can absolutely do more, and we plan to, but many significant product decisions have been made as a result of those engagements. Remember that there are a lot of LabVIEW users out there, and we can't talk to all of them. A light-hearted analogy would be to seeing the results of a national poll and saying - 'well nobody asked me!'

That being said, I do want to increase my engagement with this community, and there is clearly a lot of passion about making LabVIEW NXG the best it can be. I would love to set up some 1x1 interviews with those of you who are interested so I can better understand how you are using LabVIEW today. I will start a different thread about that.

Back to the main point - it is important to understand what LabVIEW NXG is today versus what it will become. LabVIEW NXG today is not ready for most of the applications of this community. You are some of the most advanced LabVIEW users around, and are collectively using nearly every feature in the product. As Stephen said early in this thread - NXG has many nice things, it just isn't ready for him (or most of you) yet. We are trying hard to get there and have made substantial progress, but there are still functionality gaps. We expect that you will continue to use LabVIEW for at least a few more years until NXG is more complete for your workflows. I saw a comment about not wanting to develop an application of thousands of files in NXG, and I agree that I don't consider NXG ready for that either. Similarly - converting a large project from LabVIEW to LabVIEW NXG is not something I would recommend yet either. The Conversion Utility and associated tooling is more effective for converting instrument drivers and libraries. To be honest I was surprised that no one in this thread pointed out that there is currently no way to probe classes, and no way to make custom probes.

Yes we are already at version 5.0 and we still haven't built a full replacement for LabVIEW. That is a reflection of the incredible array of features in LabVIEW and the diversity of users and user cases that this community contains. However version 1.0 was not intended as a full replacement for LabVIEW and neither is version 5.0. For a subset of our user base who are building less complex applications NXG is ready for them and they are using it. For example a lot of work went into the workflow of helping a simple user take and process their first measurement, and we are building out from that foundation. When I talked about our reorganization and change in philosophy - that also translates into how we prioritize features and workflows. We are not just racing to recreate every last piece of LabVIEW in LabVIEW NXG. We are trying to understand the problems you were using those features to solve so we can determine if that same solution is the best choice for NXG.

I plan on also addressing some of the specific points of feedback in this thread, but this post turned out much longer than I had intended! Hopefully that provides a bit of framing around the current state of LabVIEW NXG.

Thanks,

Jeff

[crelf]

On 5/11/2020 at 8:34 AM, JeffP said:

I would love to set up some 1x1 interviews with those of you who are interested so I can better understand how you are using LabVIEW today. I will start a different thread about that.

I really really hope that everyone who has chimed in with significant feedback on this thread to reach out to get one in a 1x1 session with NI - lots of people have complained that NI doesn't solicit our feedback: this is an example of NI specifically requesting it, so let's not waste the opportunity.

[Neil Pate]

1 hour ago, crelf said:

I really really hope that everyone who has chimed in with significant feedback on this thread to reach out to get one in a 1x1 session with NI - lots of people have complained that NI doesn't solicit our feedback: this is an example of NI specifically requesting it, so let's not waste the opportunity.

A pack of hungry wolves could not hold me back. I am just waiting for the thread Jeff said he was going to make.

[thols]

I want to give feedback, but its just so much. I did give feedback on 2.0 on a long list of issues on the beta forum but it was frustrating then to not know if there was any reason at all to give feedback. I don't recall even receiving anything that the feedback was received or anyone saying that they read the forum posts. I used 4.0 on a new small/tiny project but gave up since some simple things were not there yet (or who knows, maybe wont be) and I quickly had a new long list of issues but did not have time to document them, and I didn't know if there was any meaning at all in doing that.

It would make it much easier for you and us if the development was more transparent so we could see per issue what is intended to work now, what will be implemented and how and the design decisions per feature. Now, this kind of information occasionally comes from different people in different channels (forums, blogs, summits, ...), which makes it easy to not know the state of NXG when you start exploring NXG x.x and thus get frustrated. If we could have access to this information we would know what to not get frustrated about and why and what you are open for feedback on, then we could help by focusing on giving feedback where it actually is helpful to you and then you wouldn't need to respond to all this frustration in different forums/channels. Yes, we all want NXG to be great, so let us help!

[Neil Pate]

12 minutes ago, thols said:

I want to give feedback, but its just so much. I did give feedback on 2.0 on a long list of issues on the beta forum but it was frustrating then to not know if there was any reason at all to give feedback. I don't recall even receiving anything that the feedback was received or anyone saying that they read the forum posts. I used 4.0 on a new small/tiny project but gave up since some simple things were not there yet (or who knows, maybe wont be) and I quickly had a new long list of issues but did not have time to document them, and I didn't know if there was any meaning at all in doing that.

I feel your pain. I did a long private session about two years ago with some people inside NI where I showed them my current workflow and how I did not think it was going to work in NXG. Nothing at all changed as a result of that feedback.

[X___]

There will be Ph D thesis written on the Boeing MAX debacle. I am starting to wonder whether there will be, regarding the NXG one, if no insider information ever leaks out.

In the meantime, some food for thoughts: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

[drjdpowell]

JeffP, in the interest of not letting this conversation die, can you present some positive features of NXG that improve over LabVIEW?

[drjdpowell]

Conversation dead.

[JeffP]

Hi everyone,

Apologies for the slow response - this thread kicked off a number of internal discussions within NI and I was waiting for some of those discussions to shake out before setting up these engagements.

First of all - I have set up a calendly link for scheduling time slots for 1x1 discussions. This is my first time trying calendly, so I have set up 30 minute time slots for three days later this week. Let me know if you have any suggestions or tweaks to make this more effective. Thank you in advance to those of you willing to take the time to talk to me, I appreciate it! In the link I specified two different types of discussions, please specify which kind of discussion you would like to have and I will send you a Microsoft Teams link. The first type is a user interview where we discuss how you use LabVIEW today. This is not focused on NXG, it is a way for me to better understand your workflows and pain points that you encounter today. This helps me better inform design decisions we make in NXG. The second type is a feedback discussion focused on NXG - this is more open format where I will do my best to answer your questions and discuss any feedback you have on NXG.

Second - I want to address some of the points in this thread about prior engagements with NI. For the last few years we have been very focused on closing the functionality gaps between LabVIEW and LabVIEW NXG - this means we have not done as much iteration on usability and existing functionality as we would have liked. Big gaps like dynamically loading a VI, sub panels, and hardware support were prioritized higher. As we are getting closer and the gaps are getting smaller, we are re-evaluating some of these longstanding complaints and looking to address them. For example Neil mentioned he had a lengthy discussion a few years ago and didn't see any product changes as a result. I discussed this with the product owner that conducted that discussion, and it (along with several other user interviews that expressed similar concerns) led to several significant design changes - including a major redesign of how we handle tearing tabs out of the editor. In that specific case the redesign represented a significant development effort and was deemed lower priority than closing some of the gaps we mentioned earlier, but as we get through some of those higher priority items I would expect us to look at it again. There were several other areas of feedback which did lead to product changes - such as more color on diagram constants and changes to how the palettes work. We know we need to do better at closing the loop so you can see the impact that these discussions have, and we are working on finding the right venue for having those discussions with the broadest possible audience.

 Regarding dr powells question about areas which I consider significant improvemented in NXG - there are a few which immediately come to mind

1. The workflow of detecting hardware and getting a first measurement has been significantly improved. We have heard consistent feedback from new users that the getting started experience in LabVIEW is difficult - so called 'blank VI syndrome'. We tried a few different ways of addressing this in LabVIEW, but in NXG automatic detection of hardware is improved and reflected directly in the project and measurement panels let users configure their measurement and basic signal processing before being translated to G code. That is not a workflow that impacts many of the more advanced users on this forum, but it makes LabVIEW more approachable to new users which is important to grow the user base. 

2. In my opinion the changes we have made to the project are a huge improvement. Requiring a project, using the project and components to manage the dependencies between files, and mirroring the project file structure on disk (which I realize not everyone is in favor of) has eliminated cross linking. Personally I find it speeds up my development for the editor to be picking the disk location of the files I am creating - especially when I am working with classes and creating a lot of files.

3. Components in general are a big improvement over the options in LabVIEW. They simplify dependency management and encourage modular code architecture. They solve many of the limitations of PPLs. Each component translates to an exe or gll when built, which simplifies build specifications. We have also enforced a strict rule of editor run behavior being the same as built application behavior, which should improve difficult to track down bugs where it works fine in the editor but breaks in a built application.

4. Moving to an xml file format will enable us to eventually have a significantly improved integration with git and other third party tools. We are not there today, but that is where we intend to get to.

5. This is less user-visible, but the underlying architecture of NXG is more flexible than LabVIEW and has been designed for extensions and plugins from the beginning. This is easiest with C#, but it means that community members who know C# are able to extend NXG in a myriad of ways that are not possible with LabVIEW.

As I said in my previous post - LabVIEW NXG is still a work in-progress. It is not ready for complex projects yet, but we are getting closer and moving quickly. Similar to what Stephen said - I believe the vector is good, and community engagement helps us refine our direction. 

Please grab a slot for a 1x1 discussion if you want to discuss this further or are willing to talk with me about your current workflows. 

Thanks!

[Neil Pate]

Thanks Jeff, I have sent the calendly link (but I could not find the bit where we pick the Option 1 or Option 2, sorry! I would like to chat about how I use LabVIEW today).

[drjdpowell]

So where is a good forum for discussing NXG?  Here on LAVA?  I'm not one who likes short 1 on 1 private talks nor am I in to "workflows".  But I could make lots of feedback on NXG if I have time to craft posts. 

Right now, for example, I'm trying to make sense of the NXG Project created by the conversion tool from my JSONtext library.  I'm completely stuck at not knowing what a "Link" is, and how I can get the JSONtext.gcomp to not be a Link.  As a "link", namespaces don't seem to work (I can create a namespace, but not add anything to it) and I suspect this is because a "link" is some kind of leser membership in my project.  Maybe.  Who knows.  I cannot find anything in the NXG help on what a "Link" is, or how to open up the JSONtext.gcomp as not a link.  

In general, I'm experiencing a lot of "blank stare" moments in trying to figure out this software.  Can it really be designed for new users and non-programmers?

 

 

 

 

 

[LogMAN]

1 hour ago, drjdpowell said:

I'm completely stuck at not knowing what a "Link" is, and how I can get the JSONtext.gcomp to not be a Link.  As a "link", namespaces don't seem to work (I can create a namespace, but not add anything to it) and I suspect this is because a "link" is some kind of leser membership in my project.  Maybe.  Who knows.  I cannot find anything in the NXG help on what a "Link" is, or how to open up the JSONtext.gcomp as not a link.  

I don't know if there is any documentation for this, but a link points to a resource external to your project. You can create your own links by adding files that are not located in your project folder.

It looks like your component is located on a shared network location?
Maybe the conversion tool uses UNC paths and the project expects mapped paths?

Maybe you can re-add those files to get it to work.

Edited June 2, 2020 by LogMAN
Not sure if that is a network location or just Mac

[LogMAN]

1 hour ago, drjdpowell said:

In general, I'm experiencing a lot of "blank stare" moments in trying to figure out this software.  Can it really be designed for new users and non-programmers?

Welcome to the jungle!

New users wouldn't have to convert legacy code, so this is probably not an issue.

[JeffP]

7 hours ago, drjdpowell said:

So where is a good forum for discussing NXG?  Here on LAVA?  I'm not one who likes short 1 on 1 private talks nor am I in to "workflows".  But I could make lots of feedback on NXG if I have time to craft posts. 

Let me get back to you on this - we are internally discussing some options for improving this - as you noted the activity on the existing beta forum is pretty limited. We want a forum that everyone has access to where we can have collaborative discussions on NXG. The specifics are still being hashed out but I will update when I have more information. 

Regarding your question about Links - LogMAN's explanation is correct - files under Links are non-addon dependencies located outside your project folder on disk, for example if you use a subVI that is saved elsewhere. This should be uncommon for projects developed from scratch in NXG - it is more common in converted projects - especially if you convert multiple projects with shared dependencies at the same time. It is an aspect of the conversion process that we are looking to improve - at this time I would not recommend converting multiple projects with shared dependencies at the same time - it works but may lead to confusing results. 

[drjdpowell]

14 hours ago, JeffP said:

Regarding your question about Links - LogMAN's explanation is correct - files under Links are non-addon dependencies located outside your project folder on disk, for example if you use a subVI that is saved elsewhere. This should be uncommon for projects developed from scratch in NXG - it is more common in converted projects - especially if you convert multiple projects with shared dependencies at the same time. It is an aspect of the conversion process that we are looking to improve - at this time I would not recommend converting multiple projects with shared dependencies at the same time - it works but may lead to confusing results. 

JSONtext was a single project, but for some reason the conversion tool created two projects: "JSONtext" and "LooseFiles_JSONtext for NXG", plus a "Shared" folder, which actually held the JSONtext.gcomp.

I fixd the issue by:

1. closing NXG
2. moving the floder with all the JSONtext files into the same "JSONtext" folder as teh JSONtext project
3. reopening the JSONtext project
4. "Excluding" (bad terminology?) the now-broken JSONtext.gcomp "link" (was annoyed there was no way to fix the link by pointing to the new location)
5. "Add file.." to add JSONtext.gcomp from new location (was pleasently surprised that this then fixed all dependencies without LabVIEW CGs endless dialogs)

 

[JeffP]

I may be incorrect in my assumptions here - but when you converted the single project how did you specify which files to convert in the conversion utility? The logic for creating multiple NXG projects works something like this:

1. If you just selected a lvproj file its easy, we load the project, all files in it, and their dependencies. Then we determine which files will be converted and put them all in the same NXG project.
2. Similarly, if you just select VIs, we load the VIs and their their dependencies, determine which files will be converted, and put them all in the same NXG project.
3. Things get more complicated if you select some combination of VIs and a lvproj, or multiple lvproj files (or a folder with some combination). 
   1. We load everything and find all dependencies. 
   2. We create a NXG project for each lvproj file. If there are additional files which are not part of any of the lvproj files we create an additional LooseFiles project for those files.
   3. If files are shared between multiple projects, we create a Shared folder next to the projects which contains the shared files. This is because we can't preserve your file disk heirarchy - NXG requires the project and disk hierarchy match, so the only alternative would be to choose one of the projects to be the 'owner' and that didn't seem correct. Unfortunately that leads to these shared files showing up under the 'Links' section of each project.

In an ideal case these shared dependencies would be converted into a component in their own project and built into a gll that is shared between the projects, or some similar process. Directly sharing source VIs on disk between projects is not the recommended way of sharing code in NXG.

In your case - I have seen this happen in the past where a folder containing a project is converted and some files are not detected to be part of that project so they are put in another project. Autopopulating folders can also make this worse in some cases. 

In general this is a part of the conversion utility that I would like to simplify because it can be really confusing, it is just not a top priority at the moment.

[drjdpowell]

I think you need to give the User a choice at step 2 of what to do with the loose files.  In my case they are just deprecated VIs that never got deleted (deleting files in Current Gen is very inconvenient).  Step 3 need a choice too, as adding the shared files to one of the projects will usually be the right choice.

[X___]

7 hours ago, JeffP said:

Directly sharing source VIs on disk between projects is not the recommended way of sharing code in NXG.

Am I reading this right?