Mobile Context Interaction Design Guidelines
Let people still understand the next step, keep the work they have already done, and resume at the right moment while attention, hand capability, and environment keep changing.
6 principles · 13 rules · MUST 0 · SHOULD 0
Contents
Let people still understand the next step, keep the work they have already done, and resume at the right moment while attention, hand capability, and environment keep changing.
Companion files: Design Token · Reference Sources.
1. Scope and how to read
These guidelines apply to interaction on portable devices such as phones and handheld terminals while walking, carrying objects, changing grip, riding in vehicles, transitioning between places, glancing briefly, being in public spaces, under weak connectivity, and with frequent interruption by real-world activity. A person's body can be stationary while attention or available hands remain constrained; using a phone does not necessarily place someone in the mobile context these guidelines address.
These guidelines do not treat activity recognition as driver identification, and stillness, simplified modes, or completed walking tests do not demonstrate safety for driving, cycling, or hazardous work. Products MUST declare their scope of support according to the actual tasks, environments, and populations.
MUST denotes an acceptance obligation; MUST NOT is an equally strong prohibition; SHOULD is adopted by default, with deviations requiring a recorded rationale and an equivalent alternative; MAY is optional. Each independent obligation clause is judged on its own. Applicability and boundaries qualify requirements; examples and candidate values add no obligations.
Define the user outcome and the real-world interruption points before designing the interface. Manual simplification, automatic saving, and returning to the task MAY work without sensors; automatic inference is enabled only when there is a proven benefit and the user can correct it. Rules and fields are this project's design; the scope of source support is in the reference.
2. Principles and rules
| Principle | Focus and direction | Rules |
|---|---|---|
| MC1 Attention can shift at any moment | Information judgment and task segmentation | MC1-1, MC1-2 |
| MC2 Operation adapts to the body's current condition | Reachability, input intent, and stable targets | MC2-1, MC2-2 |
| MC3 Context judgment is explainable and correctable | Context facts, user choice, and adaptation | MC3-1, MC3-2 |
| MC4 Environment changes leave a usable path | Input/output alternatives and public content | MC4-1, MC4-2 |
| MC5 Judgment survives uncertain location and connectivity | Place judgment, caching, and offline action | MC5-1, MC5-2, MC5-3 |
| MC6 Interruption recovery loses no intent | Saved state, pending operations, and outcomes | MC6-1, MC6-2 |
3. Full rules
MC1-1A brief glance suffices to identify the object and the next step
Applies tothe user needs to switch attention between the device and the real environment.
Requirement: the current object, key state, and necessary next step MUST be expressed first, including the units, direction, freshness, and consequences the judgment needs. Key negations and object differences MUST NOT be mechanically truncated; when font size is enlarged, content MUST NOT be force-fitted by shrinking text. Important results and exceptions that need handling MUST be viewable again; a transient toast, animation, color, or sound MUST NOT be the sole expression.
Boundaries: read-only tasks MAY have no primary action; the information budget does not restrict necessary facts, exit, or detail. No uniform reading duration is prescribed, and short completion time does not demonstrate safe use.
Design applicationarrival information shows station name, direction, and update state together; previously saved results remain viewable after returning.
Verificationuser side — restate the state after long text, bright light, enlarged text, and gaze switches; implementation side — check that content, freshness, accessibility semantics, and result review correspond to the real object.
Counterexamplesunder-delivery — only "5" is shown with no object or unit; over-delivery — the first screen requires reading a full paragraph of background before continuing.
BasisMC-S1 supports the attention and operation constraints; the information hierarchy is project derivation.
MC1-2Tasks can pause at meaningful points
Applies toinput, comparison, confirmation, or stepwise processing may be interrupted by real-world activity.
Requirement: tasks SHOULD be segmented into understandable parts that reduce repeated input and unnecessary decisions; saving, exit, and continuation paths consistent with the promise MUST be provided. Complex judgments that need sustained attention SHOULD allow later handling and MUST NOT be forced into hasty submission by a short countdown. Any necessary time limit MUST state the actual reason, the consequence of expiry, and what remains recoverable; an expiry problem MUST NOT be dodged by indefinitely extending authorization.
Boundaries: short steps do not mean removing key consequences. Simple actions need no uniform confirmation step; entering detail, exiting, and switching back to the task MUST NOT trigger submission.
Design applicationwhen a queue number is called and the device is put away, unsubmitted content is saved as a draft; on return, "filled up to here" and the next item are shown.
Verificationuser side — after being interrupted, can state where they got to and what is next; implementation side — check that segmented saving and exit take effect and that expired intent is still intercepted.
Counterexamplesunder-delivery — the slightest interruption forces refilling the entire form; over-delivery — every field triggers a confirmation dialog and a forced save.
BasisMC-S1, MC-S2 support the context and time-limit issues; task segmentation is project derivation.
MC2-1A reachable path remains under one-handed use, carried objects, and grip changes
Applies tohands are occupied, range of motion is limited, there is shaking, or grip changes.
Requirement: primary actions and cancel/back MUST be reachable under the declared conditions of use. Fine dragging, multi-finger, or device-motion actions that are not essentially necessary MUST have alternatives; device-motion triggering MUST be disableable. Hit areas follow the applicable platform requirements and are verified against real grips, and MUST NOT be enlarged to the point of competing with one another. Left/right hand and explicit user choice MUST be respected; voice input MUST NOT be the sole answer to all physical constraints.
Boundaries: do not assume the user always has two available hands, and do not treat object-holding simulation as equivalent to all physical capability. When a task is unavailable at the moment, keep progress and exit; do not permanently lock the whole product.
Design applicationswiping can also be done as stepped tapping; one-handed mode lets the user choose the operating side, and changing grip does not force starting over.
Verificationuser side — complete tasks with actual left/right hands, carried objects, and assistive technology; implementation side — check hit areas, system-gesture conflicts, focus, and alternative paths.
Counterexamplesunder-delivery — the only submit action requires a two-finger drag; over-delivery — all useful actions hidden "for protection."
MC2-2Targets stay stable during input; mistakes can be canceled
Applies totapping, scrolling, hand changes, automatic layout, and jostling interfere.
Requirement: from touch-down to release or cancellation, targets MUST NOT move due to context changes. Ordinary single-finger actions MUST have mistouch avoidance, cancellation, or appropriate undo; irreversible actions MUST NOT execute on touch-down and require protection beforehand proportionate to the consequence. Automatic updates MUST NOT keep stealing focus, replacing the object under confirmation, or turning the original target position into another dangerous action.
Boundaries: an essentially necessary touch-down response MUST state its reason, the functions involved, and its mitigation, and is not exempt from irreversible-action protection. When identity or permission lapses, affected gestures MAY be canceled immediately with an explanation, without waiting for reflow to tighten things. Business duplicate prevention is governed by MC6-2.
Design applicationafter a press is paused, an activity-recognition change still lets the current legitimate input complete, then switches layout at a safe boundary.
Verificationuser side — can cancel a mistouch and understand the result of cancellation; implementation side — inject updates mid-press, permission lapse, finger moving away, and rapid consecutive independent inputs.
Counterexamplesunder-delivery — the button turns into Delete while it is being pressed; over-delivery — every light action demands a long press and repeated confirmation.
BasisMC-S4 supports pointer cancellation; target stability is project derivation.
MC3-1Context facts carry source, limits, and collection boundaries
Applies toactivity, location, hand state, or environment information affects functionality.
Requirement: activity, input capability, environment, and business eligibility MUST be distinguished; a single moving flag MUST NOT stand for all conditions. Facts MUST carry source, device, observation time, and validity; inference MAY yield unknown, and "in a vehicle" MUST NOT be used to infer driver identity. When collection is needed, the purpose, permissions, retention scope, and stop conditions MUST be stated; after refusal or revocation, the related collection stops and functions that do not depend on it remain.
Boundaries: trajectories are not retained long-term, the microphone is not kept open, and attention scores are not created by default just to simplify layout. Manual selection MAY be used; user settings MUST NOT masquerade as sensor observations.
Design applicationwhen activity recognition is missing, keep the layout; when location is denied, allow typing the place. Status queries do not silently expand collection.
Verificationuser side — understand the basis of the adaptation and the usable path after refusal; implementation side — test missing source, expiry, out-of-order events, and listening/saving/uploading after revocation.
Counterexamplesunder-delivery — riding in a vehicle gets classified as the driver and vehicle-related actions execute automatically; over-delivery — an ordinary view demands every context permission first.
BasisMC-S5, MC-S6 provide capability background; the inference boundaries are project requirements.
MC3-2Automatic adaptation is stable; user choice prevails
Applies toinformation density, layout, or input change automatically based on activity or environment.
Requirement: entries for explicit modes, stopping automatic adaptation, and restoring defaults MUST be provided, with their scope of effect stated. Explicit user choice prevails over inference but does not loosen permissions or business constraints. Entering and exiting a mode MUST have clear stability conditions; candidate changes, unknowns, or expiry MUST NOT trigger repeated reflow. Without valid inference, keep the user's choice; with no choice on record, keep the current legitimate layout; the default mode is used only on first launch with no history.
Layouts take effect only after touch release and the safe saving of edits; privacy tightening and revocation immediately constrain the corresponding outputs and unexecuted actions. The benefit of automation MUST be verified through task comparison against manual/ordinary modes.
Boundaries: manual ordinary mode does not prove the surroundings are safe. Stopping inference does not cancel unrelated capabilities, nor require recalibration on every launch.
Design applicationafter a user carrying bags chooses simplified mode, a brief stop does not jump back to the complex interface.
Verificationuser side — discover and correct misjudgment, and the choice persists; implementation side — replay start moving, stop, move again, activity missing, and late events, checking settle time and effect points.
Counterexamplesunder-delivery — the system keeps overriding the manual choice; over-delivery — anti-jitter makes simplified mode impossible to exit.
BasisMC-S1, MC-S5; the priority order is project derivation.
MC4-1When the environment disables a channel, a fallback remains
Applies tobright light, noise, wet hands, gloves, vibration, no microphone, or imperceptible feedback.
Requirement: core tasks MUST declare the inputs and outputs they need and their behavior when those are missing: an on-device alternative, save-for-later, or an explanation that completion is impossible. Results MUST NOT depend on a single transient feedback; declared supported paths such as screen readers and hardware keys MUST be able to complete the corresponding tasks and exit. Combined conditions MUST be assessed together; alternative paths MUST NOT depend on another already-disabled capability.
Boundaries: devices are not required to add hardware that does not exist. Speaker volume or the microphone MUST NOT be raised automatically to compensate for the environment; when reliable operation is impossible, stopping and resuming later is allowed.
Design applicationwhen it is noisy and offline, cloud speech recognition is not treated as the fallback; instead the draft is saved, with local input or a later entry point retained.
Verificationuser side — discover and complete the alternative path; implementation side — combine bright light/enlarged text, no mic/no network, wet hands/restricted touch, and check results and focus.
Counterexamplesunder-delivery — with the mic disabled, the only input button is still voice; over-delivery — every failure requires leaving the task for a full setup wizard.
MC4-2Public-environment changes do not widen content exposure on their own
Applies tobystanders, lock screen, notifications, snapshots, screen readers, or audio routing change.
Requirement: sensitive content MUST define its public preview and deliberate-reveal conditions. Screen, images, accessibility semantics, app-controllable snapshots, and automatic speech MUST follow valid eligibility; a lapse converges promptly. Headphone disconnection MUST NOT automatically switch to sensitive speaker playback; environment inference cannot replace explicit preference and permission. Authorized users MUST still have an accessible path to view the content deliberately.
Boundaries: quiet or stationary surroundings do not prove privacy; assistive-technology access does not equal automatic public display. Platform-uncontrollable output limits MUST be stated; complete anti-shoulder-surfing cannot be promised.
Design applicationheadphone disconnect pauses sensitive playback and keeps a private viewing path; returning to the public preview does not expose the expanded detail.
Verificationuser side — can control reveal and exit, and assistive-technology users are not excluded; implementation side — test route switching, lock, subject change, preview, and background snapshots.
Counterexamplesunder-delivery — the screen is occluded but audio still announces loudly; over-delivery — all public information is hidden with no way to continue.
Basisproject derivation; permission-minimization background in MC-S6.
MC5-1Place judgment expresses precision, freshness, and uncertainty
Applies tonearby search, arrival prompts, place-related conditions, or navigation information.
Requirement: the positional precision and validity the task needs MUST be defined, distinguishing permission granularity, actual measurement precision, and observation time; location permission, the user-selected destination, geofence events, and the currently valid location are four different bases and MUST NOT be derived from one another. Approximate location MUST NOT be treated directly as precise arrival, and geofence events MUST NOT be treated as latency-free current fact — the occurrence, receipt, and validity instants of a location event are kept separate, and a late arrival notice does not prove the person is still in the target area. When precision is insufficient, a reading is stale, or an event is late, conclusions depending on it MUST be constrained, with re-checking, manual place selection, or explainable waiting offered; without freshness or precision evidence, keep unknown, allow manual verification, and do not auto-submit high-consequence actions that depend on the current location. Manually selected places MUST be marked as user-designated and MUST NOT masquerade as the current location.
Boundaries: holding the precise-location permission does not guarantee current precision; map animations cannot manufacture certainty. No universal arrival radius is set; tasks that need no location MAY proceed.
Design application"Current location precision is insufficient — please check the entrance," instead of auto-confirming store arrival from one stale geofence event.
Verificationuser side — know whether it is nearby, manually selected, or location-verified; implementation side — test approximate permission, stale location, delayed entry/exit, permission change, and no location at all.
Counterexamplesunder-delivery — a stale location marks someone who has left as arrived; over-delivery — looking up a public address forces continuous precise location.
MC5-2Cached and connection state do not masquerade as current results
Applies toweak network, disconnection, cached display, and returning to the foreground.
Requirement: network state, service reachability, and data freshness MUST be distinguished. Available local content SHOULD be shown promptly but MUST retain its source and original update time; old data being refreshed MUST NOT be auto-labeled as current. When a task's data has no validity basis, unknown or expired MUST be shown and the corresponding actions constrained. Reconnection cannot by itself prove a successful refresh; with no new data, appropriate historical content and exit remain.
Boundaries: the platform connectivity icon does not equal business-request success; data needing no freshness is not forced into a uniform validity period. Recovery MAY first show content that does not depend on old values.
Design applicationin a tunnel, show the saved itinerary with its timestamp instead of claiming the train's real-time position.
Verificationuser side — distinguish historical content from confirmed current results; implementation side — test network reachable but service down, cache expiry, system clock changes, and reconnect-refresh failure.
Counterexamplesunder-delivery — a stale price becomes the valid price once the refresh animation ends; over-delivery — a brief disconnection wipes all available material.
BasisMC-S8; the freshness adjudication is project derivation.
MC5-3Offline saves, pending sends, and sync conflicts are handleable
Applies tothe task allows offline writes or deferred submission.
Requirement: local draft, authorized queue, sent state, and remote result MUST be distinguished; saving can be promised only with reliable persistence. When queuing is allowed, the execution conditions, validity period, and pre-send cancellation path MUST be stated. Before reconnection, subject, target, permissions, and conditions are re-checked; conflicts MUST be handled explicitly per task, and known protected human edits MUST NOT be silently overwritten. When automatic handling is impossible, keep each party's usable content and offer a choice.
Boundaries: not all actions suit offline queuing; public queries and payments do not share one default. The conflict strategy is not always a dialog — reliable merges that do not change user intent MAY be handled automatically.
Design applicationthe draft is saved locally; actually entering "send when online" requires explicit send intent and a cancellation entry.
Verificationuser side — know whether it was sent and what can be canceled; implementation side — test offline cancellation, queue expiry, remote object change, storage failure, and concurrent-edit conflicts.
Counterexamplesunder-delivery — after reconnect, a draft the user deleted gets sent; over-delivery — even conflict-free sync requires item-by-item approval.
BasisMC-S8 supports offline writes and conflicts; queue authorization is project derivation.
MC6-1Returning finds the original object and progress again
Applies toreal-world interruption, backgrounding, lock screen, process termination, handoff, or recovery.
Requirement: tasks that promise recovery MUST specify what is saved, when it is saved, where, the retention period, and handling after expiry. Recovery MUST locate the original object, the valid step, and a meaningful focus, stating what is done and what remains; when subject, object, permission, or necessary conditions change, the affected parts are re-checked. Save failure MUST be stated truthfully; sensitive drafts MUST NOT be shown across subjects.
Handoff MUST bind the same task and the unfinished content; the recovery path remains until receipt is confirmed. Entering detail, going back, or reopening does not constitute submission; unconfirmed drafts MUST NOT execute automatically.
Boundaries: permanent retention of all screen positions is not required; when the original object no longer exists, explain the change and offer a workable destination instead of mechanically restoring dead controls.
Design applicationafter the ticket check, return to filling the same form with focus on the valid field, not the default home page.
Verificationuser side — after interruption, can restate progress and continue; implementation side — test process kill, expiry, subject change, original-object deletion, and handoff failure.
Counterexamplesunder-delivery — recovery creates a brand-new task; over-delivery — every brief switch-out demands login and refilling.
Basisproject derivation; context-interruption background in MC-S1.
MC6-2Verify the actual outcome before deciding to retry or undo
Applies tosubmission, weak-connectivity retry, lost receipts, or pending operations after recovery.
Requirement: received, sent, accepted, and actual success/failure/unknown MUST be distinguished. Re-submissions of the same intent keep the same operation identifier; duplicate prevention covers concurrency and the executed-but-result-unrecorded window; independent consecutive intents MUST NOT be swallowed. Without a reliable receipt, verify first — a timeout MUST NOT directly conclude failure or resend under a new identifier. Automatic retry runs only with idempotency guarantees and bounded scope.
When verification is impossible, keep unknown plus an actually usable query, contact, or later entry. A cancellation request after sending is verified separately from the original operation's result; undoing an already-occurred result is another consequential action and cannot be faked by a local back button.
Boundaries: a disabled button is not evidence of duplicate prevention, and accepting a request is not business completion. The end of limited retries does not mean a known failure.
Design applicationwhen the service succeeded but the receipt was lost, show the verification status and, after recovery, query the same operation instead of sending again.
Verificationuser side — can tell which results are confirmed and what is next; implementation side — concurrent re-submission, killing the process after remote success, late receipts, and two consecutive independent operations, each verified for its actual outcome.
Counterexamplesunder-delivery — a network retry sends the message twice; over-delivery — only "unknown" is ever said, with no handling path forever.
Basisproject derivation; offline background in MC-S8.
4. States and transitions
Activity, available input, environment, location, identity, data, and submission states are each independent; a single "mobile mode" does not replace the facts. The encoding of unknown, expired, and unavailable is in the Token dictionary in this directory.
| Event | What to verify first | User outcome and prohibited behavior |
|---|---|---|
| First entry into a task | Object, capabilities, valid data, manual choice | Present a judgeable summary promptly; do not turn on every sensor by default |
| Movement starts/stops | Source freshness, user mode, stability conditions | A legitimate mode takes effect at a safe boundary; no reflow mid-press |
| Device put away / real-world interruption | Current edit, save promise, pending operations | Keep the draft; exiting does not submit |
| Channel loss / environment change | Actually available inputs and outputs, content eligibility | Provide a workable alternative; headphone disconnect does not switch to sensitive speaker playback |
| Location change | Permission granularity, actual precision, observation instant | Do not treat a stale event or nearby position as arrived |
| Reconnection | Local data, service state, authorized queue and conflicts | Saved and completed kept separate; canceled content is not re-sent |
| Foreground return / handoff return | Subject, original object, occurred results, valid focus | Continue the same task or explain the change; no duplicate execution |
5. Acceptance and delivery
Every task MUST record the user outcome, applicable conditions, normal path, interruption points, capability fallbacks, configuration rationale, and the evidence owner. Before testing, write down the event sequence, expected behavior, user evidence, mechanism evidence, pass conditions, and uncovered scope.
| Required test combinations (applied per declared scope) | User-side evidence | Implementation-side evidence |
|---|---|---|
| Long text × bright light × enlarged text | Object, direction, freshness, and consequences understandable | No necessary content truncated; semantics consistent with facts |
| One hand with object × grip change × activity unknown | Reachable, exitable, mode stable | Hit areas, layout during touch, and choice priority correct |
| Controlled walking × real interruption × return | Understands the next step after returning to the task | Draft, original object, focus, and permission recovery correct |
| Noise × no mic × no network | Alternative path genuinely completes or stages | Does not depend on another already-disabled capability |
| Public preview × screen reader × headphone disconnect | Can view legitimately and control output | Output eligibility synchronized; no automatic sensitive speaker playback |
| Approximate location × late geofence × place change | No false precise arrival | Precision, freshness, and event order adjudicated independently |
| Offline edit × remote modification × reconnect | Understands what is pending sync and which conflicts need handling | Human content protected; queue expiry/cancellation effective |
| Remote already done × lost receipt × process kill | Understands verification and the result entry point | Duplicate prevention effective; receipts do not cross objects |
| Stationary, good input and network | Simple tasks not slowed by extra confirmations | Ordinary and simplified modes consistent in business semantics |
Sensitive leakage, duplicated consequences, false success, losing promised-saved content, or unreachable necessary exits — any one of these fails the test and cannot be offset by average scores. Task completion rate, correct-understanding rate, mistouches, grip changes, recovery success rate, time to return to the task, and subjective load are set as product targets; state the denominators and how failures/interruptions are counted, and report distributions and uncovered samples.
Controlled mobile tests allow participants to pause and stop at any time; failures are not manufactured on dangerous roads. Research with actually disabled and assistive-technology users cannot be replaced by brief object-holding simulation. Documentation, mechanism, and real use are verified separately; these guidelines claim no device or user experiments have been conducted.
Implementation acceptance scenarios
These scenarios turn existing clauses into reviewable acceptance inputs and set no additional universal performance thresholds. Select them per the product's applicable capabilities and add real devices, users, input sequences, and evidence; record the reason when one does not apply, and unexecuted items MUST NOT be recorded as passed.
| Clause | Test input and anomaly | Expected behavior and failure criteria |
|---|---|---|
| MC5-1 | A geofence entry event from minutes ago arrives, but the person has left. | The late event is not treated as current arrival; valid location is checked first. |
| MC2-2 | Activity state changes while a button is pressed, triggering the simplified layout. | The current target is not replaced; necessary cancellation does not wait for the settle. |
| MC6-2 | After an offline save, reconnection finds the service already executed the original submission but the receipt was lost. | Verify the original action first, distinguishing draft, queued, and actually completed. |
Each scenario separately checks the configuration's effective values, execution records, and user-comprehensible results. Keep the version, target, event instants, failure scope, and recovery result; an unknown external result is not filled in as success or failure.
Use together with the Design Guidelines. First decide how the user completes, pauses, and resumes the task in the current context, then record those decisions in fields; automatic recognition is not a precondition for using this dictionary.
1. Data layers and reading conventions
| Layer | Prefix | Purpose and boundaries |
|---|---|---|
| Visual tokens | mobileContext.visual | Semantic roles such as color, typography, spacing, and focus; does not change identity or data state |
| Interaction parameters | mobileContext.interaction | Information budgets, action budgets, and mode settle time actually consumed |
| Policy configuration | mobileContext.policy | Input adaptation, location use, offline action, privacy, and recovery decisions |
| Runtime facts | mobileContext.runtime | Activity, location, input capability, choices, and business outcomes; not a Design Token |
Fields are formed by joining the prefix with the short keys in the tables. Required items may inherit resolvable product decisions; conditionally required items need completeness only after the corresponding capability is enabled. When something does not apply, write the reason; do not fabricate empty contracts. null is not allowed by default; unknown, off, unlimited, and unconfigured cannot share one value.
The visual part MAY use DTCG types and aliases; policies and facts use this project's structure — no fictitious DTCG policy types. dimension uses px/rem; native dp/pt stay in the platform profile with an explicit integration mapping. Timestamps carry time zones, durations are non-negative integer milliseconds, counts are integers; no cross-platform uniform hit-target size, arrival radius, or task-reading seconds are defined.
Every decision records its owner, applicable scope, rationale, effective time, capability dependencies, and verification evidence. A contract reference resolves at least to id, owner, appliesTo, decision — a document section or a configuration object both work. Missing or circular references, type mismatches, and unknown enumerations MUST be located to the field and the affected capability refused, never papered over with widened permissions or automatic execution; saved content and dependency-free exits remain available.
2. Visual tokens and platform integration
Prefix mobileContext.visual. Aliases in the table are integration illustrations and MUST resolve to the actual product collection; when explicit native components are used, their styles may provide the corresponding roles.
| Condition | Field | DTCG type | Example semantic alias | Rules |
|---|---|---|---|---|
| Key text present | primary | typography | {product.typography.bodyStrong} — current object and key state | MC1-1 |
| Auxiliary information present | secondary | typography | {product.typography.body} — necessary freshness and units must remain readable | MC1-1, MC5-2 |
| Text / background present | foreground, surface | color | {product.color.textPrimary}, {product.color.surface} | MC1-1, MC4-1 |
| Exception / pending item present | statusAttention | color | {product.color.attention} — paired with text or shape | MC5-1, MC6-2 |
| Adjacent actions present | actionGap | dimension | {product.space.controlGap} — must not let expanded hit areas collide | MC2-1 |
| Content edges present | contentInset | dimension | {product.space.contentInset} — combined with safe areas and grip | MC2-1 |
| Focus navigation present | focusIndicator | color | {product.color.focus} — outline and sizing defined by the component profile | MC2-1, MC6-1 |
visualSystemRef MUST state the platform, components, font scaling, actual hit areas, system gesture regions, focus, and contrast basis. The Web target-size provision covers 24 × 24 CSS px with explicit exceptions; it is not a guarantee of comfortable one-handed use and is not extrapolated to native devices. The Web contrast conditions for normal/large text are 4.5:1/3:1; the full applicability conditions and actual bright-light performance still need checking — see MC-S3, MC-S10.
Platform font size, reduced motion, necessary focus, and input protection take precedence over theming. A simplified mode MUST NOT be achieved by shrinking text, removing exits, or disabling accessibility semantics; handle lack of space by cutting optional content, rewriting summaries, or accessible scrolling.
3. Interaction parameters
Prefix mobileContext.interaction. Candidate values are prototype hypotheses, not human-factors standards. Parameters MUST actually be used in design or implementation; step budgets and research metrics live in the advice document.
| Condition / field | Type and legal values | Candidates and rationale | Effect and verification | Rules |
|---|---|---|---|---|
Quick entry / primaryActionBudget | integer ≥ 0, unit: actions — cap on simultaneously emphasized actions | Candidate 1, focusing the next step; 0 for read-only | Takes effect at safe layout boundaries; cancel, back, and necessary detail are excluded and cannot be squeezed out | MC1-1, MC1-2 |
Optional auxiliary information / previewFields | integer ≥ 0, unit: fields | Candidate 2, reducing short-glance reading; 0 hides optional auxiliary items | Necessary object, exceptions, consequences, units, and freshness are exempt from the budget | MC1-1 |
assisted / modeSettleMs | integer ≥ 0, unit: ms | Candidate 1000, for observing short-term jitter; the candidate activity must be continuously stable | Candidate change, unknown, or expiry resets the wait; used for both entry and exit; 0 waits not at all but still takes effect at a safe boundary | MC2-2, MC3-2 |
If a task needs different entry/exit timing, define and verify it explicitly in the inputAdaptation contract; the meaning of this field MUST NOT be quietly changed. The settle wait is not for delaying revocation, privacy convergence, action cancellation, or location invalidation. Fix values only after comparing mistouches, comprehension, and recovery load across ordinary-still, manual-simplified, and automatic modes.
4. Policy dictionary
Prefix mobileContext.policy. All fields except modeSelection are references; surfaceProfiles is a non-empty array of references. A contract's minimum content must make the conditions, allowed/prohibited behavior, exception exits, dependent mechanisms, and evidence judgeable.
| Condition | Field | Minimum decisions and missing-handling | Rules |
|---|---|---|---|
| Required | visualSystemRef | Actual platform components and visual roles, font-size/hit-target/focus basis; missing means no claim that a custom interface is ready | MC1-1, MC2-1 |
| Required | surfaceProfiles | Each task's entries, objects, fields, actions, input, back, refresh, and privacy; do not treat all entries as one page | MC1-1, MC6-1 |
| Required | capabilityContract | Core-task required capabilities, on-device alternatives, saving, handoff targets, and failure paths; no capability means no faked completion | MC4-1 |
| Interruptible stepwise task | taskSegmentation | Pausable task segments, minimum necessary judgments, autosave and repositioning, any time limit and its expiry consequence | MC1-2, MC6-1 |
| Input actions present | inputAdaptation | Left/right-hand / object-holding / assistive-technology support, alternatives to dragging and device motion, activation-cancel, touch-down exceptions, focus and safe layout boundaries | MC2-1, MC2-2, MC4-1 |
| Mode selection present | modeSelection | Enumeration manual/assisted, candidate default manual; assisted depends on valid facts, settle time, and manual correction | MC3-2 |
| Context actually collected | collection | Purpose, triggers, permissions, storage location/period, stop on revocation, and alternatives; omit when nothing is collected | MC3-1 |
| Sensitive content present | privacy | Subject eligibility, previewLevel=public/summary/hidden, deliberate reveal, controlled outputs and channel switching; unknown does not widen exposure | MC4-2 |
| Location used | locationUse | Task precision and freshness criteria, permission granularity, late-geofence handling, manual place selection, misjudgment exits; insufficient means no arrival verdict | MC5-1 |
| Freshness dependency present | freshness | Per-data-class observation instant, validity period/interval/event invalidation, clock comparison, historical display, dependent operations, and re-checking | MC1-1, MC5-2 |
| Offline write / queuing | offlineActions | Action allowlist, explicit authorization, persistent storage, queue period, cancellation, conflicts, and reconnect verification; no permission means no auto-queuing | MC5-3 |
| Recovery / handoff promised | resume | Saved object/scope/instants/period, subject binding, original object and focus, receipt confirmation, expiry and failure exits | MC6-1 |
| Consequential actions present | submission | Intent identifier, target snapshot, acceptance/result evidence, dedup window, bounded retry, cancellation, and unknown handling | MC6-2 |
modeSelection's manual provides the actually supported standard/simplified manual choice; only assisted MAY offer automatic. The user choosing automatic merely permits legitimate adaptation; it grants no collection permission and no execution eligibility. When adaptation dependencies are lost, stop new inference, keep the legitimate layout, and explain the unavailability in the relevant settings; do not override the user's choice back to ordinary mode.
The precision locationUse needs can be expressed as the area the task accepts or as verifiable conditions; sources are not forced to return meter values. Without precision metadata, state unknown explicitly; never write accuracyMeters=0. Location permission, raw coordinates, and the "user-selected destination" are three different objects.
4.1 Linked dependencies
| Promise | Must have | When missing |
|---|---|---|
| Manual simplification | Explicit choice, input adaptation, stable layout | Keep usable input; do not demand activity permission |
| Automatic context adaptation | assisted, modeSettleMs, valid activity facts, collection, manual correction, safe effect | No new automatic reflow; keep the legitimate choice |
| Arrival-related actions | locationUse, freshness, valid location, applicable authorization; add submission when consequential | Re-check or verify manually; do not execute on a late event |
| Offline pending send | offlineActions, resume, submission, persistence, authorization validity period, dedup coverage | Keep only drafts or a restricted queue; do not falsely report sent |
| Continue after handoff | Original object and content, actual receiving end, receipt confirmation, failure recovery | Findable on the original end; cannot merely show "go to the other device" |
| Sensitive audio continues | Valid identity and user choice, privacy, real output routing | Channel loss pauses affected playback; keep the deliberate viewing path |
5. Runtime facts
5.1 Per-fact encapsulation
| availability | Required fields | Usage discipline |
|---|---|---|
| known | value, source, deviceId, observedAt, receivedAt, ordering | Currently valid observation; known + false is a known negation, not unknown |
| stale | Original value, source, deviceId, observedAt, receivedAt, ordering, plus reason | Keep history; changing the observation time on reconnect to revive validity is forbidden |
| unknown | source, deviceId, checkedAt, reason | No value, no fabricated observedAt; no usable judgment for now |
| unavailable | source, deviceId, checkedAt, reason | No value; distinguish unsupported/permissionDenied/systemRestricted |
Facts involving permissions or sensitive content MUST bind subjectId; business content and operations bind objectId and, where needed, targetSnapshotId. Source ordering can use same-source same-session sequence numbers or trusted observation times; sessions are distinguished across restarts. When comparison is impossible across devices/clocks, keep pending verification — arrival order MUST NOT override. Freshness, ordering, and permissions are adjudicated separately; checkedAt MUST NOT be filled in as observedAt.
5.2 Fact catalog
Prefix mobileContext.runtime. Collections are encapsulated per key; no single global known. Device-type non-applicability is recorded in the profile; required fields cannot get optimistic defaults from theming.
| Field | value or structure | Applicability boundaries |
|---|---|---|
activity | stationary/walking/running/cycling/inVehicle, with raw source-category mapping | Adopted only when the source actually supports it; inVehicle does not mean driver; unknown is expressed in the encapsulation |
inputCapabilities | Encapsulated per capability, e.g. touch, microphone, screenReader, keys | A user's occupied hands are not derived from the device supporting touch; without an observation, an explicit mode may be used |
environment | Optional, per-signal facts; e.g. illuminance or noise conditions the source actually provides | No sensor is turned on by default to fill the table; user declarations state their source and do not pose as objective measurement |
location | Position, permission granularity, precision description provided by the source, observation time | Omit the precision value when the source provides none and constrain dependent judgments; arrival time does not substitute for observation time |
selectedPlace | User-selected place and selection basis | Not the current position; cannot substitute for conditions that must rely on real arrival |
connection | Link availability and business-service reachability encapsulated separately | A normal network does not auto-fill business reachability |
identity | Current subject, lock state, permission scope | A subject change invalidates the previous subject's sensitive eligibility |
audioRoute | Current output endpoint and availability | Headphone removal does not automatically grant speaker eligibility |
content | Object, fields, units, validity basis, and cache source | Data freshness is independent of connectivity; estimates and measurements are clearly flagged |
userMode | standard/simplified/automatic, with source, affected task/entry, and effective time | user vs. productDefault distinguished; user choice prevails over inference |
interactionState | Current touch, pending edit, focused object | Provided by the input system; determines safe layout boundaries |
checkpoint | Original object, saved content, step/focus, save evidence, expiry instant | Not filled as saved without persistence; recovery verifies object and subject first |
operation | See the next section | known only means the process fact is known; it does not require the remote result to be confirmed |
5.3 Submission and outcome combinations
An operation has at least operationId, objectId, applicable subjectId/targetSnapshotId, submission, outcome; a confirmed result attaches receiptRef or locally verifiable evidence.
| submission | Valid outcome | User meaning |
|---|---|---|
| draft | notApplicable | Unconfirmed; can be edited or abandoned |
| queued | pending | Authorized but not sent; cancellable; executes per declared conditions within the period |
| sent | pending/succeeded/failed/unknown | Handed to the executing end; the final result may arrive directly |
| accepted | pending/succeeded/failed/unknown | Accepted; does not mean the task is achieved |
| cancelled | notApplicable | Cancellation before sending confirmed; not re-sent on reconnect |
Use pending while waiting, and unknown once the wait exceeds what can reasonably be judged; a missing receipt MUST NOT be filled directly as failed. A cancellation after sending keeps the true submission and records cancelRequest=requested/confirmed/rejected separately, with the original result verified on its own; a sent operation MUST NOT be rewritten as an unsent cancelled. Undoing an already-occurred result is a new consequential operation.
Retries of the same intent keep the identifier; a new intent uses a new identifier. Duplicate prevention covers concurrency, process termination, and the entire scope where queuing/retry is allowed; beyond the guarantee period, verify first. Receipts for old objects or other operations update only their own records and do not overwrite the current task. Exhausted limited retries may still be unknown; a real handling exit MUST exist.
6. Resolution order and effect
- Resolve references and capability dependencies by task, entry point, and declared conditions; do not treat profiles as actual facts.
- Verify the validity of subject, object, current input capability, content, and necessary location; take the behavior all of them permit.
- Use the explicit user mode; with no choice on record, use the default on first launch, and keep the current legitimate layout when history exists.
- When the user chose automatic and the assisted dependencies are complete, request the switch only after the candidate activity is continuously stable; unknown/expired resets the candidate.
- Apply layout after touch release and the safe saving of edits; permission tightening and sensitive-output convergence take effect immediately, canceling affected input with an explanation when necessary.
- Resolve visual and auxiliary outputs within the permitted scope; on foreground recovery, verify dependent state first — public static content and exits MAY appear first.
Theming MUST NOT override identity, privacy, platform font size, or necessary controls. Mode switching does not change the business objective and does not reset submission state or queue periods. A new configuration or rollback does not replay already-occurred consequences. The actually effective state and the requested-switch state are recorded separately; a request MUST NOT be treated as effective.
7. Complete design configuration example: a reply draft on the commute
This example chooses manual simplification, offline draft-only, deliberate send when online, collects no activity or location, and promises no background sending. All policy references resolve within contracts. visualSystemRef selects concrete native-component responsibilities, and the visual fields may come from that profile; the example is design input for a complete task, still needing real components and service verification — not a directly runnable product.
{
"task": "commute-reply",
"interaction": { "primaryActionBudget": 1, "previewFields": 2 },
"policy": {
"visualSystemRef": "visual", "surfaceProfiles": ["editor"],
"capabilityContract": "capability", "taskSegmentation": "segments",
"inputAdaptation": "input", "modeSelection": "manual", "privacy": "privacy",
"freshness": "freshness", "offlineActions": "offline", "resume": "resume", "submission": "submit"
},
"contracts": {
"visual": { "id": "visual", "owner": "interface owner", "appliesTo": ["commute-reply"], "decision": {
"platform": "Android phone", "components": ["native-text", "native-text-field", "native-button"],
"roles": "native theme provides body, secondary text, foreground, background, attention, and focus roles",
"font": "follow system font size; necessary content is not shrunk", "hitTargets": "record platform basis and actual hit area per component; accept after one-handed field testing",
"focus": "input, send, and back reachable in task order; system back gesture usable", "evidence": "pending device, screen-reader, contrast, and bright-light verification"
} },
"editor": { "id": "editor", "owner": "interface owner", "appliesTo": ["commute-reply"], "decision": {
"object": "current-account.selected-conversation.reply-draft",
"fields": ["recipient", "draft", "save-state", "send-state"], "actions": ["edit", "send", "back"],
"input": "native-touch-or-accessibility", "detail": "same conversation", "return": "conversation list",
"refresh": "verify the conversation on open and on return; mark unverified when offline", "privacy": "privacy"
} },
"capability": { "id": "capability", "owner": "task owner", "appliesTo": ["commute-reply"], "decision": {
"editRequires": ["usable-input", "local-persistent-storage"], "sendRequires": ["valid-account", "reachable-service", "current-recipient"],
"fallback": "offline keeps the draft and exits; state clearly unsaved when persistence is impossible", "handoff": "this example promises no handoff to other devices"
} },
"segments": { "id": "segments", "owner": "experience owner", "appliesTo": ["commute-reply"], "decision": {
"steps": ["identify recipient", "edit", "send deliberately", "verify result"],
"interrupt": "save after each persistable edit; exiting does not send", "resumeCue": "original recipient, draft, and saved state",
"deadline": "no on-screen countdown; re-judge against current conversation eligibility at send time"
} },
"input": { "id": "input", "owner": "experience owner", "appliesTo": ["commute-reply"], "decision": {
"choices": ["standard", "simplified"], "default": "standard", "scope": "reply-edit entry points of the current account",
"alternative": "native keyboard, phrase selection, and assistive technology; voice not required", "activation": "activate on release; move away to cancel",
"layout": "switch after touch release and safe save of the current edit; recipient and pending content unchanged",
"irreversibleProtection": "show recipient and content before sending; the user activates send deliberately"
} },
"privacy": { "id": "privacy", "owner": "data owner", "appliesTo": ["commute-reply"], "decision": {
"previewLevel": "summary", "reveal": "valid account plus deliberately entering the conversation; equally accessible to screen readers",
"identityLoss": "hide sensitive content and block unexecuted sends", "outputs": "text, images, semantics, and controllable snapshots adjudicated in sync",
"audio": "no automatic sensitive playback; headphone disconnect does not switch to speaker"
} },
"freshness": { "id": "freshness", "owner": "business owner", "appliesTo": ["commute-reply"], "decision": {
"draft": "local draft shown at its original save time; no claim of a remote write", "recipient": "verify current object and send eligibility before sending",
"ordering": "service object snapshots and operation identifiers; verify results that cannot be compared first", "stale": "keep draft, pause sending, allow re-check"
} },
"offline": { "id": "offline", "owner": "business owner", "appliesTo": ["commute-reply"], "decision": {
"allowed": ["save-local-draft"], "queue": "no send queue", "reconnect": "only refresh eligibility and status; no automatic send",
"conflict": "keep the local draft; when remote conversation changes affect sending, the user confirms the direction — no silent overwrite"
} },
"resume": { "id": "resume", "owner": "business owner", "appliesTo": ["commute-reply"], "decision": {
"save": "report saved only after the edit is persistently written; persistently record intent before sending",
"scope": "subject, conversation, draft, focused field, and pending operations", "retention": "draft kept until successfully sent or user-deleted; on sign-out keep an isolated draft accessible only after re-authentication",
"restore": "return to the original draft after verifying subject and conversation; if the object was deleted, keep accessible text and explain",
"failure": "on save failure state unsaved; allow keeping the current edit or a user-decided exit", "unconfirmed": "no automatic send"
} },
"submit": { "id": "submit", "owner": "execution owner", "appliesTo": ["commute-reply"], "decision": {
"intent": "a stable operationId forms after confirming content and recipient", "result": "show sent only on a service success receipt; acceptance is not success",
"dedup": "the service handles concurrency and re-submission of the same identifier, covering the executed-but-unrecorded-result window; if incapable, stop the safe re-submission path",
"autoRetry": "no automatic resend", "unknown": "query the original operation; when unresolvable, keep unknown plus a later query entry; never blind-send under a new identifier",
"cancel": "only unsent operations can be confirmed canceled; a sent cancellation request and the original result are verified separately"
} }
},
"validation": {
"status": "pending-device-and-user-tests",
"cases": ["one hand holding an object", "resume after the queue number is called", "offline save", "storage failure", "subject switch", "lost receipt"],
"failIf": ["unconfirmed send", "duplicated consequences", "lost saved draft", "sensitive exposure", "necessary exit unreachable"]
}
}
Automatic adaptation is not adopted, so modeSettleMs and collection are omitted; location is unused, so locationUse is omitted. Changing to automatic send-when-online MUST add an explicit authorized queue, validity period, and withdrawal mechanism, and verify duplicate-prevention coverage — a one-line copy change is not enough. validation is a design acceptance record, not a runtime success state.
8. Configuration acceptance
- manual tasks run completely without collecting activity/location; the assisted dependencies are complete once enabled.
- Native units, visual aliases, and platform-component integration are explicit; optional budgets do not swallow necessary information and controls.
- Context facts do not fill in for one another; location permission, actual precision, freshness, and the user-selected place are kept separate.
- User choices are stable; candidate-activity invalidation resets the wait; touch and edit boundaries are correct; privacy tightening is not equated with anti-jitter.
- Offline draft, authorized queue, and submission/outcome combinations are legal; no network does not write a locally saved result as failure.
- Recovery locates the original object and focus; subject changes do not expose sensitive drafts; nothing is re-sent after cancellation.
- Duplicate prevention, unknown results, conflicts, and beyond-period handling are actually executable, with both user and mechanism evidence.
A complete configuration only proves the decisions are explainable; usability in real contexts still MUST be verified against the task matrix in the guidelines.
Configuration delivery and verification
The mode settle wait suppresses short-term adaptation jitter; it is not a location validity period, driver identification, or a safety guarantee. The timer cannot delay revocation, privacy convergence, or cancellation; a mode change must not turn a target being pressed into another action. The example millisecond values are format samples and need calibration against real grip and interruption scenarios.
The accompanying executable sample covers only mobileContext.interaction.modeSettleMs; the remaining fields are checked item by item against this dictionary — uncovered does not mean inapplicable or passed. The sample is a positive-and-negative format example for the chosen field, not a product preset that enables every capability. A complete product delivery additionally includes applicability, dependencies, evidence, execution mapping, and effect boundaries for in-flight operations.
When a field name, type, or meaning changes, update the referencing parties and the acceptance samples; changes that only reword documentation without changing legal behavior keep the existing field names. Callers read the resolved effective configuration and do not reverse-infer permissions, measurements, or completion facts from UI controls, animations, or model text. See the corresponding scenarios.
References
For checking the evidence base of the Design Guidelines and Design Token. Sources are distinguished into research, platform documentation, and standards interpretations; task contracts, rule numbering, the runtime fact model, and candidate parameters are this project's design — no source directly proves that a specific product is ready for use.
1. Context and user capability
MC-S1 · Research on mobile interaction while walking
- Evidence read: the abstract, introduction, and the discussion of how walking affects mobile operation and attention to the environment.
- Adopted: tasks in motion are constrained by both manipulation capability and the attention the real environment demands, which suits evaluation in real contexts. Maps to MC1, MC2.
- Boundaries: unreviewed effect sizes, experimental thresholds, and uniform walking speeds are not adopted; controlled-walking results do not demonstrate safety for driving, cycling, or hazardous work.
MC-S2 · Sense and Accessibility
Microsoft Research: Sense and Accessibility (PDF)
- Evidence read: the abstract, the study population, the introduction, and the discussion of situational barriers.
- Adopted: individual capability and environment jointly shape mobile use; design must not assume all users share the same physical capability. Maps to MC2, MC4 and the choice of acceptance populations.
- Boundaries: the study sample does not represent all disabled people, and findings are not extrapolated to screen-reader populations the study did not cover. Brief object-holding simulations cannot substitute for research with real assistive-technology users; this is an application judgment formed from the study's scope.
2. Operability and perceivability
MC-S3 · W3C WAI: target size and operation alternatives
Target Size (Minimum) · Dragging Movements · Motion Actuation
- Evidence read: target size, spacing, and exception conditions; alternatives to dragging and device-motion actuation.
- Adopted: the minimum Web target-size provision involves 24 × 24 CSS px with explicit exceptions; fine-motor actions must not become an unnecessary sole entry point. Maps to MC2-1, MC4-1.
- Boundaries: the understanding pages do not replace the WCAG specification text. CSS px cannot be converted directly into native dp/pt; meeting the minimum provision does not make a design suitable for all one-handed and object-holding conditions.
MC-S4 · W3C WAI: pointer cancellation
- Evidence read: the explanations of press and release, cancellation, undo, and necessary exceptions.
- Adopted: protecting intentional activation and cancellation paths. Maps to MC2-2.
- Boundaries: this does not prohibit all activation-on-press behavior; each action is accepted according to its necessity and equivalent protection. Duplicate prevention for network retries is a business mechanism that pointer cancellation alone cannot guarantee.
MC-S10 · W3C WAI: text contrast
- Evidence read: contrast conditions and exceptions for normal and large text.
- Adopted: the Web text-contrast basis includes 4.5:1 for normal text and 3:1 for large text; the font-size definitions and applicable exceptions must be checked alongside. Maps to MC1-1, MC4-1 and the visual profile.
- Boundaries: a measured ratio does not directly prove readability under bright light, reflections, or dynamic environments, nor that requirements for icons, focus, and other interface elements are met.
3. Context sources, location, and offline action
MC-S5 · Android: activity transitions
Detect when users start or end an activity
- Evidence read: activity entered/exited events and the subscription mechanism.
- Adopted: context adaptation needs to handle activity transitions rather than store one never-expiring "moving" flag. Maps to MC3-1, MC3-2.
- Boundaries: activity categories do not establish driver identity, available hands, or environmental safety; event availability depends on the actual platform and permissions. The settle wait, manual override, and layout-effect conditions in these guidelines are project design, not automatic guarantees of the API.
MC-S6 · Android: location permissions and accuracy choice
Request location permissions at runtime
- Evidence read: runtime location permissions and the approximate/precise location choice.
- Adopted: users may grant approximate location only; products need paths designed for insufficient precision and denied permission. Maps to MC3-1, MC5-1.
- Boundaries: holding the precise-location permission does not mean every observation is accurate; a manually chosen destination is not the current location. Platform permission granularity is not treated as a measurement-error value.
MC-S7 · Android: geofencing
- Evidence read: geofence triggering, latency, and the system conditions that affect responsiveness.
- Adopted: geofence events cannot be assumed to arrive in real time; late arrivals and location uncertainty must be considered. Maps to MC5-1.
- Boundaries: no cross-platform uniform arrival latency is stated, and an entry event is not treated as authorization to auto-execute consequential actions. Arrival verification and triggered consequences are decided by the specific task.
MC-S8 · Android: offline-first data design
- Evidence read: local data, read and write strategies, queues, synchronization, and conflict handling.
- Adopted: locally available data, pending writes, and remote results must be handled separately; reconnection must handle synchronization and conflicts. Maps to MC5-2, MC5-3, MC6.
- Boundaries: a specific library or background queue does not automatically guarantee business idempotency, user-authorization validity periods, or successful withdrawal. These guidelines separately define draft, authorized queue, acceptance, final result, and unknown as design constraints on task consequences.
4. Configuration expression and validation
MC-S9 · Design Tokens Community Group: the format
- Evidence read: types, values, groups, aliases, and the format of visual types.
- Adopted: visual tokens such as color, typography, and spacing can use explicit types and resolvable aliases; dimension uses px or rem.
- Boundaries: this is a Community Group format and is not called a W3C Recommendation. This project's policy contracts, native dimensions, mode settle time, and runtime facts are defined separately; a complete task configuration does not masquerade as a standard token file.
5. Conclusions not derived from the sources
- No universal attention score is defined; the presence of sensors does not justify continuously collecting activity, location, or environment by default.
- The
modeSettleMscandidate value is not treated as a universal reaction time, and step budgets are not evidence of task success. - Simulators, automated checks, or valid JSON do not substitute for verification in real contexts, with object-in-hand operation, and with assistive technology.
- This document has not re-checked the full statistical analyses of the papers above; the cited research is used to identify problems and fix test conditions, and no quantified improvement of this product is claimed on that basis.