Reorderer behaviour -- more discussion

Allison Bloodworth abloodworth at
Wed Sep 10 20:03:52 UTC 2008

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  

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)?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: LayoutCustomizerPointerBug.jpg
Type: image/jpeg
Size: 360201 bytes
Desc: not available
URL: <>
-------------- next part --------------

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