Draft Uploader Design
Erin Yu
erin.yu at utoronto.ca
Wed May 21 16:02:24 UTC 2008
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
>
>