morz-infoboard/docs/TEMPLATE-KONZEPT.md

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.