ImgQuiz

An interactive image-based quiz where each participant receives pairs of “real vs. fake” images, selects an answer, adds a short rationale, and then watches a short presenter phase where the correct answer is revealed. After all presenter turns, a scoreboard appears.

Example structures

Minimal usage

{
  "type": "ImgQuiz"
}

With intro slide, countdown, and closing screen

{
  "nodes": [
    {
      "type": "Slide",
      "data": { "headline": "Fake or Real – Can you spot the deepfake?" }
    },
    { "type": "Countdown", "autoNext": 5 },
    { "type": "ImgQuiz" },
    { "type": "End" }
  ]
}

“Deepfake Detective” preset flow (sample)

{
  "settings": { "name": "Deepfake Detective: Fake or Real", "hostAsPresenter": true },
  "nodes": [
    { "type": "Slide", "data": { "headline": "Fake or Real – Erkennst du den Deepfake?" } },
    { "type": "Countdown", "autoNext": 5 },
    { "type": "ImgQuiz" },
    { "type": "End" }
  ]
}

Purpose

• Distribute multiple rounds of image pairs to each participant.
• Collect per-image answers and short rationales.
• Facilitate a presenter phase where one participant’s current pair is shown and the host can reveal the solution.
• Display a scoreboard summarizing correct answers after all presenter turns.

Configuration

This node does not require authoring-time configuration. All gameplay data (image pairs, answers, notes, presenter order, solutions) is created and managed at runtime by the server-side node.

Runtime data contract (client payload)

The client receives a nodeData object with these fields:

• images: string[][] Current player’s image pairs. During presenter phase, the active presenter sees a single pair; all other players receive an empty list.
• answers: number[] Per-pair selected answer for the current player. -1 means unanswered.
• solutions: number[] Per-pair revealed correct answer for the current player. -1 means hidden. When the host reveals the answer for the active presenter, that item flips from -1 to 0 or 1.
• notes: string[] Per-pair rationale text for the current player, URI-encoded on the wire.
• presenter: boolean | string true when the viewer is the active presenter, false when no presenter phase is running yet, or a display name string indicating “watching presenter XY”.
• scoreboard?: ScoreboardObject Present only after all presenter turns finish. Contains sorted user scores.

Roles and views

Participant (no presenter active)

• Sees their full set of pairs and can switch between them with in-node navigation.
• Selects an answer per pair. Clicking the same answer again deselects it.
• Adds a short rationale in a text box; changes are debounced and synced.

Active presenter

• Sees only the current pair under discussion.
• Can no longer modify answers or notes while presenting.

Other participants during presenter phase

• Interaction is locked. A small notice indicates who is presenting.

Host

• Sees a compact host view. When a presenter is active, a button appears to reveal the correct answer for the shown pair.
• Can move the workshop forward and backward using standard navigation.
• Host answering is not the primary flow; the host view focuses on orchestration.

Visual design

• Full-screen, centered layout.
• Image pair rendered by the ImageQuizButtons UI with a clear, tap-friendly answer affordance.
• A single-line or multi-line rationale input below the images.
• Navigation buttons (left/right chevrons) appear for non-host users when no presenter is active.
• When the scoreboard appears, it replaces the quiz UI.

Behavior

Image distribution

• Two internal pools exist: “real” and “fake” images.
• On init, both pools are shuffled and paired into left/right combos per participant.
• Each pair records the hidden correct side on the server.

Answering

• Available while no presenter phase is active.
• Per-pair answers are stored client-side and synced with ANSWER messages.
• Tapping the selected option again toggles it to “no answer”.

Notes (rationales)

• Free text field under the images.
• Debounced by 300 ms to reduce update spam.
• Values are URI-encoded when sent and decoded on display.

Presenter phase

• The node advances into presenter mode after the first forward navigation by the host.
• A round-robin sequence of presenter turns is created. In each turn, the current presenter sees one specific pair; others observe.
• The host can reveal the correct answer for the active pair. Once revealed, the presenter’s solutions entry flips from -1 to the correct index.

Scoreboard

• After the final presenter turn, the node computes scores for all players by comparing each answer with the server-side solution.
• A ranked scoreboard is broadcast and shown to everyone.
• Per-node scoreboard values are also retained in the workshop’s scoreboard map.

Navigation

• Host uses global workshop navigation as usual.
• Non-host users receive in-node previous/next buttons to browse their own pairs only when no presenter is active. Wrapping navigation is supported.

Auto-advance

• autoNextActive is disabled in this node. Advancement is controlled by the host.

Client → server op codes

The client communicates changes through small messages:

• ANSWER (0) Payload: { answers: number[] } Saves the viewer’s answer array. Ignored while a presenter is active.
• RESOLVE (1) Payload: {} Host-only. When a presenter is active, reveals the correct answer for the presenter’s shown pair and broadcasts an update.
• NOTES (2) Payload: { notes: string[] } Saves the viewer’s notes array. Ignored while a presenter is active.

Node lifecycle

• init: Shuffles image pools, builds per-user image pairs, initializes per-user answer, solution, and note arrays, and constructs the presenter turn order.

• sendData: Sends tailored nodeData to each connected presence:

  • Active presenter: one pair plus their answer/solution/note for that pair.
  • Other participants during presenter phase: empty arrays and a “watching XY” indicator.
  • No presenter active: full arrays for each user.
  • Host: a minimal host payload with current state flags.

• messages: Applies ANSWER, NOTES, and RESOLVE updates with role and phase checks.

• next/back: Moves forward to the next presenter or backward to the previous presenter. When the final presenter completes, calculates and emits the scoreboard.

Use cases

• Media literacy: “Fake vs. Real” photo detection with brief justifications.
• Forensics warm-up: practice spotting artifacts before a deeper lesson.
• Team challenge: rotate through presenters and reveal results live.
• Assessment-lite: quick scoring without long-form grading.

Accessibility and UX notes

• Rationale input supports multi-line text and is debounced for responsiveness.
• Image buttons should provide clear focus states and labels in the underlying UI implementation.
• Consider short, plain-language placeholders and concise instructions.

Example host flow

1. Start node. Participants answer their pairs and jot short rationales.

2. Host advances to begin presenter turns.

3. For each presenter:

   • Presenter sees a single pair.
   • Host triggers “Reveal the right answer!” when ready.

4. After the last presenter, the scoreboard appears automatically.

Example: client payload shape (participant, no presenter)

{
  "images": [["fake01.jpg", "real01.jpg"], ["real02.jpg", "fake02.jpg"]],
  "answers": [-1, 1],
  "solutions": [-1, -1],
  "notes": ["Eye reflections look odd", ""],
  "presenter": false
}

Example: client payload shape (watching a presenter)

{
  "images": [],
  "answers": [],
  "solutions": [],
  "notes": [],
  "presenter": "Alice"
}

Example: client payload shape (active presenter)

{
  "images": [["real07.jpg", "fake07.jpg"]],
  "answers": [0],
  "solutions": [-1],
  "notes": ["Skin texture looks consistent"],
  "presenter": true
}

Example: scoreboard payload

{
  "scoreboard": [
    { "userId": "u_1", "user": { "name": "Alex", "avatar": "…" }, "score": 8, "oldScore": 8 },
    { "userId": "u_2", "user": { "name": "Sam",  "avatar": "…" }, "score": 7, "oldScore": 7 }
  ]
}

Integration tips

• Precede the ImgQuiz with a short slide to explain the rules and a countdown to create suspense.
• Follow with a debrief slide summarizing common cues participants mentioned in their notes.
• If you need to change image pools or increase round counts, adjust the server-side init logic accordingly.