Camera capture

Problem Context

• The task asks users to create new images or video for receipts, documents, identity evidence, damage reports, profile photos, QR-like visual data, support diagnostics, deposits, or field work.
• Users may be on mobile, desktop webcam, tablet, kiosk, assistive technology, low light, poor network, denied permissions, unsupported browsers, shared devices, or privacy-sensitive locations.
• The product may need still images, video snippets, facing-mode choice, resolution constraints, crop, rotation, blur or glare detection, metadata handling, upload progress, redaction, or retention notice.
• Camera capture is often adjacent to file upload, permission request, sensitive-data reveal, full-screen takeover, drag-and-drop upload, and future QR or barcode scanning flows.

Selection Rules

• Choose camera capture when the product must create new camera media and users need live preview, framing, capture, review, and retake behavior.
• Use file upload when existing local files are acceptable and live camera access, active media stream, and shutter feedback are not the main interaction.
• Use permission request for the standalone access rationale and timing; camera capture includes the permission ask only as one state inside the capture lifecycle.
• Use sensitive-data reveal when captured content needs masking, timed reveal, redaction, or audit after acquisition.
• Use full-screen takeover when the capture task needs an immersive temporary mode with its own navigation and exit contract.
• Use drag-and-drop upload when users move existing files into a drop zone rather than create a new photo or video.
• Prefer explicit user action before starting the stream; never activate the camera only because a page, route, carousel, or modal loaded.
• Offer upload, manual entry, skip, or assisted alternatives before or immediately after permission denial.
• Capture is not submission: freeze the frame, show what was captured, and require review for consequential workflows.
• Stop tracks and clear unsaved previews on cancel, close, submit, route change, timeout, or permission revocation.

Required States

• Unsupported browser or insecure-context state with upload or manual alternative.
• Camera permission not requested, granted, denied, and revoked states.
• Start capture state with purpose, target object, and privacy explanation.
• Device selection or front/rear camera switch state when multiple cameras are available.
• Live preview state with active camera indicator, framing guide, and stop control.
• Low light, glare, blur, occlusion, wrong orientation, or missing-subject quality warning state.
• Captured still or recorded clip state with frozen preview.
• Review state with retake, crop, rotate, replace, submit, and cancel controls.
• Upload fallback, file fallback, manual entry, or skip state when camera fails or is denied.
• Upload pending, upload failed, retry, saved, attached, or submitted state.
• Cancel or dirty-exit state that explains whether captured media will be discarded.
• Stream cleanup state after cancel, submit, permission loss, or navigation.
• Sensitive capture state for IDs, faces, addresses, payment cards, private spaces, minors, or location-revealing images.

Interaction Contract

• The camera stream starts only after a deliberate user action and contextual permission rationale.
• Users can see whether camera access is inactive, requesting, active, paused, denied, unsupported, or stopped.
• The live preview names the selected camera and shows framing guidance that matches the task's quality requirement.
• Capture freezes the result and moves to review; upload or submit does not happen from the shutter press alone unless the task is explicitly low-risk and reversible.
• Retake, replace with file, cancel, and submit controls are reachable by keyboard and touch.
• Camera denial, unavailable device, unsatisfied constraints, upload failure, and network loss preserve the task and expose alternatives.
• Closing, canceling, leaving the route, submitting, or losing permission stops the media tracks and removes unsaved sensitive previews.
• Captured media metadata, storage, retention, and review boundaries are disclosed when the content is sensitive or externally submitted.

Implementation Checklist

• Define capture purpose, target object, allowed media type, required resolution, facing mode, quality checks, fallback path, retention rule, and downstream validation before requesting camera access.
• Use a secure context and request media only from an explicit capture action; handle permission denied, not found, not readable, overconstrained, and aborted states.
• Show active-stream status, selected camera, switch-camera control, framing overlay, quality feedback, and stop or cancel control while preview is live.
• Freeze the captured frame or clip for review and keep capture state separate from upload, submitted record, file fallback, and sensitive reveal state.
• Provide retake, crop, rotate, replace, upload file, manual entry, submit, cancel, retry upload, and discard-review paths where relevant.
• Stop all media tracks on cancel, close, successful submit, route change, component unmount, permission revocation, and timeout.
• Avoid persisting raw images, EXIF, location metadata, faces, IDs, or private-space previews unless users understand the purpose and retention.
• Test mobile front and rear cameras, desktop webcams, denied permission, no camera, camera in use, low light, high zoom, keyboard, screen reader, file fallback, slow upload, and privacy-sensitive cancellation.

Common Generated-UI Mistakes

• Opening the camera automatically on page load or hover.
• Treating the shutter button as final upload for consequential tasks.
• Hiding the live preview, active camera state, stop control, or selected camera.
• Blocking the workflow when camera permission is denied even though upload or manual entry would work.
• Leaving the camera stream active after close, cancel, navigation, or submit.
• Using camera capture when a normal file upload or text field would be simpler and less invasive.
• Saving sensitive captured media or metadata after users cancel.
• Showing quality errors only after final submission instead of during preview or review.

Critique Questions

• What explicit user action starts the camera, and what purpose text appears before permission?
• What can users do when camera permission is denied, the camera is already in use, or the browser does not support capture?
• Does the preview show active camera state, selected camera, framing guide, and quality guidance?
• Is the shutter action separate from final upload or submission, and can users retake or replace the capture?
• When are media tracks stopped, and how is unsaved sensitive media cleared?
• Which metadata, images, frames, or thumbnails are stored, for how long, and who can access them?
• Is this really camera capture, or would file upload, permission request, full-screen takeover, or sensitive-data reveal own the main problem?