# Info-Board Neu - Template- und Kampagnenkonzept

## Ziel

Dieses Dokument konkretisiert die globale Orchestrierung im Admin-Backend.

Es geht um drei Kernpunkte:

1. Template-Typen und ihr fachlicher Zweck
2. Konfiguration und Bearbeitung dieser Templates
3. Zielmodell fuer Monitorwand, Einzelanzeigen und Aktivierung als Kampagne

Das Ziel ist, dass globale Inhalte von Anfang an sauber in das Systemmodell integriert sind und nicht spaeter als Sonderfall angebaut werden muessen.

## 1. Template-Typen

### `message_wall`

Dieser Typ dient fuer grosse monitoruebergreifende Botschaften.

Typische Beispiele:

- `SCHOENE FERIEN`
- `MORZ-INFO`
- `WEIHNACHTSFEIER`

Eigenschaften:

- ein Gesamtmotiv oder Gesamttext wird auf mehrere Displays verteilt
- jedes Display zeigt nur einen Ausschnitt oder einen zugewiesenen Teil des Gesamtlayouts
- sinnvoll vor allem fuer die bestehende Infowand mit hochkant montierten Bildschirmen

Technische Anforderungen:

- logisches Slot-Modell fuer die Wand
- definierte Zielgruppe von Screens
- klare Zuordnung `welcher Ausschnitt auf welchem Screen`

Verbindliche Entscheidung fuer v1:

- serverseitige Aufloesung in konkrete Screen-Szenen statt playerseitiger Segmentberechnung
- der Player erhaelt nur den fuer ihn fertigen Ausschnitt

### `full_screen_media`

Dieser Typ dient fuer ein identisches oder pro Zielgeraet passend skaliertes Vollbildmotiv.

Typische Beispiele:

- Weihnachtsmotiv auf allen Screens
- Sommerferiengrafik
- Veranstaltungslogo
- identisches Informationsvideo auf mehreren Displays

Eigenschaften:

- alle ausgewaehlten Monitore zeigen denselben fachlichen Inhalt
- die technische Darstellung kann je nach Ausrichtung variieren
- ideal fuer schnelle globale Uebersteuerungen

Technische Anforderungen:

- medientypgerechte Darstellung fuer Hoch- und Querformat
- optionale getrennte Assets pro Orientierungsgruppe
- einfache Aktivierung/Deaktivierung im Admin-Backend

### `screen_specific_scene`

Dieser Typ dient fuer kampagnenweite, aber monitorindividuelle Szenen.

Typische Beispiele:

- auf der Infowand ein Schriftzug
- auf zusaetzlichen Vertretungsplan-Anzeigen parallel ein passendes Seitenlayout
- auf bestimmten Screens ein Veranstaltungsprogramm, auf anderen ein Wegweiser

Eigenschaften:

- ein Template besteht aus mehreren gezielten Szenen
- jede Szene ist bestimmten Screens, Gruppen oder Slots zugeordnet
- hoechste Flexibilitaet fuer spaetere Ausbaustufen

Technische Anforderungen:

- Zuordnung zu konkreten Screens oder Gruppen
- getrennte Assets je Zielgeraet moeglich
- definierte Prioritaet gegenueber tenantbezogenem Content

## 2. Template-Konfiguration im Admin-Backend

### Grundaufbau eines Templates

Ein Template besteht mindestens aus:

- technischem Namen (`slug`)
- Anzeigenamen
- Template-Typ
- Beschreibung
- Zieldefinition
- einem oder mehreren Szenen-/Medieneintraegen
- optionalen Standardwerten fuer Dauer, Timeouts und Fehlerverhalten

### Konfigurierbare Felder

Pro Template sollen mindestens pflegbar sein:

- `name`
- `slug`
- `description`
- `template_type`
- Standarddauer
- Standard-Timeout
- Standard-Fehlerstrategie
- Zielmenge (`alle Screens`, `Screen-Gruppe`, `einzelne Screens`, `Wall-Slots`)

### Szenen-/Asset-Konfiguration

Pro Szene oder Teilbereich sollen mindestens konfigurierbar sein:

- Medientyp (`image`, `video`, `pdf`, `web`, `html`)
- Quelle oder Asset
- Dauer
- `valid_from`
- `valid_until`
- Fehlerverhalten
- Zielscreen oder Zielslot
- Layout-Metadaten

### Aktivierung als Kampagne

Templates werden nicht direkt abgespielt, sondern als Kampagnen aktiviert.

Eine Kampagne ist die operative Auspraegung eines Templates und enthaelt:

- Name der Kampagne
- referenziertes Template
- Prioritaet
- Aktiv-Status
- `valid_from`
- `valid_until`
- Zielmenge
- Override-Modus

### Wichtige Admin-Funktionen

Im Admin-Backend soll es dafuer geben:

- Template-Liste
- Template-Editor
- Kampagnenliste
- Aktivieren/Deaktivieren auf Knopfdruck
- Zeitgesteuerte Aktivierung
- Vorschau, welche Screens betroffen sind
- Anzeige, welche Screens aktuell von einer Kampagne uebersteuert werden

## 3. Zielmodell fuer Monitorwand und Einzelanzeigen

## Ausgangslage

Das System darf nicht auf die aktuelle 9er-Infowand beschraenkt bleiben.

Perspektivisch sind mindestens zwei Klassen von Displays zu erwarten:

- Infowand-Screens im Hochformat
- zusaetzliche Einzelanzeigen wie Vertretungsplan-Displays im Querformat

Deshalb wird von Anfang an zwischen logischem Ziel und physischer Darstellung unterschieden.

### Screen-Klassen

Sinnvolle fachliche Klassen:

- `info_wall`
- `single_info_display`
- `vertretungsplan_display`

Diese Klassen koennen spaeter fuer Voreinstellungen, Templates und Provisionierung genutzt werden.

### Orientierung als Kernattribut

Jeder Screen braucht von Anfang an eine fest definierte Orientierung.

Mindestens:

- `portrait`
- `landscape`

Optional spaeter:

- exakte Rotation `0`, `90`, `180`, `270`

Warum das wichtig ist:

- Assets muessen passend skaliert oder getrennt gepflegt werden
- globale Kampagnen koennen fuer Hoch- und Querformat unterschiedliche Szenen brauchen
- Provisionierung und Display-Setup muessen die Orientierung kennen

### Gruppen- und Slot-Modell

Es werden zwei Zielmodelle parallel unterstuetzt.

#### Gruppenmodell

Gruppen fassen Screens logisch zusammen, z. B.:

- `all`
- `wall-all`
- `wall-row-1`
- `vertretungsplan-all`

Dieses Modell ist ideal fuer:

- globale Motive
- saisonale Kampagnen
- Massenaktionen im Admin-Bereich

#### Slot-Modell

Slots beschreiben feste Positionen innerhalb einer Monitorwand.

Beispiele:

- `wall-r1-c1`
- `wall-r1-c2`
- `wall-r1-c3`
- `wall-r2-c1`

Dieses Modell ist ideal fuer:

- verteilte Schriftzuege
- zusammengesetzte Grossmotive
- geordnete Layouts ueber mehrere Screens

### Empfohlene Grundregel fuer Kampagnen

Jede Kampagne definiert ihren Zielraum explizit:

- `all_screens`
- `screen_group`
- `specific_screens`
- `wall_slots`

Die Inhaltsprioritaet bleibt dabei immer:

1. aktive Kampagne
2. tenantbezogene Playlist
3. Fallback

### Beispiel 1 - Schriftzug ueber die Infowand

- Template-Typ: `message_wall`
- Ziel: Gruppe `wall-all`
- Layout: Text wird in neun Segmente geteilt
- jeder Slot bekommt seinen Ausschnitt
- die 4 kuenftigen Vertretungsplan-Screens bleiben unberuehrt

### Beispiel 2 - Weihnachtsmotiv auf allen Screens

- Template-Typ: `full_screen_media`
- Ziel: Gruppe `all`
- fuer Portrait-Screens wird Portrait-Asset verwendet
- fuer Landscape-Screens wird Landscape-Asset verwendet

### Beispiel 3 - Veranstaltungstag mit gemischten Anzeigen

- Template-Typ: `screen_specific_scene`
- Infowand zeigt Event-Motto
- Vertretungsplan-Screens zeigen Programm oder Wegweiser
- alles als eine Kampagne administrierbar

## Auswirkung auf Datenmodell und Implementierung

Von Beginn an mitzudenken sind:

- Template-Typen
- Kampagnen als aktivierbare Instanzen
- Gruppenmodell
- Slot-Modell fuer die Wand
- Orientierung pro Screen
- moegliche getrennte Assets fuer Portrait und Landscape

Damit ist die globale Orchestrierung ein tragender Bestandteil des Systems und kein nachtraeglicher Sonderbau.

## Verbindliche Vorgabe fuer v1

Vor der UI- und Render-Implementierung gilt:

- `message_wall` wird serverseitig in konkrete Zielinhalte aufgeloest
- `layout_json` beschreibt die serverseitige Segmentlogik und Admin-Vorschau
- Slots werden geometrisch serverseitig interpretiert, nicht im Player berechnet

Details dazu stehen in `docs/LAYOUT-JSON.md`.
