Usability questions for Uploader (different issue)

Eli Cochran eli at media.berkeley.edu
Wed Jul 16 21:41:56 UTC 2008


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 already visible
- User 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.

Although I'm not sure that having the Uploader dialog come up first is  
really such a problem. The user may or may not notice it. And if they  
do, they can always move the OS File dialog out of the way to see what  
it's all about.

- 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 Files" button brings up the 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 7:03 AM, Justin wrote:
>>>
>>>> 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.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 'Add Files' button on the page 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
>>> but our example should set 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 move the overlay around and be able to see  
>>> what
>>> files are already in their current context.
>>>
>>> I'd be interested to hear the technical options here.
>>>>
>>>>
>>>>
>>>>
>>>> Please share your thoughts
>>>>
>>>>
>>>> Thanks
>>>> Justin
>>>> _______________________________________________
>>>> 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
>>
>> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>>
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080716/89edad8d/attachment.html>


More information about the fluid-work mailing list