Comprehensive File Upload

• Keep as much of the current screen as possible exposed to the user, giving the user confidence that the current flow of interaction can resume as soon as the upload is initiated. Even if it is necessary to suspend the interaction until the upload completes, the current interaction display should remain.
• Present the user with a navigational display through which they can examine the directories in the local file system and select files into a list to be transferred. Display the growing list as the user selects files. Allow the user to interact with other processes or the current application without terminating navigation, file selection, or list construction. (If necessary, employ the local system's file browser, which may limit some of the flexibility suggested here.)
• Give the user the ability to alter the list before the transfer takes place through adding and deleting entries. Other actions such as reordering the list to set the sequence in which the files are transferred may also be allowed.
• Give the user some indication of how long the transfer is likely to take, and how much impact the files will have on the space available in the remote service. Display the file size. If the duration of the transfer can be calculated, it should also be displayed. Present a summary line which gives the totals of the sizes and times for all the files in the list. These considerations may affect the user’s decisions on which files to include in the list.
• Once the list is complete, enable the user to effect the transfer of all files with a single action: a mouse-click or keystroke, for example.
• Keep the user aware of the progress of the transfers, indicating which files have been uploaded successfully. If files are large, display an indicator of the progress of each transfer as it proceeds. If durations can be calculated, display the time remaining for each file as it is transferred, updating the value continuously.
• Allow the user to interrupt the transfer, to either suspend or abort it, with an indication of which files have been uploaded and which have not.
• Allow the user to alter the list after suspending a transfer.
• Allow the user to resume a transfer after suspending it.
• Give the user clear information and a choice of actions when an abnormal condition occurs, such as:
  • A file of the same name already exists in the remote service
  • The contents of a file in the local filesystem cannot be read
  • A file is selected more than once for inclusion in the list
• Inform the user when the transfer is complete, by displaying the list with all files reported as having been uploaded.
• After transfer is complete, give the user the opportunity either to select more files for upload, or to dismiss the list. If it was necessary to suspend the original interaction, bring it back to the foreground.
• Do not confine the user to "file upload mode" if this can be avoided. Allow the user engage in other interactions while the transfers are taking place. The file upload should appear to be a background task. Unless the upload is critical to the workflow of the application, allow the user to continue with the current interaction.

In applying this pattern to a particular design, the designer must consider a number of trade-offs. The application context of the remote service should provide some insight into the correct choices. For example, if it is known that only one file will be transferred, and the application reports what files have been received, then displaying the list after transfer is complete may be superfluous.