Styles for drag-and-drop?
jutta.treviranus at utoronto.ca
Fri Jun 29 13:59:23 UTC 2007
Having conducted a large number of user trials with indiscrete
pointers (or people who cannot control a pointer very accurately),
feedback that they are over a clickable target was very valuable and
reduced the concentration needed to select a target and the confusion
about whether the cursor was over the desired selectable object. I
would encourage the use of identifiably distinct feedback both on
"mouse over" and when clicked on (or selected). It would be good to
also think about people who use alternative pointing devices such as
head pointers, eye trackers etc. where feedback plays a hugely
At 9:36 AM -0400 6/29/07, Anastasia Cheetham wrote:
>On Jun 28, 2007, at 6:58 PM, Daphne Ogle wrote:
>>> > Should the appearance of a thumb change to our 'active' look when
>>> > moused over, or should this only happen when clicked on?
>>> I believe this should be a click. This will be easy for
>>> alternative input devices.
>>> If you are going to have multiple options like copy and move you
>>> consider a menu to selec the option.
>> The appearance should only change to the "active" state when the
>> image is selected (so in this case "clicked on"). The idea here is
>> that we are giving the users affordance to know they can do
>> something with the image so we only want to do that once they
>> really can do something with it.
>What we have currently is this:
>- when the user mouses over a thumb, the border darkens
>- when the user actually clicks on the thumb, the border is dark, and
>the background darkens (same visual appearance as when the users uses
>arrow keys to select an image
>If you want to try this out, and see/feel for yourself the
>experience, let me know, and I'll point you at a currently running
>instance. It would be good to know if you think we should remove the
>dark border on the mouse over.
>>> > While a thumb is being dragged, should a representation of it stay
>>> > somehow where it was originally? If so, what should it look like?
>>> > (Note: If nothing stays there, the space collapses and all of the
>>> > subsequent images move.)
>>> The user may escape the move or copy and so it would be easier to
>>> it there while you drag. It would be good to change the mouse pointer
>>> during th emove.
>> I think the image should stay where it originally is until it is
>> dropped. We may want to visually highlight the thumbnail in its
>> original location while it's being moved.
>Ok, this isn't what currently happens. We'll have to look in to
>> Then the moving thumbnail should be a "ghost". As, Rich points
>> out, if the user "lets go" (mouse release) of the thumbnail without
>> actually dropping it in a new location then it stays where it was.
>> Leaving the image in it's original location is feedback to that
>Actually, the way the drag-and-drop works, if the imag is 'dropped'
>into the spaces between the thumbs, it is treated as a move to the
>end of the list. If it is dropped outside the frame, then it is ignored.
>>> > How should 'previewing' of the target location behave? Should a
>>> > of the thumb be placed in the target location, or should it be a
>>> > vertical bar, like iPhoto, or something else?
>>> Not sure what you mean by 'previewing.'
>> I like the vertical bar like in iPhoto. That way, the "ghost"
>> itself is sort of on top of the group of thumbnails. Trying to
>> show a visual distinction between the thumbnails and the "ghost"
>> being moved while showing it in it's new location is tricky. The
>> vertical bar is distinct from the thumbnails so easy to see and I
>> think it gives the user appropriate feedback about where it will be
>> dropped. I also think the images around the vertical bar will need
>> to "separate" a bit but just enough to see vertical bar so it can
>> be a fairly subtle change that isn't distracting to users.
>Right now, we have a version of a vertical bar: a side border of the
>image being dwelled on is highlighted in red, indicating that the
>image will be dropped on that side. We know this is not ideal.
>You know Daphne, what would probably be good would be for you to sit
>down with the current version and play with it, and log any
>recommended changes in JIRA. Then we'd have a good record, and a
>better venue for comments.
>Anastasia Cheetham a.cheetham at utoronto.ca
>Software Designer, Fluid Project
>Adaptive Technology Resource Centre / University of Toronto
> "The universe is full of magical things
> patiently waiting for our wits to grow sharper."
> -- Eden Phillpotts
>fluid-work mailing list
>fluid-work at fluidproject.org
More information about the fluid-work