SLC_Game/04_Tablet-Quiz

Tablet-Quiz — Begleit-App (Teilprojekt)

Status: Konzept · Typ: eigenständiges Software-Teilprojekt des SLC-Workshops

Das Tablet-Quiz ist der digitale Begleiter des Tabletops — kein Ersatz fürs Brett. Es ist der erklärende Gegenpart zu den Plättchen und ersetzt deren Rückseite: Die Plättchen tragen nur noch die Kurzbezeichnung, die ausführliche Erklärung liefert die App. Sie führt die Stationsreihenfolge (linearer Lifecycle), stellt pro Station ein vermittelndes Quiz, gibt danach die ausführliche Auflösung und protokolliert Verständnislücken fürs Debrief.

---

1. Ziel & Rolle im Spiel

• Stationsführung: schaltet Station für Station automatisch weiter („Nächste Station") — die Plättchen brauchen keinen Code.
• Active Recall verstärken: erst Diskussion am Board, dann vermittelndes Quiz, dann Auflösung — Gruppe rät, App bestätigt/korrigiert.
• Vollständige Erklärung: liefert nach dem Quiz die ausführliche Auflösung (ersetzt die Plättchenrückseite) aus dem Blueprint (Single Source of Truth).
• Dokumentation: erfasst automatisch, welche Aktivitäten unklar waren (→ ../05_Workshop-Dokumentation/).

Bewusst nicht das Ziel: das Spiel digital ersetzen, Echtzeit-Multiplayer, Accounts/Login, Cloud-Pflicht.

2. Datengrundlage (keine Doppelpflege)

Die App liest ausschließlich die bestehenden Blueprint-Dateien und leitet Fragen daraus ab:

Quelle	liefert
service-lifecycle_*.yaml	Aktivitäten, Beschreibungen, Reihenfolge, Gates
spm_rollen.yaml	Rollen, RACI, Gate-Keeper

Ein Build-Schritt konvertiert die YAMLs in ein statisches questions.json. Damit bleibt der Blueprint die einzige Wahrheit; Inhalte werden nie im App-Code dupliziert.

3. Fragetypen

1. Reihenfolge: „Was kommt nach tr_08?"
2. Rolle / RACI: „Wer ist Accountable für op_06?"
3. Artefakt: „Welches Artefakt entsteht bei tr_07?"
4. Gate-Logik: „Wer muss an Gate 1 zustimmen?" / „Welche Pfade gibt es?"
5. Zuordnung: „In welcher Phase liegt sp_09?"

Jede Frage: Gruppentipp → Auflösen-Button → Modellantwort. Im Anschluss an das Quiz folgt die ausführliche Auflösung der Station (vollständige Beschreibung + Rollen/RACI + Artefakt aus der YAML) — das ist der Inhalt, der früher auf der Plättchenrückseite stand.

4. Ablauf (UI-Flow)

[Start] → Szenario wählen (= Action Card)
   → App führt zur aktuellen Station (linearer Lifecycle, Fortschritt sichtbar)
   → Station:
       → Gruppe diskutiert am Board anhand der Kurzbezeichnung (App noch zu)
       → Quiz (vermittelnd): Frage(n) → Gruppentipp → "Auflösen" → richtig/falsch
       → ausführliche Auflösung der Station (Erklärung + RACI + Artefakt)
       → Gruppe reflektiert; optional "war unklar" markieren
       → "Nächste Station"
   → an Gates: Gate-Frage + Rollen-Check
   → [Ende] → Debrief-Export (unklare Aktivitäten, Quote, Pfad)

5. Funktionsumfang (MVP)

• questions.json + Stations-Inhalte aus YAMLs generieren (Build-Skript).
• Stationsführung: linearer Durchlauf mit „Nächste Station" + Fortschritt/Phasen-Farben.
• Fragetypen 1–3 (vermittelndes Quiz).
• „Auflösen"-Mechanik (Antwort erst auf Klick) + ausführliche Stationsauflösung (Erklärung/RACI/Artefakt) nach dem Quiz.
• „Unklar"-Markierung je Aktivität.
• Debrief-Export (Markdown/JSON, lokal).

Später (Ausbau)

• Gate-Fragen mit Rollen-Check (Typ 4–5).
• Mehrere Szenarien mit unterschiedlichen Fragesets.
• Punktestand / Team-Modus.
• Mehrsprachigkeit.

6. Technik-Empfehlung

• Single-Page-Web-App, offline lauffähig (PWA), passt zum bestehenden HTML-first-Stil im Repo (vgl. MB-Retro-HTMLs).
• Kein Backend nötig: statisches questions.json + LocalStorage für das Logbuch.
• Tablet im Kiosk-/Vollbildmodus; keine Konten, keine Cloud.
• Stack-Vorschlag: Vanilla JS oder leichtes Framework, ein Build-Skript (Node/Python) für die YAML→JSON-Konvertierung.

7. Schnittstellen zum restlichen Spiel

• Eingang: Szenarioauswahl = gezogene Action Card (../03_Karten/).
• Inhalt: Aktivitäten/Gates/Rollen = Brett-Elemente (../00_Konzept/).
• Ausgang: Debrief-Daten → Workshop-Dokumentation (../05_Workshop-Dokumentation/).

8. Offene Punkte

• Format questions.json spezifizieren.
• Entscheidung Framework vs. Vanilla.
• Wer pflegt/baut? (intern DIGIT vs. extern)
• Datenschutz: rein lokal, keine personenbezogenen Daten — bestätigen.