Drag-and-drop upload

Problem Context

• Users are likely to have one or more files visible in a desktop file manager and want to move them into the product quickly.
• The same workflow must still work for keyboard, mobile, assistive technology, public-device, and locked-down desktop users.
• Files can be dragged over the wrong part of the page, leave the target, include unsupported types, or include non-file data such as links or text.
• The browser may try to open dropped files unless the app prevents default handling only when file drags are involved.
• The product needs to show queued, uploading, uploaded, failed, removed, and final submit states after a drop.

Selection Rules

• Choose drag-and-drop upload when dropping files from a desktop file manager is a common, useful shortcut.
• Use ordinary file upload when the task needs dependable attachment selection without extra drop-zone complexity.
• Use text input when users can type the needed value instead of attaching a file.
• Use multi-step form when the upload is one controlled step in a longer saved journey.
• Use bulk import when the dropped file is structured data requiring mapping, row validation, and an import report.
• Do not make drag-and-drop the only upload path.
• Do not turn the entire page into an invisible drop target unless every drop outcome is clear, cancellable, and recoverable.
• Accept only file drags in the drop zone and reject links, text, unsupported formats, too many files, or oversized files with explicit messages.
• Prevent browser default file navigation only for file drags and only where the app can give users a safe outcome.
• Require review or a separate submit action when a dropped file could affect a high-stakes transaction.

Required States

• Idle drop zone with visible label, requirements, and choose-file fallback.
• Drag enter state announcing that files are over the upload area.
• Valid drag-over state showing the target will copy or accept the files.
• Invalid drag-over state for links, text, folders, unsupported formats, or too many files.
• Drag leave or cancelled state that returns the zone to idle without uploading.
• Dropped queue state listing filenames, type, size, and count.
• Uploading state with progress tied to each dropped file or batch.
• Uploaded state with remove or replace controls.
• Rejected drop state with clear recovery and requirements repeated.
• Submitted state that confirms dropped files are included only after final review.

Interaction Contract

• Dragenter and dragover make the target visibly active only when the incoming data includes files.
• Dragover cancels the browser default action so the drop event can be handled and the cursor can show copy or none.
• Dropping files reads DataTransfer files or items, validates them, and adds accepted files to the same queue used by the file input fallback.
• Dropping links, text, folders, unsupported formats, or too many files keeps existing queued files intact and explains the rejected data.
• Leaving the target before release cancels the drag affordance and does not upload anything.
• Removing a dropped file affects only that file and keeps other queued files and form answers visible.
• Click, keyboard, and file-input selection produce the same selected-file list, progress, validation, remove, retry, and submit behavior as drag-and-drop.

Implementation Checklist

• Define accepted file kinds, maximum file size, maximum count, folder policy, duplicate policy, non-file drag policy, upload timing, and final submission boundary.
• Implement the drop target with a real file input or accessible button fallback so activation with Enter, Space, click, touch, and screen readers follows the same code path.
• Handle dragenter, dragover, dragleave, and drop events; prevent default file navigation for file drags and set an appropriate drop effect.
• Process DataTransfer files, reject non-file data safely, validate type, size, and count, and add accepted files to a visible queue.
• Show active, invalid, cancelled, queued, uploading, uploaded, failed, removed, and submitted states near the drop zone.
• Provide remove, replace, retry, and final review controls before submission.
• Test desktop file-manager drags, missed targets, browser Back, keyboard fallback, mobile fallback, screen readers, zoom, slow networks, duplicate files, and unsupported file types.

Common Generated-UI Mistakes

• Replacing the normal file chooser with a drop zone that only pointer users can operate.
• Letting dropped files outside the target open in the browser and erase unsaved progress.
• Showing a dashed box that does not change state during drag enter, drag over, or invalid drag.
• Accepting links or text as if they were files.
• Automatically submitting a transaction immediately after drop.
• Clearing all queued files when one dropped file is invalid.
• Using a drop zone for bulk import without mapping, row-level errors, partial success, or import results.

Critique Questions

• Do users actually have files available to drag from a desktop file manager?
• What is the equivalent path for keyboard, mobile, screen reader, public-device, and locked-down desktop users?
• What happens if users drag over the page, leave the target, drop outside it, or drop a link instead of a file?
• Can users see which files were accepted, rejected, uploading, uploaded, removed, or still waiting for final submit?
• Does the implementation prevent destructive browser file navigation without hijacking ordinary links and text?
• When should users be allowed to undo, remove, retry, or confirm after a drop?