adminpepe/Lageplan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
Lageplan/docs/roadmap-feedback-fabian.md
Pepe Ziberi 3b57ca4594
All checks were successful
Build and Push Docker Image / build-and-push (push) Successful in 13m43s
Details
docs(roadmap): Phase 1.1 Tasks aufgeteilt in erledigt/offen
2026-05-20 21:09:53 +02:00

12 KiB
Raw Permalink Blame History

Roadmap — Feedback Fabian (Mai 2026)

Quelle: User-Feedback von Fabian, Führungsoffizier / Übungsleiter Feuerwehr. Erhalten: 20.05.2026 Status: Geplant, noch nicht umgesetzt.

Dieses Dokument ist die strukturierte Roadmap aus Fabians Feedback. Jede KI / jeder Entwickler der an Lageplan arbeitet, soll diese Datei vor Beginn lesen, um Kontext und Priorisierung zu kennen.

Originalfeedback (Zusammenfassung)

Fabian sucht eine Lösung um Einsätze und Übungen einfach zu skizzieren und zu krokieren. Lobt die App, gibt aber konkrete Verbesserungsvorschläge aus Anwendersicht:

  1. Einsatz vs. Übung unterscheiden — bei Übungen kein Journal nötig, dafür Übungsziele/Auswertung
  2. Symbol-Bibliothek erweitern — Warteraum, Rettungsachse, taktische Zeichen
  3. Symbol-Schönheitsfehler — Treppe/Eingang mit Umriss, Absperrung
  4. Stockwerke/Geschosse — eigene Werte eintragen
  5. Symbol-Kategorien aufräumen — Motorspritze unter Organisation statt Geräte; Hydrant/Leitern uneinheitlich
  6. Linien mit Typ — nach Zeichnen wählen: Rettungsachse (gestrichelt + R), Leitung (blau), Schlauch, etc.
  7. Multi-User Live — eine Person zeichnet Karte, andere schreibt Journal gleichzeitig
  8. Rapport-/Lageansicht — separate Sicht mit Pendenzen, aktueller Stand, wichtige Punkte für Führungsunterstützung (FU), darstellbar auf grossem Bildschirm; nicht alle Journaleinträge sichtbar für alle

Phasen-Plan

Phase 1 — Symbol-Architektur Redesign (3-4 Wochen) ⭐⭐

Strategischer Umbau statt nur Kategorien aufräumen. Begründung:

  • Fabians Feedback zeigt, dass die aktuelle Kategorisierung uneinheitlich ist
  • Symbol-Bibliothek ist zu starr — andere Anwender (THW, Sanität, ausländische Wehren) brauchen andere Symbole
  • Mandantenfähigkeit ist zentrales Versprechen → muss auch für Symbole konsequent durchgezogen werden

1.1 Neue Symbol-Architektur: Template-Import + 100% mandantenspezifisch

Konzept: Mandant startet mit leerer Bibliothek, importiert beim Onboarding (oder jederzeit) kuratierte Vorlagen-Pakete (Feuerwehr CH, THW, Sanität…). Importierte Symbole werden vollständig eigene Mandanten-Daten — umbenennbar, löschbar, kategorisierbar, ergänzbar.

Datenmodell:

TenantCategory      (per-tenant, frei definierbar)
  - id, tenantId, name, sortOrder, icon

TenantSymbol        (per-tenant, ehemals "Meine Symbole")
  - id, tenantId, categoryId → TenantCategory
  - name, svgPath, sortOrder, customName

SymbolTemplate      (global, read-only)
  - id, packageId ("feuerwehr-ch", "thw", "sanitaet")
  - categoryName, name, svgPath, tags

Tasks:

  • Schema-Migration: TenantCategory neu, TenantSymbol.categoryId ergänzen, SymbolTemplate erstellen
  • Migration SQL + idempotente Raw-SQL-Migration (prisma/migrate.js)
  • Seed-Skript: public/signaturen/*.svg → SymbolTemplate
  • Migration bestehender Tenants: TenantSymbol.name, svgPath, categoryId befüllen
  • Auto-Import des feuerwehr-ch Pakets beim ersten Login (oder bei leerer Bibliothek)
  • API: CRUD für TenantCategory (GET/POST/PATCH/DELETE /api/tenant/categories)
  • API: GET /api/templates — listet verfügbare Pakete
  • API: POST /api/templates/import — importiert ausgewählte Symbole als TenantSymbols
  • API: TenantSymbol erweitern — Upload-Endpoint, Kategorie-Zuordnung, gruppierte Liste
  • Files: prisma/schema.prisma, src/app/api/tenant/categories/, src/app/api/tenant/symbols/, src/app/api/templates/

1.2 UX: Symbol-Manager im Admin

Sidebar / Symbol-Verwaltung:

┌─ Meine Symbole ─────────────┐
│ ┌ Fahrzeuge ─────────┐      │
│ │ 🚒 TLF             │      │
│ │ 🚒 RW              │      │
│ │ + Symbol           │      │
│ └────────────────────┘      │
│ ┌ Wasser ────────────┐      │
│ │ 🟦 Hydrant         │      │
│ └────────────────────┘      │
│ [+ Kategorie]               │
│ [📦 Vorlagen importieren]   │
└─────────────────────────────┘

Tasks:

  • Admin-Tab: Kategorien anlegen/umbenennen/sortieren (Drag & Drop)
  • Symbole pro Kategorie verwalten (Drag & Drop zwischen Kategorien)
  • Eigene SVG-Uploads direkt einer Kategorie zuordnen
  • Import-Dialog: Pakete-Auswahl mit Vorschau, granulare Symbol-Auswahl
  • Mehrfach-Import desselben Symbols erlaubt (z.B. "TLF rot" + "TLF blau" auf gleicher SVG-Basis)
  • Files: src/components/admin/icons-tab.tsx (umbauen), neuer import-templates-dialog.tsx

1.3 Vorlagen-Pakete kuratieren

Aus dem aktuellen Symbol-Bestand werden die ersten Pakete:

  • 📦 Feuerwehr Schweiz — taktische Zeichen CH (aktueller Bestand, sauber kategorisiert)
  • 📦 Sanität / Rettungsdienst — falls Symbole vorhanden, sonst Phase 2
  • 📦 Polizei / Verkehr — als Stub für später
  • Innerhalb der Pakete: fehlende taktische Zeichen ergänzen:
    • Warteraum
    • Rettungsachse
    • Sammelplatz
    • Verletztennest / Eingang Verletzter
    • Einsatzleitung (EL) / Kommandoposten
    • Bereitstellungsraum
  • Symbol-Schönheitsfehler im Paket beheben:
    • Treppe — Umriss entfernen
    • Eingang — Umriss entfernen
    • Absperrung — Seitenlinien aufräumen
  • Files: prisma/seed/symbol-templates.ts, public/icons/

1.4 Stockwerke/Geschosse editierbar

  • Symbol-Property: instanceLabel (Freitext, pro Symbol-Instanz auf der Karte)
  • Bei Gebäude-Symbolen: optionales Textfeld für Geschosszahl (z.B. "EG+3")
  • Anzeige als Badge auf dem Symbol
  • Editierbar via Doppelklick oder Sidebar
  • Files: src/types/, map-view.tsx Symbol-Renderer, ggf. DrawFeature.properties erweitern

Phase 1.5 — Quick Polish (parallel oder danach, 1 Woche) 🔥

Kleinkram der nicht in den Architektur-Umbau passt aber wichtig ist.

  • Default-Linientyp / -farbe pro Mandant konfigurierbar
  • Symbol-Suche im Sidebar (Volltext über Name, Tags, Kategorie)
  • Häufig-benutzte Symbole oben anzeigen (Recent / Favoriten)

Phase 2 — Übungsmodus (2-3 Wochen) ⭐

Neuer Projekt-Typ, eigene Logik.

2.1 Projekt-Typ Auswahl

  • Bei "Neues Projekt": Auswahl Einsatz | Übung
  • DB-Schema: Project.type: 'einsatz' | 'uebung'
  • UI-Anpassung in app/page.tsx

2.2 Übungs-Metadaten

  • Felder: Übungstitel, Datum, Übungsziele (Liste)
  • Übungsleiter, Teilnehmer (optional)
  • Eigene Sidebar-Sektion für Übungsdaten

2.3 Journal ausblenden bei Übung

  • Bei type === 'uebung': Journal-Tab → "Übungsauswertung"
  • Karte bleibt voll funktionsfähig
  • Krokierung kann im Voraus erstellt und mit Übungsleitern geteilt werden (bestehender Share-Link)

2.4 Übungsauswertung

  • Checkliste Übungsziele mit Status: erreicht | teilweise | nicht erreicht
  • Notizen / Erkenntnisse pro Ziel
  • Gesamtbewertung / Erkenntnisse
  • PDF-Export für Debriefing (analog Rapport)
  • Files: neue Komponente uebungsauswertung-tab.tsx, neuer PDF-Renderer

Phase 3 — Linien mit Typ (1 Woche) ⭐

Smart Lines mit vordefinierten Stilen.

3.1 Linientypen definieren

  • Schlauch (default, aktuelle Linie)
  • Rettungsachse — gestrichelt, Label "R"
  • Leitung — blau
  • Absperrung — rot gestrichelt
  • Frei — Standard ohne Vorlage

3.2 UX

  • Nach Zeichnen einer Linie: kleines Popup "Was ist das?"
  • Auswahl per Klick → Linie wird automatisch gestylt
  • In Sidebar pro Linie nachträglich änderbar (Dropdown)
  • Tastatur-Shortcut für Typ-Wechsel?

3.3 Daten-Modell

  • DrawFeature erweitern: lineCategory: 'hose' | 'rescue' | 'pipe' | 'barrier' | 'free'
  • Default-Stile als Konstante (Farbe, Strich, Label)
  • Files: src/types/, tool-store.ts, map-view.tsx

Phase 4 — Rapport-/Lageansicht (Führungsunterstützung) (2-3 Wochen) ⭐

Eigenes Modul, hoher Mehrwert für FU.

4.1 Sichtbarkeits-Stufen pro Journaleintrag

  • DB: JournalEntry.visibility: 'intern' | 'rapport' | 'public'
  • UI: Dropdown beim Erstellen / Editieren
  • Migration: bestehende Einträge → intern (sicher)

4.2 Rapport-Modus (Display)

  • Neuer Tab/Modus: Rapport-Ansicht
  • Sektionen:
    • Aktuelle Lage (Freitext, prominentes Feld)
    • Pendenzen (Liste mit Status: offen/erledigt)
    • Wichtige Punkte / Befehle
    • Mittel / Personal (aktueller Stand)
  • Grosse Schrift, kontrastreich (Beamer-tauglich)
  • Auto-Refresh via Socket.IO

4.3 Display-Sharing

  • Read-only Token-Link (wie bestehende Rapport-URL)
  • Vollbild-Modus
  • Optional: Auswahl welche Sektionen sichtbar

4.4 Berechtigungen

  • Rolle "Rapport-Viewer" — sieht nur Rapport, nicht Karte / Journal
  • Berechtigung pro Projekt vergebbar

Phase 5 — Multi-User Live-Editing polish (optional, später)

Realtime-Sync läuft schon via Socket.IO — hier nur Verbesserungen.

  • Live-Cursor anderer User auf Karte (mit Name)
  • Presence-Anzeige ("Fabian schreibt im Journal", "Pepe zeichnet")
  • Soft-Locks während Symbol bewegt wird
  • Conflict Resolution bei gleichzeitigem Edit testen

Priorisierungs-Matrix

Phase Aufwand Impact Priorität Empfohlene Reihenfolge
1 — Symbol-Architektur Redesign L (3-4 W) Sehr Hoch ⭐⭐ Höchste 1.
1.5 — Quick Polish S Mittel 🔥 Hoch parallel zu 1
3 — Linien-Typen M Hoch ⭐ Hoch 2.
4 — Rapport-Ansicht L Sehr Hoch (FU) ⭐ Sehr Hoch 3.
2 — Übungsmodus L Sehr Hoch ⭐ Sehr Hoch 4.
5 — Multi-User polish M Mittel 📅 Mittel später

Begründung der Reihenfolge:

  1. Phase 1 zuerst — Architektur-Umbau, weil alles andere darauf aufbaut. Sobald TenantSymbols + Kategorien sauber strukturiert sind, sind 1.3 (fehlende Symbole) und 1.4 (Stockwerke) trivial. Auch Phase 2 (Übungsmodus) profitiert: Übungs-Pakete als eigene Templates möglich.
  2. Phase 3 (Linien-Typen) — kleine Erweiterung, hoher UX-Gewinn, unabhängig von Phase 1.
  3. Phase 4 (Rapport-Ansicht) — USP gegenüber anderen Krokier-Tools, FU-Funktion fehlt überall sonst.
  4. Phase 2 (Übungsmodus) — grosses Update; baut konzeptuell auf Phase 4 auf (Übungsauswertung ≈ Rapport).
  5. Phase 5 — Polish, kein User wartet darauf.

Risiko-Hinweis Phase 1:

  • Schema-Migration von Icon (global) zu SymbolTemplate + Auto-Import muss wasserdicht sein, damit existierende Mandanten ihre Symbole nicht verlieren
  • Vor Deploy: vollständiges DB-Backup (PostgreSQL) und MinIO-Backup (Icon-Files)
  • Auf Staging testen falls möglich, sonst kleinen Test-Tenant zuerst migrieren

Hinweise für Entwickler / KIs

  • Stack: Next.js 15, React 19, MapLibre GL JS, Prisma, PostgreSQL, MinIO, Socket.IO, Zustand
  • Sprache: Schweizerdeutsch / Hochdeutsch (Code englisch, UI deutsch)
  • Bei Symbol-Änderungen: SVGs in public/icons/ + Symbol-Definitionen + ggf. DB-Migration
  • Bei Schema-Änderungen: Prisma Migration erstellen + DB-Backup vor Deploy
  • Vor Deploy: Build testen (npx next build), commit + push, Portainer baut automatisch via Webhook
  • Realtime: bei DB-Änderungen, die alle User sehen müssen, Socket-Event triggern

Status-Tracking

Status pro Aufgabe oben in Checkboxen. Hier kurzer Überblick:

  • [-] Phase 1 — Sprint A erledigt (Schema, Migration, Seed). Sprint B–D offen.
  • Phase 2 — nicht gestartet
  • Phase 3 — nicht gestartet
  • Phase 4 — nicht gestartet
  • Phase 5 — nicht gestartet

Letztes Update: 2026-05-20 Verantwortlich: Pepe (adminpepe)

Reference in New Issue View Git Blame Copy Permalink