Unsere neue Website ist seit kurzem online! Im letzten Jahr hat unser Relaunch-Team viel Zeit und Liebe investiert. Und natürlich möchten wir euch jetzt einige Neuerungen vorstellen und Entscheidungen erläutern. Ein paar Stolpersteine während der Umsetzung gab es auch. Heute schauen wir uns das Frontend etwas näher an.
Der Prototyp
Begonnen haben wir mit einigen Screendesign-Varianten in Sketch. Nachdem die gewünschte Richtung entschieden war, konnte mit der Entwicklung eines Prototyps begonnen werden.
Dieser Prototyp basiert auf einer Symfony-Applikation mit Twig-Templating. Das Template der neuen Website konnten wir so ohne großen Overhead entwickeln – kein Docker, kein CMS-Renderingprozess. Durch Twig war es möglich, wiederholende Bestandteile wie den Website-Header und die Navigationen in Partials auszulagern. Wir bekamen also das Beste aus beiden Welten: die Schnelligkeit von statischem HTML und die Flexibilität einer Template-Engine.
Der Frontend-Build-Prozess mit Yarn und Webpack ist (beinahe) identisch zum späteren TYPO3-Projekt konfiguriert. Das Bootstrap Package haben wir per Composer (ohne weitere Funktion) mitinstalliert, um dessen SCSS-Partials einbinden zu können.
Alle Stylesheet-Partials organisieren wir mit der ITCSS-Architektur, was die Styles dauerhaft wartbar und skalierbar halten soll. Für die eingebundenen Partials von Bootstrap (und Bootstrap Package) haben wir – nach meiner Einschätzung – geeignete Positionen in den ITCSS-Layern gefunden.
Zur Abnahme von Feature-Branches stand uns auch schon im Prototyp ein Kubernetes-Cluster zur Verfügung.
Als der Prototyp eine bestimmte Reife erreicht hatte, haben wir das Styling in das neu aufgesetzte TYPO3 überführt, um das Website-Template und Inhaltselemente zu konfigurieren – und schließlich mit der Inhaltspflege zu beginnen.
Farbschemas a.k.a. Light/Dark Mode
Was macht man, wenn man sich nicht entscheiden kann? Beides! Unsere Website lässt sich mit hellem oder dunklem Hintergrund verwenden. Die Inhalte und anderen Elemente der Website passen sich der Auswahl entsprechend an (mit Ausnahme des stets hellen Headers).
Als Farbschema wird erst einmal das gewählte Erscheinungsbild des Betriebsystems bzw. Browsers berücksichtigt. Der Nutzer kann über den Button im Header eine manuelle Auswahl für die Seite treffen, die im LocalStorage des Browsers gespeichert wird.
Die Zuweisung der Farben erfolgt dann über CSS Custom Properties, umgangssprachlich CSS-Variablen genannt. Für jedes Farbschema gibt es ein Set an Variablen, die den Website-Elementen zugewiesen werden. Nicht für alle Farbwerte sind Custom Properties notwendig: bei semitransparenten Hintergründen – etwa bei Cards – scheint einfach der aktuelle Website-Hintergrund durch.
Was wir nicht verschweigen möchten: Die Verwendung solcher Farbschemas bedeutet einigen Mehraufwand. Nicht nur in der technischen Umsetzung, sondern auch in der redaktionellen Pflege: Logos, Icons und andere Bilder ohne einen Hintergrund müssen auf Hell und Dunkel lesbar bleiben. Deshalb setzen wir stark auf Grafiken im SVG-Format, deren Quellcode wir per Fluid ViewHelper direkt ins HTML rendern. Im SVG-Code arbeiten wir dann mit dem Schlüsselwort „currentColor“, um Füllfarben an das aktuelle Farbschema anpassen zu können. Bei den Kundenlogos gibt es die Pflegemöglichkeit für ein Alternativbild, das dann nur im Dark Mode gezeigt wird.
Accessibility und Usability
Auch wenn das Thema hier im Beitrag erst gegen Ende behandelt wird: berücksichtigt wurden Barrierefreiheit und Nutzerfreundlichkeit von Beginn an. Unter anderem besitzen alle Elemente unserer Website sauber definierte Focus-Styles zur Tastatursteuerung. Die Reihenfolge der Fokussierung ist logisch, aktuell nicht sichtbare Elemente werden nicht angesteuert.
Die Hauptnavigation ab Tablet aufwärts unterstützt die Steuerung per Touch, Maus und Tastatur. Nutzt man die Tastatur, öffnet die Eingabetaste den aktuellen Link und die Leertaste blendet das Untermenü ein (was auch per Screenreader kommuniziert wird). Das umgeht ein gängiges Problem in Navigationen, bei denen per Tab jede Unterseite angesteuert werden muss.
All the small things
Der Internet Explorer spielt für uns keine Rolle mehr. Im Juni 2022 wird er auch von Microsoft endlich in den verdienten Ruhestand geschickt. Das ersparte uns einige Workarounds und Polyfills.
Bei unseren selbstgeschriebenen JavaScripts sowie allen Plugins verzichten wir auf die jQuery-Bibliothek und verschlanken damit die Frontend-Ressourcen.
Auf Mobilgeräten transformieren wir (beim Scrollen) unser Logo zu einem Kreis, um Platz für den Kontakt-Link zu schaffen. Die Animation machte im Safari anfangs einige Probleme: nach einer gewissen Zeit setzte sich die SVG-Transformation unabhängig vom Scroll-Status zurück. Ursache war letztlich die Kombination aus SVG-Transformation und dem scroll-EventListener. Mit der Umstellung auf den IntersectionObserver war das Problem gelöst.
Das soll erst einmal genügen. Im nächsten Beitrag wird euch Christian in unseren Maschinenraum mitnehmen.
Bildquellen
- Leistungen im Light Mode: Sebastian Klein, MFC
- Leistungen im Dark Mode: Sebastian Klein, MFC
- Geöffnete Hauptnavigation: Sebastian Klein, MFC
- Mobilversion der Website: Sebastian Klein, MFC
- Beitragsbild „Farbschemas“: Sebastian Klein, MFC
Über Sebastian Klein
Steht irgendwo zwischen Front- und Backend. Mit einem Faible für Usability und Dokumentation. Immer auf der Suche nach Good Practices.
- Profile:
Ein Gedanke zu „Hello Dark Mode, my old friend: Unser neues Frontend“
Kommentare sind geschlossen.