Usability questions for Uploader (different issue)

Paul Zablosky Paul.Zablosky at ubc.ca
Fri Jul 18 18:07:54 UTC 2008


+1. I'm in favour of not displaying the Uploader dialog until it 
actually has some files queued for upload.  I did a brief walkthrough of 
a user's first encounter with the Uploader (using the demo) and 
concluded that having both the Uploader and the Browser appear together 
can  be confusing, but there's also really no justification for having 
the Uploader appear first and requiring the user to click the Browser 
into existence.

See the attached PDF for details of the interaction.

While most of the difficulties arise from the intractability of the File 
Browser, I'm not sure we always want to dismiss it at the points 
suggested by Eli's use cases.  In the walkthrough, the user gets things 
working, but arrives at an unnecessarily cumbersome solution -- 
double-clicking on files and repeatedly recalling the File Browser.  Is 
there some way we could avoid this?

Paul

Eli Cochran wrote:
> As I said before, that is fine. There is some additional coding to 
> make the first time through Browsing different depending on whether 
> the Uploader dialog is displayed or not. Also this diverges from the 
> Inline case as well whether the Uploader is not in a dialog but is in 
> a page. 
>
> Uploader in a dialog:
>
> Use Case One:
> - User clicks Add Files...
> - OS File dialog appears
> - User selects files, clicks OK
> - OS File dialog disappears
> - Uploader dialog appears, files are populated to queue
>
> Use Case Two:
> - User clicks Add Files...
> - OS File dialog appears
> - User clicks Cancel
> - OS File dialog disappears
> - Uploader dialog does not appear
>
> Use Case Three:
> - Uploader is alre ser clicks Browse Files
> - User selects files, clicks OK
> - OS File dialog disappears
> - File Queue is updated with new files
>
> Use Case Four:
> - Uploader is already visible
> - User clicks Browse Files
> - User clicks Cancel
> - OS File dialog disappears
> - Nothing happens because no new files have been selected. 
>
>
> Historical context: Originally the OS File dialog did not come up 
> right away because we felt it important to provide the user with some 
> context and some instruction that said that they could select multiple 
> files. We used to display the Uploader first and then the user had to 
> select Browse Files to bring up the OS File dialog. We have since 
> decided that we don't need that context or instruction, so launching 
> directly into the OS File dialog would seem to make sense. 
>
>
> - Eli 
>
>
> On Jul 16, 2008, at 11:43 AM, erin yu wrote:
>
>> I don't think it's a big problem not being able to use the browser 
>> tabs when the OS pop-up is there, because your main task at hand is 
>> to select files. If you want to use other tabs, you can simply cancel 
>> out of the OS pop-up.
>> You'll notice this is how it works uploaders on the web...
>>
>> I wanted to bring up another issue - we had talked about this a while 
>> back but here it is:
>>
>> Currently, clicking on the "Add F e OS popup /on top of /the uploader 
>> dialogue, and the user goes,  "I can see there is something 
>> underneath this pop-up, but I can't see the whole thing. what am I 
>> missing? which one should i be looking at?" 
>>
>> :o)
>>
>> If possible, it would make more sense to display /only/ the OS pop-up 
>> when Add Files is clicked.
>> User wants to upload files --> User clicks on Add files --> User 
>> selects files and clicks ok --> User clicks Upload on the uploader. 
>>
>> Erin 
>>  
>>
>>
>> On 15-Jul-08, at 2:46 PM, Eli Cochran wrote:
>>
>>> The file browsing dialog is controlled by the OS and we can't change  
>>> its behavior.
>>>
>>> - Eli "on vacation" Cochran
>>>
>>>
>>> On Jul 15, 2008, at 1:58 PM, Daphne Ogle wrote:
>>>
>>>>
>>>> On Jul 15, 2008, at iv>
>>>>
>>>>> The pop-up version of the Uploader can be viewed here:
>>>>> http://build.fluidproject.org/fluid/sample-code/uploader/pop-up/index.html
>>>>>
>>>>> The inline version of Uploader can be viewed here:
>>>>> http://build.flu e-code/uploader/inline/index.html 
>>>>> <http://build.fluidproject.org/fluid/sample-code/uploader/inline/index.html>
>>>>>
>>>>> I had two thoughts about the usability of Uploader.
>>>>>
>>>>> 1) The 'Add Files' button remains visible in the pop-up version, as  
>>>>> it
>>>>> is on the same page as the Uploader. This may cause confusion for the
>>>>> user between the 'Ad ge and the 'Browse  
>>>>> Files'
>>>>> button on the Uploader.
>>>>>
>>>>> This may just be an issue with this example (i.e. the integrator may
>>>>> have control over this)
>>>> Good point!  I think this is something the integrator would control
>>>> b a good example.  The Add files button
>>>> should be disabled when the Uploader is initiated.  I'll add something
>>>> to the design pattern where we talk about integration design
>>>> suggestions.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2) After clicking the 'Add Files' button (pop-up version) or 'Browse
>>>>> files" button (both versions) a modal OS file open dialog appears. It
>>>>> makes sense to use a modal dialog here, as the user needs to make a
>>>>> decision on files before continuing the interaction with the  
>>>>> Uploader.
>>>>> However, in a tabbed browsing environment, it will prevent the use of
>>>>> any tabs in the browser. This means that a user who is flipping
>>>>> between  tabs (e.g. to see what is already uploaded and deciding what
>>>>> needs to be), won't be able to.
>>>>>
>>>>> I'm not sure if this is an option or not, it may be that the file  
>>>>> open
>>>>> dialog is only modal.
>>>>> This is a tricky one.  The trade-off to not making the dialog modal is
>>>> the challenge with keeping track of the dialog (it gets hidden behind
>>>> other windows and user loses track of where they were in the process
>>>> for instance).  One of the benefits of the overlay dialog is the user
>>>> isn't forced to leave their context to do the uploading so
>>>> theoretically they can mo be able to see what
>>>> files are already in their current context.
>>>>
>>>> I'd be interested to hear the technical options here.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> Justin
>>>>> _______________________________________________
>>>>> fluid-work mailing list
>>>>> fluid-work at fluidproject.org <mailto:fluid-work at fluidproject.org>
>>>>>
>>>>> <http://fluidproject.org/mailm%0Attp://fluidproject.org/mailman/listinfo/fluid-work%3C/a%3E%3C/div%3E%20%3C/blockquote%3E%3Cdiv%20style=>
>>>>> Daphne Ogle 
>>>>> <http://fluidproject.org/mailm%0Attp://fluidproject.org/mailman/listinfo/fluid-work%3C/a%3E%3C/div%3E%20%3C/blockquote%3E%3Cdiv%20style=>
>>>>> Senior Interaction Designer 
>>>>> <http://fluidproject.org/mailm%0Attp://fluidproject.org/mailman/listinfo/fluid-work%3C/a%3E%3C/div%3E%20%3C/blockquote%3E%3Cdiv%20style=>
>>>>> University of California, Berkeley 
>>>>> <http://fluidproject.org/mailm%0Attp://fluidproject.org/mailman/listinfo/fluid-work%3C/a%3E%3C/div%3E%20%3C/blockquote%3E%3Cdiv%20style=>
>>>>> Educational Technology Services 
>>>>> <http://fluidproject.org/mailm%0Attp://fluidproject.org/mailman/listinfo/fluid-work%3C/a%3E%3C/div%3E%20%3C/blockquote%3E%3Cdiv%20style=>
>>>>> daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
>>>>> cell (510)847-0308
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> fluid-work mailing list
>>>>> fluid-work at fluidproject.org <mailto:fluid-work at fluidproject.org>
>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>
>>>> . . . . . . . . . . .  .  .   .    .      .         .              
>>>> .                     .
>>>>
>>>> Eli Cochran
>>>> ETS, UC Berkeley
>>>>
>>>>
>>>> _______________________________________________
>>>> fluid-work mailing list
>>>> fluid-work at fluidproject.org <mailto: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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080718/8d7e6fa1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FileUploaderTestJuly 15.pdf
Type: application/pdf
Size: 90440 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080718/8d7e6fa1/attachment.pdf>


More information about the fluid-work mailing list