Hello Allison, I've bumped Fluid-1334 up to critical for now, so that I'll keep it in my sights for the bug parade.
Thanks Justin On 16-Sep-08, at 9:45 PM, Allison Bloodworth wrote: > 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
