Reorderer behaviour -- more discussion

Justin justin.obara at
Thu Sep 11 12:26:29 UTC 2008

Hi Allison,

Just to let you know the first one already has a bug filed for it,  
Fluid-1334 (

Feel free to leave comments on the issue.
Currently the priority is set to minor. Should it be made higher?


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 worked for me: 
> .
> 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
>>> (
>>> 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:
>>>>> Three comments:
>>>>> 1. Context is king.
>>>>> How drag and drop behaves will be specific to context.  The  
>>>>> examples
>>>>> on the Layout Customizer springboard:
>>>>> ...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:
>>>> 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 <> 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
>>>>>> <> -- 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
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at
> Allison Bloodworth
> Senior User Interaction Designer
> Educational Technology Services
> University of California, Berkeley
> (415) 377-8243
> abloodworth at

More information about the fluid-work mailing list