Drag & Drop: Think Twice
It’s not a UX panacea.
Nothing embodies the graphical user interface like drag & drop. You use a mouse pointer (or, more recently, a finger) to select an object and move it to a new location. Often the object, its original location, and the destination are abstract concepts, mapped onto physical ones via familiar metaphors. It’s relatively easy to learn and, once learned, easy to extend to unfamiliar situations. (Some would say intuitive but that’s not really accurate; some training is required.) It adapts the strange world of the digital to the peculiarities of the human brain.
Drag & drop also epitomizes all the disadvantages of a GUI:
- It’s inefficient. It takes time and focus to pick an object up and put it down somewhere else.
- It’s imprecise. (And, its efficiency and precision are inversely proportional.) Watch a skilled designer work in Photoshop and you’ll be surprised by how often he moves things with the keyboard: arrow keys to nudge by one pixel, Shift-arrow keys to nudge by ten. There’s just no good way to achieve that level of accuracy with the mouse.
- It’s physically awkward. Moving a mouse with the button down strains the hand, and it’s a real physical challenge if you run out of room and need to lift the mouse. Dragging long distances over a touch screen while maintaining contact is equally difficult, and exacerbated by the fact that your figure is obscuring both the object being dragged and the drop target. If you accidentally release the button, or hit a greasy spot on your touchscreen and lose contact, you end up in a situation that’s confusing at best and often requires effort to undo. As smartphones get bigger and bigger, this problem worsens: what if you need to reposition the phone mid-drag just to reach the target?
- Its order of operations doesn’t always match the user’s thought process. Suppose I’m looking at a file on my desktop and want to move it to Documents. In the real world I’d pick the file up, walk over to Documents, open it, and drop the file in. In the virtual world I have the equivalent of one hand: once I’ve picked the file up, I don’t have a second hand with which to open Documents. So I have to set the file back down, pull up Documents, position it next to the file’s current location, and then perform the drag. Apple has alleviated this problem somewhat with things like Exposé but it’s still awkward, and one begins to understand the allure of cut-and-paste.
- It doesn’t play well with scrolling. Reordering list items over long distances is an exercise in frustration: either the canvas scrolls slowly enough for the drag operation takes forever, or it scrolls fast enough to be efficient and you overshoot your target, sometimes repeatedly.
So should you implement drag & drop? If not, what’s the alternative? As always, a little Downward Arrow is a good place to start. What’s your user trying to accomplish? How well-suited is drag & drop to that task? What interactions might be better-suited to it?
Case Study: Stky Task Drawer
My own task-management app, Stky, which you should totally go download right now, provides a perfect example. Stky is designed to keep disorganized people organized. Tasks go in a big drawer that’s usually closed. Each morning you fill your daily sticky note from there, and it’s automatically wiped clean the following morning – everything’s back in the drawer.
So your drawer gets pretty full. It’s sorted by date, with newer items first, and one of my most requested features was the ability to reorder it. I decided it was a worthwhile addition.
iOS has a standard way to do this: press and hold a list item and it “pops out”, after which you can drag to reorder.
But as I did the Downward Arrow thing I started to wonder. Why was this such a popular request? What made it worthwhile? Well, the task drawer works much like a Facebook newsfeed: new items push older items down. Often that’s fine: weeks-old items you marked as “Soon” are really just “Whenever” items whose loss you haven’t come to terms with. But sometimes, an item in need of attention gets crowded out by newer stuff, and you need to move it up. More specifically, you need to bump it up to the top of the drawer where it won’t get lost.
So it’s unlikely a user would need to move a task by one or two slots (remember, these aren’t hyper-organized people I’m targeting) but likely she’d want to move it all the way to the top. And the longer the distance, the more scrolling involved, the more frustrating drag & drop becomes. My solution? A simple bump-to-top item in the swipe menu. It’s far less flexible than drag & drop, but for the core case I identified, far more efficient.
There’s no reason I couldn’t have implemented drag & drop too: the gesture in question isn’t being used for anything else. But it turns out to be more difficult than I’d anticipated: Apple expects users to go into an Edit mode before they start dragging, and I didn’t want to complicate the app that way. Implementing drag & drop without Edit mode proved surprisingly complex, and given my hypothesis that more flexible reordering isn’t necessary, the enhancement wasn’t worth the development time. But I suspect many situations are similar: if the effort required to implement drag & drop isn’t significant, including it alongside another interaction won’t hurt.