163 lines
8.8 KiB
Markdown
163 lines
8.8 KiB
Markdown
# 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/`](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** (Handeln am Brett → Auflösung; Gates als Entscheidung) →
|
||
> **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`, **24** = 6 Services × 4 Change-Arten; Major/Normal/Standard/Emergency).
|
||
> **Deployment:** statisch, siehe
|
||
> [`app/DEPLOY.md`](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
|
||
|
||
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) — 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 → 4 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)
|
||
→ Aktivitäts-Station (schrittweiser Mikro-Ablauf, 4 Fragen je einzeln + Auflösung):
|
||
→ (1) Was steckt hinter der Überschrift? (2) Beteiligte Rollen → Figuren auf die Puck-Mulden
|
||
→ (3) RACI → Figuren ins Aktiv-Feld (R/A/C/I), mit RACI-Legende
|
||
→ (4) Artefakt als Choice → kommt in die digitale Service-Akte (Panel "📁 Akte")
|
||
→ Abschluss-Screen ("✓ Aktivität abgeschlossen"; an Phasengrenzen 🎉-Feedback) → "Nächste Station"
|
||
→ Gate-Station: App prüft die geforderten Artefakte (fehlen sie → Entscheidung gesperrt) + Pflicht-Figuren
|
||
→ Entscheidung wählen (Go/Auflagen/Zurück/Ablehnung bzw. Entwicklung/Konfiguration)
|
||
→ Konsequenz + Verzweigung (Konfiguration überspringt den Build; echte Rückschleifen;
|
||
reicht die SOR-Hoheit nicht → Demand via DPM ans Mission Board)
|
||
→ [Ende] → Debrief-Export (bearbeitete Stationen, unklare, Pfad)
|
||
```
|
||
|
||
## 5. Funktionsumfang (MVP)
|
||
|
||
- [x] Stationsführung: linearer Durchlauf mit „Nächste Station" + Fortschritt/Phasen-Farben.
|
||
- [x] Fragetypen 1–3 (vermittelndes Quiz).
|
||
- [x] „Auflösen"-Mechanik (Antwort erst auf Klick) **+ ausführliche Stationsauflösung** (Erklärung/RACI/Artefakt) nach dem Quiz.
|
||
- [x] „Unklar"-Markierung je Aktivität.
|
||
- [x] Debrief-Export (Markdown **und** JSON, lokaler Download).
|
||
- [x] 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).
|