Reorderer behaviour -- more discussion

Paul Zablosky Paul.Zablosky at
Wed Sep 10 16:51:16 UTC 2008

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,

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

More information about the fluid-work mailing list