Documentation for a historical release of Infusion: 1.3
Please view the Infusion Documentation site for the latest documentation.
If you're looking for Fluid Project coordination, design, communication, etc, try the Fluid Project Wiki.

Uploader Design Improvements Based on User Testing

Owned by Erin Yu
Last updated: Aug 19, 2008Version comment

Design Iteration

Issue 1: Pause is unintuitive

Solution 1:

Solution 2: Make Pause prominent and disable other functionalities (e.g. Remove, Add more) until user Pauses.

Issue 2: It isn't immediate to the user that multiple upload

Solution: Provide a short message to indicate multiple upload is possible.

Issue 3: The upload error message doesn't provide any actions.


Solution: Allow users to try uploading the files with errors again or remove them. Provide tool tips for each of these buttons ("Try again", "Remove").

Recommendations from User Testing

  • (DO) Add the instructions back in for how to multi-upload (+1 EY)
  • (DO) Should we rethink pause, remove, add more files?  So far people aren't using them.  They do add complexity to the interface.  If those tasks don't fall in the 80/20 rule I might vote for getting rid of them since users can accomplish both in other ways. (+1 EY: There is no need to make users wonder if it's okay to press remove before pausing. Pause is intended to be used for one of the following: 1) adding more files 2) removing files from queue 3) canceling upload. The experience would be smoother if we allowed the user to do these things directly without having to pause.)
  • (DO) Why do we have to have pause.  It's weird to have to know you have to pause first when the big red delete icon is right there in your face.  Why not let them remove but keep the file in the queue and make it way greyed out or somehow very different visually from the others.  I know it's cleaner technically but I think it's a real stretch to expect users to know to pause first.  Couldn't we leave removed files in queue and make them look distinctly removed? (+1 AB, continue to let users remove files while the upload is taking place.)
  • (eli) simplify the user experience by doing an immediate upload and de-emphasize pause and remove. (AB: I like this idea, but think users should still be able to remove files from the queue when it is uploading, which would essentially allow them to cancel the upload if necessary, and make it very clear what is and is not being uploaded.)
  • (eli) only have one progress bar with one pause button (+1 AB)
  • (eli) in addition to the progress bar include a more active hourglass or spinner so that when Progress is stalled because of network activity or file size there is still some feedback that the Uploader is still uploading. (+1 AB)
  • (AB) Fix test environment, or do an upload first yourself to ensure the user gets the Fluid Uploader on their first task.
  • (AB) Consider centering "Done" button (if it's the only button because we get rid of Pause/Resume) to make it more prominent.
  • (AB) Make the progress bar more prominent.
  • (AB) Put confirmation and error messages in one place, and add guidance for doing this to pattern, tutorial, etc.. Currently there are error & confirmation messages in two different places the Uploader and confirmation messages in the application itself. In testing my user did not see the application's confirmation messages, the Uploader's error messages, or even the Uploader's confirm message (I don't think--I actually didn't notice it).
    • In most cases, I think the application will want to handle the error messages (for consistency's sake), but there may be situations in which it makes sense to display they error messages in the uploader itself (e.g. when an application or website has no other error messages) to better ensure users see them. (+1 EY)
    • Make the "Uploaded" message in the Uploader more prominent. Consider putting the number of files *not* uploaded there too. (+1 EY)
    • Add information to the design pattern and component tutorial/documentation suggesting a very prominent "files uploaded" message (with the number of files uploaded, too, if possible--do we send this information back to the originating app?) if the messages are being handled by the application.
  • (AB) If we retain the files' individual error messages in the Uploader, make them more prominent, and if possible put the name of the file in the message.
  • (AB) Launch OS File Browser when user opens Uploader (or make "Browse files" link more prominent). (+1 EY)
  • (AB) Think about whether there are recommendations (e.g. for the design pattern)/modifications(e.g. config options for the Uploader) we'd like to make when using the Uploader with a (standard) File Manager. Is it overkill/too many steps to have to press "Done" in this case since the user can also just scroll down to see if the files were uploaded? Or is it too much in general since users are dealing with 3 different views on their files (OS File Browser, Uploader, Application File Manager)"?