Spatial Interaction Design Guidelines

Let people know where objects are, who is selected, what is being changed, and let them be able to find their way back to their own work.

These guidelines apply to products in which position, orientation, depth, scale, or spatial relationships participate in task input and outcomes, including desktop 3D editing, model inspection, furniture layout, digital-twin consoles, and spatial workspaces. Interfaces that use shadow or perspective only as decoration, where the task remains entirely ordinary flat operation, do not automatically apply. The rules do not presuppose any one specific device among mouse, touch, ray-casting, or direct grasping, nor do they require a simple product to implement a full 3D editor.

Six principles comprise 36 rules, covering understanding, selection, transformation, navigation, organization, saving, and recovery. Design Token expresses reusable decisions; reference sources state the basis and evidence boundaries.

1. Principles and applicability judgment¶

Each rule's direct obligation belongs to one principle: S1 governs expression, S2 governs targets, S3 governs transformation results, S4 governs viewpoint, S5 governs organization and saving, S6 governs control channels and participants. A single mechanism can serve multiple obligations. Each feature first declares observation/editing, single-object/multi-object, precise/free, personal/shared, and persistent/temporary, and then records the applicable rules; unknown or untested capability does not equal not applicable.

MUST / MUST NOT / MUST NOT are hard constraints; SHOULD / SHOULD NOT permit deviation after the reason, an alternative, and evidence are stated. An independent hard constraint in the main text is not weakened by a heading marked "SHOULD". Boundaries delimit the scope of application; design applications, verification, and counterexamples do not prescribe a single interface form. "Cannot" expresses a capability limitation. Verification checks both missing requirements and excessive interruption.

2. Rule quick reference¶

3. Rules in detail¶

S1 Spatial relationships are understandable¶

This principle constrains the expression of coordinates, scale, depth, and relationships.

S1-1Coordinate reference and direction have explicit meaningMUST¶

In one sentence: Coordinate reference and direction have explicit meaning.

Applies toposition or direction participates in the task.

RuleThe product MUST declare the scene origin, axis directions, length unit, and the reference for displayed orientation; object-local, parent, and view coordinates MUST be distinguishable. Coordinate conversion MUST record handedness, axis direction, unit, and transform order together; under negative scaling and parent changes, position change, direction change, and normal handling MUST be separately discernible. When presenting "left, up, front," it MUST be possible to determine relative to what; switching the reference MUST NOT silently rewrite the same object's spatial facts. When an imported coordinate convention is incompatible, convert first or block use — sharing the name "world coordinates" does not constitute evidence of source compatibility.

Boundary conditionsa permanently displayed coordinate axis is not required; expand it only when precise operation or orientation ambiguity is involved. Display precision MUST NOT be taken as underlying computational precision.

Design applicationafter selecting an object, display the current reference and axis direction, with textual numeric values provided.

Verification examples

• User side: after rotating the view, the user can tell that the object's "up" differs from the screen's "up".
• Implementation side: verify import, conversion, display, and export consistency using a known coordinate model; check export and undo against the actual object transform.

CounterexamplesUnder-delivery — rotating the view changes the world axes into the screen axes; over-delivery — every time a model is viewed, the user is required to learn the matrix.

S1-2Real scale is kept separate from observation zoomMUST¶

In one sentence: Real scale is kept separate from observation zoom.

Applies todisplaying size or allowing zoom.

RuleMUST distinguish the model's real size, object scaling, and viewpoint magnification; display units, conversions, and precision. Changing the observation magnification MUST NOT modify the object size; for scale-sensitive tasks, the real object MUST NOT be auto-scaled without notice. When data the measurement depends on is unknown, false-precision values MUST NOT be displayed.

Boundary conditionsartistically free proportions may use relative units, but MUST NOT imply real-object measurement precision.

Design applicationdimension labels update with the object; view zoom is fed back separately.

Verification examples

• User side: zoom in to observe a chair, then verify the chair's width has not changed.
• Implementation side: test unit conversion, negative and non-finite input, and the difference between displayed rounding and the actual value.

CounterexamplesUnder-delivery — pulling the camera closer is recorded as the furniture growing larger; over-delivery — every scroll-wheel zoom pops up a size confirmation.

S1-3Depth and occlusion provide consistent cuesMUST¶

In one sentence: Depth and occlusion provide consistent cues.

Applies tofront-back relationships affect understanding or operation.

RuleMUST make occlusion, perspective, size, and auxiliary cues express a consistent front-back relationship. Occluded or transparently displayed objects MUST retain identity and hierarchy cues; select-through is an operation mode and cannot be allowed to covertly change the rendered meaning of depth.

Boundary conditionsengineering cross-section, perspective-through, and other analysis modes may change appearance, but the mode and its scope MUST remain discernible.

Design applicationwhen selecting an occluded object, use outline, cross-section, or a list to locate it.

Verification examples

• User side: judge the front-back order of adjacent parts from different angles, and still know what is selected after entering a see-through mode.
• Implementation side: test transparent objects, coplanar objects, and clipping planes; hit-testing and display rules are each explicable.

CounterexamplesUnder-delivery — seeing an object behind still always selects the undisplayed mask in front; over-delivery — making every object float continuously just to prove depth.

S1-4Spatial relationships can be read semanticallyMUST¶

In one sentence: Spatial relationships can be read semantically.

Applies tocontainment, adjacency, connection, or positional relationships determine the task.

RuleMUST provide key objects with a stable name, state, and the necessary relationship expression, along with a query path that does not depend on fine-grained spatial discrimination. Objects with the same name MUST be disambiguable; color, orientation, or distance alone MUST NOT serve as the sole identifier.

Boundary conditionsreading out every vertex is not required; semantic granularity is determined by the task object.

Design applicationthe object list supports "which group it belongs to, what it is next to, whether it is currently operable".

Verification examples

• User side: find the target through the list, read its relationships, and locate it in the scene.
• Implementation side: check that object identifiers are separated from display names, that renaming does not lose references, and that semantic state updates with operations.

CounterexamplesUnder-delivery — only saying "move the red one"; over-delivery — reading out every geometric detail to the user at once.

S1-5State changes can be locatedMUST¶

In one sentence: State changes can be located.

Applies toa user-perceptible change occurs to a spatial object.

RuleMUST distinguish object change, viewpoint change, and selection change; when an important result occurs outside the field of view, provide a locatable receipt without forcing an automatic jump. Motion feedback SHOULD explain the change without obscuring the content awaiting operation; the result MUST still be understandable when dynamic effects are reduced.

Boundary conditionsreporting every frame is not required; continuous dragging may consolidate feedback, but the committed result must be explicit.

Design applicationmark the moved object in the list, providing location without snatching the viewpoint.

Verification examples

• User side: after a remote object changes, know which object changed while retaining the current viewing position.
• Implementation side: verify that events are bound to the object, the operation, and the committed result; feedback remains complete when animation is reduced.

CounterexamplesUnder-delivery — a distant object is deleted with no result notice at all; over-delivery — forcing the camera to chase every object a collaborator moves.

S1-6Spatial representation matches task precisionSHOULD¶

In one sentence: Spatial representation matches task precision.

Applies todense scenes, complex models, or precision tasks.

RuleSHOULD provide an overview, local, cross-section, or simplified representation suited to the task, and display the effect of simplification. Simplification may reduce rendering and cognitive load, but display precision MUST NOT be passed off as measurement precision; return to detail while retaining location and selection.

Boundary conditionsnot every product is required to have a professional cross-section tool; when only one representation is supported, it must be shown capable of completing the task.

Design applicationcomplex models default to an overview; enter local view after locating a part.

Verification examples

• User side: after switching to a simplified display, still find the same part and complete the allowed measurement.
• Implementation side: check the identifier mapping between the simplified layer and the source data; the geometric source used for measurement is traceable.

CounterexamplesUnder-delivery — outputting a precise measurement value using low-precision proxy geometry; over-delivery — offering ten view modes for viewing a single object.

S2 The operation target is determinable¶

This principle constrains candidates and the selection set.

S2-1Hit range matches feedbackMUST¶

In one sentence: Hit range matches feedback.

Applies topointing or direct selection exists.

RuleMUST declare hittable objects, hit regions, and priority, distinguishing pre-select, selected, operating, non-operable, and committed. Enlarging a hit region MUST NOT encroach on adjacent targets without a rule; feedback MUST match the object that actually receives the action.

Boundary conditionsfeedback may be provided by the platform or the product; a fixed aperture or ray is not required.

Design applicationpre-select displays the object name; the operated object's identity is retained after pressing down.

Verification examples

• User side: clicking a dense small target, pre-select matches the result; a disabled object does not pretend to be operable.
• Implementation side: test adjacent hit regions, zoom boundaries, and changes in input precision.

CounterexamplesUnder-delivery — highlighting A but handing the action to B; over-delivery — flashing all candidates simultaneously.

S2-2Occluded candidates can be disambiguatedMUST¶

In one sentence: Occluded candidates can be disambiguated.

Applies tooverlapping, nested, or transparent objects can be selected.

RuleMUST provide a predictable front-back hit order, and allow switching among ambiguous candidates or specifying via a list. Whether hidden, locked, or cross-section-invisible objects participate in hit-testing MUST be explicit; the user cannot be required merely to maneuver to some incidentally clickable spot.

Boundary conditionswhen there is only one valid candidate, a selection menu need not be shown.

Design applicationa short action switches candidates, showing name and outline; expand a list only for complex ambiguity.

Verification examples

• User side: select a specified part behind an occlusion without moving or deleting the object in front.
• Implementation side: verify candidate ordering is stable, and that hiding and locking policy is consistent with state.

CounterexamplesUnder-delivery — always able to select only the frontmost shell; over-delivery — popping a candidate list on every single click.

S2-3Selection level and set scope are visibleMUST¶

In one sentence: Selection level and set scope are visible.

Applies togroups, sub-objects, or multi-select are supported.

RuleMUST let the user know whether the whole, a part, or multiple objects are selected; entering a sub-level, joining, and leaving a set each have explicit feedback. Before a batch operation, the affected set must be determinable; the rule for skipping non-operable members or failing the whole batch MUST be explicit.

Boundary conditionsconfirming every batch action is not required; a reversible routine operation may execute directly and state its result.

Design applicationbreadcrumbs express hierarchy; count and outline express the selection set.

Verification examples

• User side: select two objects within a group and move them; other members remain unchanged.
• Implementation side: test empty sets, mixed permissions, and de-duplication when an ancestor and its descendant are selected simultaneously.

CounterexamplesUnder-delivery — a group and a single piece look identical, causing the whole group to be moved by mistake; over-delivery — confirming piece by piece before moving two objects.

S2-4The target stays stable during an operationMUST¶

In one sentence: The target stays stable during an operation.

Applies todragging, input, or continuous adjustment occurs after selection.

RuleMUST lock the target's identity and participating set at the start of an operation; passing over other objects, occlusion changes, asynchronous refreshes, or new input arriving MUST NOT covertly swap the target. If the target is deleted, loses permission, or cannot be resolved, terminate the operation and state what portion was already committed.

Boundary conditionslocking the target does not mean a long-term lock on collaborators; control authority is handled per S6-6.

Design applicationretain the grasped identity while dragging; hover changes do not change the operated object.

Verification examples

• User side: after dragging across multiple objects, still moving the original object.
• Implementation side: inject target deletion and candidate reordering; verify the operation ID and object ID remain unchanged.

CounterexamplesUnder-delivery — dragging onto another object switches to grabbing it instead; over-delivery — selecting once permanently blocks anyone else from editing.

S2-5Off-screen and unreachable objects can be retrievedMUST¶

In one sentence: Off-screen and unreachable objects can be retrieved.

Applies toan object may move out of view or become occluded.

RuleMUST provide a retrieval or recall entry that does not depend on the target's current visibility; distinguish locating the viewpoint from moving the object. Retrieval MUST NOT bypass permissions or release a lock; nonexistent, invisible, and not-yet-loaded MUST be fed back separately.

Boundary conditionsshort-lived decorative elements do not need persistent retrieval; task outcomes MUST be enumerable.

Design application"view" in the list moves the viewpoint; "move to workspace" previews the object's change.

Verification examples

• User side: retrieve an object that was placed far away; choosing to only view it leaves its position unchanged.
• Implementation side: test unloading, permission changes, missing objects, and extreme coordinates.

CounterexamplesUnder-delivery — an object falling out of view is treated as deleted; over-delivery — any off-screen object automatically returns to the center of view.

S2-6Near/far selection handoff is understandableMUST¶

In one sentence: Near/far selection handoff is understandable.

Applies tomultiple distances or selection methods are supported.

RuleMUST define the availability conditions and handover order for direct contact, ray, mouse, or list selection; the handoff MUST NOT re-trigger an action, jump the object, or treat a pre-select as a commit. When far-end precision is insufficient, provide zoomed observation, fine control, or semantic designation.

Boundary conditionsnot every device is required to support every method; a missing capability MUST NOT appear in an available state.

Design applicationprompt that direct operation is available when approaching an object; maintain the target and uncommitted state during the switch.

Verification examples

• User side: the same object goes from far-end selection to near-end adjustment, producing only one commit.
• Implementation side: test handoff threshold round-trips, two inputs occurring simultaneously, and method failure.

CounterexamplesUnder-delivery — a ray and direct touch each separately trigger the same action twice; over-delivery — forbidding the user from approaching the object just to avoid a switch.

S3 Transformation results are predictable¶

This principle constrains the semantics and result of a single object transformation.

S3-1Transform axes and degrees of freedom are recognizableMUST¶

In one sentence: Transform axes and degrees of freedom are recognizable.

Applies tomove, rotate, or scale is supported.

RuleMUST make the current operation, reference frame, allowed axes or planes, and constraints explicit; the control direction MUST match the result. When switching reference frame or constraint, retain an explicable current preview; if continuous mapping is impossible, complete or cancel the operation first.

Boundary conditionsa product that only offers constrained translation need not provide a six-degrees-of-freedom tool.

Design applicationshow only the currently allowed controls; numeric fields use the same reference as the controls.

Verification examples

• User side: a rotated object moves along its local axis, and after switching to the world axis the direction is predictable.
• Implementation side: use a known transform to verify local/world mapping, constraints, and input-output consistency.

CounterexamplesUnder-delivery — the control shows the local axis but moves along the world axis; over-delivery — every task requires manually choosing a coordinate system.

S3-2The rotation and scaling center is explicitMUST¶

In one sentence: The rotation and scaling center is explicit.

Applies torotation or scaling is allowed.

RuleMUST determine the pivot's source and location; for multi-select, state whether it is around a common center or each object's own origin. Changing the pivot itself MUST NOT unexpectedly move the model; the center MUST be visible before or during the transform. When a custom pivot's dependency is lost, it MUST NOT silently fall back to the world origin.

Boundary conditionssimple tasks may fix the pivot to the object center without exposing arbitrary pivot editing.

Design applicationmark the pivot with a center marker and name; show a preview before switching.

Verification examples

• User side: rotate a table around a corner of it; the corner's position holds to the agreement.
• Implementation side: test multi-select, parent-level scaling, and custom-center failure.

CounterexamplesUnder-delivery — rotating around the default origin sends the object flying away; over-delivery — every rotation requires placing the pivot first.

S3-3Snapping and constraints can be understood and releasedMUST¶

In one sentence: Snapping and constraints can be understood and released.

Applies togrid, point, edge, face snapping, or other geometric constraints are enabled.

RuleMUST state the snap candidates, the actual landing point, and the constraint in effect; keep the choice predictable as candidates approach, and allow temporary release or adjustment. Entry and release conditions MUST be defined separately to avoid jitter. When a constraint cannot be satisfied, it MUST NOT quietly deviate while still displaying success.

Boundary conditionsa hard business constraint may forbid release, but the reason MUST be explained and a legitimate adjustment path provided.

Design applicationpreview the snap line and distance; allow returning to the constraint after temporary free movement.

Verification examples

• User side: choose a target when two candidates are adjacent; releasing the snap allows continuous fine adjustment.
• Implementation side: test candidate stability at threshold boundaries, round trips, units, and constraint-solving failure.

CounterexamplesUnder-delivery — magnetic snap keeps jumping between two surfaces; over-delivery — forcing every movement to snap to the grid.

S3-4Precise input and continuous operation produce consistent resultsMUST¶

In one sentence: Precise input and continuous operation produce consistent results.

Applies tothe task requires precise position, angle, or size.

RuleMUST provide fine adjustment or numeric input commensurate with task precision, labeling unit, range, rounding, and unachievable precision. Control dragging and numeric editing MUST use the same object state; validate non-finite values, out-of-range values, and illegal scale before commit.

Boundary conditionsfree artistic creation is not required to reach engineering precision; whatever precision it does promise must still match its real capability.

Design applicationdragging completes coarse positioning; entering a distance performs fine adjustment, providing the current-versus-target difference.

Verification examples

• User side: enter a size in millimeters, switch units, then drag; the result is consistent and the error is knowable.
• Implementation side: check that display rounding does not overwrite a more precise underlying value; test zero, negative, and extreme values.

CounterexamplesUnder-delivery — displaying precision to a decimal that the position can never actually reach; over-delivery — rejecting all approximate values even for tasks with no precision requirement.

S3-5Preview, commit, cancel, and undo are kept distinctMUST¶

In one sentence: Preview, commit, cancel, and undo are kept distinct.

Applies toa spatial object or relationship may be changed.

RuleMUST distinguish a transient preview from a committed result, providing a cancel for the current operation and an undo applicable to reversible results. Cancel restores the state valid before the operation; undo scope MUST be explicit and MUST respect other valid modifications made in the meantime. Partial commits, external irreversible results, or conflicts MUST be truthfully stated, not falsely claimed as fully undone.

Boundary conditionsconfirming again after every drag is not mandatory; committing on release is acceptable, but the cancel entry must remain reachable.

Design applicationdragging shows a preview; releasing commits; undo affects only this transform.

Verification examples

• User side: after cancel, the object returns to its starting position; after undo, other already-accepted modifications remain.
• Implementation side: test batch partial failure, late responses, and operation interruption; verify the commit count.

CounterexamplesUnder-delivery — a failed release still shows "saved"; over-delivery — confirming every millimeter of a drag.

S3-6Operation gain and feedback support fine controlMUST¶

In one sentence: Operation gain and feedback support fine control.

Applies tocontinuous mapping, remote manipulation, or multi-hand operation exists.

RuleMUST declare the mapping from input motion to object motion, the fine-adjustment method, and change feedback; re-grasping or switching input MUST NOT cause a sudden jump. When two-hand input is reduced to one hand, hold, pause, or handoff MUST be defined; the system MUST NOT keep going by stale two-hand data. When overloaded, the system MUST NOT accumulate motion and then jump all at once.

Boundary conditionsthe mapping need not be one-to-one, but it must serve the task and remain predictable to the user; displaying a technical coefficient is not required.

Design applicationcoarse adjustment leads into fine adjustment; the current preview is retained across a re-grasp.

Verification examples

• User side: repeatedly grasp a distant object for small alignment adjustments without the object jumping.
• Implementation side: inject sampling reduction, delayed feedback, and single-hand failure; verify mapping continuity and discarding of expired events.

CounterexamplesUnder-delivery — releasing and re-grasping sends the object instantly to a new location; over-delivery — making every operation sluggish and uncontrollable in the name of stability.

S4 Viewpoint navigation is masterable¶

This principle constrains observation position, orientation, and navigation state.

S4-1Navigation and object operation are not confusedMUST¶

In one sentence: Navigation and object operation are not confused.

Applies tothe same input region supports both viewpoint and object changes.

RuleMUST make the current navigation or edit mode recognizable, and provide a discoverable way to switch. An accidental navigation touch MUST NOT directly modify an object; the edit state is maintained during navigation, and moving the viewpoint MUST NOT be recorded as an object transform.

Boundary conditionsgestures or key modifiers may be reused, but the mode MUST NOT be hidden behind memory alone.

Design applicationdragging the background orbits; dragging an object control transforms it; a status cue appears with the operation.

Verification examples

• User side: alternate between rotating the viewpoint and rotating an object, and be able to explain the difference.
• Implementation side: verify that viewpoint state and scene state are stored and undone separately.

CounterexamplesUnder-delivery — the same drag sometimes rotates the object and sometimes rotates the camera with no cue; over-delivery — forcing an exit from the editing task on every navigation.

S4-2Orbit, pan, and zoom have a stable referenceMUST¶

In one sentence: Orbit, pan, and zoom have a stable reference.

Applies tonavigation within a 3D scene is allowed.

RuleMUST define the orbit center, pan plane, zoom method, and boundaries; a center change MUST be predictable. When zoom changes field of view, camera distance, or observation magnification, retain understandable feedback, avoiding reverse motion after passing the target.

Boundary conditionsnot every parameter needs to be user-configurable; a navigation preset suited to the task may be provided.

Design applicationafter locating an object, orbit around it as the center; use the scene as the center for an overview.

Verification examples

• User side: observing a nearby part and a large scene, direction and speed do not suddenly reverse.
• Implementation side: test extreme near, extreme far, clipping boundaries, missing center, and different input sensitivities.

CounterexamplesUnder-delivery — zooming past an object keeps scrolling further away; over-delivery — requiring a work plane to be specified before every pan.

S4-3A lost viewpoint has a recovery entryMUST¶

In one sentence: A lost viewpoint has a recovery entry.

Applies tothe viewpoint may move far away, enter, or pass through content.

RuleMUST provide a recovery entry that does not depend on the current viewpoint position, covering both locating the selected object and an understandable overview. Recovering the viewpoint MUST NOT reset the model, the selection, or an uncommitted task; when it cannot be located, state that the object is missing or not yet loaded.

Boundary conditionssimple scenes may merge the overview and the initial viewpoint, without requiring two duplicate buttons.

Design applicationa persistent or directly callable "view selected" and "overview," retaining the return position.

Verification examples

• User side: after moving the viewpoint into the model or far from the scene, recover without reopening the file.
• Implementation side: inject extreme coordinates and an empty scene; the recovered viewpoint remains bounded and renderable.

CounterexamplesUnder-delivery — reopening the project is the only way to find the model again; over-delivery — automatic recovery keeps pulling back a user who is actively exploring.

S4-4Navigation retains orientation and return during the processSHOULD¶

In one sentence: Navigation retains orientation and return during the process.

Applies tospanning multiple spatial regions or continuously inspecting objects.

RuleSHOULD provide stable landmarks, a path, or viewpoint records, letting people know the current viewing region and return to a meaningful position. Locating an object and shared guidance MUST NOT unconditionally overwrite a person's own observation history.

Boundary conditionsa small scene completed in one screen need not provide a full navigation history.

Design applicationsave the most recent checkpoint; indicate the current level or region.

Verification examples

• User side: go from the whole into a part, then return to a previously viewed position.
• Implementation side: verify that return records handle object deletion and scene-scope changes compatibly.

CounterexamplesUnder-delivery — every time a location is made, the previously viewed position is lost; over-delivery — saving every single frame's viewpoint as a history item the user must manage.

S4-5Automatic viewpoint changes can be stoppedMUST¶

In one sentence: Automatic viewpoint changes can be stopped.

Applies toproviding animated navigation, a presentation camera, or following.

RuleMUST make the purpose and controller of automatic navigation recognizable, and allow timely stopping or exiting a follow. The automatic camera MUST NOT contend with the user's real-time input for control; after the user takes over, it MUST NOT continue rewriting the viewpoint, and resuming the follow MUST be initiated by an explicit action.

Boundary conditionsa brief locating move may complete directly, provided the user can return; confirming every camera change in advance is not mandatory.

Design applicationpreview the destination first; exit the follow and retain the current position when the user navigates.

Verification examples

• User side: during a presentation, look at a part on one's own without being pulled back on the next frame.
• Implementation side: test user input during automatic navigation, remote-control withdrawal, and a late camera event.

CounterexamplesUnder-delivery — every time the presenter turns their head, everyone's viewpoint is forcibly carried away; over-delivery — even a single ordinary locating action requires approval.

S4-6Clipping and intrusion are not disguised as data lossMUST¶

In one sentence: Clipping and intrusion are not disguised as data loss.

Applies tothe camera may approach, enter, or clip an object.

RuleMUST make clipping, hiding, not-yet-loaded, and object-nonexistent distinguishable; an observation limitation does not delete the object. When the task requires internal inspection, provide a declared cross-section or entry method; camera collision causing an unstoppable oscillation is prohibited.

Boundary conditionsordinary desktop model inspection need not simulate human-body collision; whether to prevent intrusion depends on the task.

Design applicationdisplay the cross-section state; provide an exit from the internal view and a way to locate the object.

Verification examples

• User side: when a close-up view of a model suddenly becomes invisible, determine why and recover.
• Implementation side: test near and far clipping, thin faces, empty models, and a loading-in-progress state.

CounterexamplesUnder-delivery — the camera entering the model displays "file corrupted"; over-delivery — forbidding all viewing of internal structure just to prevent intrusion.

S5 Spatial organization is recoverable¶

This principle constrains layout, parenting, and saving.

S5-1The initial layout is usable and explicableMUST¶

In one sentence: The initial layout is usable and explicable.

Applies tocreating, importing, or recovering spatial content.

RuleMUST determine the default position, orientation, and scale, avoiding key objects and controls; when placement is impossible, retain the content and provide a candidate or a pending-placement state. When the position source is unknown, the origin MUST NOT be treated as an already-verified suitable position.

Boundary conditionsthe system provides a usable default first; precise placement can then be adjusted by the user.

Design applicationa new object appears in the current workspace in a previewable state.

Verification examples

• User side: after importing objects of different sizes, they are visible, selectable, and do not cover all controls.
• Implementation side: test an empty scene, a dense scene, and missing coordinate data.

CounterexamplesUnder-delivery — an imported object lands extremely far away but is displayed as successful; over-delivery — requiring the user to fill in coordinates before every object appears.

S5-2Density and grouping preserve task structureSHOULD¶

In one sentence: Density and grouping preserve task structure.

Applies tomultiple objects or panels coexist.

RuleSHOULD define arrangement, density, grouping, and an over-limit policy, keeping key controls reachable. Automatic tidying SHOULD respect the user's spatial intent, and cannot break apart task-meaningful adjacency just for neatness.

Boundary conditionsexploratory free layout may keep an irregular arrangement, but a retrieval and recovery path is needed.

Design applicationpartition by task; when over the limit, collapse non-critical content rather than stacking indefinitely.

Verification examples

• User side: still able to find the current task when the declared object limit is reached.
• Implementation side: test continuous creation, group expansion, and density overload; key entries do not disappear.

CounterexamplesUnder-delivery — objects keep spreading until they occlude one another completely; over-delivery — automatic layout destroys all manual arrangement.

S5-3Parenting changes handle world position explicitlyMUST¶

In one sentence: Parenting changes handle world position explicitly.

Applies togrouping, attaching, binding, or unlinking relationships are supported.

RuleMUST state whether establishing and removing parenting preserves the world transform or the local transform, and display the consequence. How child objects are handled under parent movement, scaling, deletion, and failure MUST be explicit; an independent result MUST NOT be deleted merely because a parent reference became invalid. Circular parenting MUST be prevented or have an explicit legitimate model.

Boundary conditionsordinary grouping does not necessarily change the transform reference; organizational grouping must be distinguished from transform parenting.

Design applicationshow the expected landing point before binding; preserve the task-required spatial relationship by default.

Verification examples

• User side: attach an object to a rotated parent; the result matches the preview.
• Implementation side: test non-uniform parent scaling, deletion, circular dependency, and non-invertible transforms.

CounterexamplesUnder-delivery — an object suddenly jumps to the world origin after regrouping; over-delivery — every organizational grouping forces the user to understand the parent-child matrix.

S5-4User layouts have an explicit save scopeSHOULD¶

In one sentence: User layouts have an explicit save scope.

Applies tousers are allowed to adjust the workspace.

RuleSHOULD save the user's position, orientation, scale, and grouping choices, stating whether the save scope is session, project, or personal workspace. On recovery failure, retain the content and the layout intent, and provide re-placement. Automatic layout MUST NOT overwrite a saved user choice without notice.

Boundary conditionstemporary tools and transient prompts need not be saved; deviating from the saving recommendation requires a stated task rationale.

Design applicationdistinguish project layout from personal viewing settings, providing a restore-to-default.

Verification examples

• User side: after exiting and re-entering, recovery occurs within the promised scope, and missing resources can still be retrieved.
• Implementation side: test save failure, permission changes, partial recovery, and default-layout updates.

CounterexamplesUnder-delivery — everything must be rearranged on every entry; over-delivery — forcibly restoring to a layout that no longer applies.

S5-5Content and spatial presentation are saved separatelyMUST¶

In one sentence: Content and spatial presentation are saved separately.

Applies tospatial objects carry the user's work.

RuleMUST ensure that layout corruption, viewpoint loss, or an invalid external relationship does not directly delete content. Provide an enumerable content entry, distinguishing deleting content, removing from the current layout, hiding, and unloading; verify reference validity on recovery.

Boundary conditionsa purely decorative object generated temporarily may end with the session, but MUST NOT pass itself off as saved work.

Design applicationthe list retains unplaced objects; decide the position after recovering the content.

Verification examples

• User side: after clearing the layout, saved models and annotations can still be retrieved.
• Implementation side: corrupt layout references while retaining content storage; verify independent recovery and permission checks.

CounterexamplesUnder-delivery — a layout parsing failure directly clears the project; over-delivery — permanently saving even temporary decorations and stuffing them into the list.

S5-6Layout recovery and reflow results can be verifiedMUST¶

In one sentence: Layout recovery and reflow results can be verified.

Applies tobatch recovery, automatic reflow, or replacing the spatial reference.

RuleMUST state the scope of change and protect unaffected content; when recovery is incomplete, list the unrecovered items and the reason. When reflow is undoable, save the necessary state; undo must re-verify dependencies and cannot overwrite another party's already-completed valid edits.

Boundary conditionsa detailed report is not required for every recovery; normal completion may use a concise receipt, expanding only as needed for exceptions.

Design applicationpreview the set of changes; locate the exceptional items after completion.

Verification examples

• User side: after recovering part of a layout, continue working on the remaining content without redoing everything.
• Implementation side: inject partial absence, concurrent editing, and a late receipt; the result matches the actual set.

CounterexamplesUnder-delivery — recovering ten items succeeds for only eight but is written up as fully complete; over-delivery — even a minor reflow shows a lengthy diff report.

S6 Operation control is sustainable¶

This principle constrains input channels, control authority, and operation sessions.

S6-1Input mapping stays consistent and discoverableMUST¶

In one sentence: Input mapping stays consistent and discoverable.

Applies toone or more operation channels are provided.

RuleMUST define the input mapping for select, confirm, cancel, navigate, and transform, avoiding conflicts within the same context. Mode switches MUST be recognizable, and system-reserved actions take priority; custom actions provide a learning entry and an alternative.

Boundary conditionsdifferent hardware is not required to use the same physical action; task semantics must be consistent.

Design applicationgive a short prompt the first time a new operation is encountered, collapsing it on repeated use.

Verification examples

• User side: switching from mouse to keyboard or another input, know how to cancel the current operation.
• Implementation side: verify conflicting mappings, system interception, and device disconnection; the same event is not reused to commit twice.

CounterexamplesUnder-delivery — the cancel key performs a delete in a different panel; over-delivery — setting a full tutorial as a gate on every entry.

S6-2Interruption does not resume a stale actionMUST¶

In one sentence: Interruption does not resume a stale action.

Applies tomay be interrupted by losing focus, disconnecting, or switching tools.

RuleMUST distinguish input availability, operation preview, committed result, and task save. An interruption cancels an unfinished press-and-hold or drag, or enters an explicit, recoverable staged state; recovery re-establishes the input baseline and MUST NOT replay a stale action or treat reconnection as confirmation.

Boundary conditionsa collaborator or the server may keep changing; state the scope of the local pause.

Design applicationretain the result and draft after interruption; a new operation starts from the current state.

Verification examples

• User side: unplug the input device mid-drag; on reconnection there is no sudden movement.
• Implementation side: separately inject focus loss, tool replacement, and duplicate events; verify idempotent commits.

CounterexamplesUnder-delivery — recovery re-submits the last frame of action from before the disconnect; over-delivery — a brief loss of focus clears the entire task.

S6-3System control does not depend on the current spatial targetMUST¶

In one sentence: System control does not depend on the current spatial target.

Applies tothe user may enter a complex scene or an abnormal state.

RuleMUST make cancel, exit tool, save, and task recovery reachable in applicable contexts without depending on the current target being visible or selectable. Control feedback distinguishes request received from actually taking effect; a behavior that has not yet stopped MUST be truthfully stated.

Boundary conditionsa platform menu, keyboard, or auxiliary panel may be used; not every context needs it permanently present.

Design applicationprovide a directly callable command entry; retain minimal control during an exception.

Verification examples

• User side: still able to cancel and save when the target is occluded or the viewpoint is lost.
• Implementation side: inject a non-interactive primary view; verify the command channel against the actual execution result.

CounterexamplesUnder-delivery — the cancel button is attached to an object that has already vanished; over-delivery — the screen permanently piled with every system command.

S6-4Critical tasks have an equivalent operation pathMUST¶

In one sentence: Critical tasks have an equivalent operation path.

Applies tothe task depends on fine pointing, a specific posture, or complex synchronized motion.

RuleMUST provide a validated equivalent path — such as a list, numeric entry, step-by-step control, or assistive input — so that the population declared as supported can complete critical tasks. Time windows may be adjusted as needed; feedback does not rely solely on color, spatial audio, or fine motor skill.

Boundary conditionsan equivalent result does not require the same action; when a special physical skill is itself the goal, it MUST be declared in advance, while still retaining an exit and access to the outcome.

Design applicationbreak precise placement down into selecting the object, selecting the axis, and entering a numeric value.

Verification examples

• User side: complete selection, transformation, saving, and recovery using only the alternative path.
• Implementation side: compare the object, permission, and result across the two paths for consistency; assistive semantics do not omit state.

CounterexamplesUnder-delivery — treating help text as if it were an alternative operation; over-delivery — canceling all direct manipulation for the sake of an alternative input.

S6-5Private viewpoint and shared state are kept distinctMUST¶

In one sentence: Private viewpoint and shared state are kept distinct.

Applies tomultiple people jointly view or edit spatial content.

RuleMUST make explicit which objects, coordinates, and operations are shared, and which viewpoint, tools, and drafts affect only oneself. On joining, verify the shared reference; when not yet synced or unable to be mapped, operations that depend on a shared position are not allowed; pointing expresses a bound object or shared coordinate rather than one party's own screen coordinate.

Boundary conditionsparticipants are not required to see the same perspective; the same object and spatial relationship must be consistent.

Design applicationshared object operations are visible; personal camera and notes are independent; following a presentation requires explicitly entering it.

Verification examples

• User side: two people point out the same part from different viewpoints; a personal camera move does not change the other person's view.
• Implementation side: inject a missing shared reference and sync delay; block an invalid location while preserving personal viewing.

CounterexamplesUnder-delivery — assuming two people's identical screen coordinates mean they are pointing at the same object; over-delivery — forcing everyone to use the same camera.

S6-6Concurrent transforms and late-arriving results can be handledMUST¶

In one sentence: Concurrent transforms and late-arriving results can be handled.

Applies tomultiple input sources or participants may modify the same spatial object.

RuleMUST declare the policy for claiming, merging, or rejecting, feeding back the controller and the scope of effect. Disconnection, loss of permission, and claim expiry MUST have a release-and-reacquire process; a late-arriving result MUST NOT silently overwrite a newer valid edit. Undoing another person's result requires corresponding permission and an explicit scope.

Boundary conditionsnot every scenario needs an exclusive lock; where merging is possible, a verifiable merge semantics MUST be defined.

Design applicationan object being transformed shows its controller; on conflict, retain one's own preview for reapplication.

Verification examples

• User side: when two people drag the same object simultaneously, know whose result takes effect and be able to continue.
• Implementation side: test out-of-order arrival, duplication, reconnection, and revocation; verify the object revision identifier and operation attribution.

CounterexamplesUnder-delivery — whichever packet arrives last unconditionally overwrites the current result; over-delivery — locking the entire scene as long as anyone is online.

4. Terminology and state¶

Appendix A: Verification checklist¶

For every applicable clause, retain the design decision, the mechanism check, and user-task evidence together. Not-applicable requires proof of the condition; deviating from a SHOULD item requires an alternative; untested MUST NOT be marked as passed. The scenarios below add no new obligations to the main text.

Appendix B: Evidence and value boundaries¶

Task taxonomies, platform operation practices, and accessibility requirements for 3D interaction are provided as references; the strength of the guidelines, the parameter structure, and the recovery procedures are design judgments. For sources and the actual scope read, see reference materials. A given piece of software's shortcut keys, a particular device's pointing precision, or an example tolerance is not taken as a universal requirement.

Tasks should separately measure completion rate, mis-selection, transform error, recovery cost, and unnecessary interruption. Record scene complexity, object size, input device, observation distance or display size, target population, and measurement method; a single successful demo does not prove usability across the whole scope. This repository's documentation itself provides no on-device testing conclusion.

---

Release acceptance scenarios¶

The following scenarios turn existing clauses into re-checkable acceptance inputs, without setting an additional universal performance threshold. Select according to the product's applicable capability, supplementing real devices, users, input sequences, and evidence; record the reason when not applicable, and do not record as passed what was not executed.

Each scenario separately verifies the configured effective values, the execution record, and a user-understandable result. Retain version, target, event timestamp, failure scope, and recovery result; an unknown external result is not filled in as either success or failure.