Response to Fluid demo page

Tue Nov 27 00:39:35 UTC 2007

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20071126/4be06305/attachment.html>