Portlet drag and drop

[John Norman]

This looks good to me.

John

On 13 May 2008, at 16:47, Erin Yu wrote:

> 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).
>
> <Picture 44.png>
>
>
> 2. I start dragging. The default size drop target (smaller than the  
> original Mobile Uploads box) is shown, and other portlets shift up.
>
> <Picture 45.png>
>
>
> 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.
>
> <Picture 46.png>
>
>
> 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.
>
> <Picture 47.png>
>
>
> 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
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work