File uploader feedback.

Fri May 16 18:32:39 UTC 2008

I'll 2nd the thanks!   Some comments below to share earlier design  
discussions we had about these issues.

-Daphne

>>
>>
>> Given the variety of things that an application might want to do with
>> files once they've *been* uploaded, and the early status of the
>> component, it might be best for now to restrict the Fluid Uploader to
>> the actual select-and-upload portions of the workflow and to let the
>> component's customers decide for themselves how to handle  
>> successfully
>> uploaded files. If that restriction is acceptable, it would imply  
>> that
>> "Remove" *does* only refer to removing from the queue and "Cancel"
>> doesn't delete already successfully uploaded files, and also that it
>> needs to be very clear to the user that "Cancel" didn't undo any  
>> already
>> successfully completed work -- it only interrupted work-in- 
>> progress. At
>> any rate, if a "Delete from Server" capability is added to the
>> component, I hope it will be optional and clearly distinguished  
>> from a
>> queue removal. (The Firefox "Downloads" window would be a familiar,  
>> if
>> not very pretty, example of what I mean.)
Exactly!  As Erin said we conscientiously tried to keep the Uploader  
functionality limited to basic upload steps.  We had some discussion  
about helping implementors think about best practices for interactions  
leading up to and ending their interface with the Uploader.   Using  
the 80/20 rule we decided to include dropping users back into their  
context with new files in view in the workflow of the component.  We  
came up with other use cases for leaving the uploader open so users  
can continue adding files without going back (choosing files from  
multiple folders on their computer for instance).  Those interactions  
will be defined in the design pattern as "tips for implementation" or  
something of the sort.
>>
>>
>> Best,
>> Ray
>>
>> On 5/15/2008 1:05 PM, Jonathan Hung wrote:
>>> Hey Eli, Daphne, and Erin.
>>>
>>> First... that uploader rocks my socks. Seriously! Every uploader  
>>> should
>>> be as friendly. :)
>>>
>>> I spent some time putting it through the Uploader Test Protocol and
>>> encountered a few things that I would love to see in a future  
>>> iteration
>>> of the Uploader (incremental improvements, right? :):
>>>
>>> 1. A way to selectively delete already uploaded files. (That remove
>>> column is a tease! It only applies to files in a queue. :).
Based on user testing feedback this is exactly what we wanted to do.   
Apparently there are some technical difficulties with this  
implementation (Eli can say more about this).   However, this  
shouldn't be an issue in the new default work flow since the Uploader  
automatically closes after upload.  Perhaps we should say something  
about it in the design pattern best practice mentioned above?
>>>
>>>
>>> 2. Make the filename clickable to "view" the file. If an image, the
>>> browser will launch it in another window. If a document, the browser
>>> will prompt you to download it. Does whatever the default browser is
>>> configured to do for that file type. This is handy in case you  
>>> forget
>>> what you've already uploaded and want to see what it is.
Several users also tried to open files after upload in our testing.   
We were leery of including this interaction since we don't know all  
the contexts the Uploader will be used in so don't always understand  
what it means to open a file from here.  I guess this is a non-issue  
in the new default workflow since users will be dropped back to their  
context with files in view.  We should mention something in the design  
pattern about making it easy for files to be deleted at that step.   
And also say something about it in reference to the secondary  
workflows where the Uploader may remain open after upload.
>>>
>>>
>>> 3. Cancel button is a bit ambiguous. If I've already uploaded files,
>>> does hitting Cancel delete the files I already uploaded? Or does  
>>> Cancel
>>> just send you back to the previous page keeping your uploaded files
>>> intact? In which case, would "Done" be a more appropriate label?
Do you think the green checkmarks indicating files have been uploaded  
will help with this?  What we found in user testing is user's didn't  
notice the change in status to file uploaded.  I think Erin's update  
makes it pop the status pop much more.  I also think having the newly  
uploaded files in view when upload is complete will be good feedback  
that some files were uploaded.  This is something we were all  
concerned about.  Other ideas?
>>>
>>>
>>> 4. Have the uploader sing songs while it's working.... really nice  
>>> when
>>> uploading a huge batch of large. Please, no muzak.
>>>
>>>
>>> Thanks for entertaining my thoughts. :)
>>>
>>> - jonathan.
>>>
>>> --
>>> Jonathan Hung / jonathan.hung at utoronto.ca <mailto:jonathan.hung at utoronto.ca 
>>> >
>>> University of Toronto - ATRC
>>> Tel: (416) 946-8312
>>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>>
>
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080516/60fccb99/attachment.html>