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").
<<inline: 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 <[EMAIL PROTECTED]> 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 discussionfor the Uploader.When the dialogue first opens (after the OS file system window), the focusshould be on the Upload button since this is the most likely and mostprominent action on this screen. Simply pressing Enter would trigger theupload. You can traverse up using Shft + Tab to Add moreShft + 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 wouldremove 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 bydefault be on Cancel, so you can just press Enter. Shft + Tab to traverse up to pauseWhen 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 wouldbe for the mouseover pause button. Although I love the design, I worrythat 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. Idon't want to lose the elegance of the design but we'll need to figurethis 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 [EMAIL PROTECTED] Software Designer, Fluid Project http://fluidproject.org Adaptive Technology Resource Centre / University of Toronto _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work . . . . . . . . . . . . . . . . . . . Eli Cochran user interaction developer ETS, UC Berkeley _______________________________________________ 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-- Aaron Zeckoski ([EMAIL PROTECTED]) Senior Research Engineer - CARET - Cambridge University [http://bugs.sakaiproject.org/confluence/display/~aaronz/] Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
_______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
