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 >>> [email protected] >>> http://fluidproject.org/mailman/listinfo/fluid-work >> >> Allison Bloodworth >> Senior User Interaction Designer >> Educational Technology Services >> University of California, Berkeley >> (415) 377-8243 >> [EMAIL PROTECTED] >> >> >> >> >> _______________________________________________ >> fluid-work mailing list >> [email protected] >> http://fluidproject.org/mailman/listinfo/fluid-work > > _______________________________________________ > fluid-work mailing list > [email protected] > http://fluidproject.org/mailman/listinfo/fluid-work _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
