Draft Uploader Design
Ray Davis
ray at media.berkeley.edu
Fri May 23 20:56:40 UTC 2008
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
>>>>>>>>>>> <erin.yu at utoronto.ca <mailto: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>
>>>>>>>>>>>> <mailto: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 <mailto:fluid-work at fluidproject.org>
>> http://fluidproject.org/mailman/listinfo/fluid-work
>