Reorderer behaviour -- more discussion

Allison Bloodworth abloodworth at berkeley.edu
Wed Sep 17 01:45:43 UTC 2008


Hi Justin,

Thanks for letting me know that FLUID-1134 already covers this issue-- 
I added a short comment. I *would* suggest making the priority of this  
issue higher, as I think some of the problems we saw users have with  
moving portlets around in user testing stemmed from this issue.

Thanks!
Allison

On Sep 11, 2008, at 5:26 AM, Justin wrote:

> Hi Allison,
>
> Just to let you know the first one already has a bug filed for it,  
> Fluid-1334 (http://issues.fluidproject.org/browse/FLUID-1334).
>
> Feel free to leave comments on the issue.
> Currently the priority is set to minor. Should it be made higher?
>
> Thanks
> Justin
>
> On 10-Sep-08, at 4:03 PM, Allison Bloodworth wrote:
>
>> Hi all,
>>
>> Sorry for the delayed response--I was having some trouble testing  
>> this because the link for the uPortal version of the layout manager  
>> Gary references below seems to be broken. However, the version of  
>> uPortal linked off of build.fluidproject.org worked for me: http://build.fluidproject.org/fluid/sample-code/reorderer/portal/portal.html 
>> .
>>
>> First, thanks very much Paul for making this problem concrete. I  
>> agree with you that the drop target should key off of the entire  
>> object, not just the pointer. Thinking back, I actually think some  
>> of the difficulties our users ran into during testing (e.g dragging  
>> a portlet *really* with their mouse far to get it to drop) may have  
>> had to do with this.
>>
>> While checking this problem out, I also ran into another related  
>> problem with pointer position which may require the entering of  
>> another bug or two (though I think one or both of the bugs *may* be  
>> in uPortal?).
>>
>> If the calendar portlet starts on the left column, and I grab its  
>> "handle" on the right side near the red X, the screenshot below  
>> shows what happens. *As soon as I pick it up*, it shrinks and the  
>> pointer sort of floats in mid-air, not attached to the avatar at  
>> all. I originally thought this only happened when moving a portlet  
>> from a larger to smaller column (hence that is what my screenshot  
>> is of), but realized that the portlet shrinkage actually occurs as  
>> soon as you pick up this portlet, even if it remains in the left  
>> column.  This makes the interaction very clunky.
>>
>> So I think there are two new bugs:
>>
>> 1) If the portlet shrinks when picked up, the avatar should shrink  
>> towards the pointer so it remains "attached" to the pointer.
>> 2) When a portlet is picked up it should remain the size of the  
>> column its in and only re-size when it moves to a smaller column.
>>
>> Gary & Paul (& others), do you think either of these are uPortal  
>> issues? Does it make sense to enter them as bugs (either for  
>> uPortal or Fluid)?
>>
>> Cheers,
>> Allison
>>
>> <LayoutCustomizerPointerBug.jpg>
>> On Sep 10, 2008, at 9:51 AM, Paul Zablosky wrote:
>>
>>> Hello Justin,
>>>  Yes, it will be interesting to see how the users react.  I suspect
>>> that the current behaviour accounts for some of the users' responses
>>> during early testing.
>>> Thanks and regards,
>>> Paul
>>>
>>> Justin wrote:
>>>> Hello,
>>>>
>>>> I have actually filed this as a bug Fluid-1335
>>>> (http://issues.fluidproject.org/browse/FLUID-1335).
>>>>
>>>> It would be interesting to see which implementation users prefer.
>>>>
>>>> Thanks
>>>> Justin
>>>>
>>>> On 9-Sep-08, at 2:55 PM, Paul Zablosky wrote:
>>>>
>>>>> Thank you Gary.  One of the problems with this issue, is that we
>>>>> don't really have a way to do comparison testing with users.  Now
>>>>> that we're discussing this in the open fluid-work list, I can  
>>>>> put a
>>>>> question directly to the developers:
>>>>>
>>>>> Would it be possible to create a version of the reorderer that  
>>>>> sets
>>>>> the position of the drop target not with reference to the pointer
>>>>> position, but with reference to the centre of gravity of the  
>>>>> avatar?
>>>>> Since the avatar and pointer are locked together during the drag,
>>>>> this would seem to me to be a simple fixed translation of
>>>>> coordinates, but I don't know enough about the implementation  
>>>>> details
>>>>> to guess if it's easy or difficult.  Anyway, if we had such a  
>>>>> thing,
>>>>> we could easily do user testing to find out which they preferred:
>>>>> targets that move with the pointer
>>>>> targets that move with the centre of the avatar
>>>>> I'm suggesting using the centre as tracking point, simply because
>>>>> it's the most obvious alternative to following the cursor  
>>>>> position.
>>>>> There may be other loci that could be considered.
>>>>>
>>>>> I'll respond to Gary's responses within his message below.
>>>>>
>>>>> Paul
>>>>>
>>>>> Gary Thompson wrote:
>>>>>>
>>>>>> Paul,
>>>>>>
>>>>>> I'm cc'ing fluid-work so everyone can appreciate the questions  
>>>>>> and
>>>>>> digest the responses.
>>>>>>
>>>>>> Great questions.  The goal is to create an intuitive, elegant
>>>>>> design, so questioning the behavior is warranted if it seems to  
>>>>>> not
>>>>>> match your expectations.
>>>>>>
>>>>>> As Colin mentioned, the Reorder - and thus the Layout  
>>>>>> Customizer -
>>>>>> are currently moving targets.  The target movement was initiated
>>>>>> from the user testing done on the first integration environment,
>>>>>> which reported unusable response and behavior.  Refer to the user
>>>>>> testing results:
>>>>>> http://wiki.fluidproject.org/x/2Ys7
>>>>>>
>>>>>> Three comments:
>>>>>>
>>>>>> 1. Context is king.
>>>>>> How drag and drop behaves will be specific to context.  The  
>>>>>> examples
>>>>>> on the Layout Customizer springboard:
>>>>>> http://build.fluidproject.org/fluid/fluid-components/html/LayoutCustomizer.html
>>>>>>
>>>>>>
>>>>>> ...actually represent something closer to list reordering,  
>>>>>> which by
>>>>>> context will have a different behavior.  What most currently
>>>>>> represents the Layout Customizer, is the uPortal integration  
>>>>>> here:
>>>>>> http://build.fluidproject.org/uPortal/ 
>>>>>> render.userLayoutRootNode.uP
>>>>> I totally agree that context is king.  That's why I tried out  
>>>>> all the
>>>>> different examples of the reorderer on the demos page.  I found  
>>>>> that
>>>>> I had the same difficulty with all of them,  which led me to think
>>>>> that the problem was below the application level.
>>>>>>
>>>>>> 2. The grab handle can be defined.
>>>>>> And is defined to be just the portlet title bar in the Layout
>>>>>> Customizer integration in uPortal (rather than the whole  
>>>>>> portlet).
>>>>>> This should help alleviate the confusion of location of the drag
>>>>>> avatar to cursor, though we may find in further testing that  
>>>>>> that is
>>>>>> still an issue.
>>>>> Yes, I noticed this.  It's harder to demonstrate with the Layout
>>>>> Customizer because the grab area is smaller.  But you can show the
>>>>> effect by grabbing at the left or right end of the grab area.  The
>>>>> behaviour of the drop indicator is more consistent with a limited
>>>>> grab area, but it still feels strange if the grab area is at the  
>>>>> edge
>>>>> of the element I'm grabbing.
>>>>>
>>>>> This of course gives us another thing to test.  Do users prefer to
>>>>> have a large area where they can grab an element, or should it be
>>>>> limited to a specific "grab me here" region?
>>>>>>
>>>>>> 3. The drag avatar may need to be minimized in uPortal.
>>>>>> The size of a portlet in uPortal is highly variable, and user
>>>>>> testing has already uncovered the unwieldiness of large portlets
>>>>>> being dragged in a preview mode.  It may turn out that for  
>>>>>> uPortal,
>>>>>> we revert to an earlier design that more closely resembled the  
>>>>>> Yahoo
>>>>>> behavior at the time - a small grey box as the drag avatar, and a
>>>>>> non-preview, colored line as the drop indicator.
>>>>> A smaller avatar might help, but I still think it skirts the  
>>>>> issue of
>>>>> where the drop indicator appears.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> Paul Zablosky wrote:
>>>>>>> I have been playing with the reorderer examples on the daily  
>>>>>>> build
>>>>>>> page <http://build.fluidproject.org/> and getting a feel for the
>>>>>>> behaviour of the avatars and the targets.  The behaviour is not
>>>>>>> quite what I expect as I move things around, and I'm wondering
>>>>>>> whether I'm taking an idiosyncratic view of things.  The  
>>>>>>> problem is
>>>>>>> that the drop target doesn't seem to appear where I expect it  
>>>>>>> to.
>>>>>>> I position the avatar squarely over where I want to move the
>>>>>>> element, and yet the target is one position off to the left  or
>>>>>>> right (or above or below).   I have to move the avatar farther  
>>>>>>> than
>>>>>>> (I feel) should be necessary to get the target to appear where I
>>>>>>> want it. It makes the whole interaction sort of weirdly sticky  
>>>>>>> for
>>>>>>> me.  What it comes down to is that I feel I should be able to
>>>>>>> predict where the target appears, and I can't. At first I  
>>>>>>> thought
>>>>>>> that this was just a performance issue, but now I know what  
>>>>>>> causes it.
>>>>>>>
>>>>>>> Here's the explanation.  What I'm trying to do is position the
>>>>>>> avatar where I want to drop the element, but the target isn't
>>>>>>> following the avatar.  The target follows the /pointer/.  So  
>>>>>>> with a
>>>>>>> fairly large avatar -- such as a portlet window, or  a multi- 
>>>>>>> line
>>>>>>> list element, it makes a huge difference where I grab the  
>>>>>>> element.
>>>>>>> If I grab the top edge of the list element, the target will  
>>>>>>> appear
>>>>>>> in relation to the top edge of the avatar.  If I grab the bottom
>>>>>>> edge, the target follows the position of the bottom.
>>>>>>> But I never pay attention to where I grab the thing.  My eyes  
>>>>>>> are
>>>>>>> tracking the outline of the avatar, and I sort of expect the  
>>>>>>> target
>>>>>>> to appear where I have the avatar centred -- and that's not  
>>>>>>> happening.
>>>>>>>
>>>>>>> So it raises the question in my mind.  Is it just me, or do  
>>>>>>> others
>>>>>>> have the same experience of the movements of the screen  
>>>>>>> objects not
>>>>>>> quite following their expectations?
>>>>>>>
>>>>>>> Of course my experience means nothing.  I know that we can only
>>>>>>> settle an issue like this with user testing.  So here's the real
>>>>>>> question: Do users have the idea that they are influencing the
>>>>>>> position of the drop target by the location of the avatar, or do
>>>>>>> they have the feeling they are shoving it around with the  
>>>>>>> pointer,
>>>>>>> while ignoring the outlines of the avatar?  And do we have any  
>>>>>>> user
>>>>>>> testing results or research data (possibly from some outside
>>>>>>> source) that can tell us this?
>>>>>>>
>>>>>>> I spent a little time this afternoon trying to train myself to  
>>>>>>> be a
>>>>>>> better drag-and-dropper, using the four reorderer examples
>>>>>>> <http://build.fluidproject.org/> -- either centring the pointer
>>>>>>> carefully on the element I'm grabbing, or following the pointer
>>>>>>> image rather than the avatar outline.  I'm learning, but it  
>>>>>>> doesn't
>>>>>>> feel quite natural.
>>>>>>>
>>>>>>> Comments?  Am I marching to a completely off-the-beat drummer  
>>>>>>> here?
>>>>>>>
>>>>>>> Regards to all,
>>>>>>> Paul
>>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> Allison Bloodworth
>> Senior User Interaction Designer
>> Educational Technology Services
>> University of California, Berkeley
>> (415) 377-8243
>> abloodworth at berkeley.edu
>>
>>
>>
>>
>

Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
abloodworth at berkeley.edu







More information about the fluid-work mailing list