Drag and drop behaviour for the Layout Customizer

[Eli Cochran]

I have always felt that the iGoogle pattern was preferred. It made it  
clearer what the result was going to be on the page. However, there is  
something about the iGoogle pattern that I had never noticed before;  
the column widths are identical.

I actually think that you might have it backwards Colin, that the  
Yahoo pattern is better when the things that are being moved are  
different sizes and shapes, especially when they might end up being  
different sizes and shapes depending on which column they end up being  
dropped into.

I'm just musing here... what would the experience be like in in the  
iGoogle pattern if the avatar had to change dimensions as you dragged  
it around? Or maybe it doesn't and just the outline that shows the  
drop changes dimensions?

I don't have the answer. I know that I like the iGoogle pattern  
better. It gives better feedback, it's cleaner. I have a better sense  
of what the end result will be. But I worry that Yahoo made the choice  
that they made because with panes of irregular dimensions, the other  
pattern just didn't work very well.

- Eli

P.S. I think that we're using the right pattern for the Lightbox  
because there is a difference between changing the composition of a  
page, and re-ordering like-items.

On Apr 16, 2008, at 3:33 PM, Colin Clark wrote:
> Hello designers,
>
> We've been doing a lot of review and testing of the Layout Customizer
> component in preparation for the Fluid Infusion 0.3 release. One of
> the things we've been thinking about is the behaviour of drag and drop
> in this component.
>
> A couple of months ago, Gary and Shaw-Han did a great job of putting
> together some detailed mockups. They're available at:
>
> http://wiki.fluidproject.org/display/fluid/Portlet+Reorderer+Mockups
>
> If you notice, these mockups specify an approach that is very similar
> to myYahoo's news portal, available at http://cm.my.yahoo.com/. The
> noteworthy features of this approach are:
>
>  * the use of a small drag "avatar" (the thing that follows your
> mouse during a drag operation)
>  * a coloured, horizontal bar representing the drop target (the spot
> where the thing will land when you let go of the mouse)
>
> Another approach to drag and drop layouts is documented in the Fluid
> design pattern for Layout Preview:
>
> http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+Layout+Preview
>
> This approach is similar to iGoogle, http://www.google.com/ig.
> Noteworthy features include:
>
>  * the use of a full-sized, transparent drag avatar that shows the
> whole portlet
>  * a full-sized outlined box for the drop target
>  * other portlets on the page shift out of the way to show a
> realistic preview of how the layout will look
>
> What's the best approach? I'm thinking this is one of those "it
> depends" questions. When portlets are similar in size and closely
> spaced, the myYahoo approach is probably simpler and easier to
> control. When portlets are more widely spaced and may have different
> sizes, a full preview of the layout seems more useful.
>
> At the time of the original designs, it's my understanding that we
> went with the myYahoo-style interaction because it was immediately
> similar to some existing code we have in the Reorderer. On the other
> hand, the Reorderer is highly customizable. The dev team tells me that
> implementing both behaviours should be relatively straightforward. It
> may impact our release date a bit, but should we consider taking the
> time to provide an option that will allow for the iGoogle-style of
> preview?
>
> I'd really appreciate opinions and advice from designers in the
> community.
>
> Colin
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley