Drag and drop behaviour for the Layout Customizer

John Norman john at caret.cam.ac.uk
Tue Apr 22 19:07:45 UTC 2008

Also worth following developments at www.bbc.co.uk where several ideas  
are being tried...


On 22 Apr 2008, at 01:37, Gary Thompson wrote:

> 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:
> http://wiki.fluidproject.org/display/fluid/Drag+and+Drop
> Which indicates layout preview behavior a la iGoogle as documented  
> here:
> http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+Layout+Preview
> 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:
> http://wiki.fluidproject.org/display/fluid/Layout+Customizer+Results
> 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:
> http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+List+Ordering
> To also address some of the issues with locked portlets, a new set of
> designs was done, documented here:
> http://wiki.fluidproject.org/display/fluid/Layout+Customizer+Mockups
> 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,
> Gary
> 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
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

More information about the fluid-work mailing list