Dialog Confusion on File Rename

[The_Seeker]

Has anyone else seen this one?

While trying to rename a LabVIEW VI, I have just been presented a dialog that says this:

"If you do not undo the renames then the files in memory and the callers will not be updated to the new name."

(Refer to the attached .PNG for the entire dialog.)

Removing two of the 'not's from this statement, it seems that this is logically equivalent to:

"If you DO UNDO the renames then the files in memory and the callers WILL be updated to the new name."

Presumably, if you select UNDO, then you are expecting that the name WILL NOT be updated (which seems to be the point of an UNDO operation). This is the opposite of what the dialog seems to be saying. At this point, I'm not sure whether to click "Undo File Renames", or "Accept As New File".

The reason I selected the Rename option from the "Save As" Dialog was to replace the files with a renamed file. So I decided to go with "Accept As New File" option. In response, I am presented with a second dialog, giving me another opportunity to revert to the original filename. This second Dialog says:

"The file [FULL FILEPATH HERE] has been changed on disk by an external action. Would you like to revert the VI to reflect this change?"

Once again, this is rather confusing. If we REVERT the VI, what change are we reflecting? Presumably, there will be no 'change' to 'reflect' if we put everthing back to the way it was in the first place -- which is my understanding of the meaning of the word 'revert'. Also confusing here is that the choices in this dialog are "Revert" and "Cancel". It would seem to me that, when I invoke a function to 'rename' a file, woudn't 'revert' and 'cancel' be essentially be same thing?

I have typed in a new name of the file. I have chosen what appeared to be the most logical choice in the first dialog (as seen in the attached .png) -- even though this 'correct choice' runs completely contrary to the text presented in the Dialog box. Now, if I want to continue with the Rename operation, which option should I select, "Revert" or "Cancel"..?

The correct answer is... "Cancel" 

Hmmnnn... I would prefer to see something like "Proceed" or "Accept New Name"  -- or, better yet, no second dalog at all! Presumably, if the first dialog was clearer, there would be no need for a second "Are you sure...?" dialog.

Just thought I would put that out there and see if anyone else has had this experience.

D.

[Zachmx]

The options in your screenshot do seem a little confusing, but I'm having trouble recreating the dialog boxes you are seeing. Can you give me the steps you took to get those messages? Also, what version of LabVIEW are you using?

I tried saving as and renaming files in and out of projects/subVIs, and I can't seem to get the same screen you do.

[The_Seeker]

Hi Zach,

This is the first time I have encountered this dialog, so I'm not entirely sure what combination of parameters produced it. 

If I recall correctly, I had created a new VI outside of the Project, but this new VI made a call to a subVI in an open Project. (Occassionaly, I will work on a "proof-of-concept" VI outside ofthe project, and introduce it into the Project after the method has been verified. I may have been doing this at the time of these dialogs.) Otherwise, I don't think I was doing anything unusual.

This dialog was observed in LV 2011 (11.0 32-bit) running under WinXP.

D.

[Zachmx]

Still having trouble reproducing the dialog box, even with a project/VI setup similar to what you described. Can you recreate this message and possibly post your code for doing so?

[The_Seeker]

Hi Zach,

Thanks for the follow-up. I'll try to re-create the conditions, but I'm not exactly sure what I was doing that was different from usual.

I'm curious, is there no way for the LV development team to search through the source code to locate this message? Clearly, the logic in the statement is flawed (regardless of how you arrive at the dialog in question). Also, if an NI developer could locate this message, it should become clear what combination of conditions led to that particular destination.

Anyway, I will take a few minutes to try to re-create the dialog, If I can reproduce it, I'll report the steps here.

Thanks.

D.

[Zachmx]

I did some more analysis of the messages in the dialog boxes, and I think we might be able to make sense of them with some effort.

The first message reads "If you do not undo the renames then the files in memory and the callers will not be updated to the new name."

I'm guessing you changed the name of a VI in Windows while there were still open references or callers to that VI. The message here is letting you know that the callers/references will not be updated to the new name.

(1)
- Choosing "Undo File Renames" will change the VI back to its original name and solve any problems the callers/references would have.

- Choosing "Accept as New File" will allow the file to keep its new name and force the references/callers to change what they are looking for.

(2)
Reverting the VI in this case refers to changing the references/callers in your project or program to use the newly renamed VI in place of the old one.

The "Cancel" option here will not set the references/callers to the new instance of the renamed VI. This will leave everything referenced to the old name but keep the change in filename for the specific VI that you changed.

I hope this makes some sense; let me know if I didn't get that quite right.

[The_Seeker]

Hi Zach,

I don't recall making any filename changes in Windows. This is something I try to avoid at all costs. (I started way back in LV 3.0, and in the early days, a change like that was a bad idea indeed!) This dialog was produced as a direct result of choosing the "Rename" option in the "Save as" dialog. Could there be another explanation?

In any event, regardless of how it is produced, I still contend that the wording of this dialog seems to have too many "nots" to be truly clear.

Rather than this:

"If you do not undo the renames then the files in memory and the callers will not be updated to the new name." 

Why not this?

""If you do not undo the renames then the files in memory and the callers will not be updated to the new name."

This appears to be consistent with your own explanation:

"- Choosing "Undo File Renames" will change the VI back to its original name and solve any problems the callers/references would have."

And wouldn't this be much easier to follow? The fragment "do not undo" followed by another negated term seems far more confusing than it needs to be.

There are several sites with useful UI design pointers, such as this one:

http://www.voyce.com/index.php/2009/09/14/the-7-signs-your-ui-was-created-by-a-programmer/

Nothing about triple negatives (like we are seeing here), but the comments about double negatives certainly can be extended to this case.

Anyway, just thought I would pass this along in the event that someone at NI wanted to improve the usability of this task sequence.

[Zachmx]

The statement you are referring to with the double (triple) negatives is more of a warning about bad behavior that could be caused. Taking out the negatives does not hold true in this case.

The sentence you mention is confusing because it is not a cause and effect statement. It is advising you to undo the renames because the callers/references will not be updated regardless of your future actions.

It may be more clear to think of the warning like this:

"Even if you keep the renames, the files in memory and callers will not be updated to the new name."

-This version eliminates the double negative you mentioned and should preserve the originally intended meaning

[The_Seeker]

Hi Zach,

Your proposed wording seems clearer than the original. Perhaps the dialog can be changed to your wording. My intent was not to advocate any particular alternative, it was more about calling out a very confusing dialog.

In the end, I was able to get the outcome I needed, so I guess at some level, it must have been adequate -- on the other hand, with only two buttons, it was 50/50 odds from the beginning. Maybe I just got lucky.

Perhaps what we are really seeing is that relationships between VIs, the Project, and the underlying OS file structure are not as simple as they initially appear. It is not trivial to formulate a concise dialog message to explain the conflicts that can arise between these relationships. I suppose the convoluted messages I encountered are both natural, and to be expected, when largely 'left-brain' programmers take on the work of prodominently 'right-brain' linguists and writers. (Different type of brain activity, so I guess we shouldn't be surprised at the outcome.)

In any event, I understand your points, but I wasn't really asking in order to solve as particular immediate problem -- as I say, I was able to achieve the desired outcome. The intent of my message was to point out the confusion, and ask if this is really the best way to present this particular issue to users. (More of a "bug report" than a request for help.)

Anyway, thanks for your efforts.

-- D.

[Zachmx]

I understand your confusion on this issue, and I wanted to make sure the program behavior was clear to you. I'm not sure if this is technically a bug or if it could be easily changed. I can see what I can do about the dialog if you can give me details on how you were able to produce it. Unfortunately, I haven't been able to produce the dialog, and there seems to be no easy way of finding it otherwise.

In any case, thanks for pointing out the confusion on this issue; hopefully we have come up with a good enough explanation for anyone who searches the forums with this question in the future.