Portlet drag and drop

Tue May 13 15:47:27 UTC 2008

Hi Michelle/Allison,

Gary, Michelle and I had a discussion about the size of the drop  
target earlier. Here's what we talked about:

Though iGoogle handles this aspect (drop target being the exact same  
size as the portlet being dragged) very nicely, their columns are all  
the same widths, in which case the implementation is considerably  
easier.

Facebook has two columns with different widths. They use a fixed  
default size drop target for the wider column, and a fixed default for  
the narrower column. Once you pick up a portlet to start dragging, the  
default drop target starts showing and things shift immediately (the  
default drop target is in most cases smaller than the actual portlet  
you are moving). When you drop the portlet, things shift a bit more to  
adjust, and it doesn't feel strange at all.

The following screenshots illustrates how it works in Facebook:

1. I'm going to move the Mobile Uploads box. My mouse is over its  
header (I couldn't get the cursor to be in the screenshot).

2. I start dragging. The default size drop target (smaller than the  
original Mobile Uploads box) is shown, and other portlets shift up.

3. I drag it over to the narrower column. The default drop target for  
the narrower column is now shown. The avatar of the portlet being  
dragged does not change.

4. I let go, and the contents of the Mobile Uploads portlet adjust  
itself in the narrower column. The resulting portlet is longer than  
the drop target that was shown previously, but it doesn't seem  
unnatural.

This approach potentially will save a lot of development hours while  
still providing a smooth interaction.

Erin

On 12-May-08, at 5:16 PM, Allison Bloodworth wrote:

> Hi Michelle,
>
> Thanks very much for creating this mock-up! I am guessing this is  
> something that you're probably still working on, but one other  
> important piece of the interaction (which may be a little hard to  
> see in the current mock-ups) is that the drop target avatar should  
> be the same size that the dragged portlet will be when it's dropped.  
> The size may change when the portlet is moving from a larger to  
> smaller column or vice versa. This 'true to life' size is what gives  
> users the 'layout preview' of what the page will look like after the  
> portlet is dropped.
>
> Cheers,
> Allison
>
> On May 1, 2008, at 10:40 AM, Michelle D'Souza wrote:
>> Thanks for taking a look at this Herb.
>>
>>> .One recommendation - when I drag the weather portlet, for example,
>>> upwards to move it above the calendar on your test page, the
>>> calendar stays where it is; it does not move down until you let go
>>> of the weather box. Would it not be more obvious where the drop
>>> location was going to be if the calendar portlet moved down as you
>>> started dragging the weather portlet up, leaving an empty space
>>> between the two for the drop?
>>
>> I'm a little confused by this. Once the weather portlet is high  
>> enough
>> that it would drop above the calendar, the calendar does move down  
>> and
>> the empty box which signifies where the weather portlet would drop is
>> placed above the calendar.
>>
>>> Obviously this approach has the disadvantage of losing the visual
>>> cue for the original location of the weather portlet
>>
>> I think the design that is being worked out actually involves  
>> removing
>> this visual cue - I just didn't get around to mocking it up.
>>
>>> (I also exper!
>>> ienced some intermittent flashing of background items when a portlet
>>> is being slowly dragged that is a bit distracting and might confuse
>>> those with certain visual or cognitive disabilities.)
>>>
>>
>> The flashing you are seeing is a combination of two known bugs:
>> FLUID-407 and FLUID-563. This is a major problem and a blocker for  
>> the
>> 0.3 release.
>>
>> Michelle
>>
>> ------------------------------------------------------
>> Michelle D'Souza
>> Software Developer, Fluid Project
>> Adaptive Technology Resource Centre
>> University of Toronto
>>
>>
>>
>> _______________________________________________
>> 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
>
>
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080513/d352832d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 44.png
Type: image/png
Size: 193427 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080513/d352832d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 45.png
Type: image/png
Size: 203557 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080513/d352832d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 46.png
Type: image/png
Size: 206618 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080513/d352832d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture 47.png
Type: image/png
Size: 182364 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080513/d352832d/attachment-0003.png>