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 / [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]
>
University of Toronto - ATRC
Tel: (416) 946-8312
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED]
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
