Hello.
There are some situations when you are trying to copy a file to the location where it already exists. For example, when extracting file from archive to the place where it was already extracted.
The overwrite dialog may seem complicated to somebody. The current dialog looks like this (not from ark):
For example, we can remove the arrow, reduce date string, hide rename field, add Hide details button (to hide details of differences), make the preview smaller. If possible, add source ark file name (Archive.zip) to the text.
Here we write file name once (because it will be the same anyway).
But here we have a duplication of message “File already exists” (in window title and in message).
Also, do we have such bubble element for the dialog? I mean that area saying file name and question. If not, we can just write plain text there.
The differences (if presented) in size and content (hash sum identity) may be written in the middle, as in original.
No objections to reconsidering something as old as file rename dialog. Personally, however, I feel like the status quo is rather well-designed. I could be made smaller at a price of reducing thumbnails, but probably not by hiding functionality away.
Date format should be globally customizable. And renaming used often enough (personally by me) that I don’t understand why adding an extra step to access that option. For me, probably the most common scenario that shows me this dialog is Ctrl+dragging a file into the same folder to create a differently named duplicate — maybe it’s a bit of a Spacebar Heating™, not sure.
I concur that I don’t think we should change the rename feature to be hidden.
“File Already Exists” being in the title is a little obscure, most people don’t realistically look there and it might be best inside the dialog.
Bubble, agree.
I think generally the content provided in the current dialog is good, and a layout overhaul would be best, by which I mean removing the massive arrow and the differences text, which seems redundant, and allows us to shrink things a bit. The thumbnail size in the example is better too, and showing the date and size alongside also.
Oh - and always show details, rather than hiding them as in your suggested design. There’s no reason not to show the thumbnails especially when they are almost immediately visually helpful.
Wow, cool tip, thanks! I made that with many steps. I always wanted to have some thing in KDE like JetBrains IDEs have - a “Tip of the day” window. And it should contain some cool tips like this. But this is a bit off topic.
Ok, fair enough that we always should show the details. I removed Hide details link.
I also undid hiding the rename field, and used proposed text in the top.
i too have been bothered by this dialog…taking a step back, i would restate the USE CASE for this dialog:
provide the user with the choice to skip, overwrite or rename
to facilitate this it should provide a clear visually compelling presentation of the relevant information necessary to quickly make the choice rather than simply present a redundant display of stats you have to wade thru to spot the differences, where’s waldo style.
these differences should logically drive which defaults are highlighted in the dialog as further visual guidance and also just to help guide the user thru the experience.
i like to think that was the intent behind the “differences” arrow and calculation in the first place and seems like something worth expanding on rather than removing.
if exactly the same (name/size/date), then no differences would highlighted and skip would be the default (can’t think of a good reason overwrite in this case)
if different timestamps, then the timestamp difference would be highlighted and overwrite would be the default
if different sizes, then the size difference would be highlighted as well and overwrite would be the default
this sort of hierarchy of differences could be presented in rather static array so that it would be visually obvious how different the files are even if the thumbnails were exactly the same and it would help make a faster determination for which action to choose.
so for instance, if there were no difference in file size but only a difference in timestamp then the space where the size difference calculation result would normally show, would instead be left blank to indicate no difference there.
this provides immediate visual guidance while the overwrite default is highlighted at the ready and accessible by just hitting ENTER.
Here is what I am thinking. The first action cluster needs to be the main one that users will work through. For that reason I moved the buttons to the top where the action happens. I left a lonely cancel button at the bottom right. I tried to apply button corner placement to make it better and easier to click. I moved some of the strings around to work on removing the center section. I feel the center section doesn’t really add much to the main actions. Instead, we can recycle those strings and put them elsewhere.
I also left-justified the text to make it look more modern and just overall cleaner. I gave the dialog a good title, which it doesn’t have right now.
The only complaint I have against this dialog: it needs two buttons to open the conflicting files for examination. If there’s a conflict, probably I can’t decide just by looking at file sizes and thumbnails. For text files I might even want to open both files and do a manual merge.
i think this is an improvement over the status quo, but here’s my thoughts
it doesn’t need a title as the window name says what needs to be said… additionally it states that the files are different, but they might not be.
it’s overall still far too big for my taste, but maybe that’s a global thumbnail size setting or something.
the apply all toggle should default to off as is the norm in these situations, and i would swap the button order on skip and overwrite since those flow nicely from least to maximum action.
and finally i would keep the center area for difference calculation results so users can see at a glance what’s different (or not) without having to scrutinize the details listed below each thumbnail… and it could still have the > symbol graphically to immediately alert the user as to the type of dialog this is and it’s purpose.
One reason I included a title as because pushing a title to the titlebar for the window leaves little room for explaining to the user what is happening in the dialog.
I agree that it’s too big. I think the area for the items showing in the bottom could be much smaller but it seems that Plasma wants to provide a preview of the file. The only way I can see that this could be smaller is by only showing representational icons and no previews. You can also shrink the preview but this makes the preview unusable imho.
Swapping the overwrite and skip buttons makes sense.
I personally don’t see the value of seeing the difference calculation. To me, users are here to make a decision to rename, they want to go fast. Adding too much info delays their actions.
If you notice, I put the calculation up in the subtitle. So that way, from the beginning, they understand there is a specific difference between these files.
for me i would tend to ignore whats in the title text as it doesn’t seem to be dynamic or part of the the information this popup is trying to communicate… it just seems perfunctory and i would not look there for indications of differences (might read it once the first time i see this dialog but then ignore it from then on).
my eye want’s to go the negative space between the files so that i don’t have to keep looking back and forth between the two files trying to figure out what’s different about them (spot waldo).
seems to me if we are going to go thru the trouble of doing the calculation, then we might as well present that info in a prominent way that helps guide the user to make a decision.
the current design tries to do that, but could be improved upon by simply revealing the difference values for size and timestamp in two fixed placeholder locations between the files (above and below the > arrow).
if the files are identical (no difference in the timestamp or the file size) then nothing would show in either placeholder
if the timestamps were different then the upper placeholder would show the age difference
if the size were also different then both the upper and lower placeholders would show the age difference and the size difference respectively.
this gives the user a visual and eye catching heads up on the differences between the files so they can quickly decide if they need to do anything with them.
i’ll try my hand at a crude cut and paste mockup to show what i’m talking about once i figure out how to do something like mspaint in linux, still have one foot in MS world.
Can you provide a good explanation based on user experience principles that can validate your argument a little more? So far, what I read is that it’s based on personal experience.
i’ve tried to convey in words my thinking regarding the differences calculation and how it would be most helpful to inform the user, but a picture is better, so here is my crude hack of the difference arrow display
all the other distracting text has been removed and only two pieces of information are displayed (if needed) and i’ve made the results relative to the source file instead of the destination file because that reads left to right just as the graphics show.
the upper placeholder shows the timestamp difference in units relevant to the the size of the difference (if the difference was only 4 seconds it would just say “4 sec”
the lower placeholder shows the size difference in units relevant to the size difference
if the files were identical then neither placeholder would show anything at all, no value or string at all… just empty space where the numbers would show (a placeholder) if there were any difference.
this gives the user a quick visual clue as to why they are even looking at this dialog box and what they might want to do about the conflict.
In this screenshot, the source and dest files are measured in KiB. I added a single letter to the source file (which counts to two bytes for russian letter), and you can see the difference clearly. Without it, it will be hard to tell it (it is possible to achieve with full bytes size, like 439901 B and 439900 B), but this is ugly.
Regarding arrow direction, note, that for RTL languages it is pointing from right to left.
how can you have the same file name being two different sizes without also having different timestamps?.. and in fact if you look at the timestamps closely (which is what i’m trying to avoid) you can see that the source is
Newer by 1 min
so i would also want to see that displayed in addition to the size difference and it would be more helpful if they were displayed without all the extra verbiage so its’ obvious at a glance… then the user can know if they want to overwrite with the newer file or keep the older one based on the size difference (or vise versa)
as for the arrow direction and units, of course that should depend on your language settings but the calculations would be the same (source is Newer|Older by ___ and/or source is Larger|Smaller by ___) regardless of the reading direction or language.
The arrow shows the direction from source to destination, but not the fact if if is “bigger” than destination. So, there is no point to place “=” there.
