Sunday, December 03, 2006

Save As

The Save As dialog in LabVIEW 8.x is hated by some and loved by others. Crystal Drumheller called it the "best feature of LabVIEW 8." But the initial reaction of most people is, "Why does Save As bring up a dialog? Other apps don't do that."

The reason is: other applications don't have linked documents.

When you do "Save As" on a file in Microsoft Word, you aren't affecting any other Word documents. They're all independent.

In LabVIEW, however, you may be changing every other VI, project, and library in memory. Any calling VIs, referring projects, and owning libraries could refer to the original VI or the new one.

And if LabVIEW does the wrong thing, you quickly end up with the cross-linking nightmares I mentioned in my earlier post.

Now, I'm a usability advocate here at NI, and I'm a proponent of simplifying choices to improve usability. But I can't accept doing a catastrophically wrong thing half the time to avoid making the user choose.

The Save As problem was the most difficult UI design project I've ever worked on. Here's some of its story.


Prior to LabVIEW 6, the options were "Save As" and "Save a Copy As." The problem with separate menu items is that you have very little opportunity to explain what they mean inline. How many people knew what "Save a Copy As" did at first glance? From what I've heard, not many.

In LabVIEW 6, these two menu items were combined and a checkbox was added to the bottom of the file dialog:

From feedback I've gotten, I believe that most people didn't even see the checkbox until they got burned by cross-linking. After losing several days of work, people would make sure they knew what that checkbox did and check or uncheck it as needed.

This is, obviously, not good. We don't really want the software equivalent of hazing the uninitiated.

Usage Analysis

People use Save As for two completely different tasks: making a copy of a file and renaming a file.

When you throw in linked files, you find there are really six primary use cases for Save As. Here's an excerpt from the Save As specification:

We have identified the following use cases when doing FileĀ»Save As on a VI:
  • Creating a copy of this VI, intending to edit the copy.
    • Variation A: Do not update referencing files and use the clone as a starting point for a new VI.
    • Variation B: Update referencing files to refer to the new copy [This is what 7.x did by default. Example: Changing the functionality of VIs in memory but wanting to leave other callers of the original subVI unchanged].
  • Create a backup of this VI, not intending to edit the backup but intending to continue editing this VI.
  • Change name/location of VI.
  • Copy to new location on disk. (Same name, different folder on disk). [Example: Original VI is on a network drive, saving a copy to my computer].
  • Copying a VI and its subVIs to a new location. [Example: Saving an example VI and its subVIs to a new location as a starting point for new development]
  • Determining the location of a file on disk. [It's a use case orthogonal to the actual purpose of Save As, but it was requested enough that I acknowledge it as a frequent use case of the menu item].


We saw three possible approaches:
  1. Remove functionality. Seriously. As long as you're doing the task that is still possible, it's easier to use. The drawback is that any other ones just become impossible.
  2. Expose all the technical permutations of the operation. Usability specialists tend to frown on this approach, but it can give you the smallest number of options. It just means you have to know what they all do.
  3. Map the choices to tasks that the user is trying to do.

We chose to try the third approach. Hence, a dialog:

You basically have two options in this dialog: do you want to copy the VI, or rename it? If you're making a copy, you have a secondary choice, specifically what VI(s) do you want open afterwards: the new one, the old one, or both?

We intentionally made the default the same as it was in LabVIEW 7.1, so if you never paid attention to the box before, you can click through this dialog and get the same results.

To help avoid cross-linking, we added elements to the dialog when there are callers in memory.
These yellow triangles warn you that you are modifying other files, and give you the ability (via the Referencing files in memory disclosure triangle) to see what those files are.

The dialog looks intimidating, because it has text to explain the choices. But we felt we needed to explain them inline, since they are choices that are not found in other applications.

Further, the dialog can look even bigger if the VI has subVIs, because of use case number 5.

But we believed the ability to copy subVIs while copying a VI to a new location is needed too often to leave it out.

So, in summary, I hope you will give the Save As dialog a chance. Numerous people have told me that, after they took a few minutes to understand the Save As choices, they found the operations they do through Save As to be much easier than in any previous version.



Anonymous MartinP said...

One use case was left out:
Doing "save as" as a quick way of getting to a file in the windows explorer, in order to do "right click" tasks. I use this method in 7.1 to interact with ClearCase, which is obviousely in the LV environment now, but my guess is that others might miss the easy access to the file in Windows.

1:53 AM, December 04, 2006  
Anonymous Matt Holt said...

I love the 8.x style save as... but I do have a complaint:
No save all with password. I used to be able to make sure that my VIs where protected when I saved, now I have to run a VI that checks a folder for un-protected VIs and set a password accordingly.
Why would I password protect VIs even though they are never distributed as code, you ask? Well I am typically controlling ALOT of voltage (i.e. 4160V on a Medium Voltage test system with hundreds of Amps) and I will NOT risk someone "reviewing" my code and getting someone hurt.

8:06 AM, December 04, 2006  
Blogger Christina said...


We actually did consider your use case, but I didn't rank it as a primary use case.

Also, you can still get to the file in Windows explorer, it just takes one more click (or maybe two, if you had previously used the dialog with the duplicate radio button). When you click Continue for Copy or Rename, you get to the regular file dialog and you can still Cancel from there.

10:33 AM, December 04, 2006  
Blogger Christina said...


I understand that the removal of Save with Options has caused some workflow problems. We (rather naively, as it turns out) thought that Source Distributions would handle all the needed functionality of Save with Options. We will probably revisit some of our design decisions in a future version.

In the meantime, have you considered writing your own Save tool? It seems like it would be possible to write a VI that saves all VIs in memory (or in a certain hierarchy) while applying a password.

10:41 AM, December 04, 2006  
Anonymous matt holt said...

Done, just an extra step... you know us CLDs, lazy lazy lazy... LOL.

8:08 AM, December 05, 2006  

Post a Comment

<< Home