3 ms·

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 fil

by XorNot 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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.

by XorNot 10mo ago

throw-the-towel 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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 10mo 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.