Tablet-Quiz — Begleit-App (Teilprojekt)

Status: App lauffähig (PWA) · Deploy vorbereitet · Typ: eigenständiges Software-Teilprojekt des SLC-Workshops

Umsetzungsstand: Die App liegt unter app/ als statische PWA (offline-/kioskfähig). Flow: Karten-Raster (Action Card ziehen) → Change-Art bestimmen (mit Legende, „nochmal versuchen" bis richtig) → Phasen-Einstieg (Lebenszyklus-Phase anklicken) → Stationen (Diskussion/Quiz/Auflösung) → Debrief mit Markdown-/JSON-Export. Inhalte (Stationen, Quizfragen, Use-Cases) sind derzeit in app/index.html eingebettet. Die finalen Action-Card-Grafiken (Freiburg-digital-Layout) liegen in app/cards/ (s<service>-c<change>.png, alle 30). Deployment: statisch, siehe app/DEPLOY.md. Lokal testen: python -m http.server 8099 --directory 04_Tablet-Quiz/app (oder Preview-Config .claude/launch.json).

Das Tablet-Quiz ist der digitale Begleiter des Tabletops — kein Ersatz fürs Brett. Es ist der erklärende Gegenpart zu den Pucks: Die Pucks tragen nur die Kurzbezeichnung (Etikett), 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 Pucks 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 (die nicht auf dem Puck steht) 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

Reihenfolge: „Was kommt nach tr_08?"
Rolle / RACI: „Wer ist Accountable für op_06?"
Artefakt: „Welches Artefakt entsteht bei tr_07?"
Gate-Logik: „Wer muss an Gate 1 zustimmen?" / „Welche Pfade gibt es?"
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) — der Inhalt, der bewusst nicht auf dem Puck steht, sondern in der App liegt.

4. Ablauf (UI-Flow)

[1] Action Card ziehen  → Raster aller Karten-Grafiken, eine antippen
[2] Change-Art bestimmen → 5 Change-Arten + Legende; falsch = "nochmal", richtig = weiter
[3] Erfolgreiche Kategorisierung → kurze Bestätigung + Warum
[4] Einstieg finden     → Lebenszyklus groß: Phase anklicken (falsch = "nochmal")
[5] Los geht's          → App nennt Start-Station + Begründung
   → App führt ab Start-Station durch die Stationen (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)

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 und JSON, lokaler Download).
PWA / offline lauffähig (Manifest + Service Worker).
questions.json + Stations-Inhalte aus YAMLs generieren (Build-Skript) — Inhalte aktuell in app/index.html eingebettet (braucht Blueprint-Repo-Zugriff).

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. Companion-Chatbot (optional · Nachschlage-Begleiter)

Idee: Teilnehmende stellen spontane Verständnisfragen, die das feste Quiz nicht abdeckt — z. B. „Was ist das Service Design Document?" oder „Wer ist an Gate 2 accountable?". Der Bot beantwortet sie aus dem Blueprint.

Rolle & Grenzen (didaktisch)

Nachschlagen, nicht führen. Der Bot ersetzt nicht die Stationsführung. Das Lernprinzip (erst Gruppendiskussion → Tipp → App-Auflösung) bleibt das Rückgrat; ein frei führender Bot würde das „produktive Ringen" aushebeln.
Freischaltung gated: pro Station erst nach dem „Auflösen" verfügbar (oder als klar getrennter „Frag nach"-Knopf), damit er das Diskutieren-zuerst nicht kurzschließt.
Scope-begrenzt: antwortet nur aus dem Blueprint, keine freie Beratung; bei Unklarheit Verweis auf den „Unklar"-Marker → Debrief.

Datengrundlage

Der Lifecycle-Blueprint ist klein (~2.000 Zeilen YAML). Kein RAG/Vektor-Setup nötig — alle service-lifecycle_*.yaml + spm_rollen.yaml passen in einen einzigen System-Prompt-Kontext.
Single Source of Truth bleibt der Blueprint (keine Doppelpflege).

Wiederverwendung statt Neubau

Im Repo existiert bereits ein Bot: #099_tools/digitom-bot/ mit Knowledge-Base (SPM_service-lifecycle_*.md) und Dify-Upload. Vor Neubau prüfen, ob dieser als Begleiter angedockt werden kann.

Offene Architektur-Entscheidung: Offline vs. Cloud

Ein Laufzeit-LLM braucht einen API-Aufruf → Internet/Endpoint/Key. Das steht im Konflikt zur Konzept-Bedingung (offline, Kiosk, keine Cloud, kein Login; vgl. Abschnitt 6). Optionen:

Variante	Pro	Contra
(a) Cloud-LLM (Dify / Anthropic / Azure-OpenAI)	geringster Aufwand, beste Qualität	Online-Pflicht, Datenschutz-/Beschaffungsfreigabe
(b) Lokales LLM (z. B. Ollama auf dem Gerät)	offline-konform	Hardware-/Setup-Aufwand, schwächere Qualität
(c) Statische FAQ (vorab generierte Q&A aus Blueprint)	voll offline, keine Kosten	keine Freitextfragen, begrenzte Abdeckung

Empfehlung für den Pilot: mit (a) als separater, optionaler Begleiter starten und im Pilot evaluieren, ob der Mehrwert die Online-Pflicht rechtfertigt.

9. 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.
Companion-Chatbot: Entscheidung Offline vs. Cloud (Abschnitt 8).
Prüfen, ob digitom-bot/Dify als Begleiter wiederverwendbar ist.
Freischalt-Logik des Bots festlegen (nach „Auflösen" vs. jederzeit).

8.2 KiB Raw Blame History Unescape Escape