Draft Uploader Design

Tue May 20 17:05:42 UTC 2008

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Upload Use Cases.pdf
Type: application/pdf
Size: 379189 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080520/7462a258/attachment.pdf>
-------------- next part --------------

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