Reorderer behaviour -- more discussion
Paul.Zablosky at ubc.ca
Wed Sep 10 16:51:16 UTC 2008
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,
> I have actually filed this as a bug Fluid-1335
> It would be interesting to see which implementation users prefer.
> 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.
>> Gary Thompson wrote:
>>> 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.
>>> 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,
>> fluid-work mailing list
>> fluid-work at fluidproject.org
More information about the fluid-work