Simplify the file conflict / overwrite dialog (redesign)

I would probably say yes.

You’re right.

This is another great example.

We could add another line that indicates the path. Still would take less screen estate than the current. :slight_smile:

How would it be ambiguous? Don’t we go one by one then? About the rename, if the file name would be changed, the “Rename” text would ba active on the button, or two separate buttons of “Overwrite” and “Rename” would alternate depending on the name change. Using a Yes would be simpler, but apparently that would be no bueno.

I’m switching off for tonight, will check back tomorrow!

I have aligned center the info main block. Also, used verdicts in center (not in source or dest) and written them relative to source.

  1. Since you removed the “source” and “destination” labels, now the user probably doesn’t understand what “the source” is. (Probably “The second file”?)
  2. The two “the source is” lines seems redundant. You can say “… is older and smaller…”.
  3. The “Files are different” line is redundant, as the line above already made that clear.

BTW, I find the current horizontal layout a bit confusing, when dragging a file from the right pane to the left pane in Dolphin. The order of “source” and “destination” in the dialog are just the opposite of which they are in Dolphin, so I need some mental twist here. (Yes, the huge arrow helps a bit.) This is a case for the vertical layout.

maybe an > arrow would help :slight_smile:

This is true, and this is counter argument for skyfishgoo willing to have verdicts in the middle.

That is true, I know. I only made that for demonstration, because otherwise I would need to show several mockups at once. In this case it is redundant and will not be shown.

If you drag the file from right pane to the left, it will not change the order in dialog :slightly_smiling_face:

We can make the order natural (the source to destination means from top to bottom) with the wording: “Would you like this file … to replace existing file …”.

We are going around, trying to remove the arrow, and now we are again talking to add it back? Something went wrong.

Here the source is going before destination, as normal human expects. (However, this may confuse windows xp users).
I placed rename field in the source. It clarifies that the rename is going to apply for the source file (and not to the rename destination).
I placed verdicts in the source, this avoids problem of duplicating “the source file is” twice (as in proposal 04 above).

Now the wording says “Replace” while our button says “Overwrite”. We need to choose one.

Give me your thoughts on the last verdict “The file is different”. We may place it aligned with the upper “… to replace existing file”.

And another look for small horizontal previews (a bit reworked from proposal 01).

Here I have discarded the idea of showing the common name in the middle (it was removed from Source and Dest). This solves several problems. First - it looked confusing that they were paths (not end filenames). Even more if we potentially make the icons an active links.
What if we have two folders? What will be in that bubble? Nothing. And how we distinguish they are actually folders, and not files?
Also, what if user has a folder named the same as file in the destination? I.e. folder named “2.jpg”, or oppositely, file named like folder “2” (no extension).
With current dialog there is less confusion.

Also, I did not use “A file with that name already exists at the destination”, because we could reuse the text for folders, which are not “files” (for the user) and I did not want to use “item”. For folders and for files the window title will be different (“File Already Exists”, “Folder Already Exists”).

Also, I clarified the rename field title (so user knows what he is renaming).

Also, In this case I made verdicts in the middle, as skyfishgoo wished. And written them relative to source.

I hope I am not to late to give feedback:

I much prefer Src/Dest Left/Right instead of Top/Bot since this makes it much easier to compare the difference.

1 Like

i think we just watched the development cycle that evolved the old XP style dialog to one we currently have, which needs a few tweaks, but is still a vast improvement over the XP style.

This design would work with smaller pictures, and text alongside, as the example produced in the post. As it’s a dialog, the actions should go at the very bottom, rather than being split along the middle and bottom.

Yeah, we have agreed on that.

Yeah, I also think that. I have made a more polished variant of the proposal 01.

The changes:

  • Returned the conflicting file name to the Source and Destination paths (as said above, to reduce confusion).
  • Used actually a question sentence in the title, rather than a statement. That statement was vague (it said “This action will overwrite destination”, but dialog allowed to rename source). With question, user may faster understand what is the problem. We do not use “destination file”, because we may reuse this title for the folders as well.
  • Used a smaller size for icons/previews. (*), so it does not steal the attention.
  • Formatted date as in real en_US locale, to show how it will actually look.
  • Used verdicts in the center, to immediately take user’s attention.
  • The Apply to All checkbox moved to left
  • Used “Rename Source” rather than “Rename”, to clarify that this action will apply to source file rather than to destination file.

Case A: File sizes are different, but their displayed measure units are higher than the amount of difference.

  • The difference is written in verdict.
  • As there is already a verdict about different sizes, it is obvious to user that they are different, so the verdict “The files are different/identical” is not shown.

Case B: File sizes are the same, but their contents (hash sums) are different.

  • There is a verdict “The files are different/identical” (note, this does not care if dates are different, because contents is being compared), (note that is is not shown for folders).
  • If there is no difference in date, the corresponding verdict is not shown.

Do we have final consensus on this?

What do you think of free space to the left and to the right of the centered verdicts (especially when there are two lines)? Is it ok, or is it ugly? I consider this ok. If there are objections, we may place them in a single line.

Icon for image may not be available, compared to the file with available preview.
(*) - I used size 96. It is not currently in stdSizes enum, but we can add it there.
As for me, looks cute.

1 Like

Try centering the source and destination text within each half of the window.

Ok, here they are. Same as proposal 07, but Source and Destination titles are centered. (Also, fixed the date format).

Case A - approximately same size

Alternative with double lined verdicts in single line:

Case B - presizely same size

Here is a table of possible verdicts combinations (omitting the larger/smaller and older/newer variants):


This is better than the previous one, but it looks to my eye as if everything’s scattered around, and the text stands too small among the width of the window. This is my subjective opinion though.

Just for the sake of trying, what about a top to bottom layout, and less padding on the middle section?

This will be the same as in prop03. There is no way to make the window narrower, because of the buttons. And you wanted to add more spacing

I would suggest to choose prop08, and choose if we want verdicts on the same line or on separate lines.

Now that I had a second look, I think the latest proposal looks good. The verdicts on the same line looks definitely better. My only note would be avoiding string concatenation while building the string though, it is not ideal when translating.

The icon of the original was nice though, it made the dialog very distinct. If you’re familiar with the dialog the huge icon immediately tells you what the issue is. "Oh it’s about duplicates. Yeah, yeah, it’s fine. Hits OK button - Now you make me read. And think.

Since the dialog can popup out of nowhere on a longer operation it would be nice to have “What application” and “What is the issue” very prominently as the first item before proposing a solution. Something like “Dolphin found a file with the same name.”

Thanks for approving. This is how the final result will look (for case A we go with single line verdicts, and do not combine them in one sentance):

I will send MR soon.

The window title already has an application name (in this case “… - Dolphin”). Note, that this dialog in not only used for conflicts in dolphin to dolphin, but also for example, from Ark to Dolphin.


Ultra-level nitpick: File Already Exists — Dolphin. It should be an em dash normally, but I’m not sure if it’s inherent. Aside from that all very nice.

Oh, sorry, that should be em dash, yeah. This mockup was made manually, so I did not noticed that.