Image Reorderer protocol ready for review...

Thu Mar 26 16:52:32 UTC 2009

Hello Justin,
    Thanks for writing this up as a bug report under FLUID-1625 
<http://issues.fluidproject.org/browse/FLUID-1625>.  I didn't experiment 
with the different grab points on the image I was moving -- I remember 
that being significant the last time we were trying to corner this sort 
of bug with the reorderer.  I don't know if it is still a factor.

It was an interesting exercise to solve the puzzle from the "user 
testing" point of view, but I did try to characterize the behaviour well 
enough for a future regression test.

Regards,
Paul

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 alway em 
>> 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 m 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 ating 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 k 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:
>>>
>>>    1. When I move things /up/, the position of the *target* tells me
>>>       where they will fall.
>>>    2. 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 wind 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 f To unsubscribe, change 
>>>> settings or access archives,
>>>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>>
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at fluidproject.org 
>>> <mailto: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 <mailto:abloodworth at berkeley.edu>
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090326/33eb38b3/attachment.html>