Also worth following developments at www.bbc.co.uk where several ideas are being tried...
John 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 >>>>>>>>> [email protected] <mailto:[email protected] >>>>>>>>> > >>>>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work >>>>>>>> >>>>>>>> Daphne Ogle >>>>>>>> Senior Interaction Designer >>>>>>>> University of California, Berkeley >>>>>>>> Educational Technology Services >>>>>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>>> 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 >>>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>> cell (510)847-0308 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fluid-work mailing list >>>>>> [email protected] <mailto:[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] <mailto:[EMAIL PROTECTED]> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> fluid-work mailing list >>>>> [email protected] >>>>> http://fluidproject.org/mailman/listinfo/fluid-work >>>>> >>>> >>>> _______________________________________________ >>>> fluid-work mailing list >>>> [email protected] <mailto:[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 _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
