Drag and drop

Problem Context

• Users need to move, copy, reorder, assign, group, place, or change status for cards, files, tiles, rows, objects, layers, widgets, or records.
• The interface has one or more source objects and destinations such as columns, lists, folders, groups, positions, canvases, zones, or containers.
• The move can be local, persisted to a server, constrained by permissions, blocked by business rules, or coupled to workflow side effects.
• The same surface may also support click, long press, swipe action, text selection, scroll, multi-select, keyboard movement, and context menus.

Selection Rules

• Choose drag and drop when the design problem is moving an object from a source to a destination, position, group, or order.
• Use touch gesture when the question is the broader gesture vocabulary, target sizing, cancellation, and equivalent controls across many gestures.
• Use long press when sustained contact is only the pickup or secondary-action invocation before drag begins.
• Use drag-and-drop upload when the dragged object comes from the operating system as files and the product needs upload validation and queue states.
• Use kanban board when the primary pattern is workflow columns, WIP limits, card details, filtering, and status mapping; drag may be one input method inside it.
• Use sort controls when users choose a deterministic ordering rule rather than manually positioning individual objects.
• Use list view, table, tree grid, or card grid when object presentation, selection, and row or card action anatomy are the main concerns.
• Provide explicit Move, Reorder, Destination, Position, or Assign controls for every non-essential drag outcome.
• Require confirmation or review when drop changes permissions, ownership, billing, notifications, destructive state, or external side effects.
• Do not use drag and drop for invisible commands, hidden deletion, primary-only workflows, or tasks where destinations cannot be previewed clearly.

Required States

• Idle state with draggable object identity and visible drag handle or move affordance.
• Pickup state that confirms which object or selected set is being moved.
• Dragging state with preview, source placeholder, and object count.
• Valid target hover state with destination name and insertion or placement indicator.
• Invalid target state with reason such as permission, WIP limit, locked folder, unsupported type, or max items.
• Auto-scroll or edge-scroll state for large lists, boards, and canvases.
• Drop preview state showing move, copy, link, reorder, assign, or status-change consequence before commit.
• Successful drop state with status message, stable focus, updated position, and undo where appropriate.
• Canceled drag state that returns the object to source when released outside a valid target or Escape is used.
• Failed drop or server-rejected state that restores the prior model and explains retry or fallback.
• Equivalent keyboard, screen reader, switch, touch, mouse, and explicit move-menu state.
• Multi-select or bulk drag state with selected count and destination constraints.
• Mobile compact and large-text state where handles, targets, and messages remain readable.

Interaction Contract

• Dragging starts only from the intended handle, object, or selected set, not from unrelated scroll or text-selection movement.
• The source object remains identifiable during drag through a preview, ghost, placeholder, or selected-set label.
• Targets report whether they are valid, invalid, full, locked, hidden, filtered, or permission-limited before drop.
• The drop location shows exact insertion position, destination, or placement zone before the user releases.
• Releasing outside a valid target, pressing Escape, or cancelling the equivalent move path leaves the model unchanged.
• The product commits the move only after a valid drop or explicit confirmation, and reports success, failure, or pending sync.
• Equivalent controls expose the same destinations, constraints, warnings, confirmation, undo, and error states as drag.
• Drag does not steal vertical scroll, text selection, swipe action, pull-to-refresh, or system gestures without a deliberate handle or threshold.

Implementation Checklist

• Inventory draggable object types, allowed sources, destinations, move modes, constraints, side effects, and equivalent controls.
• Define pickup target, handle size, drag threshold, drag preview, source placeholder, target highlighting, insertion indicator, and drop commit timing.
• Expose invalid target reasons before drop and keep them available as text, not color alone.
• Implement Move to, Reorder, Position, Assign, or destination menus that call the same command handlers as drag.
• Preserve focus, selection, scroll anchor, filters, expanded state, and object identity after move, cancel, undo, and server failure.
• Add undo, confirmation, or pending review for risky moves and any operation with external side effects.
• Resolve conflicts with long press, scroll, swipe action, text selection, nested draggable regions, auto-scroll, and browser-native drag behavior.
• Test keyboard-only movement, screen reader actions, switch control, touch, mouse, trackpad, stylus, mobile landscape, large text, invalid targets, concurrent updates, and server rejection.

Common Generated-UI Mistakes

• Making drag the only way to move, reorder, assign, or change status.
• Showing no valid target, invalid target, insertion, or destination feedback before drop.
• Letting any pointer movement drag when users intended to scroll or select text.
• Dropping into hidden, filtered, full, locked, or permission-denied destinations without explanation.
• Changing workflow state, permissions, ownership, or notifications immediately without confirmation or undo.
• Using drag and drop upload guidance for object movement inside the product.
• Leaving focus behind after a keyboard-equivalent move.
• Persisting a failed server move visually and making the model inconsistent.

Critique Questions

• What object or selected set is being moved, and where is the source shown during drag?
• Which destinations are valid, invalid, full, locked, or permission-limited, and how do users know before drop?
• What exact result happens on drop: move, copy, link, reorder, assign, status change, or external side effect?
• What non-drag control completes the same move for keyboard, screen reader, switch, and low-precision users?
• How can users cancel before drop, recover after drop, and understand server rejection?
• How does drag avoid fighting scroll, long press, swipe action, text selection, nested drag regions, and system gestures?
• Where does focus land after pickup, cancel, drop, undo, failure, and equivalent move?