An installed screen can light up and still fail its visitor task. The language switch may lose the result, a sensor may detect staff walking behind the player, or the next guest may inherit the previous guest's choices. Before opening, test the whole cycle at the real venue and record what happened.
Archv's interactive event brief explains what to request before production. Its quote comparison guide helps reconcile unequal proposals. The opening log is the later handover: an agreed way for the buyer, installer and event operator to say what passed, what failed and who will fix it.
Agree the version, people and place being tested
Write the installed location, hardware IDs, software/content version, language versions, operating light and sound conditions, network state, date and names of the people who can sign off. A workshop demonstration and a venue test answer different questions. The test log should identify which one was performed.
The AVIXA public description of its audiovisual performance-verification standard describes a framework for choosing system elements, timing, criteria and reporting. The public summary does not give a universal pass mark for an interactive event. The team must agree the criteria for the specific visitor task and equipment.
Test a complete turn, then the exceptions
For a product explorer, ask a first-time visitor to notice the invitation, begin, compare products, finish, take or decline a follow-up, and leave the station ready for the next person. Observe without coaching first; staff can then rehearse the assistance path. ISO's public usability summary treats usability as an outcome of use, including interactive systems, and does not prescribe a single evaluation method. The real visitor task is therefore more useful than a declaration that the interface is “intuitive.”
Then rehearse states that the opening animation never shows: the visitor walks away mid-turn, two people reach for the same control, a sensor or network feed disappears, a media cue starts late, and the operator restarts the station. The proposed response may be a reduced experience, a static message or a pause in admission. Write down which state is acceptable for this event. The separate next-visitor reset test checks what remains on-screen and in storage; the opening log records whether that deeper test passed on the installed version.
If people gather around the installation, include the approach and waiting area in the venue review. The UK Health and Safety Executive's crowd-risk guidance says organizers should assess movement around attractions and site suitability. It is a useful planning reference; the actual UAE venue's rules and approval process govern its site.
An example of a usable opening record
This is an invented example, not a report from an Archv project or a standard threshold. The exhibit is a bilingual product explorer with one touch station and a shared display. Its goal is for a visitor to compare two products and reach a clear next step.
| ID and tested condition | Expected result | Observed example and decision | Owner and retest |
|---|---|---|---|
| A1 · Walk-up, no staff prompt, normal hall lighting | Visitor sees how to start and reaches a product comparison. | Pass: tester starts, compares and finishes; record time and any hesitation as diagnostic notes. | Event lead signs the observed task. |
| A2 · Switch to Arabic after choosing a product | Labels, product facts and result stay in Arabic; direction remains usable. | Fail: result screen returns to English. Hold bilingual signoff; do not hide this as a cosmetic defect. | Content/software owner updates the result state; buyer repeats the entire Arabic path. |
| A3 · Leave halfway, then another visitor approaches | Previous choices clear; the next visitor sees a clean start. | Pass after fix: automatic reset was too slow during first run; revised version cleared the session in the agreed interval. Record both attempts. | Developer supplies new version; operator retests it at the station. |
| A4 · Disconnect the external data feed during a turn | No crash or misleading product fact; operator has a defined response. | Open: installation shows a loading spinner indefinitely. No public opening on this path until the team agrees a safe fallback and verifies it. | Technical lead fixes; event owner approves the fallback. |
The table's value is its decision state. A pass identifies the version and condition that passed. A fail names the affected visitor task. An open item has an owner and a retest; it is never silently treated as accepted. If a problem affects the event's essential purpose, the buyer and venue operator should decide whether to delay, run a reduced mode or close that station. The appropriate decision depends on the actual risk and approved scope.
Sign off the evidence, not the demonstration
Keep one record with the approved version, completed tests, unresolved defects, allowed reduced modes, operator instructions, spare-device or restart steps, and support contact for every public hour. If a fix changes software or content after the test, repeat the affected path and note the new version. A single “looks good” email cannot tell tomorrow's operator which condition was actually checked.
The final signoff should belong to named buyer and operator representatives, with the supplier confirming what was installed. That gives everyone the same account of what is ready to run when the first visitor arrives.