Draft Uploader Design
Allison Bloodworth
abloodworth at berkeley.edu
Fri May 23 21:33:49 UTC 2008
Hi all,
This is definitely complicated. :)
First, I hadn't even noticed the white close "X" on the mock-ups
initially. Since that button doesn't even have words on it I think it
would be very difficult for the user to guess what will happen to the
files if it's clicked (e.g. will it leave already uploaded files or
remove uploaded files?). They might even think if they use the "X" to
close the window the upload will continue in the background--very
dangerous! The user is also in sort of a wizard mode and they system
need more information from users about what they really want to do
before ending the process. For these three reasons (plus the fact
that if we keep the Cancel button, it's redundant), I'd suggest
removing the close "X" button.
To me, the big question is how can we support what users want to do
while making sure the system match their mental model of the
interaction will be and giving them good feedback on what has
happened. The comments of Erin's users illustrates the fact that
users have different interpretations of just the word 'Cancel.' Some
users think it 'Cancels' the entire upload process (and the upload
'process' consists of many files). Hence, if the entire upload
process is canceled none of the files should remain on the server.
Others think of it as uploading a series of files. This is also the
implementation model, and we illustrate this with a progress bar
letting users know which files are uploaded, as well as with the
green checkmarks when a file is uploaded. Those users would probably
interpret 'Cancel' as canceling any uncompleted uploads. Both users
have valid viewpoints, so it's up to us to make it clear what is
happening.
Keeping the uploaded files (Erin's "dismiss" process) is definitely
the safer way to go, but it doesn't help users who don't understand
that's how it will work (because they may be afraid to press
"Cancel"). Additionally, Eli confirmed my suspicion that we can't
guarantee that in that situation the files will be overwritten, as
that is completely up to the developer (e.g. they might create a new
version of the file, with "-1" appended or something). Plus, if the
files are large, users will not want to wait through all the same
uploads *again* if they don't have to. So how do we let users know
what is really happening so they don't have to deal with any of this?
For me, the best solution is to label the button with what it will
really do, e.g. "Cancel incomplete uploads" so users can clearly
understand it before they click it, *and* realize it's an option that
will help them. I don't think "Dismiss" would work as a button name
because users may think they are just dismissing the window and that
the process is continuing. I also don't think changing the "Cancel"
button to a "Done" button (while keeping the "Pause" button as well)
immediately after some files have uploaded is a good idea because
users may not notice all the files have uploaded and press "Done"
early, causing some of their files to not be uploaded.
One other thing that I think would really help users understand that
files are being uploaded one-by-one would be to put a header over the
column with the green checkmarks that says "Complete?"
Cheers,
Allison
On May 23, 2008, at 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>>
>>>>>>>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080523/27fb32b4/attachment.html>