Draft Uploader Design

[Ray Davis]

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 <erin.yu at utoronto.ca 
>>>>>>>>> <mailto: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 
>>>>>>>>>> <mailto:a.cheetham at utoronto.ca>
>>>>>>>>>>
>>>>>>>>>> Software Designer, Fluid Project    http://fluidproject.org
>>>>>>>>>>
>>>>>>>>>> Adaptive Technology Resource Centre / University of Toronto
> 
>