Long-running operations that require occasional user input should nonetheless not block while waiting for it. They need to accomplish as much as they can as quickly as they can. If necessary the problem should be divided into the pieces that require user input and pieces that don’t so that progress can be made on some pieces while waiting for input on other pieces. This was recently brought home to me while evaluating the ChronoSync file synchronization tool.
ChronoSync can backup, mirror, or synchronize entire disks. This can involve transferring hundreds of thousands of files and gigabytes of data over a slow network. This can easily take hours to a day or more. Needless to say the user isn’t going to sit in front of their computer twiddling their thumbs during the entire operation. Consequently, you can imagine how disappointing it is to leave a computer backing up overnight, only to return to it the next morning and discover it’s copied two files while presenting you with a dialog like this:
Putting up such a dialog is not the mistake. It is OK for a program to request user input. Certainly, ChronoSync should not overwrite a changed file and potentially lose data without alerting the user. Certainly, ChronoSync should alert the user of files it could not copy. The mistake is that ChronoSync stops all other operations and waits for the user to answer this question before proceeding to copy the files that don’t require user confirmation. Typically less than 1 file in 1000 needs to be confirmed (or denied). There is no good reason not to copy the 999 files that don’t need to be confirmed while waiting for further input on the one file that does.
What ChronoSync and similar programs should do is add the questionable operation to a secondary queue. Any operation that requires confirmation goes in the queue, and waits there until the user approves or rejects it. However all the operations that don’t require user approval can continue. That way when the user wakes up the next morning, most of the files have been copied. They just have to decide what to do about the few that require manual intervention, and the process is complete.
If you need an outside eye to spot user interaction bloopers like this one, I’m available for consulting and expert design reviews. I specialize in end-user facing software and programmer-facing APIs, but I’ve been known to help out with devices like cameras, refrigerators, microwaves, and watches from time to time too.