So haben wir den Spielplan der Staatsoper Berlin von der Website ins Foyer gebracht

Prolog

Bereits Ende 2024 ereilte uns eine spannende Anfrage von der Staatsoper Unter den Linden:

Können wir den Spielplan der Webseite auf Monitoren im Kassenbereich (im Foyer) sowie – zukünftig – auf Displays in unseren Außenvitrinen ausspielen?

Die Oper versprach sich hauptsächlich Synergieeffekte durch eine Vereinheitlichung der Datenquelle und Anzeigelogik. Derzeit wurden im Haus sowohl der aktuelle Spielplan als auch digitale Plakate für einzelne Produktionen mit hohem Aufwand als Grafiken vorbereitet und dann als zusammengesetztes Video für die Monitore (im folgenden „Infoscreens“) gerendert. Kurzfristige Änderungen von Besetzungen und Programmhinweisen oder der aktuellen Ticketverfügbarkeit konnten entweder nur mit erneut hohem Aufwand oder gar nicht berücksichtigt werden.

Unsere Antwort war ein optimistisch-enthusiastisches „Selbstverständlich!“, denn grundsätzlich spricht nichts dagegen, eine Website auf unterschiedlichen Bildschirmen oder Geräten anzuzeigen, solange das Gerät (z. B. ein Fernseher) über einen internetfähigen Browser verfügt. Und die Chance, „unsere“ Website abseits ihres natürlichen Habitats ins Foyer der Staatsoper zu bringen, wollten wir uns natürlich nicht entgehen lassen.

Von Anfang an war klar, dass es Unterschiede zur Website geben musste, da die Infoscreens nicht interaktiv sein würden, und entsprechend keine Hauptnavigation, Kategorie-Filter oder Ticket-Buttons gezeigt werden sollten. Das Hauptziel war und blieb allerdings, möglichst nah an der Ausgabe der Website zu bleiben, und neue Features oder visuelle Änderungen auch immer direkt für die Infoscreens verfügbar zu haben. Wir gingen daher mit der Annahme in die Planungsphase, dass wir nur einige Komponenten ausblenden oder geringfügig anders layouten müssten.

Das Projekt hatte dann aber doch ein paar Überraschungen parat.

1. Akt: Der Browser

Die Oper war unter anderem deswegen an uns herangetreten, weil im Rahmen eines Digitalisierungsprojekts gerade neue Monitore angeschafft worden waren. Wir waren optimistisch. Zu optimistisch? Nach etwas Wartezeit bekamen wir Details zum verbauten Mediaplayer und dem installierten Browser:

Die Engine ist nicht mehr ganz jung, aber es sollten alle Funktionen damit umsetzbar sein, allerdings muss das Template so angepasst werden, das es auf einem Chrome Version 56 läuft.

Moment. „Nicht mehr ganz jung“? Google Chrome 56 war jung, als er herauskam – im Dezember 2016.

Warum war das brisant? Wir legen beim Browser Support bereits sehr konservative Bemessungsmaßstäbe an und unterstützen alle gängigen Browserversionen auf etwa fünf Jahre rückwirkend, aber nicht neun Jahre. Tatsächlich war unter anderem das Layout der Website auf Basis von Techniken umgesetzt, die erst in späteren Chrome-Versionen verfügbar waren (CSS Grid Layout).

Ein Update des Browsers war nicht möglich:

[…] leider werden wir bei der Browser-Version hängen bleiben, da das an der Firmware des Players angedockt ist [...]

Ein Umstieg auf einen anderen Mediaplayer wie Chromecast/Google TV Streamer oder einen Raspberry Pi war ebenfalls keine Option für die Oper, weil das bestehende System weiterhin zur Verwaltung der ausgespielten Inhalte genutzt werden sollte. Die Website sollte neben Fotos und Videos nur ein Element unter mehreren in einer Gesamtpräsentation sein, die über den Mediaplayer auf den Infoscreens abgespielt würde.

Für uns bedeutete das: zumindest für den Zeitpunkt des Launches im September 2025 war davon auszugehen, dass die Umsetzung in Chrome 56 funktionieren müsste.

Zum Glück war unser Werkzeugkasten darauf einigermaßen vorbereitet. Wir nutzen in allen Projekten automatische Tools, die – basierend auf einer Konfiguration im Projekt sowie dem Abgleich mit global verfügbaren und stetig aktualisierten Datenbanken – unseren geschriebenen CSS- und JavaScript-Code je nach Bedarf modernisieren oder rückwärtskompatibel machen. Das ermöglicht uns einerseits, inzwischen unnötigen Quellcode in älteren Projekten nicht mehr auszuliefern, ohne jede Datei einzeln prüfen zu müssen. Andererseits können wir gefahrlos heute Code so schreiben, wie er in aktuellen Browserversionen  funtkioniert oder sogar erst in zukünftigen funktionieren wird, und unsere Tools schreiben den Output rückwärtskompatibel um^[1].

Um den Code für Chrome 56 fit zu machen, waren daher letztendlich nur wenige Schritte notwendig:

• Aufnahme von Chrome 56 in die Browser-Support-Konfiguration unseres Toolings
• Durchsicht von CSS und JavaScript auf Funktionen, die nicht automatisch (oder „automagisch“?) rückwärtskompatibel gemacht werden konnten
• Manuelle Anpassungen: u. a. in CSS ein Fallback auf Flexbox Layout, da CSS Grid Support erst mit Chrome 57 (!) kam; in JavaScript die Ergänzung sogenannter „Polyfills“, d. h. Code-Schnipsel, die moderne Browser-Features in JavaScript für ältere Browser nachbauen

2. Akt: Der Fernseher

Mit der erfolgreich hergestellten Browser-Kompatibilität war es Zeit für die nächste Aufgabe. Parallel hatte die Oper erste Tests auf den Infoscreens ausgeführt und uns mit einem weiteren Detail überrascht:

Die Screens in der Kassenhalle sind hochkant gestellt, stellen aber automatisch auf orientation: landscape; die Templates müssten daher um 90° nach rechts gedreht werden.

Moment. „Um 90° nach rechts gedreht“? Sicherlich ließe sich die orientation, also die maschinenlesbare Ausrichtung des Geräts, leicht anpassen und eine Drehung der Website vermeiden?

Der Mediaplayer kann das Bild nicht drehen, da die anderen Inhalte wie Videos etc. sonst nicht in 4K ausgespielt werden können. Momentan läuft es dann nur in Full HD. Wir kommen also an der Drehung der Templates leider nicht vorbei.

Die Antwort war also: nein. Spannend! Zeit für den nächsten Blick in den Werkzeugkasten. Bei Aufgaben, für die es keine standardisierte Lösung gibt (unsere Lieblingsaufgaben!), beginnen wir mit einer explorativen Phase, in der wir zügig verschiedene Lösungsansätze skizzieren und prototypisch antesten.

Idee 1: CSS bietet über das Transforms Module unter anderem die Möglichkeit, Inhalte zu drehen – also genau das, was wir brauchen? Jein. Ein schneller Check ergab: grundsätzlich ist das ein möglicher Ansatz, aber eher dazu gedacht, einzelne Elemente zu drehen, und nicht die ganze Seite. Im Detail würde es knifflig, die Inhalte korrekt im Viewport zu positionieren und das korrekte Layout zu erreichen.

Idee 2: CSS bietet Writing Modes an, um Textausrichtung von links-nach-rechts (z. B. für Deutsch, Englisch und andere indogermanische Sprachen), von rechts-nach-links (z. B. Hebräisch oder Arabisch) oder vertikal (z. B. für asiatische Schriften) zu erlauben. Wäre das eine Option? Hm. CSS bietet außerdem Logical Properties an, um Layoutangaben für die Ausgabe in unterschiedlichen Textausrichtungen mit logischen anstelle von physischen Konzepten umzusetzen. In anderen Worten: statt naiv anzunehmen, dass eine CSS  width immer eine physische Breite meinen wird, kann eine logische  inline-size definiert werden, die (vereinfacht) von modernen Browsern als „Achse der Textausrichtung“ interpretiert wird. Für die senkrecht dazu verlaufende Achse existiert analog  block-size, und das Konzept der Inline- und Block-Achsen gibt es auch für Außen- und Innenabstände, Rahmen sowie ganze Layout-Module wie Flexbox.

Auch wenn Idee 2 auf den ersten Blick komplizierter wirkt, fiel der erste prototypische Test positiv aus: Die bereits erwähnten automatischen Tools waren nicht nur in der Lage, logische Konzepte wie  inline-size für Chrome 56 rückwärtskompatibel zu  width zu übersetzen, sondern erlaubten eine Konfiguration der Textausrichtung. Wir konnten also die Ausgabe der speziellen CSS-Datei so erweitern, dass logische Angaben von „links-nach-rechts“ auf der Website zu „oben-nach-unten“ für die gedrehten Infoscreens transformiert wurden.

// Auszug aus der Konfiguration
postCssPresetEnv: {
    "logical": {
        "inlineDirection": "top-to-bottom",
        "blockDirection": "right-to-left"
    },
    browsers: [
        "Chrome 56"
    ],
}

Grundlage dafür war natürlich die Nutzung von logischen statt physischen Angaben im CSS-Quellcode der Website, aber wir hatten zum Glück schon vor langer Zeit begonnen, auf diese neue Praxis umzustellen.

Finale

Mit dem Plan in der Hand ging es an die Umsetzung. Wie in den meisten Softwareprojekten üblich, stießen wir gemeinsam mit unserem Kunden unterwegs noch auf weitere Anforderungen, die sich aber alle unter Einsatz von Standardtechniken erfüllen ließen:

• QR-Codes als einfacher Weg vom Infoscreen auf die entsprechende Seite der Website auf dem Mobiltelefon
• Einrichtung einer Pufferzone rund um die Inhalte, um visuelle Blenden vor den Fernsehern zu berücksichtigen
• Ausgabe von (ggf. gedrehten) Bildern und Videos auf den plakatartigen Produktionsseiten
• redaktionelle Tools, um eine für den begrenzten (nicht scrollbaren) Viewport auf dem Infoscreen optimierte Version von langen Informationen oder Besetzungslisten bereitzustellen
• unterschiedliche Layouts für die Darstellung auf den Außenvitrinen bzw. in der Kassenhalle

Epilog

Auch wenn es vielleicht skurril anmutet, im Jahr 2025 eine bestehende, moderne Website um 90° gedreht auf einem neun Jahre alten Browser auszugeben – wir haben dieses Projekt als eine spannende Herausforderung genommen und (meistens) mit großem Spaß an der Lösung gearbeitet. Es war auch toll, wieder einmal zu sehen, wie weit CSS gekommen ist, und welche Möglichkeiten es eröffnet.

Wir freuen uns jetzt schon auf das nächste konzeptionelle Puzzle!

Hier sind unsere Mitwirkenden:

• Der um 90° gedrehte Spielplan für die hochkant montierten Infoscreens im Foyer
• Das um 90° gedrehte digitale Plakat für die Wagner-Oper Lohengrin, ebenfalls für die Infoscreens im Foyer
• Das digitale Plakat von Lohengrin im Querformat für die Außenvitrinen

1. Natürlich gilt das nur für Funktionen, die generell rückwärtskompatibel gemacht werden können, und ist kein Allheilmittel. ↩