Progress bar when loading dependencies

[gt3000]

When you launch a LabVIEW Project or Top Level VI with many Sub VIs, it can take some time while LabVIEW searches and loads all dependencies.  This is especially true when working with large RF applications.  Better CPUs and SSDs make the loading faster, but the loading time is still fairly long for most PCs.

I propose that the 'Loading Dialog', which normally shows 'Ignore Item', 'Ignore All', 'Browse' and 'Cancel' is augmented to have a Progress Bar.  Seasoned LabVIEW users are familiar with the process of loading files, however, new users will find the progress bar less daunting than a dialog box with lots of text flashing on their screen with complex words like 'Loading', 'Searching' or 'Mass Compiling'.

I would like to take a cue from the Windows 8 Copy/Paste dialog box, where a standard progress bar is shown, unless you request to see more information.

Proposed New User Experience:

To get back to Classic User Experience: click 'more...', or if a dependency cannot be found:

Kudos if you like the idea.

George T.

[gt3000]

@AristosQueue: I'll agree that it could be a difficult feature to implement.  You certainly have the experience to prove it in your post. However, by declining an entry on that basis, how will the user community be able to Kudos and show that they are interested in a feature, if it's something that is really desired?

Regarding the intent on the progress bar, I stated:

Seasoned LabVIEW users are familiar with the process of loading files, however, new users will find the progress bar less daunting than a dialog box with lots of text flashing on their screen with complex words like 'Loading', 'Searching' or 'Mass Compiling'.

In your reply, it was interpreted as:

The whole goal of a progress bar is to let you know how long you have to go get coffee, and it didn't work for any of these.

Again, I completely agree that an accurate progress bar would be great, but my idea approaches it from a different angle.

In terms of getting this implemented, instead of using number of files as the progress bar content, did the new hire consider size on disk vs. RAM loaded?  It is a lot closer to the Copy/Paste paradigm in terms of knowing 'how much work has to be done'.

Thanks for the feedback.  This is my last argument for the feature, unless you have specific questions.

[Dragis]

So one caveat here that I don't see mentioned but is used elsewhere is to only show the more elaborate progress bar if the load is going to take more than a few seconds. In other words, LabVIEW can start loading in "fast" mode that is optimized for the smallest amount of disk/memory thrashing but later move into a "monitored" version once it will take long enough that adding a little overhead to the load would not matter. I believe most users would prefer to know that a load will take 5 minutes rather than get it 4 minutes without knowing since at that point the slightly longer load is in the noise of developent.

[AristosQueue (NI)]

I was out on vacation. I want to reply to one comment from gt3000 and one from Dragis.

Dragis wrote:

> In other words, LabVIEW can start loading in "fast" mode that is optimized for

> the smallest amount of disk/memory thrashing but later move into a "monitored"

> version once it will take long enough that adding a little overhead to the load

> would not matter.

LV already does this -- if the load goes fast, we don't display the dialog at all. The dialog only comes up when the load takes longer than a given threshold.

gt3000 wrote:

> how will the user community be able to Kudos and show that they are interested in a

> feature, if it's something that is really desired?

In this particular case, it doesn't matter how many kudos the idea got. It had already been demonstrated to be technically infeasible by R&D. Not just "too expensive to do" but "logically impossible to ever implement." Your picture showed a progress bar that was moving from left to right over a process. We cannot ever implement that without a magic oracle that already knows ahead of time -- and the only way to know ahead of time is to have already done the load.

You've since posted a separate idea that proposes a different UI entirely without the progress bar. That idea is technically possible to implement it, so it won't be declined so quickly like this one was.