Hi Justin, Thanks for letting me know that FLUID-1134 already covers this issue-- I added a short comment. I *would* suggest making the priority of this issue higher, as I think some of the problems we saw users have with moving portlets around in user testing stemmed from this issue.
Thanks! Allison On Sep 11, 2008, at 5:26 AM, Justin wrote: > Hi Allison, > > Just to let you know the first one already has a bug filed for it, > Fluid-1334 (http://issues.fluidproject.org/browse/FLUID-1334). > > Feel free to leave comments on the issue. > Currently the priority is set to minor. Should it be made higher? > > Thanks > Justin > > On 10-Sep-08, at 4:03 PM, Allison Bloodworth wrote: > >> Hi all, >> >> Sorry for the delayed response--I was having some trouble testing >> this because the link for the uPortal version of the layout manager >> Gary references below seems to be broken. However, the version of >> uPortal linked off of build.fluidproject.org worked for me: >> http://build.fluidproject.org/fluid/sample-code/reorderer/portal/portal.html >> . >> >> First, thanks very much Paul for making this problem concrete. I >> agree with you that the drop target should key off of the entire >> object, not just the pointer. Thinking back, I actually think some >> of the difficulties our users ran into during testing (e.g dragging >> a portlet *really* with their mouse far to get it to drop) may have >> had to do with this. >> >> While checking this problem out, I also ran into another related >> problem with pointer position which may require the entering of >> another bug or two (though I think one or both of the bugs *may* be >> in uPortal?). >> >> If the calendar portlet starts on the left column, and I grab its >> "handle" on the right side near the red X, the screenshot below >> shows what happens. *As soon as I pick it up*, it shrinks and the >> pointer sort of floats in mid-air, not attached to the avatar at >> all. I originally thought this only happened when moving a portlet >> from a larger to smaller column (hence that is what my screenshot >> is of), but realized that the portlet shrinkage actually occurs as >> soon as you pick up this portlet, even if it remains in the left >> column. This makes the interaction very clunky. >> >> So I think there are two new bugs: >> >> 1) If the portlet shrinks when picked up, the avatar should shrink >> towards the pointer so it remains "attached" to the pointer. >> 2) When a portlet is picked up it should remain the size of the >> column its in and only re-size when it moves to a smaller column. >> >> Gary & Paul (& others), do you think either of these are uPortal >> issues? Does it make sense to enter them as bugs (either for >> uPortal or Fluid)? >> >> Cheers, >> Allison >> >> <LayoutCustomizerPointerBug.jpg> >> On Sep 10, 2008, at 9:51 AM, Paul Zablosky wrote: >> >>> Hello Justin, >>> Yes, it will be interesting to see how the users react. I suspect >>> that the current behaviour accounts for some of the users' responses >>> during early testing. >>> Thanks and regards, >>> Paul >>> >>> Justin wrote: >>>> Hello, >>>> >>>> I have actually filed this as a bug Fluid-1335 >>>> (http://issues.fluidproject.org/browse/FLUID-1335). >>>> >>>> It would be interesting to see which implementation users prefer. >>>> >>>> Thanks >>>> Justin >>>> >>>> On 9-Sep-08, at 2:55 PM, Paul Zablosky wrote: >>>> >>>>> Thank you Gary. One of the problems with this issue, is that we >>>>> don't really have a way to do comparison testing with users. Now >>>>> that we're discussing this in the open fluid-work list, I can >>>>> put a >>>>> question directly to the developers: >>>>> >>>>> Would it be possible to create a version of the reorderer that >>>>> sets >>>>> the position of the drop target not with reference to the pointer >>>>> position, but with reference to the centre of gravity of the >>>>> avatar? >>>>> Since the avatar and pointer are locked together during the drag, >>>>> this would seem to me to be a simple fixed translation of >>>>> coordinates, but I don't know enough about the implementation >>>>> details >>>>> to guess if it's easy or difficult. Anyway, if we had such a >>>>> thing, >>>>> we could easily do user testing to find out which they preferred: >>>>> targets that move with the pointer >>>>> targets that move with the centre of the avatar >>>>> I'm suggesting using the centre as tracking point, simply because >>>>> it's the most obvious alternative to following the cursor >>>>> position. >>>>> There may be other loci that could be considered. >>>>> >>>>> I'll respond to Gary's responses within his message below. >>>>> >>>>> Paul >>>>> >>>>> Gary Thompson wrote: >>>>>> >>>>>> Paul, >>>>>> >>>>>> I'm cc'ing fluid-work so everyone can appreciate the questions >>>>>> and >>>>>> digest the responses. >>>>>> >>>>>> Great questions. The goal is to create an intuitive, elegant >>>>>> design, so questioning the behavior is warranted if it seems to >>>>>> not >>>>>> match your expectations. >>>>>> >>>>>> As Colin mentioned, the Reorder - and thus the Layout >>>>>> Customizer - >>>>>> are currently moving targets. The target movement was initiated >>>>>> from the user testing done on the first integration environment, >>>>>> which reported unusable response and behavior. Refer to the user >>>>>> testing results: >>>>>> http://wiki.fluidproject.org/x/2Ys7 >>>>>> >>>>>> Three comments: >>>>>> >>>>>> 1. Context is king. >>>>>> How drag and drop behaves will be specific to context. The >>>>>> examples >>>>>> on the Layout Customizer springboard: >>>>>> http://build.fluidproject.org/fluid/fluid-components/html/LayoutCustomizer.html >>>>>> >>>>>> >>>>>> ...actually represent something closer to list reordering, >>>>>> which by >>>>>> context will have a different behavior. What most currently >>>>>> represents the Layout Customizer, is the uPortal integration >>>>>> here: >>>>>> http://build.fluidproject.org/uPortal/ >>>>>> render.userLayoutRootNode.uP >>>>> I totally agree that context is king. That's why I tried out >>>>> all the >>>>> different examples of the reorderer on the demos page. I found >>>>> that >>>>> I had the same difficulty with all of them, which led me to think >>>>> that the problem was below the application level. >>>>>> >>>>>> 2. The grab handle can be defined. >>>>>> And is defined to be just the portlet title bar in the Layout >>>>>> Customizer integration in uPortal (rather than the whole >>>>>> portlet). >>>>>> This should help alleviate the confusion of location of the drag >>>>>> avatar to cursor, though we may find in further testing that >>>>>> that is >>>>>> still an issue. >>>>> Yes, I noticed this. It's harder to demonstrate with the Layout >>>>> Customizer because the grab area is smaller. But you can show the >>>>> effect by grabbing at the left or right end of the grab area. The >>>>> behaviour of the drop indicator is more consistent with a limited >>>>> grab area, but it still feels strange if the grab area is at the >>>>> edge >>>>> of the element I'm grabbing. >>>>> >>>>> This of course gives us another thing to test. Do users prefer to >>>>> have a large area where they can grab an element, or should it be >>>>> limited to a specific "grab me here" region? >>>>>> >>>>>> 3. The drag avatar may need to be minimized in uPortal. >>>>>> The size of a portlet in uPortal is highly variable, and user >>>>>> testing has already uncovered the unwieldiness of large portlets >>>>>> being dragged in a preview mode. It may turn out that for >>>>>> uPortal, >>>>>> we revert to an earlier design that more closely resembled the >>>>>> Yahoo >>>>>> behavior at the time - a small grey box as the drag avatar, and a >>>>>> non-preview, colored line as the drop indicator. >>>>> A smaller avatar might help, but I still think it skirts the >>>>> issue of >>>>> where the drop indicator appears. >>>>>> >>>>>> Gary >>>>>> >>>>>> Paul Zablosky wrote: >>>>>>> I have been playing with the reorderer examples on the daily >>>>>>> build >>>>>>> page <http://build.fluidproject.org/> and getting a feel for the >>>>>>> behaviour of the avatars and the targets. The behaviour is not >>>>>>> quite what I expect as I move things around, and I'm wondering >>>>>>> whether I'm taking an idiosyncratic view of things. The >>>>>>> problem is >>>>>>> that the drop target doesn't seem to appear where I expect it >>>>>>> to. >>>>>>> I position the avatar squarely over where I want to move the >>>>>>> element, and yet the target is one position off to the left or >>>>>>> right (or above or below). I have to move the avatar farther >>>>>>> than >>>>>>> (I feel) should be necessary to get the target to appear where I >>>>>>> want it. It makes the whole interaction sort of weirdly sticky >>>>>>> for >>>>>>> me. What it comes down to is that I feel I should be able to >>>>>>> predict where the target appears, and I can't. At first I >>>>>>> thought >>>>>>> that this was just a performance issue, but now I know what >>>>>>> causes it. >>>>>>> >>>>>>> Here's the explanation. What I'm trying to do is position the >>>>>>> avatar where I want to drop the element, but the target isn't >>>>>>> following the avatar. The target follows the /pointer/. So >>>>>>> with a >>>>>>> fairly large avatar -- such as a portlet window, or a multi- >>>>>>> line >>>>>>> list element, it makes a huge difference where I grab the >>>>>>> element. >>>>>>> If I grab the top edge of the list element, the target will >>>>>>> appear >>>>>>> in relation to the top edge of the avatar. If I grab the bottom >>>>>>> edge, the target follows the position of the bottom. >>>>>>> But I never pay attention to where I grab the thing. My eyes >>>>>>> are >>>>>>> tracking the outline of the avatar, and I sort of expect the >>>>>>> target >>>>>>> to appear where I have the avatar centred -- and that's not >>>>>>> happening. >>>>>>> >>>>>>> So it raises the question in my mind. Is it just me, or do >>>>>>> others >>>>>>> have the same experience of the movements of the screen >>>>>>> objects not >>>>>>> quite following their expectations? >>>>>>> >>>>>>> Of course my experience means nothing. I know that we can only >>>>>>> settle an issue like this with user testing. So here's the real >>>>>>> question: Do users have the idea that they are influencing the >>>>>>> position of the drop target by the location of the avatar, or do >>>>>>> they have the feeling they are shoving it around with the >>>>>>> pointer, >>>>>>> while ignoring the outlines of the avatar? And do we have any >>>>>>> user >>>>>>> testing results or research data (possibly from some outside >>>>>>> source) that can tell us this? >>>>>>> >>>>>>> I spent a little time this afternoon trying to train myself to >>>>>>> be a >>>>>>> better drag-and-dropper, using the four reorderer examples >>>>>>> <http://build.fluidproject.org/> -- either centring the pointer >>>>>>> carefully on the element I'm grabbing, or following the pointer >>>>>>> image rather than the avatar outline. I'm learning, but it >>>>>>> doesn't >>>>>>> feel quite natural. >>>>>>> >>>>>>> Comments? Am I marching to a completely off-the-beat drummer >>>>>>> here? >>>>>>> >>>>>>> Regards to all, >>>>>>> Paul >>>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> Allison Bloodworth >> Senior User Interaction Designer >> Educational Technology Services >> University of California, Berkeley >> (415) 377-8243 >> [EMAIL PROTECTED] >> >> >> >> > 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
