Thanks, Erin. Now that I'm getting a chance to try out the Uploader working inside in a "real" application I am, in fact, finding the "Cancel" button pretty confusing, partly because of what "Cancel" means on a page with a single-file upload. It feels like it's either not doing enough (before I've queued any files, it's a no-opt rather than a "forget it, I want to go back to what I was doing before"), or it's doing too much (once I've queued a bunch of files it acts exactly like a "Remove all files from the queue" button). It's amazing what a difference a real workflow makes! :)
Best, Ray On 5/23/2008 1:19 PM, Erin Yu wrote: > Thanks everyone for your feedback. > Jon says we should get t-shirts made, "I vote for two buttons". =) > > For argument's sake, let's call the two approaches the "dismiss" way and > the "cancel" way. I'm leaning towards the "dismiss" way (keeping the > uploaded files ... and even labeling the button Dismiss or Close rather > than Cancel) for the following reasons: > > *1) From the users' perspective: *Daphne's use cases are valid; I've had > some friends say they expect to see none of the files. But I've also > talked to others who said they would expect the uploaded whole files to > stay. > Here are some of the responses I got from talking to users: > > /"I'd be annoyed if I took a long time to upload lots of files and there > was only one or two that was a mistake. *I would rather have left the > ones that are already uploaded and delete the wrong one instead of > starting all over again*"/ > / > / > / "If I *wanted to cancel the entire upload* (Because I'm uploading it > elsewhere, or someone tells me that the files are no longer needed), I'd > complain that the files are still there."/ > / > / > /"i would expect cancel to stop the uploads that are happening and stop > the uploads that haven't happened yet. *i would *never* expect cancel to > touch completed uploads*"/ > / > / > /"if they're independent files, *whatever whole file is already uploaded > should stay uploaded*"/ > / > / > It seems that if we support the Dismiss way, everyone would be > relatively happy. Even the user who wants to stop now and start over > again later, can do just that. if they select to upload the same batch > of files later, it will just overwrite whatever is already there. If > they don't want some of them, they can simply delete the files from the > file manager. No harm done. > > *2) From the development perspective:* I'd imagine it's probably easier > and cheaper to keep the upload component simple and separate from file > management component. > > Right now, I think it makes most sense to keep the files already > uploaded and let the file management component handle the delete. We can > always validate this through user testing later. :) > > Erin > > > > > On 22-May-08, at 4:58 PM, Ray Davis wrote: > >> In fact, after looking at the (terrific!) current design overview again, >> I wonder if it's worth trying the experiment of removing the >> traditionally form-like "Cancel" (which I'd generally expect to take me >> off the current page to some default place, and which is ambiguous on an >> active AJAX-y component embedded in some larger context). As an >> alternative, maybe usability-test the usual twins, "Start Uploading" and >> "Stop Uploading"? "Dismiss the current window, doing whatever the >> default behavior is" is handled by the "Done" button, and "Undo all >> changes I've made during this part of my work" still seems a little >> outside the scope of an upload queue manager.... >> >> Just a side-note, the underlying swfupload technology isn't able to >> support a distinction between "stopping" a set of uploads and "pausing" >> a set of uploads. The "cancel" mentioned in its documentation refers to >> a _single_ file (rather than the entire operation), and is equivalent to >> deleting it from the queue. >> >> Best, >> Ray >> >> On 5/22/2008 10:10 AM, Ray Davis wrote: >>> I may have said this before, but I'd recommend keeping the Uploader >>> component for *uploading*, since I think that's the natural scope of a >>> client-side component and will make it easier to drop in for the normal >>> single-file upload (and easier for non-Flash or non-JS environments to >>> fall back to the normal single-file upload). >>> >>> In this case, for example, it makes more sense to me if "Cancel" refer >>> only to uploads that haven't yet executed. It also makes for an easier >>> analogy to multi-downloader tools and components, where cancel as a >>> "Stop all" is very different from "Delete everything I've successfully >>> downloaded." >>> >>> If the application UX calls for a "Cancel" that applies to a longer work >>> flow (e.g., a multi-step addition of files), then the application UI can >>> be designed to deal with it in a less ambiguous fashion, including >>> possibly warning the user that it intends to throw away the already >>> uploaded files (or warning the user that it *doesn't* intend to throw >>> them away). But if we start trying to invent a one-size-fits-all >>> approach without having more real-world clients, I worry that we're >>> likely to guess wrong. >>> >>> Best, >>> Ray >>> >>> On 5/21/2008 8:51 PM, Eli Cochran wrote: >>>> Allison, >>>> Thanks for the input. Just to make things more complicated, we're >>>> hoping that back-end developers will implement a true Cancel, one that >>>> actually deletes the uploaded files, but that'll have to be up to the >>>> back-end developer. So in some cases the Cancel could be a destructive >>>> Cancel and in others it could be a non-destructive Cancel. >>>> In the non-destructive case, I would actually prefer a "Done" button, >>>> as I think that it's clearer that what's happening is that the use is >>>> continuing with whatever files have already uploaded. I think that >>>> it's worth testing. >>>> - Eli >>>> On May 21, 2008, at 6:30 PM, Allison Bloodworth wrote: >>>> >>>>> Very nice job Erin, Daphne & Eli! :) I have a couple small suggestions. >>>>> >>>>> I find the "Cancel" button somewhat ambiguous if users have already >>>>> successfully uploaded some files. I think there has been some >>>>> discussion around this already, but I think it is important to let >>>>> users know what will happen to those already uploaded files if they >>>>> hit 'Cancel.' Perhaps upon hitting Cancel, the user could receive a >>>>> message stating which files have been successfully uploaded, and that >>>>> the upload of the remaining files was canceled? The checkmark after >>>>> the files have uploaded may help the user realize it, but I'm not >>>>> sure that less technically savvy users will understand this. I don't >>>>> think I'd feel sure without checking out the target folder of the >>>>> uploads the first time I used the uploader. >>>>> >>>>> In screen 3.1 I would also probably be a little afraid to even press >>>>> "Cancel" if I wanted to retain the already uploaded files, but didn't >>>>> want to upload any more. I can't think of a great way to alleviate >>>>> this problem, but perhaps re-naming the button in some way, like >>>>> "Cancel uncompleted uploads" (ugh, but that's really what it is) or >>>>> "Cancel remaining uploads" would help? (I know, it's wordy...I can >>>>> think more on this if that would be helpful...) >>>>> >>>>> Cheers, >>>>> Allison >>>>> >>>>> On May 21, 2008, at 9:53 AM, Erin Yu wrote: >>>>> >>>>>> The initial design (version 1) is no longer on the page, because I >>>>>> didn't see a value in keeping it in there (and having a really long >>>>>> page). >>>>>> >>>>>> The first design you see on the page is the latest (version 3). If >>>>>> you scroll down, you'll see the previous design (version 2). Let me >>>>>> go edit the titles to say "New" and "Old". ;) >>>>>> >>>>>> >>>>>> On 21-May-08, at 12:46 PM, Daphne Ogle wrote: >>>>>> >>>>>>> Nice job Erin! I think button workflow we discussed yesterday >>>>>>> works well. >>>>>>> >>>>>>> I got a little confused on the wiki page because it's actually the >>>>>>> first set of designs that are current but the 2nd set says >>>>>>> "Revised Design (version 2)". Should those just be archived at >>>>>>> this point -- or retitled to show they are old? >>>>>>> >>>>>>> -Daphne >>>>>>> >>>>>>> On May 21, 2008, at 9:02 AM, Erin Yu wrote: >>>>>>> >>>>>>>> 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] <mailto:[EMAIL PROTECTED]> >>>>>>>>>>> <mailto:[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] >>>>>>>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>>>>>>> <mailto:[EMAIL PROTECTED]> >>>>>>>>>>>> >>>>>>>>>>>> Software Designer, Fluid Project http://fluidproject.org >>>>>>>>>>>> >>>>>>>>>>>> Adaptive Technology Resource Centre / University of Toronto >>> >>> >> >> _______________________________________________ >> fluid-work mailing list >> [email protected] <mailto:[email protected]> >> http://fluidproject.org/mailman/listinfo/fluid-work > _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
