Provide options to disable new features that change basic development flow

[Marc_A]

New features that help us code more efficiently are great, but recently some have been added that change how things work and can be more of a detriment for people not used to them. I'm simply asking for an option to be added when a feature like this is in a new version of LabVIEW. Here are two examples of what I mean, from each version's documentation:

2017:

• Maintaining Wire Connections When Moving Objects - LabVIEW 2017 automatically maintains wire connectivity when you move objects in and out of structures on the block diagram.

2019: 

• Create Constant, Create Control, and Create Indicator - Creates a constant, control, or indicator from a terminal. These shortcut menu items have long been available and are now duplicated at the top of the shortcut menu.

Both of these are disruptive if you're used to doing things a certain way. Maintaining wire connections is nice, but only when I want it to happen (which is how it works when you disable it, it's much better.) I spent more time undoing and removing objects through structures than I ever saved from the automatic wiring. The one in 2019 just doesn't make sense to me. Those functions are already in the shortcut menu. Moving them to the top just moves other functions, like "Use default if unwired", that I constantly use.

I've disabled both of these using keys added to the configuration file, so it's possible that an option can do the same. I just wish it was included so I didn't have to go hunting for the configuration key every time something like this is added.

[Bob3571]

I absolutely agree!

[Intaris]

The ability to switch on and off certain IDE features... Hmm.

I used to hate the too auto-switch feature. Now I have it on all the time.

I used to hate quick drop. Now I use it (some of the time).

I'm pretty sure adjusting to the new IDE is part of staying "up to date" and "hip" in the LV world.

>insert dad moves here<

[Marc_A]

Intaris, those are both examples of new features implemented the right way. The auto tool is optional, and quick drop is something you have to invoke with ctrl+space, you never have to use it if you don't want to. I'm talking about things that change what people are used to with no option to disable them.

[MichaelBalzer]

See also:

Opt out permanently from "maintain wires connected"

Provide an option to disable auto-insert of shift registers

I also use ini keys to disable these and other recent features that don't have explicit options to change. I'm not hopeful a configuration option will be added for any of them. My only hope is that the keys aren't removed in some future version.

[UMASO]

I absolutely agree!  

There must be many people being annoyed with this.  I feel like this sudden change of shortcut order is kinda ignorance of user's voice.  

[AristosQueue (NI)]

> I feel like this sudden change of shortcut order is kinda ignorance of user's voice. 

Both of those changes were made with LOTS of attention to the users' voices -- and, yes, I deliberately changed plurality there. We made a conscious choice that we knew would inconvenience some customers, and some would be very unhappy with the change. I'll try to explain why, though I do not really that expect my explanation will make you feel any better.

Whenever we make a change like this, we evaluate the relative cost of harm to existing customers versus the ongoing maintenance cost of two different code paths in the product, and we balance that on our understanding of our customers. In some cases, we may feel that even those who don't like the change may actually end up working faster in the long run, so it's worth pushing the change on them. We get this information by watching customers work in various situations (customer visits, people coming into our usability lab) or by customer feedback (on forums, etc).

It is an extremely hard challenge, but if we don't sometimes say, "The UI is changing unconditionally" then we end up with a code base that has option switches running all the way back to LV 1.0, with an almost-guaranteed net increase in bugs overall because of the multiplicative increase in code paths. In this case, we did create the undocumented option tokens. By choosing to make them undocumented, we can provide customers an out if the pain is so egregious that they complain, but we also are ok blowing those away in the future if the old path gets in the way of any future development, even slightly.

Personally, I wanted the "Create" moved to the top EXCEPT on wires where I use "Clean Up Wire" all the time. I was one of the user voices evaluated -- and overridden. There were lots of others, accumulated over several years. A year later, I've adjusted to the new menus and find that, yeah, I still sometimes wish clean-up were moved up, but the consistency of Create is worth it. Your experience may be different.

Sometimes we make the wrong call. We have gone back and reworked features to make them more tolerable, we have added options for features, and we've even backed out features (much rarer).

No one on my team is ever happy causing any pain and frustration to our customers. Doing that is counterproductive to selling our software (financial motive) and our general enthusiasm as engineers (part of our "payment" is the joy of seeing our product used by others). We do it only with slow consideration, with a lot of arguing, and, whenever possible, with user data. But we do sometimes do it. And we will do it again in the future. For that reason, NI is going to decline this idea.

[Darren]

Declined for reasons listed in AristosQueue's post above

[UMASO]

AristosQueue,

Thanks for the explanation.  

It is great to know that these changes were made with lots of attention to the users' voice. Me and other users around me felt that these changes were suddenly made, because we did not know that there has been such an approach based on many user feedback.  Without knowing such process, we thought these changes were made based only on a few LabVIEW R&D people, who would like to push their new ideas.  

It would have had a better impression to us, if the reason for these changes had been reasonably explained.  Without explanations, users felt being behind and try to recover what we had just before.  

Anyways, thank you so much for keep trying and making LabVIEW better environment.  

[AristosQueue (NI)]

UMASO: If you have suggestions on communicating this, please let us know. We did discuss the reasoning in NIWeek presentations. It was also in conversations on the forums leading up to the change. Neither of those is really a broadcast out to the user base, but I don't really have a better option. Putting such comments in the Upgrade Notes doesn't make a lot of sense, in my opinion -- we wouldn't want to bog down the Notes because people scan that list to get a sense of what changed, and putting it elsewhere in the documentation will just mean it gets lost. With some major features, like LVOOP, we have done white papers to explain our reasoning, but I don't think that would be read, or even found, for smaller features (my opinion).

Plus there's just a general override on all our changes that we try to only change things that need changing. We could write on every changed bullet point, "In accordance with our observance of users, in order to upgrade the experience of most users even at the expense of downgrading for a few, we are making the following change:"  But it would be replicated on every changed bullet point.

We make mistakes, and posts like this one are important to the feedback loop. At the moment, I think this kind of after-the-fact communication for those who ask is the best we've got.

Suggestions welcome.

[UMASO]

Thank you for the additional follow-up. 

If we consider something to do after the change has been made, I agree with your comments, and there is not so many things to do.  

However, there may have been other way for you and your LabVIEW users to decide this change.  

In my opinion, the change of order in run-time shortcut is not a "small" change.  Run-time shortcut is something clicked many many times, once people get used to it, especially for wire clean-up, replace with shift-register, replace case selector, etc.  The more getting used, the faster the mouse operation becomes, and it gets naturally done like breathing.  Sudden addition of three "create" shortcut menu breaks the natural users habit, and this is not something small.  

I wish there had been some kind of public vote for this change before final decision was made.  "NI R&D plans to add three short-cut on top from LabVIEW 2019.  It must accelerate the development on LabVIEW, because ~~~~ ".  Then, users (LabVIEW stakeholders) have change to put thumb up/down, and it leads to the final decision.  

As a system developer on NI platform, I really think much of my users' usability on the software.  Therefore, if I make any changes, I try to listen to as many stakeholders as possible.  

Thank you so much again for your time and efforts to have an ear for me, just one user abroad.  

Regards,