Don’t let drag-and-drop become a drag

Web designers must consider accessibility and other user experience issues in their drag-and-drop implementations. This post offers some issues and solutions.

Merry Christmas from sunny Singapore! Started this post a while ago, wrote the bulk yesterday, might as well add a few more sentences and publish it on Christmas. Also, sorry, bad title puns again.

Drag-and-drop is a cute extension of the physical paradigm that works particularly well on touch devices for obvious reasons. It’s naturally suited to tasks where user-defined sorting of some kind is required. It’s also a great way to show off and engage users by creating something fun to play with: anyone who has ever interacted with a draggable element has pulled it randomly around the screen while savoring that rare sense of control over the interface, no matter how superficial. I’m fond of it, especially for the analogue sense it brings to digital interactions.

Problems arise when this control method is applied indiscriminately to content of all sizes and types, without regard for screen size, page length or consistency. Users get tired when drag-and-drop is unwieldy, has to traverse large distances, or if intermediate/drop behavior isn’t consistent with expectations set by other sites and applications. As an example, let’s look at LinkedIn, the website that reminded me to write this post today – although LinkedIn is by no means the sole offender.

Aside: I appreciate that LinkedIn is constantly experimenting with their interface – it’s very nice to see that they’re continually striving for improvement.

They’ve made a big change to their Edit Profile page recently – or maybe I was subject to a variation in an A/B test, we’ll never know. But to reorder entries on the profile I now drag and drop chunks of employment history etc. around. (But only positions I currently hold can be moved – another frustration that took a while to understand.)

I can be verbose in written communication, use bulleted lists, and have a lot of media on entries like those for illustration or design. These mean that the height of the draggable element becomes far too unwieldy for effective manipulation. Below is a screenshot of a reordering attempt. The element is too large to easily move, and it’s made worse by frustrating intermediate behavior that makes it hard to do what I want even if I manage to move the element.

This particular drag-and-drop implementation also doesn’t allow me to just move the element roughly to where the target destination is – a behavior I expect since the only possible action is a crude swap and no finer control is needed. Instead, I have to align the top of the element with the top or bottom of the target to bump the target into the spot where my original element was.

What if I want to move the element to a target spot far away on the page, beyond my screen boundaries? Now the user is forced to perform an awkward shuffle that involves

  1. bumping the element against the edges of the screen to force scrolling (slow, and finding that exact spot is an exercise in precision pointer manoeuvring)
  2. holding the element down while scrolling with a wheel, keys or another finger, and hoping that the element follows along or at least reappears when the cursor is moved (which doesn’t always happen, forcing the user to try method 1 again)

If my finger slips – possible for users with poor motor control – or if I get to my destination and the draggable element has been lost somehow, I have to perform the dance all over again.

Let’s have a quick video example of said dance, this time on the website I first ran into the issue on, WordPress. WordPress has used drag-and-drop in their widgets page for quite a long time – you drag options from a pool of available widgets to an “active” zone, which enables them on your blog. This worked very well at first, but as the list of available widgets grows ever-longer, adding widgets has now become a big chore: good luck to you if you select a widget at the bottom of the list.

The problem is complicated once we throw accessibility into the mix (as always!) – say for instance you’re me with my terrible eyesight and have your browser zoom set between 150-175% by default. Working sometimes with Magnifier open and docked, I have at worst 11.5″ of screen real estate on an already-small 13″ 1280×800 screen. The following is a screenshot of my entire browser window at my normal zoom levels: the draggable element is too large to even fit on the screen.

On drag-and-drop pages where I have to traverse large screen distances or work with tall elements, I basically zoom out to 50% or less, do all my edits there, then restore to my usual 150%. It is incredibly frustrating.

There are a few solutions to drag-and-drop usability problems. The most obvious is to add a different method of control. Try for instance up/down buttons that reorder elements in a list. WordPress has actually done something about the problem (slipped in so quietly that I just found out 30 seconds ago). Widgets can now be added by clicking on their titles, which brings up a menu allowing you to select where they should go, followed by an Add Widget button.

If you want to keep the fun and impressiveness of drag-and-drop, there are ways to do it in a manner considerate of the fact that not all users have the same computing setup as the developer does. Some possibilities:

  • shrink elements when they are picked up
  • have a little schematic where changes can be made and reflected on the main content
  • drop targets that scroll together with your position on the screen so that they are always visible

Drag-and-drop is a very nice user interface touch in my opinion. When used well it adds fun, simplicity and a deliciously analogue tactility (which I love), enabling users do what they want faster and more easily. But care needs to be taken to ensure it doesn’t become a drag on the overall experience.


A few more pieces on accessible design: designing with accessibility in mind, a site against low contrast, a very short blog post/comment thread on designing for poor motor control (there seems to be a dearth of posts on this topic).

Noticing when the glasses fall off

User-centred design is a lens through which we can see the world, but it can sometimes feel like a new pair of glasses that you carry around and sometimes forget to wear.

Although I am now a user experience designer with the Yale Student Developers, and have always seen myself as a very user-centred person – whether I’m programming or drawing a magazine cover – I haven’t been doing this quite long enough that this way of thinking is completely internalized. If you’ll forgive the somewhat contrived analogy, user-centred design is a lens through which we can see the world, but to me it still feels like a new pair of glasses that I carry around but sometimes forget to wear.

Today I had to borrow a laptop from a friend to record a short video for German class. (I actually had to try three friends and three laptops, and none of them worked properly, so I’m going to give the speech in person after class tomorrow. Yay, “technology-enabled learning” done wrong!) While trying to get to the webpage that would let me submit my homework, I couldn’t help noticing that this friend’s laptop was horribly slow. Tabs in Chrome were all unresponsive. It took me 20 seconds just to application-switch.

Curious, I looked at what was running in the background and the first signs of the problem became evident: he somehow had four antivirus suites (two expired, one semi-functional, one apparently working) and five file-syncing/cloud backup services all running at the same time. Despite the presence of the file-syncing clients, he also wasn’t keeping backups of any of his data. The applications running might not have been the source of the slowness, but that the machine (and his data) was in this state gave a good hint as to what the problem might be.

When I returned his laptop to him I asked if he was aware of this situation. “Uh, yeah,” he told me, sounding unsure. “I think I installed all those programs by accident? I can’t find the uninstallers. And I don’t back up my data, yeah, I know I should, but…”

This is a facepalm moment, isn’t it? This is the kind of story that you tell back at the tech support office, to collective head-shakes and horrified looks. “Oh my god,” we go. “Why are users so inept?” And then we exchange smug looks. Users, man.

This is the moment you have to catch yourself. Is it really the user who is at fault? Or is it because the uninstallation process** isn’t intuitive? Why isn’t he backing up his data despite having multiple user-friendly cloud backup services at his disposal? Does he think it’s too difficult? Does he not realize that these programs offer him a way to back up his data? Could it be that these aren’t as easy-to-understand as we think they are? (You’d be surprised at how hard it is to explain the concept of file syncing to people, even college undergraduates who have spent at least half their lives online.)

I certainly didn’t realize what I was doing at first – after all, poking fun at the less tech-savvy is a comfortable and familiar hobby for most of us. I was telling a programmer friend about what had happened, and we were expressing amazement at how widespread bad computing habits were when he remarked, “people need to take better care of their computers” – and I suddenly became very aware of how we were pinning all the blame on this guy who had lent me his laptop so I could do my homework.***

As UX and product management people in the tech world, it’s only natural that the user-centric glasses we try our best to wear still fall off our nosebridges sometimes. After all, we’re mostly in this industry because we care about the people using our products, yes, but also because we love technology. We think the stuff engineers can come up with is awesome, and we want to make it even better. We’re all geeks. (Some more than others.) There will always be times when we forget that not everyone is the same way, when we’re baffled by another person’s unfamiliarity with something we work with every day, when we’re tempted to roll our eyes and declare the the problem exists between the chair and the keyboard.

What’s important is realizing when that happens, taking stock of the situation, putting the glasses back on, and looking again.

* I considered adding the sentence “my goal is to have the mental equivalent of laser surgery”, but after thinking about it for a little while, I decided that this isn’t really something I want. Although great in theory, I suspect that would tip me too far into the other direction, and cause me to lose touch with engineers instead. I need to be able to see how others see – not fully become others and lose the ability to view things from multiple perspectives.

** Mobile is one place that really gets this right. Uninstalling apps on smartphones is almost universally painless – perform the action that brings up a context menu, then select “remove” or tap a cross or drag it to a trash bin. Macs come a close second, except that the drag-to-Trash gesture doesn’t work for every type of application. The desktop environment is so wide open and subject to developer whims that the same kind of standardization is hard to achieve.

*** The way we instinctively shift responsibility off our products onto users reminds me a little of the language used in contemporary misogyny, actually: “women need to be less aggressive”, “women need to wear less revealing clothes”, “women need to sacrifice their careers to focus on their families”. If we can put so many resources into hiring UX people and good PMs to change the dialogue surrounding our products from “users need to X if they don’t want broken computers” to “computers should make it easy or needless for users to X”, we can definitely put the same amount of effort into changing the power dynamics and dialogue surrounding non-males in the tech