3 ms·

Sorry for the small digression. It's on topic. Just a few minutes ago, while copying 63 GB worth of pics and videos from my phone to my laptop, KDE forwarded m

by Rygian 9mo ago

Sorry for the small digression. It's on topic. Just a few minutes ago, while copying 63 GB worth of pics and videos from my phone to my laptop, KDE forwarded me the error "File <hard to retain name.jpg> could not be opened. Retry, Ignore, Ignore all, Cancel". This was around file 7000 out of 15000. The file transfer stopped until I made a choice. As a user, what am I supposed to do with such a popup? It seems like a very good example of "Eror Handling Without Purpose" as the article describes, but at user level. Except that here, the audience is "a plain user who just dragged a folder to make a copy" and none of the four options (or even the act of stopping the file transfer until an answer is chosen) is actually meaningful for the user. The "Putting It Together" for this scenario should look like: a non-modal section populates with "file <hard to retain name.jpg> failed due to reason; at the end of the file transfer you'll get a list with all the files that failed, and you'll have an option to retry them, navigate to their source position to double-check, and/or ignore".

XorNot 9mo ago
This design still doesn't work: what if the user walks away and the computer is powered off in the meantime? I.e. you need to write the report of this to a file itself. In fact you should allocate a decently large file upfront to make sure you can write the report and the error message (out of disk space for example).
- throw-the-towel 9mo ago
  And what if the computer is kidnapped by the US Army while it's copying the files? You just can't defend against everything, but an imperfect solution can still be an improvement over the status quo.
  - XorNot 9mo ago
    No, but imagine doing all the work to collect up a list of files that failed only to say, pop a modal at the end of the process that coincides with the user hitting Enter because they were multitasking and it auto-accepts the dialog. Information gone, context lost, in fact your entire design has failed to change the experience at all! All because of one UI overlap that's actually very common. We have shared workstations for example where this would be a typical use case for non-tecchnical users across multiple user logins: ensuring you can check that the big data transfer was complete a few hours later would be very useful, but if you only do a fraction of the work for completeness then again, it's of no benefit.
    - marcosdumay 9mo ago
      Yes. The entire reason DEs expect people to dismiss those dialogs is because they are modal. And there's no reason at all for them to be modal. KDE even got an entire notifications application, and discovered that it's bad to make them modal. But didn't move away from the idea of dismissing them on any interaction, it still acts like it's a modal.
  - vineyardmike 9mo ago
    > kidnapped by the US Army.... You just can't defend against everything Of course not. The litmus test IMO should be "what would a normal intelligent human do in this situation?" A human would copy every file it could, maintaining a list of issues. When you were available to address concerns, it'd present the options to you. The human would give up if the US Army showed up, but a human would restart a TCP connection automatically without asking for permission again (or more analogously, redial a phone call). A human would save their work automatically, and when you showed back up, would find that work for you. (In 2026, things like "retry" should be automatic outside some very specific limitations too, because of course a human would try again if they failed).
    - yetihehe 9mo ago
      > what would a normal intelligent human do in this situation? Problem is that this requires testing what actual "normal intelligent human" would do, because very often programmer has other ideas and UI/UX people have other ideas. > A human would copy every file it could, maintaining a list of issues. How do you know? From your idea what should be done instead of current version? I would not do it like you said. Also, there are many reasons for transfer not succeeding and depending on a reason why transfer didn't succeed, you should make different decisions. sometimes reasons are not predictable by a program (a new file transfer method over pidgeons was transparently added to the system and "carrier attacked by predator" was not included in "how to handle this reason").
    - 1718627440 9mo ago
      > A human would copy every file it could, maintaining a list of issues. Please not, I want my computer to be a dumb tool, who really only does what I told it to. I do not want to have it have it's own agenda. > In 2026, things like "retry" should be automatic outside some very specific limitations too No. I can tell the computer to retry, when I didn't it is because I didn't want it to.
- Rygian 9mo ago
  It goes quite far, actually. A file transfer should remain active even if both devices (source, destination) are physically disconnected, or in network partitions, or when devices are full, need media change, etc. The only valid states for a file transfer are: ongoing, fully completed with 100% success, or explicitly cancelled by the user with a full usable report of what got copied, fully or partially, and what did not get copied. The file transfer dialogs and tooling of today's mainstream computing are stuck in the nineties.
  - yetihehe 9mo ago
    Then you will have another control panel or log of ongoing file transfers, which will accumulate waiting transfers over the years a device was used.
grumbel 9mo ago
> As a user, what am I supposed to do with such a popup? Change the floppy disk. In the MSDOS days those messages were useful, as read errors might be caused by having the wrong floppy in the drive. The OS had no way to know when the floppy was changed and "Retry" allowed you to swap the disks back and try again. In modern days it is less useful, the behavior just got carried over. Windows addresses this issue somewhat by scanning the directory tree before the actual copying starts, this can catch some errors before they happen and gives you better progress reporting on top. But a single dialog that keeps track of the whole copy/move operations, not a modal dialog attached to individual read/write calls would be the way to go here. This is a case of the GUI sticking to close to what the OS is doing instead of what the user intended to do.
- 1718627440 9mo ago
  > Windows addresses this issue somewhat by scanning the directory tree before the actual copying starts Which really sucks because no you need to wait for minutes before it actually starts moving or deleting. I generally just abort, start the midnight commander or just invoke mv/del directly. > But a single dialog that keeps track of the whole copy/move operations Which is what is the case here? The question and buttons appear in that dialog.
  - grumbel 9mo ago
    > The question and buttons appear in that dialog. The error/retry dialog is for the failure of moving an individual file, not for a failure of the move operation as a whole. Those individual error dialogs provide no means to deal with cascading errors. All you can do is "Skip All", but that means you get no further information on errors anymore. The error reporting should be part of the Moving dialog itself and provide a list of everything that failed in the move, along with potential ways to resolve it. More detailed reporting than "Could not read" would also be welcome (io, permission, ...).

by Rygian 9mo ago

XorNot 9mo ago

This design still doesn't work: what if the user walks away and the computer is powered off in the meantime? I.e. you need to write the report of this to a file itself. In fact you should allocate a decently large file upfront to make sure you can write the report and the error message (out of disk space for example).

throw-the-towel 9mo ago
And what if the computer is kidnapped by the US Army while it's copying the files? You just can't defend against everything, but an imperfect solution can still be an improvement over the status quo.
- XorNot 9mo ago
  No, but imagine doing all the work to collect up a list of files that failed only to say, pop a modal at the end of the process that coincides with the user hitting Enter because they were multitasking and it auto-accepts the dialog. Information gone, context lost, in fact your entire design has failed to change the experience at all! All because of one UI overlap that's actually very common. We have shared workstations for example where this would be a typical use case for non-tecchnical users across multiple user logins: ensuring you can check that the big data transfer was complete a few hours later would be very useful, but if you only do a fraction of the work for completeness then again, it's of no benefit.
  - marcosdumay 9mo ago
    Yes. The entire reason DEs expect people to dismiss those dialogs is because they are modal. And there's no reason at all for them to be modal. KDE even got an entire notifications application, and discovered that it's bad to make them modal. But didn't move away from the idea of dismissing them on any interaction, it still acts like it's a modal.
- vineyardmike 9mo ago
  > kidnapped by the US Army.... You just can't defend against everything Of course not. The litmus test IMO should be "what would a normal intelligent human do in this situation?" A human would copy every file it could, maintaining a list of issues. When you were available to address concerns, it'd present the options to you. The human would give up if the US Army showed up, but a human would restart a TCP connection automatically without asking for permission again (or more analogously, redial a phone call). A human would save their work automatically, and when you showed back up, would find that work for you. (In 2026, things like "retry" should be automatic outside some very specific limitations too, because of course a human would try again if they failed).
  - yetihehe 9mo ago
    > what would a normal intelligent human do in this situation? Problem is that this requires testing what actual "normal intelligent human" would do, because very often programmer has other ideas and UI/UX people have other ideas. > A human would copy every file it could, maintaining a list of issues. How do you know? From your idea what should be done instead of current version? I would not do it like you said. Also, there are many reasons for transfer not succeeding and depending on a reason why transfer didn't succeed, you should make different decisions. sometimes reasons are not predictable by a program (a new file transfer method over pidgeons was transparently added to the system and "carrier attacked by predator" was not included in "how to handle this reason").
  - 1718627440 9mo ago
    > A human would copy every file it could, maintaining a list of issues. Please not, I want my computer to be a dumb tool, who really only does what I told it to. I do not want to have it have it's own agenda. > In 2026, things like "retry" should be automatic outside some very specific limitations too No. I can tell the computer to retry, when I didn't it is because I didn't want it to.
Rygian 9mo ago
It goes quite far, actually. A file transfer should remain active even if both devices (source, destination) are physically disconnected, or in network partitions, or when devices are full, need media change, etc. The only valid states for a file transfer are: ongoing, fully completed with 100% success, or explicitly cancelled by the user with a full usable report of what got copied, fully or partially, and what did not get copied. The file transfer dialogs and tooling of today's mainstream computing are stuck in the nineties.
- yetihehe 9mo ago
  Then you will have another control panel or log of ongoing file transfers, which will accumulate waiting transfers over the years a device was used.

grumbel 9mo ago

> As a user, what am I supposed to do with such a popup? Change the floppy disk. In the MSDOS days those messages were useful, as read errors might be caused by having the wrong floppy in the drive. The OS had no way to know when the floppy was changed and "Retry" allowed you to swap the disks back and try again. In modern days it is less useful, the behavior just got carried over. Windows addresses this issue somewhat by scanning the directory tree before the actual copying starts, this can catch some errors before they happen and gives you better progress reporting on top. But a single dialog that keeps track of the whole copy/move operations, not a modal dialog attached to individual read/write calls would be the way to go here. This is a case of the GUI sticking to close to what the OS is doing instead of what the user intended to do.

1718627440 9mo ago
> Windows addresses this issue somewhat by scanning the directory tree before the actual copying starts Which really sucks because no you need to wait for minutes before it actually starts moving or deleting. I generally just abort, start the midnight commander or just invoke mv/del directly. > But a single dialog that keeps track of the whole copy/move operations Which is what is the case here? The question and buttons appear in that dialog.
- grumbel 9mo ago
  > The question and buttons appear in that dialog. The error/retry dialog is for the failure of moving an individual file, not for a failure of the move operation as a whole. Those individual error dialogs provide no means to deal with cascading errors. All you can do is "Skip All", but that means you get no further information on errors anymore. The error reporting should be part of the Moving dialog itself and provide a list of everything that failed in the move, along with potential ways to resolve it. More detailed reporting than "Could not read" would also be welcome (io, permission, ...).