LabVIEW Developers Feature Brainstorming

[JLoftus]

Hello,

I have been brainstorming ways in which we could improve the load warnings system in LabVIEW.  By "load warnings", I mean the information LabVIEW displays after it has loaded up a (hierarchy of) VIs/LVClasses/etc that explains differences between what is in memory and the source files on disk.

Oftentimes, these differences are automatic changes LabVIEW makes for you, either as a result of searching for subVIs or to update deprecated code features from VIs saved in older versions.  We report them as warnings because only you as the programmer can really determine if they are important or not.

Also note that there is an analogous set of warnings generated when you perform a Save For Previous... operation -- as with loading, LabVIEW sometimes makes automatic changes to ensure compatibility with the older target LabVIEW version.

For reference, the load warnings dialog looks like this in LabVIEW 8.5:

I would like to gather feedback on a few particular aspects of how you currently use this load warnings system:
(1) Do you typically read this warning dialog in detail?  Do you scan over it looking for particular types of warnings?

(2) Do you use the "Save to File..." button to export the warnings to a text file for later examination?  If so, do you use any automated tools to parse/filter these text files?

(3) Does this dialog ever appear at times when you really would rather it be suppressed?  Is it ever essential to suppress this dialog?

Thanks,

-=James

[tst]

I think that in both types of use cases it is important to know that things changed, but when loading in a newer version, some changes are not as critical as others. I don't usually save the changes, unless I relink a lot of VIs and want to over them and make sure.

How about these improvements:

1. The window will not be modal. It will stay open and allow double clicking the list to be brought to the specific location of the change.
2. The Window will have a tree or listbox instead of the string which would make telling the difference between the different messages easier. An alternate solution is using string formatting (bold font, color), but that's less preferable.
3. The window will have an option for sorting\grouping either by VI or by type of change (e.g. all the places where a certain change was made would be grouped together).
4. Potentially dangerous changes (e.g. cross linking) will have an attention getting text (font, color) explaining the danger.

[Albert.Geven]

Hi
thanks for asking

The layout of the load file difference certainly has to be improved. It is difficult to see the path difference.
Maybe the essential difference can be bold, and the layout such that eases comparing (starting at the same position)

And the difference could be mentioned: v7.0-->v8.5
or wire changes or even a complete difference could be given (by highlighting all changes if possible at all)

For projects or libs a check could be done to give the changes for the complete lib or just a part.

[Albert.Geven]

Hi

I was importing (creating) a project from a set of vi's written in lv8.2
One bad situation is when you have moved a folder with libraries to a new spot and have to acknowledge each of these vi's to be loaded from a new place.
At least a Boolean should be present to "do this for all of the slected items"

[Kevin_Price]

---

(1) Do you typically read this warning dialog in detail?  Do you scan over it looking for particular types of warnings?

(2) Do you use the "Save to File..." button to export the warnings to a text file for later examination?  If so, do you use any automated tools to parse/filter these text files?

(3) Does this dialog ever appear at times when you really would rather it be suppressed?  Is it ever essential to suppress this dialog?

---

1. Depends what I'm working on.  Sometimes I read it in detail, sometimes I skim it over.  However, the *format* of the information is *very* tedious to read.  It'd be great to be put into a view similar to the Windows Explorer "details" view.  Different aspects of the information are in different columns and you can click on a column heading to sort by that particular column.

2. If the list of warnings is long, I definitely use the "Save to File..." button for later line-by-line scrutiny.   I don't use any automated tools to parse or filter that file.

3. No, I can't think of a time that it ought to be suppressed entirely.

-Kevin P.

[JLoftus]

Thanks for the feedback, everyone -- keep it coming!

I certainly agree that the information presented in it's current format can be very dense and difficult to read.  That's one of the main things I'd like to see improved.  Currently, I suspect that many people skip over it more often than they should just because the density of the information can be overwhelming.  On the flipside, there are of course many times when you really don't need all of that information up front, which leads to a follow-up question:

(4) What do you think about the idea of a load warnings summary that would show up in place of the current dialog, with the option of opening a detailed view?  For example, such a summary could just show an overall count of all warnings (and/or files affected by warnings) along with short one-line descriptions of the most common warnings.

Albert also reminds me of a class of messages that do *not* show up in the current Load Warnings dialog. All simple version change messages, of the form "The VI, last saved with LabVIEW 7.1.1, has been converted to version 8.5." are actually only showed in the Explain Changes dialog that you can optionally open when deciding whether to save your VIs.  These are "simple" version changes in the sense that LabVIEW did not actually change your code in any significant way -- it merely re-compiled and updated the save format.  As such, these messages have not been seen as severe enough to warrant an entry in the Load Warnings list.  So here's one more follow-up question:

(5) Would seeing simple version change messages immediately on load be useful enough for you to justify the extra volume of load warnings? (Presuming all warnings were displayed in a more readable format, of course.)

[Albert.Geven]

Hi

keep improving, the dialogs in 8.5 are already much better.

The upgrade version msg can be of interest but only to group all those vi's and mostly is just what I expect.
Also grouping vi's with the same old and same new path gives way to what you mostly expect from a move of a part of the source.

These groupings make it fast to accept or cancel such loads

[JLoftus]

Albert:

I'm a little confused by what you said about grouping VIs.  Are you talking about grouping VIs listed in the Load Warnings dialog by the type of warning that applies to them?  I've explored this concept a bit, and it looks promising.

Your last sentence confuses me, though, particularly if my understanding of the rest of your post is correct:  you say "These groupings make it fast to accept or cancel such loads." -- what do you mean by cancel?  In a sense, the Load Warnings actually show up after it's too late to "cancel" -- the VI hierarchy is already loaded and linked up, so the best you can do is close the top-level VI you just loaded and refuse to save changes you don't want.  Or are you talking about the other conflict dialogs and management tools available in 8.5 helping you to decide whether to cancel before the load has completed?

[Albert.Geven]

Hi

sorry for the confusion
I indeed mean to not save the loaded program or library.
the grouping concept comes to  mind immediately when loading software in 8.5
these management tools also need this grouping.

[JLoftus]

Hello again -- I've got one more thing I'd like y'all's opinion on.

One of the ideas we've been kicking around a bit is the concept of replacing the current modal Load Warnings dialog with a simpler summary dialog.  This summary view would report the essential information of how many warnings ocurred during the current operation, and perhaps the types and counts of the top 3 or so warnings that ocurred.  The idea is that you should be able to make a preliminary decision about the magnitude of potential problems without getting bogged down in the details.

The summary dialog would also provide you with an option to view all the details immediately or "ignore" the details and keep working.  Regardless of your choice, you would have the option to recover those details later via a modeless dialog accessible in the menu bar.  This modeless detailed view is where we would incorporate all your other feedback on displaying the details in a more accessible format.

I've got a mocked-up screenshot of this concept below.  The sheer count of warnings shown isn't necessarily common, but this one is intended to show this summary dialog at it's most complex.

Does this look like an improvement over the current system?  Any specific feedback on this mockup?