Quote:
Originally Posted by emolina
I like that, the ONLY issue I can think of is that people are used to having whatever's under the finger get out of the way for re-arranging. But again, doing it like iOS4 will help once that's out on the iPad.
|
I thought about that earlier.
I'm not sure what iOS4 will do, we'll see on Monday. In the mean time, here's two possible solutions:
Clarification
If a person drags a single issue/issues onto a long box (over it, then lift finger), they intend to put them in.
If a person drags an issue/issues onto another issue, they want to create a new long box.
If a person drags one long box onto another, they want the two to combine. All issues in both long boxes will be placed together into the current one.
In all three cases, the issues they're dragging don't change position until they lift their finger. Lifting the finger is the user's way of saying "Here. I want them here."
But how does this interface allow for changing the arrangement of the icons they are dragging over?
Solution 1:
It doesn't. Only alphabetical order. Target icons remain in place, as stationary targets for drags.
(I don't like this solution, but it is a perfectly valid one. Delicious Library, on the Mac, does things this way.)
Solution 2:
If a user drags the issue/issues over a long box or another issue, at first the target icon doesn't move. It's only when they keep dragging, past the center, almost to the edge of the icon, nearly to the "gutter" between icons that it displaces, widening the gutter, forming a space to drop the issues onto.
The icon displaces in the opposite direction of the current drag: if the user is dragging left, the issue displaces right, so the new space is created under their finger - if they want to drop it in the current space, it's easy. Just lift the finger.
If they drag past the new space, towards the next icon, the displaced icon moves back into position (shrinking the space they're leaving) but the next icon remains stationary. It doesn't displace until they dragged over it and almost off it, when it will displace, widening the gutter on that side. And so forth.
At any time, the use can "drop" the issues where they are. If over an icon, the issues move there ("into" a box). If over a space, the issues move there.
(Also, shake to undo. If you dropped accidentally, they can move back instantly.)
Here's why this works:
Three reasons to drag over an icon.
1.) Just passing by. Their target is somewhere else, and they don't intend to stop.
2.) New neighbors. They want to move issues next to the current one (above, below, left or right.)
3.) Special Delivery. They want to move issues onto the current one, either because it's already a long box or they want it to become a long box.
How to differentiate?
It's a matter of discerning user intent. We wait to move an icon until the users have almost "left" the current one. If they're leaving, they don't want to stop here. Either they want to drop it next to this icon ("New Neighbor"), or they want to keep going past it ("Just Passing By").
In either case displacing the target icon - to create a new space for the user to drop the current issues onto - is an expected response (the rest of the OS responds this way). If they "drop" the issues in the space, that's where they wanted them.
If they continue moving, past the space towards another icon, they don't want to drop the issues in the space, so the next icon becomes a potential target. It doesn't displace until they're leaving it's boundaries.
In this wise, dragging towards the edge of an icon becomes the trigger for moving it: Drag, keep dragging, nothing happens, almost reach the edge, icon displaces. Drag over space, keep dragging, reach a new icon, keep dragging, nothing happens, almost reach edge, that icon displaces.
This gives the user a sense of control over where to drop their moving issues. They will learn the "feel" of moving them, learn that the behavior is consistent and reproducible, and hence controllable.