File uploader feedback.

[erin.yu at utoronto.ca]

Thanks Jonathan & Ray for your feedback.

Yes, I agree there needs to be a distinction between an "upload  
component" and a "content management component". We did try to stick  
to the basic multi-file upload functionality, and making that simple  
and quick.

We plan to make this component an overlaid dialog that floats above  
user's current screen (keeps them in context) and drops them back to  
that screen once the upload is done, so they can see the new files  
that have been added immediately and can manage those files (move,  
delete, or edit them).

With that in mind, I encourage you to have a look at the updated design at:
http://wiki.fluidproject.org/display/fluid/Multi-File+Uploader+Overview
would love to hear any other thoughts you might have on it.

Erin

Quoting Ray Davis <ray at media.berkeley.edu>:

> I'm nervous about jumping in here, but I wonder if the limitations of
> the current uploader demo page -- particularly it's not updating a
> browser panel or redirecting automatically to the next page in the
> workflow after it's done -- might tempt us to grow what's supposed to be
> an "uploading component" into an "online content management UI."
>
> 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.)
>
> 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. :).
>>
>> 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.
>>
>> 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?
>>
>> 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
>