Draft Uploader Design

Eli Cochran eli at media.berkeley.edu
Thu May 22 03:51:05 UTC 2008 

Allison,
Thanks for the input. Just to make things more complicated, we're  
hoping that back-end developers will implement a true Cancel, one that  
actually deletes the uploaded files, but that'll have to be up to the  
back-end developer. So in some cases the Cancel could be a destructive  
Cancel and in others it could be a non-destructive Cancel.

In the non-destructive case, I would actually prefer a "Done" button,  
as I think that it's clearer that what's happening is that the use is  
continuing with whatever files have already uploaded. I think that  
it's worth testing.

- Eli

On May 21, 2008, at 6:30 PM, Allison Bloodworth wrote:

> Very nice job Erin, Daphne & Eli! :) I have a couple small  
> suggestions.
>
> I find the "Cancel" button somewhat ambiguous if users have already  
> successfully uploaded some files. I think there has been some  
> discussion around this already, but I think it is important to let  
> users know what will happen to those already uploaded files if they  
> hit 'Cancel.' Perhaps upon hitting Cancel, the user could receive a  
> message stating which files have been successfully uploaded, and  
> that the upload of the remaining files was canceled? The checkmark  
> after the files have uploaded may help the user realize it, but I'm  
> not sure that less technically savvy users will understand this. I  
> don't think I'd feel sure without checking out the target folder of  
> the uploads the first time I used the uploader.
>
> In screen 3.1 I would also probably be a little afraid to even press  
> "Cancel" if I wanted to retain the already uploaded files, but  
> didn't want to upload any more. I can't think of a great way to  
> alleviate this problem, but perhaps re-naming the button in some  
> way, like "Cancel uncompleted uploads" (ugh, but that's really what  
> it is) or "Cancel remaining uploads" would help? (I know, it's  
> wordy...I can think more on this if that would be helpful...)
>
> Cheers,
> Allison
>
> On May 21, 2008, at 9:53 AM, Erin Yu wrote:
>
>> The initial design (version 1) is no longer on the page, because I
>> didn't see a value in keeping it in there (and having a really long
>> page).
>>
>> The first  design you see on the page is the latest (version 3). If
>> you scroll down, you'll see the previous design (version 2). Let me  
>> go
>> edit the titles to say "New" and "Old". ;)
>>
>>
>> On 21-May-08, at 12:46 PM, Daphne Ogle wrote:
>>
>>> Nice job Erin!  I think button workflow we discussed yesterday works
>>> well.
>>>
>>> I got a little confused on the wiki page because it's actually the
>>> first set of designs that are current but the 2nd set says "Revised
>>> Design (version 2)".  Should those just be archived at this point --
>>> or retitled to show they are old?
>>>
>>> -Daphne
>>>
>>> On May 21, 2008, at 9:02 AM, Erin Yu wrote:
>>>
>>>> Hi,
>>>>
>>>> The updated design (and the keyboard interaction) can be found  
>>>> here:
>>>> http://wiki.fluidproject.org/display/fluid/Uploader+Design+Overview
>>>>
>>>> If you have better icons, let me know. :)
>>>>
>>>> Erin
>>>>
>>>> On 20-May-08, at 1:05 PM, Eli Cochran wrote:
>>>>
>>>>> Erin,
>>>>> These designs are really coming along.
>>>>>
>>>>> I'm sorry that we didn't get a chance to chat about this at the  
>>>>> end
>>>>> of last week.
>>>>>
>>>>> This last design tweak really got my brain whirring. To the point
>>>>> where I had to map out for myself all the possible paths. So I did
>>>>> some quick use cases which I've included here. I don't know if  
>>>>> they
>>>>> will help you but they really helped me.
>>>>>
>>>>> I think your previous incarnation, the one just before this one,  
>>>>> was
>>>>> closer. Pause and Cancel can not be combined. And Done and Upload
>>>>> also need to be separate actions.
>>>>>
>>>>> Here is my thinking:
>>>>>
>>>>> Upload and Pause are the flip of each other. Which means that they
>>>>> could share the same button and flip between the two modes. Cancel
>>>>> and Done are distinct actions and therefor need to be separate
>>>>> buttons. Cancel should probably always be available, while Done
>>>>> should be available as soon any one file has been uploaded.
>>>>>
>>>>> I considered that maybe Upload, Pause, and Done could share the  
>>>>> same
>>>>> button, except then there would be no way to do a "Done" with  
>>>>> only a
>>>>> partial upload in that case.
>>>>>
>>>>> Three distinct actions/three distinct buttons:
>>>>>
>>>>> Upload/Pause
>>>>> 	starts and stops upload action
>>>>> Cancel
>>>>> 	cancels the whole transaction
>>>>> 		[ideally with a back-end implementation that cleans up after
>>>>> itself]
>>>>> Done
>>>>> 	dismisses the uploader after one or more uploads
>>>>>
>>>>> Thanks,
>>>>> Eli
>>>>>
>>>>> <Upload Use Cases.pdf>
>>>>>
>>>>>
>>>>> On May 16, 2008, at 2:54 PM, Erin Yu wrote:
>>>>>
>>>>>> Yeah, thanks, Aaron. I had thought about that, and you just
>>>>>> crystalized it for me (that Cancel as default won't work).
>>>>>>
>>>>>> I only put the focus there, because Done is greyed out at that
>>>>>> point (while upload is still going). My other thought was to make
>>>>>> the red button a Pause button rather than a Cancel button, and  
>>>>>> have
>>>>>> it change to "Continue upload" when clicked. (Cancel feature is
>>>>>> still available at the top right "X").
>>>>>>
>>>>>> <uploaderKeyboard07.png>
>>>>>>
>>>>>>
>>>>>> This simplifies things, and we no longer need the "mouse-over the
>>>>>> progress bar" pause.
>>>>>>
>>>>>>
>>>>>> On 16-May-08, at 5:38 PM, Aaron Zeckoski wrote:
>>>>>>
>>>>>>> Dialogs in operating systems that default to cancel so that I  
>>>>>>> can
>>>>>>> accidently hit enter and cancel them are a huge inconvenience. I
>>>>>>> would
>>>>>>> personally recommend against following a convention like that.
>>>>>>> Nothing
>>>>>>> is worse than thinking you have switched windows and hitting  
>>>>>>> enter
>>>>>>> and
>>>>>>> cancelling a long running process (upload/download/whatever). If
>>>>>>> you
>>>>>>> are going to make something the "enter key" default while
>>>>>>> uploading,
>>>>>>> how about the pause which can at least be undone. It will
>>>>>>> accomplish
>>>>>>> the same goal (stop the upload) but not result in frustration if
>>>>>>> that
>>>>>>> is not what the user wanted or they accidently hit enter twice
>>>>>>> in a
>>>>>>> row.
>>>>>>> -AZ
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 16, 2008 at 10:29 PM, Erin Yu <erin.yu at utoronto.ca>
>>>>>>> wrote:
>>>>>>>> Thanks for bringing up a good point!
>>>>>>>> It would be nice to create a keyboard convention, so we can  
>>>>>>>> apply
>>>>>>>> consistent
>>>>>>>> the keyboard interaction and visual feedback throughout our
>>>>>>>> components.
>>>>>>>> Here's an idea for the keyboard interaction. This is by no  
>>>>>>>> means
>>>>>>>> perfect,
>>>>>>>> but would be a good starting point of our keyboard interaction
>>>>>>>> discussion
>>>>>>>> for the Uploader.
>>>>>>>>
>>>>>>>> When the dialogue first opens (after the OS file system  
>>>>>>>> window),
>>>>>>>> the focus
>>>>>>>> should be on the Upload button since this is the most likely  
>>>>>>>> and
>>>>>>>> most
>>>>>>>> prominent action on this screen. Simply pressing Enter would
>>>>>>>> trigger the
>>>>>>>> upload.
>>>>>>>>
>>>>>>>> You can traverse up using Shft + Tab to Add more
>>>>>>>>
>>>>>>>> Shft + Tab will move the cursor further up and put the focus on
>>>>>>>> the list of
>>>>>>>> files (the first item on the list will in focus by default).  
>>>>>>>> The
>>>>>>>> Arrow
>>>>>>>> keys let you to go up and down the list, and pressing Tab at  
>>>>>>>> any
>>>>>>>> point will
>>>>>>>> take the focus away from the list (and back on Add more).  
>>>>>>>> Remove
>>>>>>>> being the
>>>>>>>> only option for each item, pressing Enter with a focus on an  
>>>>>>>> item
>>>>>>>> would
>>>>>>>> remove it from the list.
>>>>>>>>
>>>>>>>> When the files are uploading, the most likely action here would
>>>>>>>> be to wait
>>>>>>>> for the upload to finish. But if you wish to cancel, the cursor
>>>>>>>> will by
>>>>>>>> default be on Cancel, so you can just press Enter.
>>>>>>>>
>>>>>>>> Shft + Tab to traverse up to pause
>>>>>>>>
>>>>>>>> When done, this dialogue box will go away automatically after  
>>>>>>>> one
>>>>>>>> second,
>>>>>>>> but the focus will be on Done (if you wanted to make it go away
>>>>>>>> immediately).
>>>>>>>>
>>>>>>>> Erin
>>>>>>>>
>>>>>>>> On 16-May-08, at 10:17 AM, Eli Cochran wrote:
>>>>>>>>
>>>>>>>> Anastasia,
>>>>>>>> I'm glad that you brought that up. Yesterday, as I was looking
>>>>>>>> over
>>>>>>>> the designs, I started to think about what keyboard interaction
>>>>>>>> would
>>>>>>>> be for the mouseover pause button. Although I love the  
>>>>>>>> design, I
>>>>>>>> worry
>>>>>>>> that it might be very hard to communicate that action both for
>>>>>>>> the
>>>>>>>> keyboard and for ARIA.
>>>>>>>>
>>>>>>>> Usually when I look at a design, even a complex design like  
>>>>>>>> this
>>>>>>>> one,
>>>>>>>> I can easy see the keyboard actions, but this one is worrying
>>>>>>>> me. I
>>>>>>>> don't want to lose the elegance of the design but we'll need to
>>>>>>>> figure
>>>>>>>> this one out.
>>>>>>>>
>>>>>>>> - ELi
>>>>>>>>
>>>>>>>> On May 16, 2008, at 6:14 AM, Anastasia Cheetham wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I've put the original design as well as the one revised in
>>>>>>>> response
>>>>>>>>
>>>>>>>> to
>>>>>>>>
>>>>>>>> Daphne and Eli's feedback on the wiki:
>>>>>>>>
>>>>>>>> http://wiki.fluidproject.org/display/fluid/Multi-File+Uploader
>>>>>>>>
>>>>>>>> +Overview
>>>>>>>>
>>>>>>>> Erin, these designs look great!
>>>>>>>>
>>>>>>>> Seeing the mouse-over images made me think that we should start
>>>>>>>>
>>>>>>>> considering what the keyboard interaction will be for this
>>>>>>>> component.
>>>>>>>>
>>>>>>>> It makes sense to me to start considering that as early as
>>>>>>>> possible.
>>>>>>>>
>>>>>>>> So questions are:
>>>>>>>>
>>>>>>>> - What keystrokes will be used to navigate to the various  
>>>>>>>> regions
>>>>>>>> of
>>>>>>>>
>>>>>>>> the interface?
>>>>>>>>
>>>>>>>> - What keystrokes will be used to activate the various actions?
>>>>>>>>
>>>>>>>> - What will be the visual indications of the interesting  
>>>>>>>> moments
>>>>>>>>
>>>>>>>> associated with keyboard-based use of the component? (what  
>>>>>>>> *are*
>>>>>>>> the
>>>>>>>>
>>>>>>>> interesting moments?)
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Anastasia Cheetham                   a.cheetham at utoronto.ca
>>>>>>>>
>>>>>>>> Software Designer, Fluid Project    http://fluidproject.org
>>>>>>>>
>>>>>>>> Adaptive Technology Resource Centre / University of Toronto
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>>
>>>>>>>> fluid-work mailing list
>>>>>>>>
>>>>>>>> fluid-work at fluidproject.org
>>>>>>>>
>>>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>>>
>>>>>>>> . . . . . . . . . . .  .  .   .    .      .         .              .
>>>>>>>>                .
>>>>>>>>
>>>>>>>> Eli Cochran
>>>>>>>> user interaction developer
>>>>>>>> ETS, UC Berkeley
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Aaron Zeckoski (aaronz at vt.edu)
>>>>>>> Senior Research Engineer - CARET - Cambridge University
>>>>>>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
>>>>>>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
>>>>>>
>>>>>
>>>>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>>>>>
>>>>> Eli Cochran
>>>>> user interaction developer
>>>>> ETS, UC Berkeley
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> Allison Bloodworth
> Senior User Interaction Designer
> Educational Technology Services
> University of California, Berkeley
> (415) 377-8243
> abloodworth at berkeley.edu
>
>
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080521/4ed3308d/attachment.html>

More information about the fluid-work mailing list