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: <http://fluidproject.org/pipermail/fluid-work/attachments/20071127/86cca769/attachment.html>
More information about the fluid-work
mailing list