Response to Fluid demo page
Colin Clark
colin.clark at utoronto.ca
Wed Nov 28 20:01:47 UTC 2007
Hi all,
We're planning a complete reworking and simplification of the
LayoutHandler API after 0.1 goes out the door. These need to be easier
to customize and extend.
We can definitely make this behavioural change in the process.
Colin
Michelle D'Souza wrote:
> Yes, this is technically possible but not until after the release. :)
> From a technical perspective the keyboard behaviour of the Reorderer is
> handled by the 'layout handlers'. To change the behaviour that you have
> described requires a new layout handler. It's actually a fairly simple
> thing from the technical perspective and perhaps at the same time we can
> simplify the API of the layout handlers. :)
>
> Michelle
>
>
> On 27-Nov-07, at 10:50 PM, Allison Bloodworth wrote:
>
>> Daphne and I figured out that we were both suggesting the same thing:
>> in keyboard mode, continue to have no avatar for the "hovering" image,
>> but add a red line indicator of where the image is about to go before
>> CTRL is released *instead* of actually moving the image. When CTRL is
>> released, move the image. So essentially CTRL+ arrow would move a red
>> line, not an image until CTRL is released. This follows the Drag and
>> Drop - List Ordering design pattern. We feel this would be a better,
>> more easy to understand interaction for the user--can anyone tell us
>> if this would technically be possible?
>>
>> Thanks!
>> Allison
>>
>> On Nov 27, 2007, at 5:21 PM, Daphne Ogle wrote:
>>
>>> Comments below...
>>>
>>> -Daphne
>>>
>>> On Nov 27, 2007, at 4:26 PM, Allison Bloodworth wrote:
>>>
>>>> What I was really suggesting is that perhaps the interactions
>>>> *should* be the same. Shaw-Han and I were just working on the
>>>> drag-and-drop design patterns which just made me believe this even
>>>> more. They are still rough, but we have two different sub-patterns,
>>>> one for Layout Preview
>>>> (http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+Layout+Preview)
>>>> and one for List Ordering
>>>> (http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+List+Ordering).
>>>> The argument is that in certain situations it is helpful and in
>>>> others disorienting to give the users a preview of what will happen
>>>> before they drop the image/object. We believe that in List Ordering
>>>> (which is what the Lightbox is) it is usually not helpful to show a
>>>> preview of the new order of the images/objects before the one being
>>>> moved is dropped. We see that in the Lightbox where with the
>>>> keyboard interaction it is difficult to follow what is happening.
>>>> Currently the reasons we feel it is a good idea to show a layout
>>>> preview include (feel free to add to this!):
>>> This makes sense to me. Layout preview is important. I think what
>>> I'm suggesting isn't of much value is the hover location -- indicated
>>> with the avatar. See next comment for more details.
>>>>
>>>> * When it isn't possible to make clear how the layout will change
>>>> using an indicator such as a bar or an arrow (e.g. portals with
>>>> different sized portlets) without moving any of the objects themselves
>>>> * When a user needs to see the visual form (e.g. shape, balance,
>>>> negative space) of the new layout in order to know whether to drop
>>>> the object (which doesn't usually happen in a horizontal line or grid)
>>>> * When a user needs to see all the objects in their new order before
>>>> making a decision that they should complete the movement an object
>>>> (this one is more open-ended, but I don't think this can really be
>>>> argued for the Lightbox as that's not the way the mouse works, and
>>>> it is more implementation than user need which is driving this
>>>> keyboard interaction)
>>>>
>>>> Though in the implementation of the Lightbox, the when the keyboard
>>>> is used an image is currently moved each time a user hits
>>>> CTRL+Arrow, maybe instead we should wait until they release the CTRL
>>>> key. I would argue that the immediate movement of the image may
>>>> actually not match a user's mental model in that if the user is
>>>> holding down the CTRL key, they may not think of the image as being
>>>> "dropped" until that key is released. It would certainly be good to
>>>> do some user testing on this, but I'm guessing that most users would
>>>> hold down the CTRL key long enough to make displaying a red bar
>>>> before the CTRL key is released and the item is dropped a helpful
>>>> affordance. Then (hopefully) they would understand that they can get
>>>> a preview before actually moving the image and the whole interaction
>>>> would be easier to follow.
>>> I was thinking this same thing. However, I'm wondering if we really
>>> can *not* drop the image until the keys are released. With drag and
>>> drop, the action is cancelled if the user drops the image in a
>>> location not allowed (on top of another image or outside the
>>> thumbnail area) and it goes back to it's original location. I don't
>>> think the same scenario exists with keyboard interaction. On click
>>> of CTRL+arrow the drop location simply becomes the next droppable
>>> location. Perhaps it's the avatar that is confusing since the
>>> keyboard moved image never really hovers areas that aren't droppable.
>>> How about using the red line indicator but not having an avatar with
>>> keyboard interaction? That way the user can see where they are going
>>> to drop the image but the avatar doesn't add complexity to the view.
>>> The slim red line in between thumbnailes won't make the other
>>> thumbnails move around with each move like they do now. So, from the
>>> users perspective the image isn't moved until they drop it in the new
>>> location by releasing the CTRL key. Make sense? These highly
>>> interactive actions are hard to describe in text :).
>>>>
>>>> By the way, though our time is limited before the release we would
>>>> *definitely* welcome feedback on these design patterns! In the
>>>> future we will plan for more time for review of design patterns.
>>>> This release snunk up on me a bit, but I will be thinking about an
>>>> appropriate review process for future patterns before they are put
>>>> into a release (and these patterns can certainly be updated for
>>>> future releases).
>>>>
>>>> Cheers,
>>>> Allison
>>>>
>>>> On Nov 26, 2007, at 4:39 PM, Daphne Ogle wrote:
>>>>
>>>>> Good points but I don't think we want the mouse and keyboard visual
>>>>> cues to be the same since the interactions are not the same.
>>>>>
>>>>> With drag & drop the image doesn't actually move anyplace until the
>>>>> mouse click is released. The avatar shows where you are dragging
>>>>> the image to and where it would drop if you let go right now.
>>>>> Keyboard interaction moves the image one spot immediately so there
>>>>> isn't the preview of where it will land. There is not avatar since
>>>>> the image is actually being moved with each ctrl+arrow. The
>>>>> important cue is going to be: where did it just land. Can I follow
>>>>> it as I move it along?
>>>>>
>>>>> -Daphne
>>>>>
>>>>> On Nov 26, 2007, at 3:09 PM, Allison Bloodworth wrote:
>>>>>
>>>>>> It seems like the proper interaction takes place when you "pick
>>>>>> up" the image using the keyboard--it turns gray just like the
>>>>>> original image does when you pick it up with the mouse. I agree
>>>>>> that when you have moved it but not yet "dropped" it, however, it
>>>>>> is really hard to follow. The interaction also seems correct for
>>>>>> when the image is dropped via keyboard--just as it does with the
>>>>>> mouse, it appears as a selected image. It is just that with the
>>>>>> keyboard in that midway state where it isn't in its old spot
>>>>>> anymore and is in a temporary spot but not yet "dropped" at its
>>>>>> new spot that it's hard to know what has happened.
>>>>>>
>>>>>> However, I think I see what the person making the comments below
>>>>>> is suggesting, and it sounds like it could be a good solution.
>>>>>> Essentially, until the keyboard user has "dropped" the image by
>>>>>> releasing CTRL+arrow, they image shouldn't move. Instead, the
>>>>>> half-tone image should remain in its old spot and the new
>>>>>> (potential) spot should be indicated by the red line (the same way
>>>>>> it happens with the mouse). After it's dropped, the image moves to
>>>>>> that spot and the red indicator goes away. It seems that would
>>>>>> make what is happening easiest to follow for the user, and it
>>>>>> would match the mouse interaction almost exactly.
>>>>>>
>>>>>> On Nov 19, 2007, at 9:49 AM, Daphne Ogle wrote:
>>>>>>
>>>>>>> Comments below...
>>>>>>>
>>>>>>> On Nov 19, 2007, at 6:58 AM, Joseph Scheuhammer wrote:
>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> A few weeks back, I posted a message to the wai-xtech DHTML
>>>>>>>> style guide
>>>>>>>> working group asking for their opinions about the fluid demos on
>>>>>>>> http://build.fluidproject.org/. Specifcially, I asked:
>>>>>>>>
>>>>>>>>> In terms of keyboard accessibility, the Reorderer currently
>>>>>>>>> defines:
>>>>>>>>> 1. the arrow keys for navigating among the orderable items, and
>>>>>>>>> 2. control+arrow to move an orderable item to a new location.
>>>>>>>>>
>>>>>>>>> The latter constitutes a kind of keyboard based drag-and-drop. In
>>>>>>>>> terms of this interest group, are these reasonable keystroke
>>>>>>>>> definitions given the context?
>>>>>>>>
>>>>>>>> I received a number of interesting responses. In particular, one
>>>>>>>> fellow
>>>>>>>> had a lot of comments about the visual feedback regarding
>>>>>>>> selection and
>>>>>>>> focus in the lightbox. I asked him if he would mind my
>>>>>>>> forwarding his
>>>>>>>> email to this group, since his ideas were of a "design" nature.
>>>>>>>> I have
>>>>>>>> not heard a response. But, since his ideas are worth discussing,
>>>>>>>> I've
>>>>>>>> decided to just quote his suggestions and post them here without
>>>>>>>> providing his email.
>>>>>>>>
>>>>>>>> So: these aren't my ideas, but someone else's. What do people think?
>>>>>>>>
>>>>>>>>> Keyboard Interaction:
>>>>>>>>>
>>>>>>>>> The use of the ctrl key with the arrow keys is good. We usually
>>>>>>>>> also
>>>>>>>>> map Ctrl+Home and Ctrl+End to move the items (here the image)
>>>>>>>>> horizontally , similar to the effect of standard home and end.
>>>>>>> Ctrl+home and Ctrl+End are a great idea. In fact, I think they
>>>>>>> were included in the original descriptions of behavior (or at
>>>>>>> least should have been :) ).
>>>>>>>>>
>>>>>>>>> Recognition:
>>>>>>>>>
>>>>>>>>> I think it is quite helpful to indicate the use of the Ctrl
>>>>>>>>> key. But
>>>>>>>>> the indication currently is counter-productive because while
>>>>>>>>> moving
>>>>>>>>> the user needs to know where the object has moved to. Due to the
>>>>>>>>> half-tone coloring it is much harder to recognize than using the
>>>>>>>>> standard focus coloring . From my opinion the focus should keep
>>>>>>>>> the
>>>>>>>>> current colo rs (you don ’ t really lose the focus here) but a
>>>>>>>>> small
>>>>>>>>> icon or other additional indicator shows the effect of m oving,
>>>>>>>>> most
>>>>>>>>> favorable a similar indicator as the mouse would indicate when
>>>>>>>>> moving
>>>>>>>>> objects in all directions. (Use Alt+Space, then select “ move ” in
>>>>>>>>> Windows. The mouse cursor changes to indicate the effect.)
>>>>>>> Took me a minute to understand what this meant but I think I do
>>>>>>> now and totally agree. Essentially, the visual feedback on the
>>>>>>> image being moved via keyboard is backwards from moving with a
>>>>>>> mouse. We currently display the moving image opaquely for
>>>>>>> keyboard but not mouse. Since the keyboard moves the image
>>>>>>> immediately (rather than just showing where it would be moved
>>>>>>> until it is dropped like with the mouse) showing where it moved
>>>>>>> to is tricky. It takes a lot of focus to "see" the image as it
>>>>>>> is moving (and others are moving to make room for it) and I don't
>>>>>>> think we can expect users will have that kind of focus on a task
>>>>>>> like this. I think this person suggests we also use the red line
>>>>>>> indicator to show where the image is moving to. Since the image
>>>>>>> moves right away I'm not sure how helpful that would be. In my
>>>>>>> mind the problem is staying with the image as it moves. Perhaps
>>>>>>> it could use less opacity and a strong outline to help
>>>>>>> differentiate it from the other thumbnails on the page?
>>>>>>>
>>>>>>> -Daphne
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ;;;;joseph
>>>>>>>>
>>>>>>>> 'A dog, a panic in a pagoda'
>>>>>>>> - "Bob", W. A. Yankovic -
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> 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>
>>>>
>>>>
>>>>
>>>>
>>>
>>> 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
>>>
>>>
>>>
>>
>> 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 <mailto:fluid-work at fluidproject.org>
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> ------------------------------------------------------
> Michelle D'Souza
> Software Developer, Fluid Project
> Adaptive Technology Resource Centre
> University of Toronto
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
--
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
More information about the fluid-work
mailing list