Response to Fluid demo page

Allison Bloodworth abloodworth at berkeley.edu
Wed Nov 28 03:50:04 UTC 2007


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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20071127/86cca769/attachment.htm>


More information about the fluid-work mailing list