Response to Fluid demo page
Michelle D'Souza
michelle.dsouza at utoronto.ca
Wed Nov 28 15:24:17 UTC 2007
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
>>>>>>> http://fluidproject.org/mailman/listinfo/fluid-work
>>>>>>
>>>>>> Daphne Ogle
>>>>>> Senior Interaction Designer
>>>>>> University of California, Berkeley
>>>>>> Educational Technology Services
>>>>>> daphne at media.berkeley.edu
>>>>>> cell (510)847-0308
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> fluid-work mailing list
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Daphne Ogle
>>>> Senior Interaction Designer
>>>> University of California, Berkeley
>>>> Educational Technology Services
>>>> 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
>>>
>>>
>>>
>>>
>>
>> Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> 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
>
>
>
>
> _______________________________________________
> fluid-work mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071128/1429fb8c/attachment.html>
More information about the fluid-work
mailing list