Don't bury the lede: What's the real story behind a UI interaction?

A user interface designer, like a journalist, should avoid burying the lede: engaging the user with an opening question or statement that omits the most critical point of interest. The lede is the all-important opening sentence of a news story, and journalists labor over them. User interface interactions have ledes too, and they should be crafted with as much care.

The Move File dialog in Windows Vista offers a convenient example. (Although a dialog is used here, this principle applies equally well to web pages or other UI modalities.) The Move File dialog appears when a user attempts to move a file into a folder that already contains a file of the same name:

Can you see the disaster in progress? Most users can't either.

This dialog has buried the lede. It focuses the user's attention on the fact that there is another file with the same name in the destination folder. It fails to point out a much, much more interesting condition: The user is about to overwrite a newer file with an older file.

To its credit, this Move File dialog does improve upon the older File Replace dialog in previous versions of Windows: it offers more details that can help the user make a decision, and offers a new option to keep both files. (The latter is particularly helpful when dealing with files like auto-named digital photos, because a user can easily take different photos that end up with the same name.)

Overwriting a file is not, by itself, an uncommon or bad thing. It is a daily occurrence for users to overwrite an older file with a newer version of that same file. The user may be posting an updated copy of a document to a backup location, or to a server for use by others, or to removable media for transportation elsewhere, etc. This is business as usual.

Going the other way—overwriting a newer file with an older files—is a much rarer event. The user might be giving up on work they've done and throwing it away. Alternatively, they could be restoring a backup file to replace one that has become corrupted. Either event is unusual, a point which should be emphasized in the dialog.

The above dialog's text fails at this, as does its layout and typography. There are numerous pieces of text competing for attention, but among the most prominent are the bolded file names. That's a bit odd, since the entire premise of the dialog is that these two file names will be the same. The dialog has carefully drawn the user's attention to information which is guaranteed to be redundant. (If the user is moving multiple files, only some of which have conflicts, the file names are relevant—but that case can and should be handled specially.)

As just a very first cut at revising the above dialog to restore the lede, some text could change. The typography could be tweaked to focus on the salient time stamps. A different sound is probably also in order, to distinguish the invocation of this dialog variant from the more normal one above, and emphasize that something unusual is going on.

(It should be pointed out that the designers of Vista's Win32-based UI can't actually set a run of text in bold, as shown in the dialog's introductory statement, because Win32 is font impoverished.)

This revision would clearly needs a ton more work, but is a start in the right direction. At least the dialog now opens with the lede.

Comments

[Sam]

Funny, it seems both Microsoft and you missed an error in this dialog:

In the option 'Dont't Move' it says 'leave this file in the *destination* folder'.
But it is the source file, so we will leave it in the *source* folder, obviously.

[Graham Glass]

Wouldn't it also be clearer to say "what you would like to do?" at the top instead of "click the file you want to keep?"

Cheers,
Graham

[Alex]

Just for comparison, I reckon the XP dialog was even clearer - effectively "Replace this file (details) with this one (details)?" And then there's Mac OS X - "A newer (or An older) file with this name already exists in this location. Do you want to replace it with the one you're moving?" Simple and clean.

[nstlgc]

Sam, I think they mean "leave the file in the destination folder" as in "don't overwrite it". The file listed is the one in the destination folder (the one that's about to be overwritten), not the one in the source folder.

[Tom Clancy]

"Overwrite the newer file" sounds like the opposite of what you mean, unless I misunderstood. Either way, it could be clearer.

[Geof Harries]

I would consider the original term "replace" to be much simpler and easier to understand than "overwrite". Also, in both instances, "destination folder" seems awfully geeky. Why not again use more plain language, such as Apple's "location"?

[David]

Can I point out the biggest usability issue with this dialog? Without moving your mouse over the text I couldn't work out how to action this window. There is a Cancel button and nothing else. I read the text a few times before I realised that the whole text block was a clickable area. It still throws me off when I get this window sometimes as I get a huge amount of text to read and my natural reaction to the window like every other window is to look at the bottom for the possible buttons to action the window. It is just a few more seconds where I am forced to stop and read the text and then remember to click the text. Some simple buttons would of been better at the bottom of this window with most of the text still being made available.

[Stephen Mok]

David, I guess you missed the "Click the file you want to keep" instruction.

[Ram Yoga]

Actually, I agree with David. Normally you wouldn't take the time to read the entire text. And the "Click the file you want to keep" is pretty discrete. The "cancel" button has a higher click affordance, so your natural instinct is to click that button.

I'm sure, though, that this problem will lessen as users get used to Vista. But I'm equally sure that some people will hit cancel by mistake. BTW: What DOES happen when you click "Cancel"?

[Adam]

Do users really reason about file newness through file times though? What if I've been working on a file and get 'the newest version' of it from an email which happens to have an earlier file time on it? Woudldn't it then be confusing to see Windows refer to it as a newer file?

Or do users even reason about the newness of files at all? I've seen plenty of examples of users appending letters or numbers to the end of files instead of looking at the file's Last Modified Time.

[Sandeep Mohan]

Good points and post. This has been possibly dealt with in the comments but I would suggest that the options be reversed for an user interaction with less "anxiety". For example, the dialog ought to offer the option to save both, not move or finally overwrite the 'newer' file in that order.

[lucmars]

Yes, the best is to not confuse the user with "newer"/"older". Just warns that this file already exists in this location, replace it ? replace/cancel.
Either the user knows what he/she is doing and then overwrites, either the user goes in doubt and then cancel.

[kate]

actually, this feature is REALLY annoying me. daily, i bring at least ten files from work to my home computer to update. in XP the dialog box would tell me which file was newest. now, every single time i copy a file, i have to wonder if i am accidentally overwriting my updated file with a file that may be older. is there any fix for this???