Drag and drop behaviour for the Layout Customizer

Gary Thompson gary at unicon.net
Tue Apr 22 00:37:06 UTC 2008

The topic of innovation versus convention makes for a spirited 
discussion.  There is great value in thinking strategically as well as 
tactically.  For the topic of behavior of the Layout Customizer, that 
behavior should be thought out on both levels; meaning that tactically 
the behavior must be considered in the present convention in order to 
produce a functioning component for the current environment for which it 
is intended, and that strategically the present convention should be 
questioned to discover opportunity for innovation.

Tactically, and in the context of uPortal, the behavior of the Layout 
Customizer must exist in the convention of tabs, columns, and portlets.  
Even though this is an inherited model, it is a good convention, one 
that is being used (in essence) by all of the examples given: MyYahoo, 
iGoogle, and Facebook.  This form of layout, called the canons of page 
construction <http://en.wikipedia.org/wiki/Canons_of_page_construction>, 
is an even deeper convention than computer screen or Web layouts, drawn 
from the legacy convention of typographical layout dating back to the 
medieval era.  For our Fluid component, I believe the tactical goal is 
to produce the best conventional solution for a canonical grid and where 
there are established design patterns to draw from.

Strategically, as is being done in many other areas of the Web, the 
canonical grid layout may need to be challenged.  Envisioning a "better 
way" will require more than a Fluid component, almost guaranteeing 
fundamental changes to the platforms Fluid is building components for.  
I am not downing such visionary thought, but simply making the point 
that it is for the future as innovation that becomes *good* convention 
usually requires a significant amount of blood, sweat, and tears (and 
sometimes even public ridicule).  Let us envision the future, but let us 
also better the present situation.

Returning to the tactical, let me see if I can address some of the other 
design issues that have come up.

In summary, initial designs for the Layout Customizer were based from 
the Image Gallery Lightbox reorderer as is documented here:

Which indicates layout preview behavior a la iGoogle as documented here:

And overall, this was the preferred behavior.

User testing was done by Barbara Glover and Shaw-Han Liem on a 
development version of the uPortal3 theme in an attempt to get early 
feedback on the design and especially feeling out behavior in regards to 
locked portlets.  The user testing results are documented here:

The three prime issues from user testing were:
1. Realizing that portlets could be dragged
2. Understanding that some portlets may be locked (fixed in the layout)
3. Clear drop target indicator(s)

As has been pointed out, the layout preview behavior falls apart when 
the preview does not portray accurate results.  This becomes a problem 
when the content changes size and shape when moving from one location to 
another.  As was mentioned by others, this can specifically be seen in 
columns of different width.  The information I received from Shaw-Han in 
review of the user testing was that the Fluid component technology could 
not (and no known drag and drop solution could) dynamically 
resize/reshape the contents of the drag avatar as it is dragged to 
different shaped containers.

Additional consideration was needed in that portlets vary greatly in 
size and shape to begin with.  In the layout preview behavior, moving a 
large portlet resulted in contents dropping off the page, obscured drop 
targets, and sometimes jarring content/layout changes.

With these two considerations, it was decided that a smaller drag avatar 
was needed with less (or no) visual preview of the results.  Something 
more akin to the List Ordering drag and drop design pattern and what 
MyYahoo currently uses, as is documented here:

To also address some of the issues with locked portlets, a new set of 
designs was done, documented here:

The thought was to make the first release of the Layout Customizer 
follow the List Ordering behavior and then proceed to solve the Layout 
Preview issues and develop the component to be configurable to either 
List Ordering behavior or Layout Preview behavior in subsequent release.

Both the drag avatar and drop indicator of the current design should be 
refined (color, size, etc.) by further user testing to ensure the 
original three issues are addressed.

The Facebook behavior - especially for messages - should be 
incorporated, and would be a great solution to indicating locked portlets.

I hope that helps clear the fog,


Paul Zablosky wrote:
> I agree John.  My fear was that we could be slipping into a technology 
> focus, and sticking with a model that we simply inherited.  I am 
> suggesting that we take a look at the columnar model of presentation, 
> and decide if it really is user-focused, and that it does add benefit 
> to both the viewing and customizing of the page.  If we convince 
> ourselves that it does, based on good evidence, and/or 
> well-established design principles, we should continue to work with 
> it. If not, then we should consider the pros and cons of the alternatives.
> A lot of work was done in the early days of windowing system on just 
> this sort of problem.  We had tiling competing with stacking, and all 
> sorts of dashboard approaches.  If we think of portlet windows like we 
> do desktop windows, what should be the organizing constraints, and 
> what should be free for customization? 
> Paul
> John Norman wrote:
>> I believe we have slipped into technology focus here rather than user 
>> focus (apologies if I am wrong). A portal page is a place where 
>> columns make sense (to me). I think of it like a traditional (e.g. NY 
>> Times) newspaper. Many years have gone into developing presentations 
>> that get a lot of information onto a page in a readable way. Columns 
>> help here. In other situations, the page layout may want to be more 
>> flexible as Paul suggests, e.g. placing functional fragments (a 
>> discussion thread, or an assignment in education examples) into a 
>> page of text or text and images. The placing of images in a word 
>> document is a simple and well known example. In this case, there are 
>> other considerations such as how the text flows around the dropped 
>> object. Is this still the same process and should it use the same 
>> technology (code)? I suspect there would be value in reusing code but 
>> it might really be a different design pattern. 
>> My 2 cents
>> John
>> PS we definitely want the 'variable size/shape organised on a canvas' 
>> use-case for Sakai page authoring. But this is likely to be different 
>> to the 'dashboard' landing page which most closely corresponds to the 
>> portal (newspaper) use-case. I would imagine Portfolio might be an 
>> example where different sized and shaped boxes arranged on a page 
>> might also make sense.
>> On 18 Apr 2008, at 23:56, Paul Zablosky wrote:
>>> Allison,
>>>     Your discussion of the columns of different widths prompts me to 
>>> question the whole notion of having colums, and what their value is 
>>> to the user.  With the original uPortal customization tools, columns 
>>> provided a crude organization of the display -- allowing users to 
>>> move portlet windows left or right by shifting them to the next 
>>> column.  But with drag and drop the user can move the portlet 
>>> through a continuous space, dropping it anywhere, and columns become 
>>> less useful as a page organization model.  As for columns that are 
>>> narrower than the portlet, we should remember that the user can 
>>> adjust the column widths -- so is there a reason to restrict the 
>>> user from dropping a portlet in a column that is too narrow?  She 
>>> can always adjust the column width and retry the drag-and-drop -- so 
>>> why would we make extra work for her?  Tangentially, we should 
>>> remember that it's possible to resize the portlet width -- dropping 
>>> it into a too-narrow column could just make it skinnier -- and this 
>>> could be reflected in the dimensions of the avatar (the avatar would 
>>> get narrower if it moved to a narrower column).
>>> I suppose what I'm suggesting here is that before we get caught up 
>>> in how to deal with procrustean columns, we should think about just 
>>> what the column convention is useful for, and how much of it we need 
>>> to maintain. Right now portlet coordinates are column number and 
>>> ordinal position, but does it have to be that way?  And right now 
>>> column boundaries are the way the user says "I want everything over 
>>> here to be just this wide, and no wider", but it's worth questioning 
>>> just what this means from the user's viewpoint.
>>> The layout of boxes you show below doesn't fit into columns, but it 
>>> may make sense to the user.  So what is our reason for prohibiting 
>>> it?  I feel that having some sort of grid that portlets can  snap to 
>>> makes sense, just to help the user make the layout look regular on 
>>> the screen, but your example suggests that simple columns may be 
>>> both more restrictive and more cumbersome than is necessary.
>>> Paul
>>> Allison Bloodworth wrote:
>>>> Hi there, 
>>>> I definitely believe that we should support the i-Google style 
>>>> preview that our 'drag and drop layout preview' pattern supports. 
>>>> However, I had also not noticed before that (as Eli pointed out) 
>>>> the iGoogle portlets are all the same size. If this pattern is used 
>>>> for columns with different widths, I'm guessing this may complicate 
>>>> things from both a coding and user perspective. For instance, how 
>>>> do you clearly tell a user that they cannot drag a portlet from a 
>>>> wider column into a narrow column? It may be that there would be 
>>>> enough feedback with the fact that a drop target did not appear, 
>>>> but that would be something I think we should user test. Another 
>>>> question would be whether we even want to prevent that 
>>>> interaction...should users be able to drag portlets around without 
>>>> worrying about column width? I'm guessing the coding for this could 
>>>> be complicated. This could result in a page like this:
>>>> <mime-attachment.png>
>>>> ...but perhaps there *may* be contexts where this would make sense 
>>>> (e.g. users organizing piles of photos if the Gallery every 
>>>> implements this). I did a bit of searching on the web and it seems 
>>>> like not too many portals (or design patterns) are dealing with at 
>>>> least *moveable* portlets of differing widths yet, so this is 
>>>> probably something that deserves more thinking and then inclusion 
>>>> in our design patterns.
>>>> I had also been a bit confused by what was described as the more 
>>>> "Yahoo!-style" interaction our Layout Customizer displayed, as I 
>>>> hadn't been too involved in the Layout Customizer design process 
>>>> and actually hadn't seen a (in the process of being dragged) 
>>>> portlet avatar represented as a very small box before. Today I 
>>>> realized why--*Yahoo! has apparently recently changed this 
>>>> interaction in their portal*, though their drag-and-drop modules 
>>>> Design Pattern has *not* been updated to reflect 
>>>> it: http://developer.yahoo.com/ypatterns/pattern.php?pattern=dragdropmodules#. 
>>>> If you hit "play" you will see that a half tone avatar is still 
>>>> used here, as opposed to the very small box representing the 
>>>> portlet which Layout Customizer (and My Yahoo!) is currently using. 
>>>> This is the interaction I was more familiar with, and is 
>>>> represented by our Drag-and-drop List Ordering Pattern 
>>>> (http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+List+Ordering).
>>>> I had a short conversation with Gary about this a few weeks ago, 
>>>> and he said that after the usability testing done on a more 
>>>> i-Google-like implementation:
>>>> "One of the main concerns was keeping the drag avatar the same size 
>>>> as the original portlet.  With potentially very large portlets, 
>>>> there were usability issues with having such a huge drag avatar, 
>>>> jerk-like shifting in the page contents on drag, and sometimes 
>>>> obscuring the drop target indicator with the drag avatar."
>>>> It sounds like this could be a real concern, but I'm wondering if 
>>>> using a full-size half-tone avatar (which you can see through, so 
>>>> the drop target is visible), which both Yahoo!'s *design pattern* 
>>>> (not portal) and iGoogle use, might mitigate this problem in a more 
>>>> effective way. This could be backed up by user testing, but I am 
>>>> worried that users will not be able to see or understand the 
>>>> interaction of a very small avatar, which they may not clearly be 
>>>> able to understand is a representation of the portlet they are 
>>>> dragging (because it is difficulty to make that mapping and is 
>>>> likely not in accord with the user's mental model of what a portlet 
>>>> looks like). With an avatar that is the same size which immediately 
>>>> moves from the original spot when the user begins to drag it, the 
>>>> mapping is much more clear.
>>>> I had also suggested to Gary that we make our drop target color 
>>>> very different from the portal's theme colors (e.g. make it green) 
>>>> to ensure users could see it. I would also recommend including this 
>>>> info in the design pattern.  Also, I thought the way the drop 
>>>> target is placed right next to a portlet without any padding makes 
>>>> it harder to see. I'd like to see it spaced about halfway between 
>>>> the portlets in between which it is indicating a drop target.
>>>> After we figure out what to do with the portlet avatar styling for 
>>>> the Layout Customizer if anyone is up for thinking through some of 
>>>> this and updating the design patterns with me, let me know.
>>>> Thanks!
>>>> Allison
>>>> On Apr 16, 2008, at 4:54 PM, Daphne Ogle wrote:
>>>>> Thanks Colin!
>>>>> Looking at the results it does look like users had difficulty  
>>>>> understanding where the portlet would land based on the summary:
>>>>> "Drop Target Indicators:
>>>>>      * Green bar is too small and not being noticed enough.
>>>>>      * Maybe make it thicker and with an arrow indicating where  
>>>>> portlet will go."
>>>>> Perhaps we could include the bar and make it thicker along with the  
>>>>> igoogle dotted outline pattern?  Not being involved in the testing,  
>>>>> it's difficult to understand exactly where the hang up was for  
>>>>> participants.
>>>>> It looks like the link is broken to the original designs (off the  
>>>>> testing page Colin identified below).   Assuming we have it 
>>>>> someplace,  
>>>>> we could do some additional testing with the new design and an 
>>>>> updated  
>>>>> version of the old one.  Since so much changed between designs I'm  
>>>>> concerned that testing just the new design won't give us very good  
>>>>> comparison information.
>>>>> That said, our current iteration is very full so we could sure use  
>>>>> some volunteer help doing the testing if we decide to go that 
>>>>> route?   
>>>>> And takers?  We could do pretty low intensive "hallway" testing so I  
>>>>> wouldn't expect it to take more than a day but we'd have to look 
>>>>> at it  
>>>>> closer to see what is required.
>>>>> -Daphne
>>>>> On Apr 16, 2008, at 4:38 PM, Colin Clark wrote:
>>>>>> Daphne,
>>>>>> Sorry for the confusion; we haven't renamed all the wiki pages to  
>>>>>> reflect the new Layout Customizer name. The user test results are  
>>>>>> located here:
>>>>>> http://wiki.fluidproject.org/display/fluid/Portlet+Layout+Manager+Results
>>>>>> The results, as I read them, suggest that some participants had  
>>>>>> difficulty determining exactly where their portlet would land. On  
>>>>>> the other hand, this test was performed with a prerelease version 
>>>>>> of  
>>>>>> the component that was a bit buggier in some respects.
>>>>>> Hope this helps,
>>>>>> Colin
>>>>>> On 16-Apr-08, at 7:33 PM, Daphne Ogle wrote:
>>>>>>> Does anyone know where the user testing results for the layout  
>>>>>>> customizer are?  There doesn't seem to be a link off the main page  
>>>>>>> for the component and I haven't had luck with search (probably  
>>>>>>> don't know what terms to use).
>>>>>>> Thanks!
>>>>>>> -Daphne
>>>>>>> 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 <mailto:fluid-work at fluidproject.org>
>>>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>> Daphne Ogle
>>>>>>> Senior Interaction Designer
>>>>>>> University of California, Berkeley
>>>>>>> Educational Technology Services
>>>>>>> daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
>>>>>>> cell (510)847-0308
>>>>>> ---
>>>>>> Colin Clark
>>>>>> Technical Lead, Fluid Project
>>>>>> Adaptive Technology Resource Centre, University of Toronto
>>>>>> http://fluidproject.org
>>>>> Daphne Ogle
>>>>> Senior Interaction Designer
>>>>> University of California, Berkeley
>>>>> Educational Technology Services
>>>>> daphne at media.berkeley.edu <mailto:daphne at media.berkeley.edu>
>>>>> cell (510)847-0308
>>>>> _______________________________________________
>>>>> fluid-work mailing list
>>>>> fluid-work at fluidproject.org <mailto: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 <mailto: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 <mailto: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

More information about the fluid-work mailing list