Fwd: Image Reorderer protocol ready for review...

Thu Mar 26 18:44:46 UTC 2009

FYI -- Looks like the Image Reorderer is not ready for user testing.   
We could include the Layout Reorderer in testing...

Testing:  http://wiki.fluidproject.org/display/fluid/Layout+Reorderer+User+Testing+-+Round+4
Component Design Page:   http://wiki.fluidproject.org/display/fluid/Layout+Reorderer+Design+Overview

If that makes sense to you, I'll need to do a little work to the  
protocol.  It's in pretty good shape as I worked on it recently but  
then abandoned since we weren't going to test it.   I think it would  
be a good one to include in accessibility testing, particularly since  
it is included in the current uPortal release and is being used in the  
3akai concept project.

Let me know what you think.

-Daphne

Begin forwarded message:

> From: Daphne Ogle <daphne at media.berkeley.edu>
> Date: March 26, 2009 11:34:58 AM PDT
> To: Justin <justin.obara at utoronto.ca>
> Cc: Allison Bloodworth <abloodworth at berkeley.edu>, Paul Zablosky <Paul.Zablosky at ubc.ca 
> >, Fluid Work <fluid-work at fluidproject.org>
> Subject: Re: Image Reorderer protocol ready for review...
>
> Thanks all for finding this!  I think this bug is significant enough  
> (basically the user can't complete their task) that we won't want to  
> do any user testing until it is fixed.  I'll make a note on the  
> testing page and add a comment to the bug so when it gets fixed we  
> remember to double back and do some testing.
>
> -Daphne
>
> On Mar 26, 2009, at 5:39 AM, Justin wrote:
>
>> Hello,
>>
>> Thanks for spotting that bug. I suspect that it is another  
>> occurrence of this issue ( http://issues.fluidproject.org/browse/FLUID-1625 
>>  ), that Eli spotted a while back.
>>
>> I don't think that we'll get to fixing it for the 1.0 release, but  
>> we should try to keep it on our radar for the next one. I'll  
>> comment on the issue with this other means of reproducing it.
>>
>> Thanks
>> Justin
>>
>> On 25-Mar-09, at 8:54 PM, Allison Bloodworth wrote:
>>
>>> Hi Paul,
>>>
>>> I believe you've found a bug! The red drop target should always  
>>> tell users where the item will fall--when it doesn't that's  
>>> definitely a bug. In http://build.fluidproject.org/fluid/sample-code/reorderer/image-reorderer/image-reorderer.html 
>>> , I verified that if I hold an image too far to the right *only  
>>> when moving it downwards* (just like you found) it doesn't drop  
>>> where the red drop target indicates it will.
>>>
>>> This seems like a pretty important bug -- is it something we  
>>> should try to fix before the release?
>>>
>>> Cheers,
>>> Allison
>>>
>>> On Mar 25, 2009, at 5:05 PM, Paul Zablosky wrote:
>>>
>>>> Hi Daphne,
>>>>     I tried to perform the tasks in the Round 1 protocol, and I  
>>>> must say I completely failed at task 2.  Well, not completely,  
>>>> but it took me many minutes to figure out how to perform it  
>>>> reliably.  I'm sure that no tester would have given me enough time.
>>>>
>>>> If I have the fruit images in two rows, it is really easy to move  
>>>> any of the second row images to the centre of the first.  If  
>>>> there are seven images in Row 1, I simply select any second row  
>>>> image and place the target after Row 1, Image 3.  It doesn't  
>>>> matter how the avatar is positioned -- if the target is to the  
>>>> right of Image 3, my selection drops into the middle.  I also  
>>>> notice that the target is a good indicator of which images the  
>>>> one being moved will fall between.  That is, if the target is  
>>>> between the blackberry and cherry, that's where the one I'm  
>>>> moving ends up -- between the blackberry and the cherry.
>>>>
>>>> So far, so good.  My success at moving images from Row 2 to Row 1  
>>>> is so confidence-inspiring that I decide to move an image from  
>>>> Row 1 into Row 2. Should sort of work the same, shouldn't it?   
>>>> (Now I know that it won't  quite be the same, because I know that  
>>>> I'm really operating on a one dimensional list, not a grid.  So  
>>>> things will rearrange themselves to fill gaps, but I let my sense  
>>>> of having learned something in the first trial carry over.)
>>>>
>>>> Now what happens? Well first of all, I find that the position of  
>>>> the target causes rather different behaviour.  If  I place the  
>>>> avatar over the image currently in the centre of Row 2, it  
>>>> doesn't seem to matter which side of it the target is on.  The  
>>>> current centre image moves to the left and the one I'm moving  
>>>> takes the centre position.  So, I sort of know how to get my  
>>>> image into the centre, but I'm totally confused about how to get  
>>>> my image between two others.  The "between-ness" rule I had  
>>>> inferred from the previous trial doesn't work any more.
>>>>
>>>> So I experiment a bit an suddenly find that things aren't  
>>>> dropping where I expect.  I'm totally confused until I notice  
>>>> that the relative positions of the avatar and the target are  
>>>> important with this kind of move (Row 1 to Row 2).  If the centre  
>>>> of the avatar is a bit to the left of the target, the image ends  
>>>> up on the left side, and if it's a little bit to the right, the  
>>>> image ends up on the right side.  The rule I now infer is "the  
>>>> image my avatar is hovering over will scoot to the left, and my  
>>>> image will replace it --  the position of the target doesn't  
>>>> really matter.  This is a lot different from "a gap will open up  
>>>> where the target is now, and my image will go in between".
>>>>
>>>> So I end up with two rules:
>>>> When I move things up, the position of the target tells me where  
>>>> they will fall.
>>>> When I move things down the position of the avatar tells me where  
>>>> they will fall.
>>>> I'd be embarrassed to tell you how long it took me to figure this  
>>>> out.  I hope your test subjects are able to catch on a bit  
>>>> quicker than me.
>>>>
>>>> One other thing I noticed which you may want to control for while  
>>>> testing. If you resize the window so that the rows have an even  
>>>> number of images, the "middle" is less well-defined than if you  
>>>> have an odd number..
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Daphne Ogle wrote:
>>>>>
>>>>> http://wiki.fluidproject.org/display/fluid/Image+Reorderer+User+Testing+-+Round+1
>>>>>
>>>>> Any feedback would be greatly appreciated!
>>>>>
>>>>> 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
>>>>> To unsubscribe, change settings or access archives,
>>>>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>>>
>>>> _______________________________________________________
>>>> fluid-work mailing list - fluid-work at fluidproject.org
>>>> To unsubscribe, change settings or access archives,
>>>> see 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
>>>
>>>
>>>
>>>
>>
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne at media.berkeley.edu
> cell (510)847-0308
>
>
>

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/20090326/d9633e28/attachment.html>