Happy Holidays!

Wishing you all a happy and safe holiday season.
- Christina

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.

History

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].

Design

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.