290 lines
7.3 KiB
Markdown
290 lines
7.3 KiB
Markdown
# 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
|