Draft Uploader Design
Erin Yu
erin.yu at utoronto.ca
Fri May 16 21:54:55 UTC 2008
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").
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uploaderKeyboard07.png
Type: image/png
Size: 8288 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080516/17956960/attachment.png>
-------------- next part --------------
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/]