Operate, rehearse, and accept an interactive experience

Participate without relying on a single gesture

Offer an equivalent choice/response when someone cannot jump, raise a hand, stand, or use a phone. Options include a reachable button, on-screen selection, or host assistance. Preserve the activity’s purpose.

• Provide clear instructions and visual confirmation; do not communicate turns through color or sound alone.
• Prepare reviewed synchronized captions, including sounds necessary for comprehension. Provide descriptions of relevant visual information.
• Do not make exit require repeating the failed gesture. Allow decision time, pause, and stimulus adjustment as designed.

Proposed rehearsal: participation while seated, without speaking, and without a phone; complete the task with alternative controls and request assistance. Review reach, legibility, and listening positions. WAI references inform design; assess the complete experience with users/specialists before claiming standards compliance.

One person, a group, and a queue need different rules

Define session start and availability: presence, confirmation, agreed duration, or host closing. Separate active/waiting areas so queue movement does not alter the current participant’s picture.

• Assign priority for several people: turn, zone, or shared action. Show who can act and how a companion joins.
• Agree target duration, closing notice, and reset. An operational timer must not eject someone needing help without explanation.
• Plan staffing against arrival estimates and duration. Sessions per hour are not permitted occupancy.

Proposed rehearsal: early next arrival, abandonment, companion, and no-action session. Clear previous choices rather than attributing them to the next visitor. The operator can pause admission and guide exit. Coordinate circulation with the venue and production team, and agree how the planned control system enables new sessions.

Use the minimum data needed for the response

A ripple may need only presence or an ephemeral position. Before adding camera, voice, or cloud, map incoming data, processing location, what leaves the device, and retention. Numeric output alone does not guarantee anonymity.

• Prefer zone states to identification when identity is unnecessary. Consider a button/manual choice without a camera.
• If camera input is needed, define field/processing; recording must not become an automatic byproduct. For voice services, confirm audio transmission/retention.
• Separate authorized performer assets and audience inputs. Use fictional characters or cleared/authorized assets and disclose synthetic representation.

Proposed review: data map, services, retention, access, and stage owners; test a nonidentifying alternative. Agree required information/permissions with event owners/advisers. Technical scope alone neither changes legal notices nor establishes privacy compliance.

Clear states and operator control

1. Active
2. Expired data → idle
3. Operator → local
4. Preview → enable

Audience idle, listening, response, and pause should look different. Operators also need valid source, data age, selected content, and active mode. “Connected” alone cannot show whether the character responds correctly.

• Set manual priority over sensors/remote requests; avoid competing controllers.
• Agree idle, local-content, and assisted cues with the planned control system. Require state feedback where supported.
• On recovery, discard expired actions and check preview before public response.

Proposed example: active → expired data → idle; any state → operator → local; recovery → preview → agreed enable. Restart must not show previous-session information.

Proposed rehearsal: input loss mid-answer, conflicting orders, and recovery. Record requested command separately from observed state. This governs noncritical image/audio, not machinery or safety.

Multiple days: return to a known state

Prepare an opening sequence with owners: content/project version, needed services, inputs, calibration, and output before inviting participants. Actual operation follows equipment/venue procedures.

• Before opening: compare physical marks, test zone/assisted control, voice/captions, session reset, and local content.
• During: log detection degradation, lighting changes, worn peripherals, and recovery times. Plan inspection pauses without active participants.
• Closing: stop participation, keep approved project and issue log; apply agreed data retention and technical shutdown.

Proposed rehearsal: authorized off-program restart returning to the same configuration without relying on one operator’s memory. Check retained versus restored settings. Test backup/replacement before the event; avoid routine updates during program.

Sensor, position, content, firmware, or version changes may invalidate previous checks. Record changes and repeat affected checks only. Surface/peripheral maintenance follows approved methods.

Rehearse representative event conditions

Use intended character, content, light, sound, clothing, and zone. A quiet one-person sensor demonstration does not validate a queue, music, and lighting changes.

• Condition matrix: intended/changing light, noise, one/several people, heights, clothing, occlusion, prolonged session, and restart. Agree script-relevant variations.
• Per test: version, condition, stimulus, expected/observed result, method, tolerance, owner, and authorized evidence. Unobserved fields remain pending.
• Change one condition at a time for diagnosis, then repeat the complete journey under representative load. Include assisted participation.

Example criterion to test: “When two people cross, the system keeps the active session’s selection or returns to idle, according to the agreed rule.” During rehearsal, record what happens and compare it with that criterion.

Prepare data/link loss and recovery off-program with test sources. Approval for use depends on the actual installation and its responsible teams. After relevant changes, identify acceptance checks needing review before opening.

Delivery and acceptance: scope, files, and tests

Delivery should let the owner understand what they receive and operate the approved scope. Separate editable projects, playback resources, documentation, and interfaces. A video folder alone does not describe an interactive system.

• Inventory: project/build, resources, versions, formats, devices/interfaces, licenses, and rights. Identify transferred items and third-party dependencies.
• Operation: signal/coordinate maps, state script, controls, opening/closing, fallback, and agreed owners.
• Tests: expected/observed matrix, conditions, method, date, authorized evidence. Separate documentation review, simulation, and physical rehearsal.
• Acceptance: record deviations, use restrictions, pending actions, owner, and closure criteria. Complete acceptance after checking those criteria with the actual system.

Proposed review: another person locates the approved version, follows an off-program restart, and demonstrates assisted/fallback modes under supervision. Confirm recoverability from agreed copies and identified dependencies.

Opening the system requires reviewing installation and use conditions with their owners. Acceptance concerns the real system and tested conditions. Later hardware, version, lighting, or journey changes may need further checks.