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 <[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 >>>> 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 [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/] >> > > . . . . . . . . . . . . . . . . . . > . > > Eli Cochran > user interaction developer > ETS, UC Berkeley > > _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
