Reorderer behaviour -- more discussion

Wed Sep 17 12:46:57 UTC 2008

Hello Allison,

I've bumped Fluid-1334 up to critical for now, so that I'll keep it in  
my sights for the bug parade.

Thanks
Justin
On 16-Sep-08, at 9:45 PM, Allison Bloodworth wrote:

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