NI Employee Interested in User Feedback...

[dtucker]

Hi! I recently started working at NI and I'm interested in what dialog/error messages LabVIEW throws that the users find confusing/ambiguous/useless.

A good example is a case where LabVIEW (not a user-built VI) opens a dialog box with "Press OK to [perform some action] or Cancel to [perform some other action]" with an OK/Cancel button. The point here is that OK and Cancel buttons themselves don't describe what is actually going to happen, and that makes them sort of useless. I would like to find examples of these in LabVIEW.

Feel free to reply back, preferably with a VI or project I can load and reproduce the ambiguous dialog or error.

Some more background: I just started working at NI and with LabVIEW just shy of a month ago. As such, I'm slowly learning more and more about LabVIEW, but I don't have the insight that many of you, the end users, have. Hence, here I am! I'm hoping I can learn a lot from the LabVIEW "veterans" here.

[Daklu]

I'm interested in what dialog/error messages LabVIEW throws that the users find confusing/ambiguous/useless.

How about just annoying? There are (IMO) too many "are you sure" messages. For example, drop a case structure on a block diagram and put a random function in each of the cases. Right click on it and select "Remove Case Structure." We're lovingly rewarded with this warning:

This happens with any multi-frame stacked structure (event, diagram disable, etc.) that has content in the other frames. I understand NI is looking out for inexperienced programmers, but we understand the behavior and consequences of removing a stacked structure. We don't need to be reminded every single time. I can safely say in the years I've been using Labview I have never, not one single time, changed my mind about removing a structure because of the dialog box.

[Black Pearl]

I second Daklu. After all, we have an undo operation.

Maybe we can just have a checkbox 'do not show this message again'. And make sure there is an ini file entry for this, so we can keep this setting across machines by simply copying the ini file.

Felix

[Daklu]

And make sure there is an ini file entry for this...

Better yet, categorize this dialog box and other newbie-friendly warnings as "tips" and give us the option to disable all of them at once.

[SteveChandler]

Darren posted an idea to remove the dialog on the exchange. I initially liked it but then I thought that it is removing a feature. There is no other way to tell if all other cases are empty. This probably dates back to when there was no undo in LabVIEW so it probably should have a checkbox like "Do not ask me again"

[Michael Aivaliotis]

Anything that can be undone should not have a dialog, period. Get rid of it altogether. No checkboxes or ini settings.

[ShaunR]

This is a real pain and gives no indication whatsoever where to look.

You get it after building an application exe that works fine in the IDE and usually find that a diagram disable structure somewhere isn't doing what it says on the tin.

[mje]

Anything that can be undone should not have a dialog, period. Get rid of it altogether. No checkboxes or ini settings.

This. I absolutely agree.

Also any dialog boxes that must be shown should never be yes/no/ok/cancel/etc. Make a proper UI with large buttons that clearly explain what action will happen if you click on the button. Windows 7 did a lot of this, and though they went a little overboard in my opinion it was definitely a step in the right direction.

[Tim_S]

This is a real pain and gives no indication whatsoever where to look.

A very big second on that one. Debugging why executables don't work like source code is a big headache to me.

Tim

[dtucker]

Expanding upon the idea of a .ini token... depending on how many dialogs this could affect (say, 5 or less), each could have its own .ini token. If more dialogs are affected, they could all share one token and it could be an unsigned integer where the integer holds information on whether a certain dialog should be displayed or not. For example, say the token value is 56. That's 111000 in binary. That could represent windows 1, 2, and 3 should not be displayed (the lower 3 bits) and windows 4, 5, and 6 should be displayed. There could also be an entry into the Tools->Settings dialog where users can select which dialogs are displayed (along with a "Show All" and "Show None" button that selects/deselects all).

While this is a great idea, it isn't within the scope of the topic. I was originally looking for dialogs that need to be reworded.

The .ini token idea though is a great idea! I think it should be submitted to the idea exchange and see how other users feel about it.

[asbo]

When you have dependency conflicts in a project, the "Project Dependency Conflicts Detected" dialog pops up and has Close and Help buttons. The Close button should really be an OK button, the first time I encountered it, I thought that LV was either going to close the project or not load my VI.

[John Lokanis]

This is a real pain and gives no indication whatsoever where to look.

You get it after building an application exe that works fine in the IDE and usually find that a diagram disable structure somewhere isn't doing what it says on the tin.

You also get this if you use some .NET assemblies that are missing on the target machine. Took a LONG time to figure that one out!

[Cat]

The message that only tells me to get on ni.com to get information about some error. This isn't helpful for those of us who don't run connected to the Internet.

[blawson]

Expanding upon the idea of a .ini token... depending on how many dialogs this could affect (say, 5 or less), each could have its own .ini token. If more dialogs are affected, they could all share one token and it could be an unsigned integer where the integer holds information on whether a certain dialog should be displayed or not. For example, say the token value is 56. That's 111000 in binary. That could represent windows 1, 2, and 3 should not be displayed (the lower 3 bits) and windows 4, 5, and 6 should be displayed. There could also be an entry into the Tools->Settings dialog where users can select which dialogs are displayed (along with a "Show All" and "Show None" button that selects/deselects all).

While this is a great idea, it isn't within the scope of the topic. I was originally looking for dialogs that need to be reworded.

The .ini token idea though is a great idea! I think it should be submitted to the idea exchange and see how other users feel about it.

No, that is a terrible idea! The .ini file should be human-readable and generally user-editable. Making the selection into a bitfield makes it hard to read and with no reference to which dialogs it controls makes it impossible to translate. We also do not need more clutter in the tools->options UI.

Anything that can be undone should not have a dialog, period. Get rid of it altogether. No checkboxes or ini settings.

Absolutely. Start with this, it ought to eliminate most of the truly repetitive ones.

[asbo]

Just noticed another in the CLN dialog:

[Grampa_of_Oliva_n_Eden]

When closing a project we get a "something has changed" that the detils seldom help reveal. I have given up trying to find the answers on occation. It should show us what has changed and the nauture of those changes.

Ben

[blawson]

Just got this yesterday testing an installer. I installed new versions (over old) of LV and DAQmx runtimes, then installed my app and ran it without restarting.

That says "VI has an error of type 302208. The full development version of LabVIEW is required to fix the errors" at least 100 times. The dialog is ~1350x800px on a 1680x1050 screen. Oh and when you click OK, it leaves the main VI FP open, broken, and not running.

When I restarted it worked fine.

cracked me up