Draft Uploader Design
Daphne Ogle
daphne at media.berkeley.edu
Thu May 22 17:22:33 UTC 2008
Allison, Eli and I were just talking about this a bit more. We didn't
come up with an agreed upon solution but I thought I'd try to share
the discussion here so others can weigh in. Allison & Eli please add
and/or correct anything that doesn't seem to represent our
conversation (it is my perspective of the conversation :) ).
The main reason for having a cancel action is to allow the user to
stop what they are doing -- and perhaps start over at some later
time. The scenario is, I started an upload and either didn't realize
how much time it was going to take or I get interrupted in the middle
(we know this happens all the time for instructors from research) and
have to run out. At that point I don't even want to have to think
about what actually got uploaded and what didn't. I just want to say
"forget it for now" and I'll come back to it later and start over.
A secondary reason is to allow the user to 'undo' an action they
didn't mean to take (uploading of 1 to all the files). I
We tossed around a couple ideas for how to support this use case
without having a cancel button:
1) Change the label of the button to be more explicit. As Allison
points out it can get very wordy. And even with clearer labeling the
user gets a mixed message since uploaded files have the big green
checkmark next to them. The other concern is what Eli mentions below
-- we are dependent on the component implementor for how the cancel
actually works since it is a back end function. If users *see* the
same uploader in various places they will expect it to work the same.
If it gets implemented differently in different contexts it would just
be plain cruel to the user to have to figure out that it does
different things and different places.
2) Get rid of the cancel button but bring back a file status and a
remove column. Initially we had both columns and in an attempt to
simplify we combined them (even with both columns we weren't allowing
the user to remove individual files so the remove button disappeared
for already uploaded files anyway). We could bring the remove column
back and additionally add a 'remove all' and allow removal of uploaded
files. That would allow the user to undo as much of the upload as
they need to (without going back to the applications context).
There's still the mixed message of the green checkmark but perhaps
having the remove right next to it would make it clearer that you
really can remove this file.
3) Just get rid of the cancel button and assume (hope) that the
implementors do the right thing and allow users to easily manipulate
(delete in this case) the set of uploaded files once they are back in
their app/original context. In our user testing, the majority of
users said they would be too nervous to do anything while the uploader
is working and if they wanted to undo part or all of the upload they
would wait until it was done and delete it from their original
context. This is great and would actually be a fine way to handle
both use cases as long as the newly uploaded files are easy to get
to. What if they already had many files in that context, then they
upload a new group of files which get interspersed throughout the
existing files? The user needs a way to somehow filter all the files
down to the group they just uploaded. The challenge here is that the
component doesn't handle this part of the workflow. It will be left
to the implementor in their context. We can suggest the need to have
this kind of filter in the design pattern and technical documentation
but will all implementors use these references? Is that enough?
4) Justin brought up the idea of having 3 buttons. Erin, Eli and I
also talked about this and decided it got a bit complicated requiring
the user to decide between 3 different buttons. If the buttons are
clear though so the user doesn't have to really think about which one
want than I don't think it complicates things. With this scenario we
are still left with the ambiguity of "cancel" and would probably want
to come up with a more explicit button label.
Okay -- way more than enough to think about. I hope I haven't just
complicated things. As Eli said this morning -- 2 buttons causing so
much trouble!
-Daphne
On May 21, 2008, at 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>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> . . . . . . . . . . . . . . . . . .
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> Eli Cochran
>>>>>>>>> user interaction developer
>>>>>>>>> ETS, UC Berkeley
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Aaron Zeckoski (aaronz at vt.edu)
>>>>>>>> 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
>>>>> fluid-work at fluidproject.org
>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>
>>>> Daphne Ogle
>>>> Senior Interaction Designer
>>>> University of California, Berkeley
>>>> Educational Technology Services
>>>> daphne at media.berkeley.edu
>>>> cell (510)847-0308
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> . . . . . . . . . . . . . . . . . . .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080522/2dec50f7/attachment.html>