Drag and Drop

Moving something on screen used to mean translating the action into words. Putting a file in another folder meant typing a move command along with a source and a destination. Reordering a list worked the same way: edit the number attached to each row, or click a move-up button.

Watch someone trying to get the twelfth item into second place and the problem is obvious. The screen redraws after every one of ten clicks, and counting how far along you are is your job, not the computer's. Overshooting and clicking back down happens constantly. The action was finished in the person's head while their hand was still tapping the same spot ten times.

Dragging exists to close that gap. Moving a sheet of paper across a desk means picking it up and putting it down, not describing the move. Treating on-screen elements like physical objects lines up the shape of the intention with the shape of the action. It was also the first interaction to make serious use of affordance — the property that lets an object's appearance suggest what can be done with it.

Three motions — grab, move, release — and the interaction is only complete when the screen answers each of them.

1. Grabbing. Pressing alone doesn't start it; the pointer has to move some distance while held. Mice typically use a threshold of three or four pixels, while touch screens swap distance for time and require a press of roughly 0.3 seconds. Without that threshold, every attempt to scroll a list registers as picking up a row instead. The moment it starts, the grabbed element lifts or tilts slightly to show that it is now in hand.
2. Moving. A semi-transparent copy follows the pointer, and valid destinations show a line or an open gap. Without that indicator, nobody knows where the item will land until after they let go, which turns every move into a guess followed by a check. Lists longer than the viewport also need the edges to scroll automatically while something is held over them — without it, nothing can travel past what is visible, and sending the twentieth item to the top becomes impossible.
3. Releasing. Let go over a valid destination and the item settles there; let go anywhere else and it returns to where it started. That return animation runs about 0.2 seconds so that nobody reads the item as having been deleted. Snapping it back instantly would look identical to the item vanishing and reappearing, which is the one outcome a person moving their own data should never have to wonder about.
4. Committing. The element changing position on screen and the change being saved are two separate events. If the save fails, the screen has to go back and say so. Skip the feedback here and people close the tab believing the change stuck.

The same interaction splits four ways depending on what it changes.

1. Reordering. Moving items up and down within one list to set priority — task lists, playlists, menu editors. The position itself carries the meaning here, so whatever sits at the top is understood as the most important thing without anyone having to label it.
2. Regrouping. Moving an item into a different container to change its state or category. Pulling a card from the in-progress column to the done column on a kanban board is the standard case, and there the movement itself is the command that changes the state.
3. File upload. Dragging a file from outside the browser into the window. It takes fewer steps than opening a file picker, so products with frequent uploads usually offer both.
4. Placement. Positioning elements at arbitrary coordinates in an editing tool. Unlike reordering there are no predefined slots, so without snapping to a grid the result accumulates small misalignments. Four cards whose left edges each differ by two pixels look wrong in a way that is hard to point at.

"Let people reorder this list by dragging. Right now there's only a move-up button."

A request to replace repeated clicking with a single continuous motion.

"On mobile it collided with scrolling, so we made it start after a long press."

Explaining how one gesture being read two ways got resolved by adding a condition.

"If dragging is the only way, there's no way to reorder with a keyboard."

Pointing out that this interaction alone leaves some people unable to do the task.

At Pagedeck the discussion came up over sorting in the document library. Noa proposed letting people drag documents into order inside a folder, and Theo asked the follow-up question on the spot: with two hundred documents in view, how many times does the screen auto-scroll to carry the twentieth one to the top, and what happens if the pointer is released partway.

What they settled on was keeping the drag interaction and adding a move-to-top command in the right-click menu. Mia attached one more condition: the screen should say whether a reordering is visible only to that person or to the whole team. In a shared library that question comes up more often than the ordering itself.

The most common belief is that the interaction is intuitive enough to need no explanation. For anyone who has done it once it genuinely is easy, which makes the belief feel right. The trouble is that there is no way to learn the feature exists before trying it. A button is visible; the fact that a row can be dragged is not. That is what a signifier is for — a cue added deliberately to announce that something is interactive. The six-dot grip handle on the left of a row and the cursor that changes on hover both do that job. Build the feature without one and usability testing typically finds two or three people in ten discovering it.

Treating the interaction as sufficient on its own is the other mistake. It works fine with a mouse, so no alternative seems necessary. But for someone with tremors, someone navigating by keyboard, or someone listening to the screen through a screen reader, holding a button while moving a precise distance is difficult or simply impossible. That is why accessibility standards ask for a second path to the same outcome. Letting keyboard navigation select a row and move it with arrow keys, or adding a move-to-top menu item, solves it. Either one costs nothing if it goes in during design, and means redrawing the whole list if it gets added later.