Devices
Design for Capabilities, Not Logos
A device matrix should describe what an application can observe, render, and interact with—not assume that every phone, headset, or pair of glasses behaves the same.
A capability profile
Useful capability fields include tracking modes, field of view, hands or controllers, depth, scene mesh, camera access, eye gaze, persistent anchors, geospatial localization, passthrough, display type, compute class, network conditions, and thermal limits. The client reports observed capabilities at runtime; the backend may return device-appropriate content or workflows.
Capabilities should be required, preferred, or optional for each feature. This makes fallbacks explicit. A placement tool may require six-degree-of-freedom tracking, prefer depth, and optionally use hands.
Phones and tablets
Handheld devices offer broad reach, familiar touch input, cameras, GPS, and strong mobile compute. They work well for guided AR, scanning, wayfinding, and field workflows. Their limits include arm fatigue, a narrow window into the scene, variable depth support, and distraction while walking.
Design short sessions, clear map fallbacks, and touch controls that do not require precise one-handed movement. Preload assets and handle thermal or battery constraints in sustained camera experiences.
Headsets and glasses
Headsets can provide persistent stereo views, tracked hands or controllers, and room-scale interaction. Optical or video passthrough, field of view, comfort, input, and platform capabilities vary substantially. Glasses may prioritize lightweight, glanceable information over dense immersive scenes.
Use the least intrusive presentation that supports the task. Keep essential controls reachable, avoid blocking the environment, and provide a non-immersive route for settings, account recovery, and detailed text.
Sensors and companion systems
External cameras, beacons, GPS receivers, robots, or industrial sensors can improve localization and scene state. Their data needs the same frame, time, calibration, and confidence treatment as device sensors. A spatial API can fuse these sources while preserving provenance.
Plan for partial availability. A system should explain when an external source is offline and how that changes accuracy or available actions. Do not silently substitute lower-quality data for safety-critical workflows.
Content and performance tiers
Device-aware delivery can select texture formats, model detail, effects, tile density, and update rate without changing durable entity identity. Use measured capability tiers rather than user-agent strings alone. A standalone headset and a tethered system may share an API while receiving different assets.
Instrument time to first useful view, decode time, memory, frame timing, battery, and thermal behavior. Performance is part of interaction quality; late or unstable content can be more harmful than lower visual fidelity.
Privacy and visible state
Devices may observe location, gaze, hands, rooms, and bystanders. Request sensitive capabilities at the moment of value, minimize retention, and make recording or sharing visible. The application should communicate when mapping, localization, or collaboration is active.
Use product-level permissions and scopes in addition to operating-system prompts. A user who grants camera access for local placement has not automatically granted permission to upload a room scan or share an anchor publicly.
Continue the field guide
Turn Spatial Data Into a Reliable Contract
Use the journal for implementation patterns, standards context, engine integration, and platform-specific design decisions.
Read the Spatial Systems Journal