Reorderer behaviour -- more discussion

Paul Zablosky Paul.Zablosky at ubc.ca
Wed Sep 10 22:26:44 UTC 2008


Allison,
    I see what you mean about the avatar shrinking, and leaving the 
pointer outside its boundaries.  I think this may be what issue 
Fluid-1334 <http://issues.fluidproject.org/browse/FLUID-1334> refers 
to.   I agree that if a portlet shrinks when picked up, it should 
"shrink around" the pointer. 

The whole idea of the avatar shrinking when the object is grabbed seems 
to me to be useful.  Any object that is big and unwieldy can shrink to a 
more compact image of itself while being dragged.  The drop target can 
indicate the size of the space the portlet will occupy in its new 
location, giving the user an idea of how the move will affect the 
appearance of the layout. Again, a round of user testing could probably 
tell us whether this makes sense or not.

Regards,
Paul

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080910/52c673dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 360201 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080910/52c673dd/attachment.jpe>


More information about the fluid-work mailing list