Behörden sind seitdem dazu verpflichtet, insbesondere ihre Web-Präsenzen und Apps so zu gestalten, dass diese möglichst keine Barrieren enthalten, etwa in Bezug auf die Schrift- oder Farbgestaltung. Im Jahr 2019 kam dann die EU-Richtlinie 2019/882 über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen, der sog. European Accessibility Act (EAA). In Deutschland ist der EAA durch das Barrierefreiheitsstärkungsgesetz (BFSG) vom 16. Juli 2021 umgesetzt worden, das vollumfänglich ab dem Stichtag 28. Juni 2025 gelten wird.

Zweck des BFSG ist es, im Interesse der Verbraucher und Nutzer die Barrierefreiheit von Produkten und Dienstleistungen zu gewährleisten. Dadurch wird für Menschen mit Behinderungen ihr Recht auf Teilhabe am Leben in der Gesellschaft gestärkt und der Harmonisierung des Binnenmarktes Rechnung getragen (§ 1 BFSG). Nach der Definition aus § 2 Nr. 1 BFSG gelten als Menschen mit Behinderung all diejenigen, die langfristige körperliche, seelische, geistige oder Sinnesbeeinträchtigungen haben, die sie in Wechselwirkung mit einstellungs- und umweltbedingten Barrieren an der gleichberechtigten Teilhabe an der Gesellschaft hindern können. Als langfristig wird hierbei ein Zeitraum angesehen, der mit hoher Wahrscheinlichkeit länger als sechs Monate andauert.

Anwendungsbereich

Bei vom BFSG erfassten Dienstleistungen handelt es sich um die folgenden:

• Telefondienste
• E-Books
• Messenger-Dienste
• Bankdienstleistungen
• Elektronischer Geschäftsverkehr (E-Commerce)
• Personenbeförderungsdienste
• Auf Mobilgeräten angebotene Dienstleistungen im überregionalen Personenverkehr

Folgende Produkte müssen zukünftig die BFSG-Vorgaben erfüllen:

• Computer
• Notebooks
• Tablets
• Smartphones
• Geldautomaten
• Fahrausweis- und Check-in-Automaten
• E-Book-Lesegeräte
• Router

Die gesetzlichen Anforderungen gelten allerdings nur für Produkte und Dienstleistungen, die nach dem 28. Juni 2025 in Verkehr gebracht werden.

Folgende Personenkreise sind dafür verantwortlich, die BFSG-Regelungen dann umzusetzen:

• „Dienstleistungserbringer“ (§ 2 Nr. 4 BFSG): Jede natürliche oder juristische Person oder rechtsfähige Personengesellschaft, die auf dem Unionsmarkt eine Dienstleistung für Verbraucher erbringt oder anbietet, eine solche Dienstleistung zu erbringen (also Dienstleister).
• „Hersteller“ (§ 2 Nr. 11 BFSG): Jede natürliche oder juristische Person oder rechtsfähige Personengesellschaft, die ein Produkt herstellt oder entwickeln bzw. herstellen lässt und dieses Produkt unter ihrem eigenen Namen oder ihrer eigenen Marke vermarktet (also Produzenten).
• „Einführer“ (§ 2 Nr. 13 BFSG): Jede in der Europäischen Union ansässige natürliche oder juristische Person oder rechtsfähige Personengesellschaft, die ein Produkt aus einem Drittstaat auf dem Unionsmarkt in den Verkehr bringt (also Importeure).
• „Händler“ (§ 2 Nr. 14 BFSG): Jede natürliche oder juristische Person oder rechtsfähige Personengesellschaft in der Lieferkette, die ein Produkt auf dem Markt bereitstellt, mit Ausnahme des Herstellers oder des Einführers (d.h. Zwischen- / Großhändler).

Als Dienstleister in diesem Sinne zählen u.a. auch alle Website- bzw. Webshop-Verantwortliche und App-Betreiber, jedenfalls wenn das betreffende Angebot gegenüber Endverbrauchern erbracht wird (B2C). Rein private Angebote sind ebenso ausgenommen wie reine B2B-Angebote. Außerdem sieht das BFSG eine Ausnahme für Kleinstunternehmen im Dienstleistungsbereich vor (§ 3 Abs. 3 BFSG). Ein Unternehmen, das weniger als 10 Personen beschäftigt und entweder einen Jahresumsatz von höchstens 2 Mio. Euro erzielt oder dessen Jahresbilanzsumme sich auf höchstens 2 Mio. Euro beläuft, gilt als Kleinstunternehmen (§ 2 Nr. 17 BFSG).

Ausnahmen

Es gibt aber auch Dinge, die vom BFSG nicht erfasst werden. Dessen Vorgaben gelten demnach nicht für den folgenden Inhalt von Webseiten und mobilen Anwendungen:

• Aufgezeichnete zeitbasierte Medien, die vor dem Stichtag veröffentlicht wurden
• Dateiformate von Büroanwendungen, die vor dem Stichtag veröffentlicht wurden
• Online-Karten und Kartendienste, sofern bei Karten für Navigationszwecke wesentliche Informationen barrierefrei zugänglich in digitaler Form bereitgestellt werden
• Inhalte von Dritten, die von dem betreffenden Wirtschaftsakteur weder finanziert noch entwickelt werden noch dessen Kontrolle unterliegen
• Inhalte von Webseiten und mobilen Anwendungen, die als Archive gelten, da ihre Inhalte nach dem 28.06.2025 weder aktualisiert noch überarbeitet werden.

Dienste, die Verbrauchern den Zugang zu audiovisuellen Mediendienste (z.B. Netflix, Amazon Prime, Disney+ & Co.) ermöglichen, werden vom BFSG ebenfalls nicht erfasst. Hierfür werden eigene Regelungen zur Barrierefreiheit erlassen. Außerdem müssen die BFSG-Vorgaben nicht umgesetzt werden, wenn deren Einhaltung zu einer unverhältnismäßigen Belastung führen würde. Eine „unverhältnismäßige Belastung“ in diesem Sinne liegt vor, wenn die Einhaltung der Barrierefreiheitsanforderungen eine zusätzliche übermäßige organisatorische oder finanzielle Belastung darstellt und es nach vernünftigem Ermessen nicht möglich wäre, eine oder mehrere der Anforderungen des BFSG vollumfänglich anzuwenden. Hier geht es um das Verhältnis von Nettokosten, die mit der Einhaltung der Barrierefreiheitsanforderungen verbunden sind, zu den Gesamtkosten (Betriebs- und Investitionsausgaben) bzw. den Nettokosten, die mit der Einhaltung der Barrierefreiheitsanforderungen verbunden sind, zum Nettoumsatz. Diese Beurteilung ist schriftlich zu dokumentieren, fünf Jahre lang aufzubewahren und auch alle fünf Jahre zu wiederholen. Zudem muss die zuständige Marktüberwachungsbehörde unverzüglich informiert und ihr die Dokumentation bereitgestellt werden.

Allgemeine Pflichten

Produkte, die auf dem Markt bereitgestellt werden, und Dienstleistungen, die angeboten oder erbracht werden, müssen ab dem Stichtag barrierefrei sein. Das umfasst neben dem Produkt bzw. der Dienstleistung selbst u.a. auch Gebrauchsanweisungen, Sicherheitsinformationen oder Kontaktangaben zum Hersteller. Produkte und Dienstleistungen sind dann barrierefrei, wenn sie für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind (§ 3 Abs. 1 S. 2 BFSG). Die konkreten Anforderungen an die Barrierefreiheit richten sich nach der Verordnung über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen nach dem Barrierefreiheitsstärkungsgesetz (BFSGV). Diese bestimmt in ihrem § 3 Abs. 1, dass regelmäßig der Stand der Technik zu beachten ist (siehe Kasten „Praxistipp“).

Um die Vorgaben der BFSGV mit Leben zu füllen, veröffentlicht die Bundesfachstelle für Barrierefreiheit auf ihrer Website regelmäßig u.a. eine Auflistung der wichtigsten zu beachtenden Standards, aus denen die Barrierefreiheitsanforderungen detailliert hervorgehen, sowie aktuelle Informationen zu den zu beachtenden Standards.

Folgende allgemeine Anforderungen werden gemäß BFSG an Websites gestellt:

• Websites müssen auf konsistente und angemessene Weise wahrnehmbar, bedienbar, verständlich sowie robust gestaltet werden.
• Im Fall der Verfügbarkeit von Unterstützungsdiensten (z.B. Help Desk, Call Center, technische Unterstützung, Relaisdienste oder Schulungsdienste) müssen diese die Informationen über die Barrierefreiheit und die Kompatibilität der Dienstleistung mit assistiven Technologien mit barrierefreien Kommunikationsmitteln bereitstellen.
• Produkte im Sinne des BFSG, die zur Erbringung einer Dienstleistung verwendet werden, müssen die entsprechenden Anforderungen erfüllen.
• Es müssen bestimmte Pflichtinformationen bereitgestellt werden.

Zu den Pflichtinformationen zählt insbesondere auch die Barrierefreiheitserklärung (Anlage 3 zu § 14 BFSGV). Diese muss folgende Angaben enthalten:

• Beschreibung der geltenden Anforderungen an die Barrierefreiheit
• Allgemeine Beschreibung der Dienstleistung in einem barrierefreien Format
• Beschreibungen und Erläuterungen, die zum Verständnis der Durchführung der Dienstleistung erforderlich sind
• Beschreibung, wie die Dienstleistung die einschlägigen Barrierefreiheitsanforderungen erfüllt
• Angabe der zuständigen Marktüberwachungsbehörde

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Alle Pflichtinformationen…

• werden über mehr als einen sensorischen Kanal bereitgestellt;
• sind für den Verbraucher auffindbar;
• werden in verständlicher und wahrnehmbarer Weise dargestellt;
• werden in Textformaten zur Verfügung gestellt, die sich zum Generieren alternativer assistiver Formate durch den Verbraucher eignen, die auf unterschiedliche Art dargestellt und über mehr als einen sensorischen Kanal wahrgenommen werden können;
• werden in einer Schriftart mit angemessener Größe und mit geeigneter Form unter Berücksichtigung des vorhersehbaren Nutzungskontexts und mit ausreichendem Kontrast sowie ausreichenden Abständen zwischen den Buchstaben, Zeilen und Absätzen dargestellt;
• werden in einer alternativen Darstellung des Inhalts angeboten, wenn Elemente nicht textlichen Inhalts enthalten sind.

Pflichten im E-Commerce

In Bezug auf Dienstleistungen im elektronischen Geschäftsverkehr müssen gemäß § 19 BFSG:

• Informationen zur Barrierefreiheit der zum Verkauf stehenden Produkte und der angebotenen Dienstleistungen bereitgestellt werden, soweit diese Informationen vom verantwortlichen Wirtschaftsakteur zur Verfügung gestellt werden,
• Identifizierungs-, Authentifizierungs-, Sicherheits- und Zahlungsfunktionen, wenn diese nicht in Form eines Produkts, sondern im Rahmen einer Dienstleistung bereitgestellt werden, wahrnehmbar, bedienbar, verständlich und robust gestaltet werden, und
• Identifizierungsmethoden, Authentifizierungsmethoden, elektronische Signaturen und Zahlungsdienste, wenn diese bereitgestellt werden, wahrnehmbar, bedienbar, verständlich und robust gestaltet werden.

Checkliste Website

Folgende konkrete Maßnahmen sollten generell für eine BFSG-konforme Website realisiert werden:

• Verbesserung von Benutzererfahrung und Benutzeroberfläche
• Gestaltung von Websites leicht navigierbar und verständlich
• Schaffung von klaren, verständlichen Layouts
• Integration von interaktiven Elementen zur Unterstützung von Menschen mit Behinderung (z.B. „Text vorlesen lassen“)
• Verwendung von Farbkontrasten oder auch Implementierung von Sprache-zu-Text-Funktionen
• Interaktive Elemente, wie Links, Formulare und Buttons, so gestalten, dass sie von Screenreadern leicht erkannt werden können (klar beschriftet und in einem kontrastreichen Format)
• Tastaturnavigation muss ohne Einschränkungen möglich sein
• Bereitstellung von „Alt“-Texten für Bilder
• Verwendung von leicht verständlicher Sprache
• Bereitstellung der Pflichtinformationen („Erklärung zur Barrierefreiheit“)
• Bei PDF-Dateien lesbare Schriftarten und angemessenen Kontrast verwenden sowie eine Strukturierung der Informationen in einer Weise, die von Screenreadern leicht verarbeitet werden kann

Für Behörden existiert die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (kurz: Barrierefreie-Informationstechnik-Verordnung, BITV 2.0). Darin gibt es die gesetzliche Vermutung, dass die Anforderungen an die Barrierefreiheit als erfüllt anzusehen sind, wenn die harmonisierten Normen oder Teile dieser Normen umgesetzt wurden. Eine vergleichbare Vorschrift gibt es mit § 4 BFSG auch, so dass hier eine entsprechende Vermutung zugunsten des betreffenden Website- bzw. App-Betreibers angenommen werden kann. Es ist daher vorteilhaft, sich an bestehende Normen zu halten, insbesondere an den europäischen Standard EN 301 549 sowie an die Web Content Accessibility Guidelines (WCAG). Auch wenn sich die BITV 2.0 und damit auch EN 301 549 und WCAG in erster Linie an öffentliche Stellen richten, kann Unternehmen nur empfohlen werden, sich in puncto Barrierefreiheit ebenfalls daran zu halten.

Sanktionen

Die Nichteinhaltung der BFSG-Vorschriften stellt eine Ordnungswidrigkeit dar. Hierbei wird es nach dem 28. Juni 2025 also beispielsweise um das Inverkehrbringen eines nicht barrierefreien Produkts, um das Anbieten einer nicht barrierefrei gestalteten Dienstleistung oder um die Nichtbereitstellung der Pflichtinformationen gehen. Je nach konkretem Verstoß droht hier eine Geldbuße von bis zu 100.00 Euro.

The post Barrierefreiheit im Digitalen: So erfüllen Sie die neuen BFSG-Anforderungen ab 2025 appeared first on webinale 2025.

Elisa Czerski ist Unternehmerin, Philosophin und Wirtschaftswissenschaftlerin. Basierend auf ihren akademischen Forschungen, in denen sie die Verbindung von KI, Robotik, Neurowissenschaften und Ethik untersucht hat, gründete sie im Jahr 2021 N Robotics.

In diesem Vortrag erkundet sie das transformative Potenzial der Verknüpfung von KI und Robotik. Es werden die bedeutendsten Fortschritte, Anwendungen und Herausforderungen besprochen, wobei der Fokus auf ethischen Implikationen und verantwortungsbewusster Entwicklung liegt. Ziel des Vortrags ist es, einen prägnanten Überblick über den aktuellen Stand der verkörperten KI und deren Auswirkungen auf die Gesellschaft zu vermitteln.

The post Keynote-Video: How Advancements in Robotics and AI Will Affect All of Us appeared first on webinale 2025.

Teil 1 – Theorie
Bedeutet digitale Barrierefreiheit den Kontrollverlust über Corporate-Design?

Teil 2 – Praxis
Ein Design für eine barrierefreie Webseite erstellen – wie gehe ich vor?

Teil 2 – Praxis

Jedes Design bzw. jede Webseitenkonzeption sollte mit Research über die Nutzenden beginnen. Für barrierefreie Webseiten ist es natürlich notwendig, sich nicht nur mit dem klassischen “Menschzentrierten Gestaltungsprozess” [1] zu beschäftigen und dessen Methoden anzuwenden, sondern sich auch darin zu vertiefen, dass Menschzentriert nicht heißt, dass im Zentrum der “normale” Mensch steht, sondern alle Menschen mit ihren körperlichen, kognitiven und psychischen Eigenarten.

Das wirkt sich idealerweise bereits stark auf die Wireframes aus, die berücksichtigen sollten, dass interaktive Elemente auf allen Geräteklassen sowohl mit der Maus, als auch mit der Hand und mit der Tastatur bedienbar sein müssen.

Nachdem die Wireframes feststehen, kann eine erste Farbversion entstehen. Eine Methode ist dabei sicherlich, zunächst die Startseite zu gestalten. Sinnvoller jedoch ist es, zunächst zu schauen, welche Inhaltsblöcke es auf der gesamten Webseite geben soll und diese auf einer Meta-Seite zusammenzuziehen. Auch wenn ich bei der Konzeption oft den Ansatz “Mobile first” vertrete, empfehle ich in diesem Fall, eher mit einer Desktop-Größe zu beginnen. Am besten mit einer, auf der nicht die ganze Breite genutzt wird, sondern rechts und links noch die Hintergrundfarbe des Bodyelements sichtbar sein wird. Desktop HD mit 1440px Breite zum Beispiel.

Meine Meta-Seite umfasst:

1. Darstellung und Position von Skip-Links für Screenreader-Nutzende und ggf. Einstellungen zur Barrierefreiheit, die nicht automatisch abgedeckt werden können.*
2. <head> der Seite mit
   1. Logo
   2. Suche
   3. Navigation
   4. Metanavigation
3. <main> der Seite mit
   1. h1 Überschrift (für alle Templates!)
   2. Fließtext in Paragraphen 16px (= 1rem im CSS)
   3. Links
      1. innerhalb der Seite
      2. zu externen Seiten
      3. auf Dokumente, die geöffnet werden (Dateiformat mit angeben!)
      4. auf Dokumente, die herunter geladen werden (Dateiformat mit angeben!)
   4. Headlines Level 2–6
   5. Weitere Inhaltsblöcke:
      1. Zitate
      2. Informationsboxen
      3. Sortierte Liste
      4. Unsortierte Liste
   6. Formularelemente:
      1. Eingabefelder
      2. Dropdown-Felder bzw. Comboboxen
      3. Checkboxen und Radiobuttons
   7. Nicht vergessen! die Spezialfarben für:
      1. Selektierten Text
      2. Scrollbar-Design
      3. Hover-Darstellung von Links
      4. Visited-Darstellung von Links
      5. Hover-Darstellung von visited Links
      6. Fokus-Farbe und Stil für alle Elemente (one fits all?)

* Position und Darstellung hiervon bestimmen, ob sie ebenfalls im <head> platziert werden können oder eine eigene <section> erhalten.

Je nachdem, wie die Brand bisher aussieht, fange ich mit den bereits feststehenden Farben an, eine erste Version zu bauen. Dabei achte ich darauf, die Unterscheidungen zwischen einzelnen Abschnitten und Elementen nicht über die Invertierung der Schriftfarbe zu lösen, sondern achte darauf, möglichst eine andere Hintergrundfarbe oder andere Gestaltungselemente zu verwenden die einen ausreichend hohen Kontrast zu der Fließtextschrift hat.

Erst wenn diese Version fertig ist, dupliziere ich sie und bearbeite die Version für den jeweils anderen Modus. Dabei achte ich immer darauf, alle Farben, die miteinander kombiniert werden können, auch gegeneinander zu prüfen, ob der Kontrast ausreichend ist.

Wenn die Farbgestaltung feststeht kommen noch exemplarische Ausarbeitungen in verschiedenen Schriftgrößen sowie für eine grobe oder feine Eingabemethode dazu.

Wichtig ist natürlich nach wie vor die responsive Darstellung, die im Prüfschritt 9.1.4.10 Inhalte brechen um [2] ein Level AA-Kriterium darstellt.

Farbmodi mit CSS Farb-Variablen mit wenigen Codezeilen umsetzen

95% der in Deutschland verwendeten Browser unterstützen inzwischen den Einsatz von CSS-Variablen [3]. Für die wenigen Browser, die dies noch nicht unterstützen, gibt es den Fallback den Farbwert mit in den Aufruf der Farbe zu schreiben. Wenn Sie die 0,09% Unterstützung für den Internet Explorer 11 ebenfalls unterstützen möchten können Sie dies mit einem Polyfill [4] tun.

CSS-Variablen sind deshalb so wichtig, weil wir ihnen an zentraler Stelle sagen können, für welche Farbpräferenz sie gelten sollen.

Zunächst wird das Set von Farben für den Tag-Modus am Anfang der CSS-Datei gesetzt, da CSS (zur Erinnerung, CSS steht für “Cascading Style Sheet”) gesetzte Regeln so lange innerhalb von bestimmten Bereichen vererbt, bis sie anderweitig überschrieben werden. Zur besseren Veranschaulichung des Prinzips habe ich Farbnamen gewählt:

:root {
   --body: white;
   --copy: black;
   --logo: red;
   --link: blue;
}

Damit der Tag-Modus auch der Modus ist, der beim Ausdrucken verwendet wird, setzen wir bei den folgenden Media-Queries immer den Geltungsbereich “only screen” zusätzlich zu der eigentlichen Abfrage mit ein. Dann gelten die Anweisungen nicht für den Druckmodus.

@media only screen and (prefers-color-scheme: dark) {
  :root {
    --body: black;
    --copy: white;
    --link: yellow;
}

Im weiteren Verlauf werden diese Variablen den jeweiligen Eigenschaften zugewiesen. Das Komma hinter dem Variablen-Namen und der Default-Farbwert sind für diejenigen Browser gedacht, die keine Variablen unterstützen:

body {
     background: var(--body, white);
}

#logo {
     color: var(--copy, black);
     fill: var(--logo, red);
}

p {
     color: var(--copy, black);
}

a {
     color: var(--link, blue);
}

Für die ID #logo bin ich davon ausgegangen, dass das Logo aus einem rot gefärbten SVG mit daneben stehendem schwarzen Text besteht. Der Text wird durch die Eigenschaft color eingefärbt, der Logo-Pfad im SVG durch fill.

Der Farbwert “red” wird mit dem Hexadezimalwert #FF0000 aufgelöst. Er erreicht im Kontrast zu weiß ein Verhältnis von 4, was nur die Voraussetzungen für Schrift mit mehr als 24px erfüllt. Da wir davon ausgehen, dass das Logo eher groß angezeigt wird, reicht dies gerade so aus. Auf schwarzem Hintergrund ergibt sich ein Kontrastverhältnis von 5.25, was auch die Kriterien für AAA für große Schrift erfüllt. Da dies als ausreichend betrachtet werden kann wird die Farbe –logo in den Einstellungen für den Nacht-Modus nicht verändert.

Das Ergebnis sieht automatisch so aus dass die linke Version sichtbar ist wenn der Tag-Modus aktiviert wurde und der rechte bei aktivem Nacht-Modus:

The post Ein Design für eine barrierefreie Webseite erstellen – wie gehe ich vor? appeared first on webinale 2025.

Teil 1 – Theorie
Bedeutet digitale Barrierefreiheit den Kontrollverlust über Corporate-Design?

Teil 2 – Praxis
Ein Design für eine barrierefreie Webseite erstellen – wie gehe ich vor?

Und dann das: Menschen mit visuellen Einschränkungen können das bereitgestellte Webangebot nicht nutzen und die angebotenen Produkte und Dienstleistungen nicht kaufen:

• weil das viele Weiß sie blendet und sie die Seite wieder schließen.
• weil sie die Farben nicht richtig sehen und die Links nicht finden.
• weil sie die Schrift in der festgelegten Größe nicht lesen können.
• weil sie die Funktion hinter den schicken Icons nicht deuten können.
• …

In dieser Artikelserie geht es darum aufzuzeigen, dass es möglich ist, ein Corporate Design so zu erweitern, dass es (visuell) barrierefrei nutzbar ist.

Teil 1 – Theorie

Elemente von Corporate-Design und -Identity

Zu einer Corporate-Identity gehören:

1. Corporate Culture
2. Corporate Communication
3. Corporate Behavior (inklusive Corporate Social Responsibility)
4. Corporate Design

Das Corporate-Design umfasst den visuellen Firmen-Auftritt und wird in einem Styleguide bzw. Brand Book festgehalten:

• das Logo bzw. Wort-Bild-Marke inkl. Regeln wie es einzusetzen ist
• die Farben und Farbkombinationen die verwendet werden dürfen
• die erlaubten Schriften und Schriftschnitte bis zu einer eigenen Hausschrift
• die Bildsprache von Fotos und Illustrationen
• weitere gestalterische Stilmittel z.B. Icons, Formen, Kombinationen

Die meisten Corporate-Designs sind darauf ausgelegt, auf und in allen Medien ein einheitliches Erscheinungsbild zu transportieren.

Was ist das Problem?

Corporate Designs werden für Menschen entwickelt, deren Augen …

• nahezu 100% Sehkraft haben
• gut sehen können:
  • alle Farben
  • alle Sättigungsabstufungen von grau bis knallig
  • alle Kontraste unabhängig der Farben und ihrer Sättigung
  • alle Schriftgrößen
• generell gut fokussieren können
• sich an helle und dunkle Lichtverhältnisse adaptieren können
• nicht blendempfindlich sind
• unterschiedlich große Schriften lesen können
• räumlich sehen können

Die Realität sieht anders aus!

Die folgende Tabelle stellt eine grobe Übersicht über Seheinschränkungen dar, ohne Vollständigkeit zu bieten. Es geht mir darum, zu verdeutlichen, dass viel mehr Menschen betroffen sind als allgemein angenommen. Auffällig ist die ungleiche Verteilung auf Männer und Frauen bei den Farbsehschwächen und Migräne. Daten für nichtbinäre und agender Menschen liegen nicht vor. Alle Zahlen sind eher mit Vorsicht zu genießen, weil sie in Deutschland nicht offiziell erfasst werden. Das gilt insbesondere auch für Blindheit [2].

Wie bei allen anderen Behinderungen auch, nehmen Seheinschränkungen im Alter zu. Zwar gibt es Menschen, die gar keine Probleme haben, oder deren Probleme sich mit Brillen, Kontaktlinsen und Operationen ausgleichen lassen, aber sie sind nicht in der Mehrzahl.

Farbsehschwächen

Haben Sie eine Farbsehschwäche? Manch einer erfährt es erst beim Führerscheintest. Um das zu testen, gibt es die Ishihara-Farbtafeln. Wer in den unten stehenden Kreisen aus verschiedenen farbigen Punkten keine Zahl oder nicht die Zahl sieht, die Menschen mit voller Farbwahrnehmung sehen, hat möglicherweise die darunter stehende Farbschwäche.

Abbilding 1: Ishihara-Farbtafeln

Die oben abgebildeten Farbtafeln sind aus der Wikipedia [4]. Die linke zeigt eine einstellige Zahl, die beiden anderen eine zweistellige. Weitere Tafeln und auch eine animierte Darstellung des Prinzips für Farbenblinde gibt es in der Wikipedia.

Die häufigsten Farbsehschwächen liegen im Rot-Grün-Bereich. Speziell diese sind auch Chromosomen-spezifisch, weshalb mehr Männer betroffen sind.

Einen kleinen Einblick, wie es ist in einer Welt ohne Farben zurecht zu kommen ist im folgenden Video beschrieben: https://youtu.be/ChQ9bpK2oU4

Kurzsichtigkeit, Weitsichtigkeit und Astigmatismus

Kurzsichtigkeit ist von den genannten Einschränkungen in der digitalen Barrierefreiheit am wenigsten zu beachten, wenn sie mit einer Brille oder Kontaktlinsen ausgeglichen werden.

Für Weitsichtige ist die Möglichkeit, die Schriftgröße auf ihren Geräten größer einstellen zu können, wichtig. 

Menschen mit Astigmatismus (die Lichtbündel brechen nicht nur an einem Punkt im Auge, es kommt zu Überstrahlungen) oder Menschen, die nur noch eine sehr geringe Restsehkraft haben, benötigen noch weit größere Schriften und Kontraste bzw. die Möglichkeit, die ganze Seite zu skalieren. Alles, was sich automatisch oder unerwartet bewegt, stört den ohnehin schwierigen Prozess der Orientierung und unterbricht den Lesevorgang.

Migräne

Nicht direkt ein Problem mit den Augen, aber mit Lichteinfall können z.B. Migräneschübe zusammenhängen. “Weltweit leiden zehn bis 15 Prozent der Erwachsenen an Migräne. Etwa 6 bis 8% aller Männer und 12 bis 14% aller Frauen sind betroffen. Bei Frauen sind die Attacken meist länger und intensiver.

Alleine in Deutschland sind etwa 3,7 Millionen Frauen und rund 2 Millionen Männer betroffen. Am häufigsten ist die Migräne in der Gruppe der 35 – 45- Jährigen. Danach gehen bei beiden Geschlechtern Schwere und Häufigkeit der Attacken zurück.” Heißt es im Manual der Deutschen Migräne- und Kopfschmerzgesellschaft. [5]

Auswirkungen der visuellen Barrierefreiheit auf das Corporate Design

Jede Brand hat das Bestreben, einen größtmöglichen Bekanntheitsgrad zu erlangen. Nur wenigen gelingt dies wie Coca-Cola. Was in Deutschland der Ausspruch “Du lebst wohl hinter dem Mond” ist, ist in Griechenland “Aber Coca-Cola ist in deinem Dorf angekommen?” [6]. Einen größeren Erfolg kann sich eine Marke wohl kaum wünschen.

Der Grund, weshalb ich Coca-Cola im weiteren Verlauf dieses Artikels nicht beschreibe liegt daran, dass deren Webseite absolut unbrauchbar als gutes Beispiel für Barrierefreiheit ist. 

Kontraste – elegant vs. lesbar

Lange Zeit galt es als “Schick” im Design mit eher geringen Farbkontrasten zu arbeiten. So sollte z.B. eine graue Schrift auf weiß wie Silber anmuten. Der Farbcode des Farbnamens “silver” wird mit #C0C0C0 angegeben. Im ContrastChecker [7] wird bei dem Farbton auf weißem Grund ein Kontrastverhältnis von 1.83 ausgerechnet. Um mindestens das Konformitäts-Level AA zu erreichen braucht es ein Kontrastverhältnis von 3 für Schriften über 18pt (1pt entspricht 1,333px und somit sind 18pt umgerechnet 24px [8] – was bei einer normalen Darstellungsgröße von 16px  wiederum 1.5rem entspricht).

Das Verhältnis von 4.5 reicht laut Definition für Schriftgrößen unter 24px aus. Erst ab einem Kontrastverhältnis über 7 wird das Konformitäts-Level AAA erreicht.

Farben im Corporate Design

Die verwendeten Medien haben schon immer einen Einfluss auf die farbliche Gestaltung einer Marke genommen. So war Gelb beispielsweise lange Zeit in Logos verpönt, um das Problem zu umgehen, dass es beim Versenden von analogen Faxen nicht übertragen wird. Da Faxe weitgehend (!) keine Rolle mehr spielen, ist das inzwischen obsolet.

Abgesehen von solchen Überlegungen spielen die Erkenntnisse der Farbpsychologie, aber auch das brancheninterne Benchmarking hinsichtlich Zugehörigkeit und Abgrenzung eine Rolle. Ob auch die Verfügbarkeit der gewünschten Farben für verschiedene Druckverfahren berücksichtigt wird, hängt natürlich stark davon ab, was das Unternehmen vertreibt. 

Gerade Wohlfühlprodukte haben es in der digitalen Barrierefreiheit visuell schwer, da sie oft auf Pastelltöne auf weißem Grund zurückgreifen. Oft hilft es jedoch, den Einsatz der Farbe anzupassen: helle Farben im Hintergrund können durchaus eingesetzt werden. Solange die Schriftfarbe einen ausreichenden Kontrast zum Hintergrund hat, kann auch das barrierefrei sein!

Tag-Modus – Nacht-Modus – Egal-Modus?

Früher habe ich gerne einzelne Elemente der Webseite invertiert. Wenn beispielsweise der Inhalt selbst dunkle Schrift auf hellem Hintergrund enthalten hat, habe ich den Header und Footer sowie Elemente, die ich hervorheben wollte, oft mit heller Schrift auf dunklem Hintergrund angelegt. Im Nacht-Modus habe ich die Bereiche einfach invertiert.

Dabei bin ich jedoch dem Trugschluss erlegen, es gäbe einen “Egal-Modus”, also eine Einstellung mit der Nutzende sagen können, dass sie mit beiden Modi gut zurechtkommen. Das ist leider nicht der Fall.

Meiner kleinen und ganz bestimmt nicht repräsentativen Stichprobe bei LinkedIn und unter Freund:innen nach, gibt es durchaus einen großen Anteil an Menschen, denen es nichts oder wenig ausmacht, wenn eine Seite durchmischt ist. Dies sind dann aber oft die Menschen, die eben nicht auf barrierefreies Design angewiesen sind. Diejenigen, die sich aus medizinischen Gründen für einen Modus entschieden haben, bevorzugen es, wenn möglichst wenig Flächen invertiert sind.  

Wenn wir uns nicht aktiv darum bemühen, sowohl einen Tag- als auch Nacht-Modus bereit zu stellen, dann kann es uns passieren, dass Menschen im Betriebssystem einstellen, dass der Bildschirm invertiert werden soll. Dann werden aber nicht nur die Hintergründe und Texte invertiert, sondern auch unsere Brand-Farben und je nach Einstellung auch alle Bilder.

Abbildung 2: Original-Design und invertierte Darstellung auf dem Mac mit der Systemeinstellung Barrierefreiheit/Ansicht/Farben umkehren.

Das Design soll sich nicht wie in Abbildung 2 gezeigt von türkis/lila in rot/grün verändern, sondern vom invertierten Bereich im Content her sollen die Farben grundsätzlich im genannten Spektrum bleiben, aber so dunkel werden, dass sie mit heller Schrift funktionieren.

Abbildung 3: Tag-Modus-Design und Nacht-Modus-Design wie gewünscht.

Nun kann es natürlich sein, dass Nutzende den Nacht-Modus UND das Invertieren des Screens aktiviert haben. In dem Fall würde auch die dunkle Variante invertiert werden.

Abbildung 4: Nacht-Modus-Design und invertierte Darstellung

Dadurch, dass ich beide Farbvarianten gestaltet und die gewünschten Farben im Code zugewiesen habe, behalte ich (weitgehend) unabhängig von der Einstellung der Nutzenden die Kontrolle über die Farben meiner Webseite.

Manche Webseiten bieten deshalb auf der Seite selbst die Möglichkeit an, die Webseiten zu invertieren oder mit anderen Farbvarianten darzustellen. Dies ist an sich gut gemeint, besser ist es jedoch, wenn sich jeder Mensch die benötigten oder gewünschten Einstellungen im Betriebssystem des Gerätes einstellt und dann das Betriebssystem, alle Webseiten und Apps sich daran anpassen. Additional können solche Tools gerne eingesetzt werden, jedoch nicht als Ersatz für eine barrierefreie Gestaltung und Programmierung.

Darum lautet meine Empfehlung:

1. Stellen Sie einen Tag- und Nacht-Modus bereit!
2. Invertiert so wenig Elemente wie möglich!
   Gerade Webseiten, auf deren Inhalte Sie später keinen Einfluss mehr haben, sollten diesbezüglich robust angelegt werden.

Telekom-Tochter t-online zeigt wie es gelingen kann

Dass Farben wichtig sind, zeigt in Deutschland vor allem die Telekom, die sich bereits im Jahr 2000 die Farbe Magenta eintragen lassen hat. Beim DPMA [9] heißt es, der Markenrechtsschutz (der noch bis zum 31.12.2025 läuft) gelte u. A. für “Zurverfügungstellung von über das Internet abrufbaren Inhalten”. Die Telekom selbst hat eine eigene Seite über die Farbe Magenta verfasst, auf der es heißt “Heute ist Magenta ein eingetragenes Markenzeichen in der Europäischen Union, den USA und weiteren Ländern.” [10].

Die unterschiedlichen Tochterfirmen der Telekom verwenden den eingetragenen Farbcode in unterschiedlicher Weise. Was zum einen zeigt, dass es sich um eigenständige Seiten handelt, aber auch, wie viel Varianz innerhalb einer Marke möglich ist, ohne den grundsätzlichen Wiedererkennungswert einzubüßen.

Abbildung 5: Header der Webseite Telekom.com – nur im Tag-Modus verfügbar

Abbildung 6: Header der Webseite Telekom.de – nur im Tag-Modus verfügbar

t-online.de ist hier unser (nicht perfektes, aber gutes) Beispiel dafür, dass ein Corporate Design im Tag- und Nacht-Modus funktionieren kann, ohne den grundsätzlichen Charakter einzubüßen:

Abbildung 7: Header der Webseite t-online.de im Tag-Modus

Abbildung 8: Header der Webseite t-online.de im Nacht-Modus

Bitte beachten Sie, dass nicht nur das Schwarz im eigenen Logo, sondern auch im Logo von Amazon invertiert wurde!

Der eingetragene Farbcode mit dem Hexadezimalwert #E20074 hat zu weiß ein Kontrastverhältnis von 4.68. Bis auf die höchsten Kriterien AAA für kleine Schriften und die absolute Farbdifferenz besteht sie damit den Check auf Barrierefreiheit. Auf Schwarz hingegen beträgt das Kontrastverhältnis nur 4.49. Dies gilt nur für Schrift mit mehr als 24px als barrierefrei – gemäß der Konformitätsstufe AA.

Entsprechend ist der Tag-Modus vom Kontrast her barrierefreier als der Nacht-Modus. Dies zeigt, dass es teilweise nötig sein kann, zusätzlich zur bestehenden Brand-Farbe eine weitere Farbversion als Brandfarbe zu definieren.

 Für die Telekom könnte das so aussehen:

Tatsächlich fallen die notwendigen Änderungen am Farbwert sehr gering aus um in beiden Versionen das Konformitätslevel AA zu erreichen.  

Damit kein Missverständnis entsteht: die zusätzlichen Farbwerte dienen der Verdeutlichung, wie eine Brand adaptiert werden müsste und sind keinesfalls die von der Telekom neu eingeführten Farbwerte!

 Sie sehen, dass es unter dem Gesichtspunkt der Barrierefreiheit gar nicht so leicht ist, eine bestehende Marke zu transformieren. Nicht nur bei SEO, auch beim Design gilt es, die Barrierefreiheit sorgsam gegen andere Aspekte abzuwägen.

 Zum “Glück” für die Telekom reicht es laut der Richtlinie, dass die Level AA-Kriterien zum Start der Gültigkeit der EAA umgesetzt werden. Nun ist natürlich immer die Frage, ob es dem eigenen Anspruch entspricht, “nur” die gesetzlichen Vorgaben zu erfüllen, oder tatsächlich das Maximum an Barrierefreiheit zu erzeugen, wie es in der BITV unter § 3 Anzuwendende Standards in Passus (4) heißt: es “[…] soll ein höchstmögliches Maß an Barrierefreiheit angestrebt werden.” [14]

 Mein Lösungsvorschlag wäre in dem Fall der Telekom:

1. Den Tag-Modus für die “normale” Einstellung, ohne zusätzliche Einstellung, dass mehr Kontrast benötigt wird, so lassen.
2. Den Farbwert für den Nacht-Modus für das Level AA anpassen.
3. Für den Fall, dass Nutzende in den Einstellungen angegeben haben, dass sie mehr Kontrast bevorzugen bzw. benötigen, die Farbwerte für AAA im Tag- und Nacht-Modus nutzen (@media (prefers-contrast: more).
4. Den Eintrag bei der DPMA um diese Angaben ergänzen. Mit den Informationen wann welcher Farbton gilt.

 Für alle, die gerne die Richtlinie wüssten, auf die ich mich beziehe: BITV 2.0 Nummer 11.7 Benutzerdefinierte Einstellungen [15]. Dort heißt es: “Die Seite soll benutzerdefinierte Browsereinstellungen berücksichtigen.” Nun können Sie argumentieren, dass Tag- und Nachtmodus ja keine speziellen Browsereinstellungen sind.

Genaugenommen verlangt dieser Prüfschritt derzeit, dass sich die Webseiten auch an benutzerdefinierte Farbeinstellungen anpassen. Mit meinen Test-Farben im Firefox sieht die t-online.de bis auf die Logo-Farbe unabhängig von Tag- oder Nacht-Modus wie folgt aus:

Abbildung 9: Darstellung im Firefox mit der Einstellung “Oben ausgewählte Farben anstatt der Farben der Seite verwenden: Immer”

Spätestens an diesem Punkt entzieht sich die Farbgestaltung spätestens unserem Einfluss.

 Es gibt auch noch die Darstellung im Forced-Color-Mode, den laut Windows 4% der Nutzenden insgesamt und laut WebAIM 50% der Nutzenden mit starken Seheinschränkungen eingestellt haben, wie im Blog von Polypane beschrieben [16]:

Abbildung 10: oben der Tag- und unten der Nacht-Modus, wie ihn Chrome auf dem Mac mit dem Rendering “forced-colors: active” anzeigt

The post Bedeutet digitale Barrierefreiheit den Kontrollverlust über Corporate-Design? appeared first on webinale 2025.

In welchen Situationen ist ein Audit sinnvoll?

Ein Performance Marketing Audit ist in verschiedenen Situationen sinnvoll. In den letzten Monaten sank die Konsumlaune [1] und in zahlreichen Unternehmen steht weniger Budget zur Verfügung. Gerade jetzt ist es daher wichtig zu überprüfen, ob das vorhandene Budget optimal genutzt wird. Zudem profitieren Inhouse-Marketing-Teams von regelmäßigen Audits, um sicherzustellen, dass ihre Kampagnen den aktuellen Best Practices der Branche entsprechen.

Darüber hinaus bietet sich ein Audit gerade in wichtigen Unternehmensphasen an. Wenn ein Unternehmen eine internationale Expansion plant, ist ein Audit unerlässlich, um sicherzustellen, dass bestehende Maßnahmen zielgerichtet umgesetzt sind und bestehende Strategien auf die neuen Märkte zugeschnitten werden können. Doch auch in Phasen, in denen die Performance nicht den Erwartungen entspricht und möglicherweise 50 % des Media-Spendings gekürzt werden müssen, kann ein Audit dabei helfen, die Kampagne zu optimieren, um eine optimale Leistung zu erzielen und trotz Budgetreduzierung keine zu starken Umsatzeinbrüche in Kauf nehmen zu müssen. Auch Startups, die sich in der aktuellen Zeit verlängern müssen und die ihr Budget nun über einen längeren Zeitraum strecken müssen, können von einem Audit profitieren, um ihre Kampagnen auf längere Sicht zu planen und effizienter zu werden.

Welchen Zweck erfüllt ein Audit im Performance Marketing?

Der Zweck eines PPC-Audits besteht darin, sicherzustellen, dass das Budget optimal genutzt wird, die Kampagne den aktuellen Best Practices entspricht und die Performance verbessert wird. Ein Audit ist auch wichtig, um sicherzustellen, dass alle Kanäle optimal genutzt werden. Möglicherweise besteht in einzelnen Kanälen die Möglichkeit das Budget bei wachsendem Umsatz zu erhöhen, während in einem anderen Kanal Budget eingespart werden könnte, ohne an Umsatz zu verlieren. Auch wenn Budgets für das nächste Jahr oder Quartal neu geplant werden, sollte die Budgetallokation überprüft werden. Ein Performance-Marketing-Audit sollte daher Budgeteinsatz und Kostenstrukturen prüfen, sowie Verbesserungspotenziale aufzeigen. Das Ergebnis des Audits ist dann in der Regel ein Bericht, der Empfehlungen zur Verbesserung der Kampagnen enthält.

Für wen ist ein Performance Marketing Audit interessant?

Auch wenn einzelne Empfehlungen innerhalb eines Audits sehr spezifisch und detailliert sein können, ist ein PPC-Audit nicht nur für den Account-Manager interessant. Die Empfehlungen betreffen auch die Verantwortlichen für Landingpage und Conversion-Rate-Optimierung, die Verantwortlichen für die Erstellung der Werbeanzeigen und letzten Endes sind die Empfehlungen zur Budgetallokation auch für den CFO des Unternehmens interessant. Es ist wichtig, sicherzustellen, dass die Kampagne auf die Bedürfnisse aller Stakeholder zugeschnitten ist. Ein Audit ist also hilfreich für alle, die daran interessiert sind, gemeinsam das Beste aus ihrem Marketing-Budget herauszuholen. Hier sind normalerweise weit mehr Personen betroffen als der Online Marketing Manager, der die Kampagnen verwaltet.

Welche Elemente sollten geprüft werden?

Um den unterschiedlichen Stakeholdern gerecht zu werden, sollte die Analyse im Kern vier unterschiedliche Themenfelder abdecken: Kostenstrukturen, Landingpages, Conversion- und Kostentreiber sowie die Top 100 Elemente im jeweiligen Werbekonto.

Analyse der Kostenstruktur

Zur Optimierung der Effizienz von Werbemaßnahmen, ist eine Analyse der Kostenstruktur ein wichtiger erster Schritt. Hierbei sollten wichtige Metriken wie ROAS und Cost/Conv. für einzelne Werbemaßnahmen auf verschiedenen Plattformen geprüft werden. Durch eine Überprüfung der Budgetallokation kann ermittelt werden, ob das Budget effektiv auf die verschiedenen Plattformen verteilt ist. Ein Beispiel in Tabelle 1 zeigt, dass eine Erhöhung des Budgets bei Microsoft Ads zu einem höheren Umsatz führen könnte als bei Google Ads.

Tabelle 1: Vergleich unterschiedlicher Metriken für die Plattformen Google Ads, Meta Ads und Microsoft Ads

Es ist jedoch zu beachten, dass bei einer Erhöhung des Budgets die Metriken nicht unbedingt konstant bleiben. Eine Analyse der Budgetallokation ist daher wichtig, um eine effiziente Verteilung des Budgets zu gewährleisten und möglicherweise auf effizienteren Kanälen unter geringerem Budgeteinsatz den gleichen Umsatz zu erzielen.

Eine weitere wichtige Analyse betrifft den Vergleich von Cost-Share und Revenue-Share innerhalb einer Werbeplattform. Diese Auswertung ist in Tabelle 2 dargestellt. Hierbei sollte der Kosten-Anteil einer Kampagne in etwa dem Umsatz-Anteil entsprechen, um sicherzustellen, dass Kampagnen, die viel Umsatz erzielen, auch einen möglichst hohen Anteil des verfügbaren Budgets erhalten. Kampagnen mit hohem Kosten-Anteil und niedrigem Umsatz-Anteil wie etwa Kampagne B sollten in den Kosten reduziert werden. Im Beispiel könnte dafür das Budget auf Kampagne C umverteilt werden. Bei einer solchen Analyse sollte berücksichtigt werden, dass neue Kampagnen, die erst seit wenigen Tagen aktiv sind, eine faire Chance bekommen sollten ausreichend Daten zu sammeln und die Performance durch erste Optimierungen zu steigern, bevor die Kosten zu stark gesenkt werden.

Tabelle 2: Vergleich von Kosten und Umsätzen unterschiedlicher Kampagnen innerhalb einer Plattform

Analyse von Conversion- und Kostentreibern

Nachdem bereits analysiert wurde, welche Kanäle und Kampagnen zum Umsatz beitragen, geht es im nächsten Schritt nun darum zu analysieren, welche einzelnen Elemente im Werbekonto gut funktionieren und welche nicht konvertieren. Für Google Ads können nicht konvertierende Keywords pausiert werden, während bei Meta Ads Anzeigen oft viele Impressionen und Reichweite erzielen, die keine oder nur wenige Sales und Umsätzen generieren. Um zu vermeiden, dass einzelne Elemente zu hohen Kosten führen, können automatische Regeln eingerichtet werden, um Keywords oder Anzeigen zu pausieren, die nicht zur Performance beitragen. Eine Möglichkeit besteht darin, eine Kostengrenze auf Basis des Cost/Conv. festzulegen.

Abb. 1: Anlegen einer automatischen Regel bei Google Ads, um Keywords zu pausieren, die bereits 100 € gekostet haben ohne zu konvertieren

Weiterhin können Landingpages überprüft werden, um sicherzustellen, dass keine 404-Fehler auftreten und Anzeigen ins Leere laufen. Bei Google Ads kann ein 404-Skript eingesetzt werden, um sämtliche Landingpages innerhalb des Werbekontos zu überprüfen. Dieses Skript wird von Google selbst kostenfrei zur Verfügung gestellt und muss lediglich im eigenen Werbekonto implementiert werden. [2]

Eine weitere Möglichkeit ist die Auswertung von Dimensionen und Segmenten. Bei Google Ads kann die Performance nach Standort oder Tageszeit direkt im Interface überprüft werden, während bei Meta Ads die Überprüfung schwieriger geworden ist. Allerdings kann man in Google Analytics oder anderen Webanalyse-Tools prüfen, welche Zielgruppe den größten Anteil am Umsatz hat, um die Werbung auf diese Zielgruppe zu konzentrieren. Es kann sich zeigen, dass Werbung am Wochenende oder außerhalb der Geschäftszeiten kaum zu relevanten Umsätzen führt, weshalb eine Anpassung der Werbeschaltung in Erwägung gezogen werden kann.

Analyse der Landingpages

Nachdem zuvor bereits Landingpages aufgedeckt wurden, die nicht erreichbar sind und demnach nicht zu Sales und Umsätzen beitragen können, liegt im nächsten Schritt der Werbekampagnen-Analyse der Fokus noch einmal auf der Landingpage-Optimierung. Eine effektive Steigerung der Conversion-Rate auf der Landingpage kann bei gleichen Werbeausgaben höhere Umsätze generieren oder bei niedrigeren Werbeausgaben gleichbleibende Umsätze erwirtschaften. Das Beispiel in Tabelle  verdeutlicht, wie die Conversion-Rate von 3,0 % auf 3,5 % durch verschiedene Optimierungsmaßnahmen erhöht werden kann. Bei unverändertem durchschnittlichem Warenkorbwert und Kosten sinkt der Cost/Conv. von 33 € auf 29 €, was zu einem höheren Umsatz von 2.100 € anstelle von 1.800 € führt.

Tabelle 3: Vergleich unterschiedlicher Metriken für die Plattformen Google Ads, Meta Ads und Microsoft Ads

Neben der Steigerung des Umsatzes können Werbetreibende durch Landingpage-Optimierung auch das Werbebudget effizienter nutzen. Bei einer Steigerung der Conversion-Rate von 4,0 % auf 4,5 % wie in Tabelle 3 müssen nur noch 857 € anstelle von 1.000 € eingesetzt werden, um den gleichen Umsatz von 4.000 € zu erzielen. Dies führt zu einem höheren ROAS von 467 %.

Regelmäßige Überprüfung der Landingpages auf ihre Performance und gegebenenfalls Optimierungsmaßnahmen sind daher essenziell. Webanalyse-Tools wie Google Analytics können hierbei hilfreiche Informationen zur Verfügung stellen und dabei unterstützen, die Leistung schwacher Landingpages zu verbessern.

Analyse der Top 100

Im letzten Schritt des Audits nach der Untersuchung von Kontenstrukturen und Kostentreibern, steht die Analyse der Top 100 Elemente an. Diese werden jeweils nach ihren Kosten sortiert. Im Fall von Google Ads sollten die Top 100 Suchanfragen, Keywords und Produkte für Google Shopping-Anzeigen betrachtet werden. Für Werbung im Bereich Social Media Ads sollten die Top 100 Anzeigen überprüft werden.

Um die Top 100 Elemente im Werbekonto zu analysieren, können wie in Abbildung 2 neun verschiedene Bereiche betrachtet werden. Soll Budget eingespart und nur in effektive Elemente investiert werden, sollte man sich auf die All Stars und gegebenenfalls auch auf die Neglected Gold Mines konzentrieren. Wasteful Leaks wurden bereits im zweiten Schritt identifiziert, aber es können auch andere Elemente problematisch sein. Obwohl die roten Elemente (High Interest Opportunities, Low Quality Terms und Benchwarmers) derzeit keine Kosten verursachen, da sie aufgrund weniger Klicks kaum Impressionen generieren, können sie langfristig gefährlich werden und sollten daher kritisch überprüft werden, bevor sie in einem nächsten Schritt möglicherweise pausiert werden.

Abb. 2: Keywords, Suchanfragen oder Anzeigen können in neun unterschiedlichen Gruppen kategorisiert werden

Insbesondere die zweite Spalte der Efficiency Threats ist für die Kosteneinsparung von Interesse, da viele Impressionen auf diese Elemente entfallen, obwohl sie problematisch sein können. In einem idealen Kampagnensetup, fällt nur ein sehr geringer Anteil der Top 100 Elemente in diesen Bereich. Auch die Elemente der Kategorie Undercover Sabotage können gefährlich werden, da sie zwar zu Umsätzen und Conversions beitragen, aber der Cost/Conv. deutlich über dem angestrebten Zielwert liegt. Wenn man an dieser Stelle Budget einspart und einen Teil dieses Budgets in die All Stars oder Neglected Goldmines investiert, kann man möglicherweise bei gleichem oder weniger Budgeteinsatz mehr Umsatz erzielen.

Fazit

Eine Analyse der Kostenstruktur und auch der einzelnen Elemente wie Landingpages oder Keywords lohnt sich als in jedem Fall. Ein Performance-Marketing-Audit ist daher ein unverzichtbares Werkzeug, um sicherzustellen, dass die Kampagnen optimal laufen und das Beste aus dem verfügbaren Werbebudget herausholen. Durch regelmäßige Audits kann zudem sichergestellt werden, dass die Kampagnen den aktuellen Best Practices entspricht und auf die Bedürfnisse aller Stakeholder zugeschnitten sind.

Die Session der Autorin auf der webinale 2023

Links & Literatur

[1] GfK-Konsumklima-Index von Oktober 2020 bis Oktober 2022 (Quelle: Statista https://de.statista.com/statistik/daten/studie/2425/umfrage/gfk-konsumklima-index/)

[2] Google Ads Linkchecker Skript: https://developers.google.com/google-ads/scripts/docs/solutions/link-checker

The post Mit Performance-Marketing-Audits Online-Werbung optimieren appeared first on webinale 2025.

Backlinks und SEO

entwickler.de: Hallo Kaspar! Du sagst in deinem Webinale Abstract: „Suchmaschinen lieben Backlinks.“ Sind die Zeiten der Linkfarmen also noch nicht vorbei?

Kaspar Szymanski: Nein, die Zeiten der Linkfarmen sind ganz sicher nicht vorbei, auch wenn manch eine Suchmaschine deren Ende vielleicht ganz gern herbeisehnen würde. Solange Backlinks ein Ranking-Faktor sind, wird es allen Qualitätsrichtlinien, oder seit neuestem “Grundlagen der Google-Suche”, und allen damit verbundenen Risiken zum Trotz dennoch PageRank-Linkaufbau geben. Daran werden auch kurzfristige SEO-Hypes wie ChatGPT nichts ändern.

entwickler.de: Ohne nun deinen Talk vorweg zu nehmen: Vielleicht kannst du einmal einen Tipp geben, wie man sich „gute“ Backlinks aufbaut?

Kaspar Szymanski: Ein wirklich guter Link ist einer, der relevanten, konvertierenden Traffic steigert. Ob das nun ein PageRank- oder nofollow-Link ist, das ist unerheblich.

entwickler.de: Es gibt ja viele Rankingfaktoren. Wie würdest du das Thema Backlinks heute einschätzen, im Vergleich zu anderen Faktoren wie On-Page-Optimierung (Keywords, etc.), User Signale oder andere.

Kaspar Szymanski: Das kommt immer auch auf die Website und die Branche an. Backlinks können einen enorm positiven Einfluss auf den Erfolg einer Online-Plattform haben.

Tatsache ist aber auch, dass die Mehrheit von Websites keine oder nur wenige Backlinks haben. Online-Erfolg auch bei den führenden Suchmaschinen ist also auch ohne Backlink-Aufbau möglich.

Es gibt tatsächlich zahlreiche, vielversprechende Suchmaschinenoptimierungs-Alternativen. Der Fokus auf die Nutzererfahrung ist enorm wichtig und kann, wenn richtig umgesetzt, dazu beitragen, die Konkurrenz weit hinter sich zu lassen.

Eine andere vielversprechende Alternative stellt Performance dar. Google rankt bei vergleichbaren Webauftritten die schnellere Plattform fast immer höher. Das liegt daran, dass Nutzer schnellere Webauftritte bevorzugen. Es ist also durchaus möglich, mithilfe von technischer SEO die Wettbewerber zu schlagen. Und im Idealfall berücksichtigt die SEO-Strategie alle relevanten Faktoren, inklusive jener im On- wie auch Offpage-Bereich.

SEO in Zeiten von ChatGPT & Co.

entwickler.de: Was hältst du von Entwicklungen aus dem AI-Bereich – ChatGPT ist das Stichwort? Manche sagen, solche KI-basierten Systeme werden der klassischen Google-Suche schon bald den Rang ablaufen, da sie Antworten liefern, ohne dass ein User sich erst lange selbst durch Webseiten wühlen muss. Ist ChatGPT das Ende von Google, wie wir es kennen?

Kaspar Szymanski: In der SEO-Branche gibt es regelmäßig neue Trends, von denen einige hoffen, dass sie alles revolutionieren werden. Es ist noch nicht lange her, da war es Voice Search, nun ist ChatGPT in den Vordergrund gerückt. Eine Revolution der Suchindustrie ist aber in absehbarer Zeit eher unwahrscheinlich.

ChatGPT ist ein interessantes Tool, das, an aktuellen Standards gemessen, auf großen Datenbanken und maschinellen Lernprozessen basiert. Von echter KI sind wir da noch ein wenig entfernt. Tests liefern in englischer Sprache teilweise überzeugende Ergebnisse, manchmal aber auch totalen Unsinn. Es gibt durchaus Anwendungsbereiche, in denen ChatGPT als unterstützendes Werkzeug sinnvoll eingesetzt werden kann. Für die überwiegende Mehrheit von Website-Betreibern hat es aber keine Relevanz und sollte nicht von tatsächlich kritischen SEO-Bereichen wie Performance oder dem Alleinstellungsmerkmal ablenken.

entwickler.de: Was ist das wichtigste Take-away, das du den Besuchern deiner Webinale-Session mitgeben möchtest?

Kaspar Szymanski: Linkaufbau mit Fokus auf konvertierenden Traffic ist risikofrei. Ein weiterer Vorteil ist, dass die Erfolgsmessung unmittelbar möglich ist. Der ehemalige Google-Ingenieur und führender SEO-Experte Fili Wiese hat dazu einige Ideen in einem Beitrag veröffentlicht, die direkt in die SEO-Strategie eingebunden werden können. Sehr empfehlenswert: https://online.marketing/guide/linkbuilding/.

entwickler.de: Vielen Dank für dieses Interview!

The post ChatGPT sollte nicht von tatsächlich kritischen SEO-Bereichen ablenken appeared first on webinale 2025.

Diesen Prozess genau so zu gestalten, damit er funktioniert, ist längst zu einer zentralen strategischen Überlegung im Online-Marketing geworden. Doch inzwischen haben das viele Unternehmen bereits erkannt, was ist also zu tun? Differenzierung ist hier das große Stichwort, aber wie? Hier kommt das Konzept der „Content-Experience“ ins Spiel.

Um sich bestmöglich von der Konkurrenz abzuheben, muss der Content so nah wie möglich an den Bedürfnissen und Erwartungen der Nutzer:innen ausgerichtet sein, dabei aber gleichzeitig einen höheren Mehrwert und eine bessere Struktur bieten und dabei noch den eigenen Unique Selling Point überzeugend kommunizieren. Nur so können Unternehmen ein unvergessliches Erlebnis für die Zielgruppe schaffen. In geschickter Kombination mit Suchmaschinenoptimierung und der entsprechenden Reichweite wird Content-Experience zu einem Hebel für nachhaltig höhere Conversion-Rates.

In diesem Artikel erkläre ich, was genau unter Content-Experience zu verstehen ist, wie sie sich von User-Experience unterscheidet und wo genau der Bezug zu SEO und langfristige Conversion-Optimierung zusammenhängt.

Kurze Definition: Was ist Content-Experience überhaupt?

Content-Experience (Content-UX) beschreibt alle Erfahrungen, die Nutzer:innen auf einer Website mit den Inhalten machen. Es ist eine spezielle Variante der User-Experience (UX). Letztere hingegen bezieht sich auf alle Erfahrungen, die potenzielle Kund:innen mit einem Unternehmen machen, nicht nur auf die digitalen. Dabei werden zum Beispiel auch analoge Touchpoints wie Konferenzen oder andere physische Begegnungen mit einem Unternehmen berücksichtigt, also auch die Erfahrung, die sie mit den Produkten oder Dienstleistungen machen. Damit deckt die UX also die komplette Customer Journey ab.

Im digitalen Kontext wird UX oft mit Design und Programmierung assoziiert. Wie sieht die Website aus? Welche Elemente können die Nutzer:innen zur Interaktion nutzen? Welche visuellen Effekte gibt es auf der Seite? Während Content-Management-Systeme immer modularer werden und einige dieser Aufgaben bereits von KI übernommen werden, bleibt der entscheidende Unterschied in den Inhalten selbst. Hier geht es nicht nur um User-Experience oder Content Design – das Stichwort lautet Content-Experience.

Content-Experience und User-Experience: Eine untrennbare Verbindung

Eines sollte deutlich geworden sein: Content-Experience und User-Experience sind eng miteinander verbunden und können nicht isoliert voneinander betrachtet werden. Die User-Experience umfasst verschiedene Disziplinen wie Design, Programmierung und Produktmanagement, die alle zur Gestaltung einer positiven Nutzererfahrung beitragen. Dabei beeinflussen bestimmte Bereiche der User-Experience auch die Content-Experience, denn die Art und Weise, wie digitale Inhalte präsentiert werden, hat großen Einfluss auf ihre Wirkung.

Im digitalen Raum müssen Inhalte nicht nur informativ und lesbar sein, sondern auch ansprechend und benutzerfreundlich gestaltet werden. Die Konzentrationsspanne der Nutzer:innen ist begrenzt, daher müssen sie schnell und intuitiv auf Inhalte zugreifen können, um Interesse zu wecken und Conversions zu fördern. Hier kommen Designer:innen und Programmierer:innen ins Spiel, die passende Elemente zur Gestaltung digitaler Inhalte auf einer Website bereitstellen.

Besonders im B2B-Bereich spielt die Content-Experience eine wichtige Rolle. Eine ansprechende Gestaltung allein reicht nicht aus, um potenzielle Kund:innen zu überzeugen. Es ist ebenso wichtig, dass die Inhalte auf höchstem sprachlichen und fachlichen Niveau kommuniziert werden, um den anspruchsvollen Informationsbedürfnissen der Zielgruppe gerecht zu werden. In diesem Kontext wird Content-Marketing zur Königsdisziplin.

Content-Experience und Content-Marketing: Das unschlagbare Team für eine erfolgreiche Customer Journey

In der heutigen Zeit suchen User:innen auf Websites nach Antworten auf ihre Fragen und Informationen zu Produkten oder Dienstleistungen. Im B2C-Bereich geht es dabei meist um spezifische Produkte, die eine Kaufabsicht hervorrufen. Im B2B-Bereich hingegen kann das Informationsbedürfnis der Zielgruppe sehr viel komplexer sein. Hierbei legen B2B-Kund:innen besonderen Wert auf Vertrauen und Expertise. Um dies zu erreichen, muss der Content genau auf ihre Bedürfnisse und Pain Points ausgerichtet sein. Nur so kann es dir gelingen, deine Zielgruppe abzuholen, dein Unternehmen zu positionieren, deine Marke erfolgreich zu kommunizieren und Vertrauen aufzubauen.

Um diese Ziele zu erreichen, ist es wichtig, User:innen während ihrer gesamten Customer Journey mit relevanten Inhalten zu begleiten und ihnen einen echten Mehrwert zu bieten. Dafür ist es notwendig, die Zielgruppe und ihre Erwartungen genau zu kennen. Zu Beginn der Customer Journey sollten unwerbliche, aber sehr informative Inhalte im Vordergrund stehen, um das Vertrauen der User:innen zu gewinnen. Sobald sie mit deiner Lösung vertraut sind, können sie schrittweise an dein Produkt oder deine Dienstleistung herangeführt werden. Hierbei können Conversion-Elemente wie Whitepaper oder E-Books, Seminare oder Webinare, Checklisten und Ratgebertexte u. v. m. eingesetzt werden, um hochwertige Leads zu generieren.

Nur durch ein starkes Zusammenspiel von Content-Experience und Content-Marketing kann eine erfolgreiche Customer Journey sichergestellt werden. Auf diese Weise kann die Zielgruppe auf allen relevanten Kanälen erreicht, Vertrauen aufgebaut und die Marke erfolgreich positioniert werden.

Was ist mit SEO? Wie man sie erfolgreich mit Content-Experience verknüpft

In den letzten Jahren haben die Google Core Updates gezeigt, dass die Suchmaschine zunehmend den Fokus auf ihre User:innen richtet. Sie möchte ihnen genau das bieten, wonach sie suchen oder was sie benötigen. Infolgedessen rückt das Thema Content-Experience für Website-Betreiber:innen und Unternehmen immer stärker in den Vordergrund. Eine bestmögliche Content-Experience ist daher unerlässlich, um gute Rankings und eine steigende Sichtbarkeit in Suchmaschinen zu erzielen.

Während Mitarbeiter:innen aus dem Marketing solche Entscheidungen oft intuitiv treffen, arbeiten SEO-Expert:innen eher datenbasiert. Tools zur Messbarkeit von Erfolgen sind für das organische Suchmaschinenranking unverzichtbar. Die Herausforderung besteht allerdings darin, dass die Content-Experience als solche kaum messbar ist. Obwohl die Lesbarkeit bereits ein Rankingfaktor im SEO ist, messen Tools lediglich Faktoren wie die Satzlänge oder die Anzahl der Wörter in einem Text. Dies sagt jedoch kaum etwas über die tatsächliche Lesbarkeit und die Nutzererfahrung mit digitalen Inhalten aus. Wie können wir also eine Lösung dafür finden?

Eine Möglichkeit besteht darin, die Lesbarkeit und Nutzererfahrung manuell zu bewerten und sie mit den Daten der SEO-Tools zu kombinieren. Eine andere Möglichkeit ist die Verwendung von Heatmaps und anderen Tools, um das Verhalten der User:innen auf der Website zu analysieren.  Hierbei können beispielsweise Klicks, Verweildauer und Scrolltiefe aufgezeichnet werden, um die Benutzerfreundlichkeit und Nutzererfahrung zu verbessern.

Eine erfolgreiche Verknüpfung von Content-Experience und SEO erfordert eine enge Zusammenarbeit von Marketing- und SEO-Teams sowie eine kontinuierliche Überwachung und Optimierung. Auf diese Weise können Website-Betreiber:innen und Unternehmen nicht nur ihre Rankings und Sichtbarkeit verbessern, sondern auch eine positive User-Experience für ihre Zielgruppe schaffen.

Content-Experience messen mit Benchmarking und UX-Score

Um die Content-Experience messbar zu machen, bietet sich eine Herangehensweise durch Benchmarking an. Hierbei werden die Top 10 Suchergebnisse und Inhalte für die wichtigsten Keywords analysiert und verglichen. Es gilt herauszufinden, welche Inhalte in den Top 3 ranken und was sie von den anderen Suchergebnissen unterscheidet. Ist der Inhalt passend für die Phase der Customer Journey, auf der sich die User:innen befinden? Ein detaillierter Vergleich der Wettbewerbsunternehmen liefert wichtige Indikatoren, um den eigenen Inhalt noch besser und relevanter für die Zielgruppe aufzubereiten. Dabei können zusätzliche Assets wie eine Checkliste zum Download, ein Whitepaper oder ein Video helfen.

Um die Content-Experience im Rahmen des Möglichen zu objektivieren, haben wir bei suxeedo eine Skala zur Bewertung wichtiger Aspekte der Content-Experience entwickelt:

Quelle: suxeedo GmbH

Auf der Abbildung sehen wir, wie eine Skala dabei hilft, unterschiedliche Websites und die Content- Experience auf ihnen einzuordnen und zu vergleichen.

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

 Eine Skala zur Bewertung der Content-Experience hilft dir dabei, einzelne Kategorien aufzubrechen und Schwachstellen zu identifizieren, bei denen andere Wettbewerber:innen besser performen. Auch wenn Content-Experience prinzipiell subjektiv ist – also eine Erfahrung, die jedes Individuum anders macht – können einige wichtige Kriterien vergleichbar gemacht werden. Folgende Faktoren tragen dazu bei, die Content-Experience in Teilen messbar zu machen:

• Strukturelle Attraktivität: Ist ein Inhalt in snackable Abschnitte unterteilt, die prägnante Zwischenüberschriften aufweisen und sich leicht navigieren lassen?
• Visuelle Attraktivität: Ergibt sich aus Websitegestaltung ein stimmiges und ästhetisches Gesamtbild, das Farben und Gestaltungselemente seiten- und inhaltsübergreifend wiederholt und somit für Wiedererkennbarkeit und Orientierung sorgt?
• Grafiken, Videos und Bilder: Nutzt du eine Variation von Formaten innerhalb deiner Inhalte oder innerhalb eines Beitrags? Grafiken, Videos, Bilder oder Audioelemente können komplexe Inhalte leichter konsumierbar machen und für Abwechslung sorgen.
• Attraktive Listenelemente: Verwendest du Tabellen, Listicles, Aufzählungen oder andere übersichtliche Veranschaulichungen, um Fakten und Informationen darzustellen und somit die Lesbarkeit deines Inhalts zu erhöhen?
• Scrollbarkeit: Wie schnell können sich Nutzer:innen durch deinen Inhalt navigieren und zu der Information finden, nach der sie explizit suchen?
• Sprache: Wie gut verständlich ist deine Sprache und passt sie zur Zielgruppe?

Ausblick: Content-Experience als langfristiger Faktor im B2B und B2C

Ob B2B oder B2C: Content-Experience bleibt ein zentraler Erfolgsfaktor für Unternehmen. Während im B2C-Umfeld Marketing Automation, Retargeting und Conversion-Optimierung im Fokus stehen, sind Produkte im B2B-Bereich oft komplexer und preisintensiver, was den Entscheidungsweg zur Transaktion verlängert. Doch auch hier ist es entscheidend, die Zielgruppe mit passendem Content zur richtigen Zeit zu erreichen, zu begeistern und schließlich zu überzeugen – selbst wenn sich der Erfolg in Form von Downloads und Leads statt direkter Käufe zeigt. Nutze diese Chance, um dich von der Konkurrenz abzuheben und die Customer Experience nachhaltig zu verbessern.

The post Conversion-Optimierung war gestern, jetzt kommt Content-Experience! appeared first on webinale 2025.

Dass die Anforderungen mit einem klassischen Shop von der Stange nur sehr schwer zu bewältigen wären, wurde uns während der Workshops in der Konzeptionsphase für einen Onlineshop schnell bewusst.

Eine fertige Shoplösung bringt zwar bereits viele Funktionalitäten mit sich und der Initialaufwand fällt geringer aus, jedoch konnte keine der Standardlösungen die Anforderungen vollumfänglich abdecken. Anpassungen wären unumgänglich gewesen. Zudem soll eine global konstante Performance erreicht werden – egal ob der Käufer in New York, Zürich oder Tokyo sitzt. Das setzt eine entsprechend skalierende Infrastruktur voraus.

Composable Commerce und Headless

Hier konnte ein Composable-Commerce-System überzeugen: Trotz initial höherem Aufwand lassen sich Anpassungen wesentlich freier und dadurch mit geringerem Aufwand umsetzen. Das System ist bspw. bereits global verteilt. Damit werden Anfragen aus dem Frontend von der Region beantwortet, die dem Anfragenden am nächsten ist. Schnelle Antwortzeiten wirken sich positiv auf den Umsatz aus und erhöhen die Konversationsrate.

Nebst dem Composable-Commerce-System kommt ein Headless CMS für den Inhalt zum Einsatz. Headless bezieht sich auf die Fähigkeit, das Frontend vom Backend zu entkoppeln, in diesem Fall die Commerce- und CMS-Schnittstellen vom Backend-Betriebssystem und PIM zu trennen.

Die Architektur erlaubt es uns, durch verteilte Systeme rasend schnelle Applikationen zu entwickeln, deren Kommunikationsmittelpunkt eine schlanke Mezzio-Applikation ist.

In diesem Artikel werden nur die Schnittstellen zum ERP (SAP) und einem Headless Commerce (CommerceLayer) beschrieben. Der Fokus liegt auf der Kommunikation zwischen den APIs mittels einer Mezzio-Applikation. Welcher Hersteller angebunden wird, ist nicht von Belang. Für ein vollständig funktionierendes Shopsystem sind selbstverständlich weitere Systeme (Headless CMS, Payment Provider etc.) notwendig. Der beschriebene Code ist in einem öffentlichen Repository [1] abrufbar. Genug der Theorie – wie sieht eine solche Implementation nun aus?

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Das Mezzio Skeleton

Laminas bietet mit dem Mezzio Skeleton [2] ein Installationsprogramm an, welches ein neues Mezzio-Projekt auf Grundlage von Benutzerentscheidungen erstellt:

composer create-project mezzio/mezzio-skeleton composable-commerce-mit-mezzio

Wenn die Installation aktuell nicht unter PHP 7.4 ausgeführt wird, lässt ein Bug [3] die Installation fehlschlagen. Um diesen zu umgehen, wird das Projekt geklont, die composer.lock-Datei entfernt und anschließend ein composer install ausgeführt:

git clone [email protected]:mezzio/mezzio-skeleton.git composable-commerce- mit-mezzio
cd composable-commerce- mit-mezzio
rm composer.lock
composer install

Ein Assistent führt durch die Installation der neuen Applikation und gibt die Wahl der Applikationsstruktur, des Service-Containers usw. In der ersten Option wird die modulare Struktur ausgewählt. Die Modulstruktur ermöglich eine saubere Trennung der Applikationsteile bzw. -logik. Das wird im späteren Teil der Implementation ersichtlich. Die weiteren Optionen werden beim Standard belassen. Nach Abschluss der Installation steht eine fertige Mezzio-Applikation bereit.

Im Folgenden werden verschiedene PHP Standards Recommendations (PSRs) erwähnt. Interessierte erfahren auf den Seiten der Framework Interoperability Group [4] alles Wissenswerte.

Die wichtigsten Komponenten der eben erstellten Applikation in der Übersicht:

• mezzio/mezzio: Die PSR-15 Kernkomponente zur Verarbeitung von Web-Requests
• laminas/laminas-service-manager: PSR-11 Dependency Injection Container
• mezzio/mezzio-fastroute: FastRoute [5] Router
• laminas/laminas-diactoros: PSR-7 Implementation für die Darstellung von HTTP-Nachrichten
• laminas/laminas-config-aggregator: Komponente zum Sammeln und Zusammenführen von Konfigurationen aus verschiedenen Quellen

Im nächsten Schritt werden die API-Clients umgesetzt. Hierfür wird ein HTTP-Client benötigt. Es kann eine beliebige PSR-18-Implementation verwendet werden. In diesem Projekt wird die beliebte Bibliothek von Guzzle eingesetzt:

composer require guzzlehttp/guzzle

CommerceLayer API

Mit der modularen Applikationsstruktur kann die Applikation in verschiedene Module organisiert werden. Ein Modul repräsentiert hier einen separaten Ordner innerhalb von src. Diesem wird ein eigener Namespace zugewiesen. Für alles Relevante bzgl. CommerceLayer wird nun ein Modul erstellt. Ebenso werden später Module für weitere Schnittstellen und den ApiConnector erstellt.

Mezzio bringt einen Console Command mit, der diese Arbeit erledigt. Standardmäßig wird ein Modul mit einem src– und template-Ordner erstellt. Da keine Templates eingesetzt werden, kann eine flache Struktur mit der Option -f erstellt werden. Dabei wird auf Unterordner verzichtet und der Namespace direkt im Modulordner registriert:

vendor/bin/laminas mezzio:module:create CommerceLayer -f

Im Modulordner wird eine ConfigProvider-Klasse erstellt. Diese ist dafür zuständig, alle Services innerhalb des Moduls zu verwalten. Wo die Services registriert werden, spielt letzten Endes keine Rolle. Es ist ebenfalls möglich, diese in einer großen, global gültigen Datei zu hinterlegen. Wesentlich übersichtlicher ist es jedoch, diese Dienste modulweise zu verwalten.

API-Client

CommerceLayer bietet eine mächtige Schnittstelle, die JSON-API-kompatibel ist und kontinuierlich weiterentwickelt wird. Für die Kommunikation mit der CommerceLayer-Schnittstelle wird der zuvor installierte Guzzle-HTTP-Client zum Versenden und Empfangen der HTTP-Nachrichten eingesetzt. Der HTTP-Client benötigt einen mandantenspezifischen Basis-URL sowie einen gültigen Access-Token. Die Authentifizierung erfolgt über OAuth 2.0. Da die Erstellung des Tokens über OAuth 2.0 den Rahmen des Artikels sprengt, wird lediglich ein TokenProvider-Stub verwendet, das diesen Prozess symbolisch darstellt.

In der Konfiguration wird ein Options-Array deklariert, das dem Guzzle-Client übergeben wird. Darin werden der Basis-URL und die für die JSON API notwendigen Header definiert (Listing 1).

<?php
 
declare(strict_types=1);
 
return [
  'commerce_layer' => [
    'client' => [
      'options' => [
        'base_uri' => 'https://my-app.commerce-layer.com/',
        'headers'  => [
          'Content-Type' => 'application/vnd.api+json',
          'Accept'       => 'application/vnd.api+json',
        ],
      ],
    ],
  ],
];

Um den Client später als Service abrufen zu können, wäre es möglich, eine Factory für Psr\Http\Client\ClientInterface zu erstellen. Jedoch kann mit einem Interface nur ein Service referenziert werden. Aus diesem Grund wird pro Schnittstelle ein eigenes ApiClientInterface erstellt. Das ApiClientInterface erweitert lediglich das Psr\Http\Client\ClientInterface (Listing 2).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer;
 
use Psr\Http\Client\ClientInterface;
 
interface ApiClientInterface extends ClientInterface
{
}

In einer Mezzio-Applikation wird die gesammelte Konfiguration dem Service Container unter dem Schlüssel config übergeben. Damit kann die Factory die Clientkonfiguration abrufen und dem Client-Constructor übergeben (Listing 3).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer;
 
use GuzzleHttp\Client;
use Psr\Container\ContainerInterface;
 
class ApiClientFactory
{
  public function __invoke(ContainerInterface $container): Client
  {
    return new Client(
      $container->get('config')['commerce_layer']['client']['options']
    );
  }
}

Im ConfigProvider werden die Services registriert. Damit weiß der Service-Container, wie ein angefragter Service instanziiert wird (Listing 4).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer;
 
class ConfigProvider
{
  public function __invoke(): array
  {
    return [
      'dependencies' => $this->getDependencies(),
    ];
  }
 
  public function getDependencies(): array
  {
    return [
      'invokables' => [],
      'factories'  => [
        ApiClientInterface::class => ApiClientFactory::class,
      ],
    ];
  }
}

Dieses Muster – die Verwendung einer Factory zur Instanziierung eines Service und die Registrierung des Service im ConfigProvider – illustriert, wie ein Service in einer Mezzio-Applikation erstellt wird. In diesem Artikel wird dieses Muster für sämtliche Services verwendet, jedoch aus Platzgründen nicht explizit erwähnt. Neben der Verwendung einer Factory gibt es einige weitere Möglichkeiten zur Verwendung von Services mit dem Laminas Service Manager. In der Dokumentation [6] sind diese ausführlich beschrieben.

Im nächsten Schritt wird ein CommerceLayer Client erstellt, der Anfragen entgegennimmt, diese mit einem Access-Token ergänzt und schließlich über den API-Client versendet (Listing 5). Wie zuvor erwähnt, ist die Implementation des TokenProviders nicht Bestandteil dieses Artikels.

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer;
 
use CommerceLayer\Client\TokenProvider;
use Psr\Http\Client\ClientInterface as HttpClient;
use Psr\Http\Message\RequestInterface;
use Psr\Http\Message\ResponseInterface;
 
class Client
{
  public function __construct(
    private readonly HttpClient $httpClient,
    private readonly TokenProvider $tokenProvider
  ) {
  }
 
  public function sendRequest(RequestInterface $request): ResponseInterface
  {
    return $this->httpClient->sendRequest(
            $this->withToken($request)
    );
  }
 
  private function withToken(RequestInterface $request): RequestInterface
  {
    return $request->withHeader('Authorization', $this->tokenProvider->getToken());
  }
}

Datentransferobjekt

Um das Interpretieren von Antworten auf API-Anfragen nicht zu wiederholen und Daten einheitlich innerhalb der Applikation weitergeben zu können, wird ein Datentransferobjekt (DTO) eingesetzt (Listing 6). Ein DTO ist ein Objekt, das dazu dient, Daten zu kapseln und sie von einem Teilsystem einer Anwendung an ein anderes zu senden.

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer\Sku;
 
use Psr\Http\Message\ResponseInterface;
 
use function json_decode;
 
use const JSON_THROW_ON_ERROR;
 
class Dto
{
  public function __construct(
    public readonly ?string $id,
    public readonly string $code,
    public readonly string $name,
  ) {
  }
 
  public static function fromResponse(ResponseInterface $response): self
  {
    $data = json_decode(
      $response->getBody()->getContents(),
      true,
      512,
      JSON_THROW_ON_ERROR
    );
 
    return new self(
      $data['data']['id'],
      $data['data']['attributes']['code'],
      $data['data']['attributes']['name'],
    );
  }
}

Obwohl eine SKU sehr viele Informationen enthalten kann, wird das DTO der Einfachheit halber hier mit nur drei Eigenschaften deklariert:

• id: Repräsentation der CommerceLayer-ID. Diese kann leer (null) sein, z. B. für neue SKUs.
• code: die SKU oder einfach Artikelnummer.
• name: Name der SKU.

Nebst dem Constructor wird ein statischer Constructor bereitgestellt, welcher ein DTO anhand des Psr\Http\Message\ResponseInterface-Objekts instanziiert. Dieser ermöglicht die Erstellung einer DTO-Instanz aus dem Response-Objekt verschiedener Anfragen (wie Read, Create oder Update), ohne Logik duplizieren zu müssen.

Requests

Der Client nimmt für API-Anfragen Psr\Http\Message\RequestInterface-Instanzen entgegen. Die Requests werden in einer separaten Klasse instanziiert und später vom Repository verwendet.

Beispielhaft zeigt die folgende Klasse den Request zur Erstellung neuer SKUs (Listing 7).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer\Sku\Request;
 
use CommerceLayer\Sku\Dto;
use GuzzleHttp\Psr7\Request;
use Psr\Http\Message\RequestInterface;
 
use function json_encode;
 
use const JSON_THROW_ON_ERROR;
 
class Create
{
  public static function create(Dto $dto): RequestInterface
  {
    $data = [
      'data' => [
        'type'       => 'skus',
        'attributes' => [
          'code' => $dto->code,
          'name' => $dto->name,
        ],
      ],
    ];
 
    return new Request(
      'POST',
      '/api/skus',
      [],
      json_encode($data, JSON_THROW_ON_ERROR)
    );
  }
}

Repository

Mit dem umgesetzten Client, Request und DTO kann nun das Repository implementiert werden. Die Anwendung wird sich des Repositorys bedienen, ohne selbst die Requests zu definieren oder Access Tokens zu generieren etc.

Das Repository bietet zunächst drei Methoden an: readOneByCode, create und update. Alle Methoden geben ein DTO-Objekt zurück, sodass eine einheitliche Signatur angeboten und die Interpretation der HTTP-Antwort nicht wiederholt wird. Das Repository kann erweitert werden, um weitere Anwendungsfälle wie das Löschen einer SKU abzudecken (Listing 8).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer\Sku;
 
use CommerceLayer\Client;
use CommerceLayer\Sku\Request\Create;
use CommerceLayer\Sku\Request\ReadOneByCode;
use CommerceLayer\Sku\Request\Update;
 
class Repository
{
  public function __construct(
    private readonly Client $client,
  ) {
  }
 
  public function readOneByCode(string $code): Dto
  {
    $request  = ReadOneByCode::create($code);
    $response = $this->client->sendRequest($request);
 
    return Dto::fromResponse($response);
  }
 
  public function create(Dto $dto): Dto
  {
    $request  = Create::create($dto);
    $response = $this->client->sendRequest($request);
 
    return Dto::fromResponse($response);
  }
 
  public function update(Dto $sku): Dto
  {
    $request  = Update::create($sku);
    $response = $this->client->sendRequest($request);
 
    return Dto::fromResponse($response);
  }
}

Mit diesem Stand kann nun mit der CommerceLayer-API kommuniziert werden. SKUs können erstellt, ausgelesen und aktualisiert werden.

Im gleichen Verfahren werden weitere Schnittstellen angebunden. Im Beispielprojekt wird die SAP-Schnittstelle angebunden. Obwohl diese im weiteren Verlauf verwendet wird, ist sie hier nicht explizit beschrieben.

Events

Um Daten auf dem aktuellen Stand zu behalten, gibt es unterschiedliche Ansätze. Klassisch vertretend sind Cronjobs, die Daten von Zeit zu Zeit selbst zuziehen.

Dieses Projekt baut auf eine ereignisgesteuerte Architektur. Das ist ein Softwarearchitekturparadigma, das die Erzeugung, Erkennung und Nutzung von Ereignissen sowie die Reaktion darauf fördert. Das bedeutet, dass Drittsysteme unsere Applikation über ein Ereignis, wie z. B. eine Preisänderung oder Bestellaufgabe, informiert. Auf dieses Ereignis kann nun reagiert und Prozesse können abgebildet werden, wie sie benötigt werden.

Product Update

Als Beispiel wird die Implementierung der Produktaktualisierung aufgezeigt. Unser System wird über eine Produktänderung benachrichtigt. Es holt sich die Daten aus dem Quellsystem und schreibt sie ins Zielsystem. Für die Kommunikation zwischen den Schnittstellen wird ein ApiConnector-Modul erstellt.

Transferrer

Die Transferrer-Klasse hat die Aufgabe, Daten aus dem Quellsystem abzurufen und im Zielsystem zu speichern. Dadurch bedient sie sich der zuvor erstellten Repositoryobjekte. Als Parameter wird ein Wert verwendet, anhand dessen der SKU in beiden Systemen referenziert werden kann – der SKU-Code.

Sollte der SKU in CommerceLayer (SkuRepository) nicht vorhanden sein, generiert der Guzzle-Client aus einer Antwort mit HTTP-Status 404 eine ClientException. Diese wird gefangen und anstelle eines Updates ein Create ausgelöst. Die daraus resultierende Klasse sieht wie in Listing 9 aus.

<?php
 
declare(strict_types=1);
 
namespace ApiConnector\Material\DataToCommerce;
 
use CommerceLayer\Sku\Dto;
use CommerceLayer\Sku\Repository as SkuRepository;
use GuzzleHttp\Exception\ClientException;
use Sap\Material\Repository as MaterialRepository;
 
class Transferrer
{
  public function __construct(
    private readonly MaterialRepository $materialRepository,
    private readonly SkuRepository $skuRepository,
  ) {
  }
 
  public function __invoke(string $skuCode): void
  {
    $material = $this->materialRepository->readOneBySku($skuCode);
 
    try {
      $sku = $this->skuRepository->readOneByCode($material->sku);
 
      $updatedSku = new Dto(
        $sku->id,
        $material->sku,
        $material->name,
      );
 
      $this->skuRepository->update($updatedSku);
    } catch (ClientException) {
      $this->skuRepository->create(Dto::fromMaterialDto($material));
    }
  }
}

Dass das Ereignis „Produktaktualisierung“ den Transferrer aufrufen kann, muss dieser über eine Route exponiert werden. Die Route bzw. die darüber eingehenden Anfragen werden von einem RequestHandler abgearbeitet, welcher wiederum den Transferrer aufrufen.

In einer Mezzio-Applikation werden die Routen an der Applikationsinstanz in config/routes.php definiert [7] (Listing 10). Der erste Parameter definiert den Pfad und optional mögliche Argumente. Der zweite Parameter gibt die RequestHandler-Klasse an. Als dritten Parameter kann man einen Namen angeben. Dieser spielt später noch eine wichtige Rolle.

$app->get(
  '/api/event/material-change/{sku-code}',
  Api\Event\MaterialChange\RequestHandler::class,
  'api.event.material-change'
);

Dem RequestHandler wird ein Request-Objekt übergeben, das vom Router mit Argumenten angereichert werden kann (Listing 11). In diesem Fall wird der SKU-Code ausgelesen. Es folgt eine einfache Validierung, welche im Fehlerfall eine Antwort mit „Status 400 – Bad Response“ zurückgibt.

Anschließend wird der Transferrer aufgerufen. Mögliche Fehler resultieren in einer Antwort mit „Code 500 – Internal Server Error“. Im Erfolgsfall wird eine einfache „204 – No Content“-Antwort geliefert.

<?php
 
declare(strict_types=1);
 
namespace Api\Event\MaterialChange;
 
use ApiConnector\Material\DataToCommerce\Transferrer;
use Laminas\Diactoros\Response\EmptyResponse;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\RequestHandlerInterface;
use Throwable;
 
use function is_string;
 
class RequestHandler implements RequestHandlerInterface
{
  public function __construct(
    private readonly Transferrer $transferrer
  ) {
  }
 
  public function handle(ServerRequestInterface $request): ResponseInterface
  {
    $skuCode = $request->getAttribute('sku-code');
 
    if (
      ! is_string($skuCode)
      || $skuCode === ''
    ) {
      return new EmptyResponse(400);
    }
 
    try {
      ($this->transferrer)($skuCode);
    } catch (Throwable) {
      return new EmptyResponse(500);
    }
 
    return new EmptyResponse();
  }
}

Endpoint-spezifische HMAC-Validierung

Mittels HMAC signierte Payloads bieten die Möglichkeit einer Authentifizierung unter Verwendung eines gemeinsamen Geheimnisses anstelle von digitalen Signaturen mit asymmetrischer Kryptografie (Public-Key-Verschlüsselungsverfahren).

Die CommerceLayer API signiert Event Payloads mit HMAC. Um die Echtheit des Senders sicherzustellen, wird empfohlen, diese Signatur mit einem geteilten Geheimnis zu verifizieren. CommerceLayer generiert für jeden WebHook ein eigenes geteiltes Geheimnis. Dieses wird in der Konfiguration mit dem Namen der entsprechenden Route hinterlegt (Listing 12).

<?php
 
declare(strict_types=1);
 
return [
  'commerce_layer' => [
    // [..]
    'webhooks' => [
      'shared_secrets' => [
        'api.event.customer_create' => 'my-secret',
      ],
    ],
  ],
  // [..]
];

SharedSecretStore

Die geteilten Geheimnisse werden zur Laufzeit in einen SharedSecretStore gelesen, welcher die Aufgabe hat, ein SharedSecret anhand des Route-Namens auszugeben (Listing 13 und 14).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer\Authentication\Hmac;
 
class SharedSecret
{
  public function __construct(
    public readonly string $route,
    public readonly string $secret,
  ) {
  }
}

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer\Authentication\Hmac;
 
use CommerceLayer\Authentication\Hmac\Exception\SharedSecretNotFoundException;
 
class SharedSecretStore
{
  /** @var SharedSecret[] */
  private array $sharedSecrets;
 
  public function __construct(SharedSecret ...$sharedSecrets)
  {
    $this->sharedSecrets = $sharedSecrets;
  }
 
  public function has(string $route): bool
  {
    foreach ($this->sharedSecrets as $sharedSecret) {
      if ($route === $sharedSecret->route) {
        return true;
      }
    }
 
    return false;
  }
 
  public function get(string $route): SharedSecret
  {
    foreach ($this->sharedSecrets as $sharedSecret) {
      if ($route === $sharedSecret->route) {
        return $sharedSecret;
      }
    }
 
    throw SharedSecretNotFoundException::fromRoute($route);
  }
}

Validator

Der Validator ist dafür zuständig, anhand von SharedSecret und Payload die Signatur zu berechnen und überprüfen, ob diese mit der übergebenen Signatur übereinstimmt (Listing 15).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer\Authentication\Hmac;
 
use ErrorException;
use Throwable;
 
use function base64_encode;
use function hash_hmac;
use function restore_error_handler;
use function set_error_handler;
 
use const E_WARNING;
 
class Validator
{
  private const ALGORITHM = 'sha256';
 
  public function invoke(
    string $sharedSecret,
    string $signature,
    string $payload
  ): bool {
    try {
      set_error_handler(static function (
        $level,
        $message
      ) {
        throw new ErrorException($message);
      }, E_WARNING);
 
      $message = hash_hmac(
        self::ALGORITHM,
        $payload,
        $sharedSecret,
        true
      );
    } catch (Throwable) {
      restore_error_handler();
 
      return false;
    }
 
    restore_error_handler();
 
    if (false === $message) {
      return false;
    }
 
    $calculatedSignature = base64_encode($message);
 
    return $calculatedSignature === $signature;
  }
}

Middleware

Der Validator kann die Signaturen überprüfen. Nun wäre es sehr mühsam, diesen in jedem RequestHandler manuell aufzurufen. An einer Route können eine oder mehrere Middleware-Klassen hinterlegt werden. Diese werden in definierter Reihenfolge abgearbeitet. Eine Middleware hat die Möglichkeit, einen Request frühzeitig zu beenden, wenn bspw. die anfragende IP-Adresse nicht gestattet ist oder ein API-Rate-Limit überstiegen wurde. Dann wird ein Response-Objekt zurückgeliefert. Ist die Überprüfung positiv verlaufen, wird die Anfrage an die nächste Middleware in der Kette weitergegeben, bis schließlich mit einem Response-Objekt geantwortet wird. Die Middleware für die HMAC-Validierung setzt die zuvor erstellten Komponenten ein (Listing 16).

<?php
 
declare(strict_types=1);
 
namespace CommerceLayer\Authentication\Hmac;
 
use Laminas\Diactoros\Response\EmptyResponse;
use Mezzio\Router\RouteResult;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;
 
use function assert;
use function count;
 
class Middleware implements MiddlewareInterface
{
  public function __construct(
    private readonly SharedSecretStore $secretStore,
    private readonly Validator $hmacValidator,
  ) {
  }
 
  public function process(
    ServerRequestInterface $request,
    RequestHandlerInterface $handler
  ): ResponseInterface {
    $route = $request->getAttribute(RouteResult::class);
    assert($route instanceof RouteResult);
    $routeName = $route->getMatchedRouteName();
 
    if (false === $routeName) {
      return new EmptyResponse(401);
    }
 
    if (! $this->secretStore->has($routeName)) {
      return new EmptyResponse(401);
    }
 
    $signature          = $request->getHeader('x-commercelayer-signature');
    $numberOfSignatures = count($signature);
 
    if (1 !== $numberOfSignatures) {
      return new EmptyResponse(401);
    }
 
    $payload = (string) $request->getBody();
 
    if (
      $this->hmacValidator->invoke(
        $this->secretStore->get($routeName)->secret,
        $signature[0],
        $payload
      )
    ) {
      return $handler->handle($request);
    }
 
    return new EmptyResponse(401);
  }
}

Middleware zur Route hinzufügen

Diese wird nun dem RequestHandler in der Route vorangestellt. Anfragen mit ungültigen Signaturen werden von der Middleware frühzeitig beendet und erreichen den RequestHandler nicht. Auf die gleiche Weise können alle anderen Endpunkte, die eine HMAC-Signatur überprüfen sollen, ergänzt werden, ohne jeden RequestHandler erweitern zu müssen. Mit dem in Listing 17 gezeigten Code ist die Middleware auch schon einsatzbereit.

$app->get(
  '/api/event/customer-create',
  [
    CommerceLayer\Authentication\Hmac\Middleware::class,
    Api\Event\MaterialChange\RequestHandler::class,
  ],
  'api.event.customer_create'
);

Viele Wege führen nach Rom

Dem aufmerksamen Leser ist nicht entgangen, dass die Codebeispiele stark vom eigentlichen Framework entkoppelt sind und wo immer möglich auf PSRs gesetzt wird. Das bedeutet, dass das Framework selbst in den Hintergrund gerückt und ersetzbar(er) geworden ist. Das ist erfreulich, da das Framework oder auch einzelne Komponenten leichter abgelöst werden können, wenn sich bspw. die Anforderungen ändern oder einzelne Bibliotheken nicht mehr gewartet werden. Wahrscheinlich ist es möglich, den gezeigten Fall mit nahezu jedem anderen modernen PHP-Framework umzusetzen.

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Fazit

Im Team haben wir vor wenigen Jahren diverse Frameworks evaluiert und uns einstimmig für Mezzio entschieden, um das vorherige Framework abzulösen. Mit unserer Entscheidung sind wir voll zufrieden, weil Mezzio

• es uns erlaubt, das Framework so einzusetzen, wie es die jeweiligen Projektanforderungen erfordern, ohne auf unflexible Vorschriften des Frameworks Rücksicht nehmen zu müssen,
• es einem leicht macht, testbaren Code zu schreiben, der sauber vom Framework getrennt ist und
• eine sehr hilfreiche Community hat, die schnelle Unterstützung im Forum [8] und Chat [9] anbietet.

Wenn wir etwas an Mezzio verbessern könnten, wäre das die Größe der aktiven Community – das ist eine Einladung an alle Interessierten, sich am Laminas-Projekt zu beteiligen. Es wird von wenigen Schultern getragen und hat eine vergleichsweise große Anzahl stiller Benutzer. Mezzio kann von Mitwirkenden profitieren, die Dokumentationen schreiben, Issues bearbeiten, sich als Maintainer einer Komponente begeistern oder finanziell unterstützen [10].

Das beschriebene Projekt ist im Sommer 2021 live gegangen. Eine vollständige Fallstudie kann auf der Seite der Intelliact AG [11] abgerufen werden. Ein rückwärts gerichteter Blick bestätigt, dass mit dieser Architektur die richtige Entscheidung getroffen wurde. Kunden und Endkunden sind von der Performance begeistert. Beim Best of Swiss Web Award wurde das Projekt aus 351 Einreichungen zum Masterkandidat [12] nominiert und gewann u. a. den goldenen Preis in der Kategorie Technologie [13].

Zusammengefasst: Mezzio kann den Global Playern definitiv das Wasser reichen!

The post Composable Commerce mit Mezzio appeared first on webinale 2025.

Die weltweit erste Website bestand lediglich aus reinem Text und Hyperlinks. Aussehen, Verhalten und Nutzung des Internets haben sich seitdem radikal verändert. Das Web wurde zu einer interaktiven Plattform, die Nutzer:innen aktiv mitgestalten können. Jede der Sites und Anwendungen enthält Inhalte, die verwaltet und bearbeitet werden müssen. Doch nicht bei jeder inhaltlichen Änderung soll gleich ein Entwicklerteam beauftragt werden. Die Lösung bieten Content-Management-Systeme (CMS), denn sie ermöglichen es, Inhalte und Medien zu verwalten und zu veröffentlichen (Abb. 1).

Abb. 1: Funktionsweise eines klassischen CMS

Warum Headless?

Die aktuellen Trends im Web und die voranschreitende Digitalisierung stellen CMS vor neue Herausforderungen. Im Zeitalter internetfähiger Kühlschränke genügt es nicht mehr, eine responsive Website zu betreiben. Heterogene Ausgabegeräte benötigen häufig eine speziell auf den jeweiligen Kanal zugeschnittene Anwendung. Der Inhalt ist hingegen überall gleich – zumindest in Teilen. Damit er nicht mehrmals an unterschiedlicher Stelle erzeugt und gepflegt werden muss, wurde in den letzten Jahren das Konzept der Headless CMS entwickelt.

Abb. 2: Funktionsweise eines Headless CMS

Ein Headless CMS hat die Vorteile klassischer CMS, bietet also einen Administrationsbereich, in dem Content Creators Inhalte anlegen und verwalten können. Gleichzeitig ist es nicht mehr an ein einziges Frontend gebunden. Das ist nämlich komplett vom Backend entkoppelt: Die Daten können über eine standardisierte Schnittstelle abgerufen und auf einem beliebigen Frontend dargestellt werden (Abb. 2).

Trends von Content-Management-Systemen

Knapp 40 Prozent aller Websites verwenden ein CMS [1]. Durch die rasante Entwicklung und Digitalisierung müssen CMS immer mehr leisten:

• Ausgabekanäle: Mit der Digitalisierung existieren immer mehr internetfähige Geräte, mehr Anwender, mehr Software und mehr Content. Ein modernes CMS muss Inhalte für beliebige Anwendungen, native Apps, Webshops, E-Mail, Marketing, Intranet etc. bereitstellen können.

• Frameworks: Mit Headless CMS können beliebige Frontend-Frameworks genutzt werden. Mit Frameworks sparen Entwickler:innen Zeit und Kosten, um eine Website zu erstellen, da sie vorgefertigte Komponenten und den „Baukasten“ ihrer Wahl nutzen können.

• Cloud: Moderne CMS sind über den Browser als universale Schnittstelle bedienbar und können ohne eigenen Installationsaufwand in der Cloud bereitgestellt und auch skaliert werden.

• Usability und User Experience: Gute CMS sollten einen einfach bedienbaren Administrationsbereich haben, um den Lernaufwand der Nutzer:innen mit unterschiedlichen Vorkenntnissen gering zu halten. Außerdem sollten sie den Redakteur:innen Freiraum für individuelle Gestaltung bieten.

• Content Delivery Networks (CDNs): Endnutzer:innen gehen davon aus, dass eine Website schnell lädt. Die Conversion Rate sinkt, wenn die Seite nicht innerhalb von 2,4 Sekunden geladen ist [1]. CDNs können im Zusammenspiel mit CMS dabei helfen, dass der Inhalt schnell bei den Nutzenden ankommt. Sie verringern die Latenz und helfen, Infrastruktur gleichmäßig auszulasten.

• Search Engine Optimization (SEO): Wird eine Website für Suchmaschinen optimiert, kann sie schneller gefunden werden, was wiederum zu einer höheren Conversion Rate führt. Dazu müssen Metadaten für den Inhalt festgelegt werden. Moderne CMS bieten einfache Möglichkeiten, Metadaten wie den Titel, eine Bildbeschreibung oder Keywords festzulegen.

• Sicherheit: Um sich vor Hackerangriffen zu schützen, benötigt ein CMS bestmögliche Sicherheitsmechanismen. Dazu gehören ein Authentifizierungs- und Autorisierungskonzept, um zu bestimmen, wer auf welche Daten zugreifen kann, und die Verschlüsselung vertraulicher Daten.

• Verschmelzung von Content und E-Commerce: Moderne CMS kombinieren Inhalte mit Produkten und Dienstleistungen. Kunden sollen persönlich angesprochen werden, indem das CMS etwa den Aufenthaltsort, die Zeitzone oder das genutzte Endgerät auswertet. Zum Einsatz kommen beispielsweise integrierte KI-basierte Chatbots.

• Headless und Microservices: Headless CMS sind Teil des JAM-Stacks (JavaScript API Markup). Die Inhalte werden mittels API an ein beliebiges JavaScript Framework angebunden, sodass kein monolithisches System entsteht. Das CMS bleibt modular und Entwickler:innen können selbst bestimmen, wo und wie die Daten gespeichert und wie die Website gerendert wird.

Headless CMS im Vergleich: WordPress, Strapi und Sanity

Nun wollen wir drei populäre Headless CMS vergleichen. WordPress wurde 2003 von Mike Little und Matt Mullenweg entwickelt und diente ursprünglich als Blogveröffentlichungsplattform. Das traditionelle CMS bietet ebenfalls die Möglichkeit, die Daten über ein API abzurufen. Wegen der riesigen Community rund um WordPress und weil das CMS so viel genutzt wird, darf es in diesem Vergleich nicht fehlen.

Strapi wurde 2015 gegründet und ist ein auf Node.js basierendes Headless CMS. Es hat sich vor allem auf die Erstellung des API spezialisiert, das sich flexibel anpassen lässt, sodass es den Bedürfnissen der Nutzenden entspricht.

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Sanity.io ist ein CMS, das 2017 entwickelt wurde. Es wirbt mit der Vereinheitlichung und Strukturierung von Inhalten. Sanity ist als Software as a Service (SaaS) erhältlich, sodass die Inhalte direkt in einer Cloud gespeichert und den Nutzenden zur Verfügung gestellt werden.

Im Folgenden werfen wir nun einen detaillierteren Blick auf eine Auswahl wichtiger Merkmale moderner Headless-CMS:

• API,

• Hosting,

• Content Modeling,

• Gestaltungsfreiheit für Webredakteur:innen sowie

• Preismodelle.

Das Herzstück eines Headless CMS: das API

Das Application Programming Interface (API) dient als Schnittstelle zwischen dem Headless CMS und einem oder mehreren Frontends. Das Programmierparadigma REST bildet hier den Standard im Web, sodass RESTful APIs von fast jedem internetfähigen Gerät genutzt werden können. RESTful APIs haben allerdings auch einige Nachteile, wie das Over- und Underfetching. Overfetching beschreibt, dass alle verfügbaren Inhalte einer Ressource zurückgegeben werden, auch wenn sie nicht benötigt werden. Underfetching bedeutet, dass immer nur ein Endpunkt gleichzeitig abgerufen werden kann. Sollen mehrere Ressourcen angefragt werden, muss das nacheinander geschehen.

Neue Abfragetechnologien versprechen, diese Probleme zu lösen. Zu den bekanntesten zählt GraphQL. Im Gegensatz zu RESTful APIs strukturiert GraphQL die Daten nicht nach Ressourcen, sondern nach Typen und deren Attributen. Dadurch gibt es nur einen Endpunkt, mit dem mehrere Ressourcen abgefragt werden können. Der Request kann außerdem so definiert und gefiltert werden, dass nur die tatsächlich benötigten Daten zurückgegeben werden.

RESTful APIs, GraphQL oder CROQ

Das System Strapi nutzt standardmäßig ein REST API, das es erlaubt, Inhaltstypen durch Endpunkte zu erreichen. Es werden automatisch Endpunkte für CRUD-(Create-Read-Update-Delete-)Funktionalitäten erstellt. Zudem gibt es die Möglichkeit, Endpunkte anders zu benennen und zu verändern. Dabei können Endpunkte komplett oder teilweise deaktiviert, mit berechneten Daten gefüllt oder komplett überschrieben werden. Zusätzlich bietet Strapi die Möglichkeit, über ein Plug-in auch das GraphQL API zu nutzen. GraphQL erstellt automatisch für jeden Inhaltstyp Querys und Mutations.

WordPress ist zwar kein Headless CMS, bietet aber ein REST API an, das standardmäßig unter dem folgenden URL abgefragt werden kann: https://<wordpress-site-url>/wp-json/. Zusätzlich können durch Plug-ins weitere Abfragesprachen wie GraphQL genutzt werden. WordPress generiert automatisch API-Endpunkte, mittels PHP können aber auch eigene Endpunkte definiert werden.

Sanity verwendet standardmäßig die hauseigene Abfragesprache CROQ. CROQ steht für Graph Rational Object Queries und wurde speziell für den Einsatz dieses CMS entwickelt. Ebenso wie bei GraphQL werden nur die benötigten Daten abgerufen, Informationen aus verschiedenen Ressourcen verbunden und in einer Antwort zurückgegeben, die individuell strukturiert werden kann. Mit CROQ können Ressourcen nur abgefragt und nicht verändert werden. Eine beispielhafte Abfrage wird im nachstehenden Code gezeigt, in dem alle Künstler mit Namen, einem Link zur entsprechenden Künstlerwebsite und Kunstwerken zurückgegeben werden. Als Kunstwerke werden alle Objekte geladen, die dem jeweiligen Künstler zugeordnet wurden. Darüber hinaus bietet Sanity auch ein GraphQL API an. Allerdings können hier nur Querys und keine Mutations verwendet werden. Um Inhalte zu verändern, kann ein REST API genutzt werden.

*[ _type == "artist"]{
  name,
  "link": slug.current,
  "artworks": *[_type == "artworks" && artist._ref == ^._id]
 }

Cloud-Hosting

Hosting ist ein wichtiges Kriterium, da es über die Verfügbarkeit der Daten und die Geschwindigkeit der Website Aufschluss gibt. Moderne CMS setzen auf Cloud-Hosting. Dabei liegt das CMS auf mehreren miteinander verbundenen Servern. Die Auslastung kann auf mehrere Server verteilt werden, was zu einer besseren Performance führt. Meist wird die Cloud durch das Pay-as-you-go-Preismodell abgerechnet, sodass nur das gezahlt wird, was wirklich genutzt wird. Da die Rechenkapazität einfach skaliert werden kann (durch Ab- und Zuschalten von Servern) wird eine enorme Flexibilität erreicht. Zudem wird die Verfügbarkeit garantiert.

Strapi ist eine Open-Source-Software und kann on-premises, also in einer eigenen Umgebung, gehostet werden. Alternativ stehen Leitfäden bereit, um die Software manuell auf einen Cloudanbieter wie AWS oder Azure zu deployen. Ein vom Unternehmen angebotenes Cloud-Hosting befindet sich derzeit noch im Aufbau.

Bei Sanity ist die Verwaltungsumgebung Sanity Studio Open Source. Das CMS kann damit lokal getestet und aufgesetzt werden, das API wird allerdings auf den Servern des Unternehmens gehostet. Das bringt einige Vorteile mit sich: Das Deployment ist mit nur einem Befehl erledigt, und Sanity stellt nicht nur die Pipeline und Kapazität zur Verfügung, sondern kümmert sich gleich selbst um regelmäßige Updates und Backups.

Beim Open-Source-Platzhirsch WordPress kann man auf sämtliche Möglichkeiten und fast unzählige Hostinganbieter zurückgreifen. Viele Unternehmen bieten beispielsweise eine Ein-Klick-Installation mit regelmäßigen Updates und Backups an.

Schneller an die Inhalte: Content Delivery Networks

In unserer schnelllebigen Zeit ist es wichtig, dass Kund:innen und Nutzer:innen schnell auf die Inhalte Zugriff haben. Content Delivery Networks (CDNs, Abb. 3) sind geografisch sinnvoll verteilte Server, die für ein schnelles Bereitstellen von Internetinhalten sorgen. Um die Latenz möglichst gering zu halten und damit eine bessere User Experience zu gewährleisten, speichern CDNs Kopien von Webinhalten auf sogenannten PoPs (Points of Presence). Damit kann der Caching-Server, der physikalisch dem Client am nächsten ist, die Inhalte bereitstellen. Das hat noch einen weiteren Vorteil: Dank des temporären Speicherns können Inhalte effizient für mehrere Nutzende bereitgestellt werden. So werden Netzwerküberlastungen verhindert.

Sanity stellt CDNs für Assets und das API bereit. Die Asset-CDNs basieren auf Google-Services und cachen Bilder, Videos und andere Formate. Um die API-CDNs zu nutzen, kann statt dem URL api.sanity.io einfach apicdn.sanity.io angesprochen werden.

Abb. 3: Funktionsweise eines Content Delivery Networks

Unterschied zwischen Cloud und CDNs

Cloud-Hosting und die Verwendung eines CDN sind sehr ähnlich, denn beide speichern Inhalte auf mehreren geografisch verteilten Servern. Sie unterscheiden sich allerdings in ihrem Verwendungszweck: CDNs sind keine Webhosts. Sie sind lediglich für das Zwischenspeichern von Caching-Daten verantwortlich, um Inhalte näher und schneller an Endkonsument:innen zu bringen. Cloud-Hosting wiederum wird verwendet, um flexibel und bei Bedarf kurzzeitig mehr Kapazitäten für das Hosting und das Bereitstellen von Daten zu ermöglichen.

Content First

Content Modeling beschreibt den Prozess, mit dem eine logische Struktur erstellt wird, in der Inhalte gespeichert werden können. In einem Content Model werden einzelne Inhaltstypen, eine Art Template, mit ihren Attributen definiert und im Detail beschrieben. Die Attribute sind gewöhnlich Inputblöcke, in die Inhalt eingetragen werden kann. Das können ein Text, eine Zahl, Medien, eine Enumeration oder andere CMS-spezifische Inhaltstypen sein.

Wie in Abbildung 4 dargestellt, sollten alle Informationen auf kleinstmögliche Datenstücke heruntergebrochen und sinnvoll beschriftet werden. Der Inhaltstyp „Katze“ hat hier die Attribute „Name“ (Text), „Alter“ (Nummer) und „Bild“ (Media). Von einem Inhaltstyp können mehrere Instanzen angelegt werden, in diesem Beispiel Katze #1 und Katze #2.

Abb. 4: Beispiele für einen Content Type und dessen Attribute

Content Hub durch strukturierten Inhalt

Alle CMS nutzen ein Content Model zur Strukturierung des Inhalts. Doch vor allem Headless CMS folgen dem sogenannten Content-first-Ansatz, da sie sich auf die Strukturierung der Inhalte konzentrieren und nicht auf deren Darstellung. Klassische CMS wie Drupal oder Typo3 haben nur wenig Struktur: Die Inhaltstypen sind fest vordefiniert (z. B. Websites, Blogposts und User) und nur schwer erweiterbar. Zudem haben die Inhaltstypen nur wenige Attribute, wie in Abbildung 5 auf der linken Seite dargestellt ist. Der Inhaltstyp Website hat beispielsweise nur das Attribut header und body, in dem alle Inhalte, wie Texte, Bilder und Videos eingefügt und formatiert werden.

Im Gegensatz dazu können mit CMS wie Strapi eigene Inhaltstypen definiert werden. Eine Website über Künstler könnte zum Beispiel die Inhaltstypen Künstler, Kunstwerk, Blogbeitrag und Website haben. Jeder dieser Inhaltstypen kann mit beliebig vielen und unterschiedlichen Attributen ausgestattet werden (Abb. 5, rechte Seite).

Abb. 5: Links unstrukturierter Inhalt mit wenigen Attributen, rechts strukturierter Inhalt

WordPress speichert Inhalte nur bedingt strukturiert

WordPress bietet von Haus aus keine Möglichkeit, eigene Inhaltstypen zu erstellen. Da WordPress ein klassisches CMS ist, ist es nicht auf diese Art der Inhaltsstrukturierung ausgelegt. Standardmäßig verfügt WordPress über sieben Content Types, genannt Post Types. Über Plug-ins oder im Code mit PHP können auch eigene Types erstellt werden. Bekannte Plug-ins sind dafür das „Custom Post Type UI“ oder „Advanced Custom Fields“. Bei der Wahl des Plug-ins muss auf die Erstellung von API-Endpunkten geachtet werden. Nicht jedes Plug-in erstellt automatisch Schnittstellen mit den CRUD-Funktionen. Teilweise müssen sie im Code selbst erstellt werden.

Sanity und Strapi bieten mehr Möglichkeiten

Sanity und Strapi bieten für das Content Model vergleichbare Funktionalitäten, wobei sie sich vor allem in der Erstellung unterscheiden. Strapi bietet für die Erstellung der Inhaltstypen und -attribute ein intuitives User Interface, mit dem alle Optionen ausgewählt und definiert werden können. Bei Sanity müssen die Inhaltstypen und -attribute im Code festgelegt werden. Das ist anfangs aufwendiger, da die Möglichkeiten von Attributen und deren Optionen in der Dokumentation nachgelesen werden müssen. Gleichzeitig bietet das mehr Freiheiten in der Erstellung und Verschachtelung. Besonders interessant sind dabei spezielle Inhaltstypen, die dem größten Nachteil von strukturiertem Inhalt entgegenwirken sollen: Komponenten und Arrays ermöglichen Redakteur:innen mehr Freiheit in der Gestaltung der Inhalte.

Inhaltsattribute für mehr Gestaltungsspielraum

Jedes CMS bietet eigene Attribute an. Folgende sind allerdings bei der Mehrheit vertreten:

• RichText ist Text, der neben dem Inhalt auch Formatinformationen speichert.

• Komponenten bündeln mehrere Attribute zu einem neuen Attribut, zum Beispiel Vorname und Nachname. Diese können meist von allen Inhaltstypen verwendet werden.

• Wiederholbare Komponenten sind Komponenten, die mehrmals verwendet werden können, z. B. können für einen Inhaltstyp „Workshop“ mehrere Termine eingetragen werden, jeweils mit den Attributen Uhrzeit und Ort.

• Durch Arrays können Redakteur:innen aktiv die Reihenfolge des Layouts mitbestimmen. In diesen Zonen können Komponenten definiert werden, die von den Redakteur:innen nach Belieben verwendet und strukturiert werden können. Wie in Abbildung 6 zu sehen ist, kann in einem Array eine Komponente erstellt und mit Drag-and-drop in die gewünschte Reihenfolge gebracht werden. Redakteur:innen können dadurch zum Beispiel entscheiden, ob sie zuerst ein Bild und dann den Text platzieren möchten oder umgekehrt.

Abb. 6: Mit Arrays kann das Layout beeinflusst werden (Sanity Studio)

Gestaltungsmöglichkeiten für Redakteur:innen

Ein Attribut kann auch ein RichText-Feld sein, wie z. B. in Abbildung 5 auf der linken Seite das „Body“-Element. Für den RichText gibt es oft WYSIWYG-(What-you-See-Is-What-You-Get-) Editoren, mit denen grundlegende Formatierungen möglich sind wie Schriftgröße oder -farbe. Allerdings sind diese Editoren auch stark in der Gestaltung von Layouts eingeschränkt und machen das Verwenden von Inhaltstypen innerhalb des RichTexts schwer.

WordPress verwendet seit 2018 als Standard-WYSIWYG-Editor den Gutenberg-Editor. Dieser speichert den Inhalt in eigenen Blöcken ab, sodass diese leicht per Drag and Drop verschoben und manipuliert werden können. Die „Blöcke“ des Gutenberg-Editors werden allerdings nicht als einzelne Objekte abgespeichert. Sie sind über das API daher nicht einzeln erreichbar. Die Nutzenden des API bekommen daher nicht selten ein riesiges HTML-Objekt zurück.

Da Headless CMS für getrennte Speicherung von Inhalten und Darstellung ausgelegt sind, wird RichText im Frontend nicht automatisch mit den gleichen Formatierungen angezeigt, die im CMS vorgenommen wurden. CSS-Klassen werden zwar in HTML gespeichert und in der API-Response mit überliefert, aber solange die CSS Styles im Frontend nicht definiert werden, können die Styles nicht angezeigt werden.

Strapi nutzt deshalb keinen WYSIWYG-Editor, sondern Markdown. Durch die simple Syntax ist Markdown leichtgewichtig und verhindert Fehler in der Semantik. Mit Markdown kann eine Überschrift nicht eingefärbt oder in der Größe verändert, sondern nur dem semantischen Zweck zugeordnet werden. Die Semantik kann dann einfacher im Frontend gestylt werden.

Preisvergleich

Alle drei untersuchten CMS bieten eine kostenlose Version an, die für private, aber auch kleinere Projekte ausreichend ist. Strapi als selbstgehostete Software beschränkt in der kostenfreien Version die Support- und Autorisierungsfunktionalitäten. Ein um einige Funktionalitäten und Support erweiterter Tarif ist ab 9 $ pro Monat (ohne Hosting) erhältlich. Sanity, das nur als SaaS-Produkt (also mit Hosting) vom Unternehmen erworben werden kann, beschränkt in der kostenlosen Version beispielsweise die Anzahl der Nicht-Admin-Nutzer:innen sowie Bandbreite, Medien, Speicherplatz etc. Für kleine Teams existiert ein Preismodell ab 99 $ pro Monat.

WordPress ist damit schwer zu vergleichen, da die Kosten und das Angebot je nach Hostinganbieter stark variieren. Dabei sollte nicht vergessen werden, dass die Kosten für mögliche Plug-ins noch dazu kommen können.

Fazit: Strapi für größere Projekte empfehlenswert

Durch die große Anpassbarkeit und Personalisierungen empfiehlt sich Strapi vor allem für größere Projekte. Das API kann mit eigenen Endpunkten angepasst werden, und durch Zugriffsberechtigungen wird genau definiert, wer welche Informationen abrufen darf. Strapi zeichnet sich durch ein sehr intuitives User Interface aus, das alle Inhalte sortieren und durchsuchen kann. Mit dem Content Type Builder können die Inhaltstypen und ihre Attribute einfach über das Interface zusammengestellt werden (Abb. 7).

Abb. 7: Der Content Type Builder von Strapi erlaubt es, die Inhaltstypen über ein GUI zu erstellen

Außerdem bietet Strapi Redakteur:innen die Möglichkeit, sich selbst in die Gestaltung miteinzubringen: Es gibt einen Markdown-Editor und Dynamic Zones, eine Art Array, durch die das CMS zu einem Drag-and-Drop-Editor werden kann. Trotzdem kann das Webdesign komplett unabhängig im Frontend gestylt werden.

Durch eigenes Hosting hat man Kontrolle und Sicherheit über seine Daten. Gleichzeitig ist das Hosting auch der größte Kritikpunkt an Strapi: Das Set-up ist relativ komplex und zeitaufwendig, ist also nicht für Anfänger geeignet. Außerdem bietet Strapi momentan (Stand November 2022) noch kein eigenes Cloud-Hosting an.

Tabelle 1: Vergleich der drei Systeme im Überblick

Sanity als Allrounder

Sanity ist besonders für kleine bis mittelgroße Projekte geeignet. Sanity folgt dem Content-first-Ansatz durch und durch: Jedes bisschen Information wird in einem separaten Block gespeichert und ist über das API abrufbar. Sanity enthält dafür nicht nur viele verschiedene Content Types für jede Art von Attributen, sondern strukturiert selbst den Inhalt des Editors in einzelne JSON-Objekte.

Außerdem ist Sanity vor allem eins: schnell. Mittels eines Befehls kann das in Sanity Studio lokal entwickelte Projekt deployt werden und ist bereit für die Nutzung. Für eine bessere Performance verwendet Sanity CDNs für das Caching von Assets und Informationen. Auch Bilder können optimiert und ein Hotspot kann gewählt werden, damit die wichtigen Aspekte des Bildes immer angezeigt werden.

Standardmäßig bietet Sanity CROQ für Abfragen an, um möglichst zielgenaue Querys zu formulieren. Dennoch benötigt es einigen Zeitaufwand, die Abfragesprache zu lernen. Ein weiterer Nachteil ist, dass Nutzer:innen des API nicht in Rollen zusammengefasst werden und ihre Rechte eingeschränkt werden können. Außerdem bietet Sanity kein Hosting auf eigenen Servern (on-premises), was für größere Projekte mit sensiblen Daten unattraktiv sein kann.

WordPress kann als Headless CMS nicht mithalten

WordPress sollte als Headless CMS nur genutzt werden, wenn es ausdrücklich gewünscht ist. Der größte Vorteil liegt in dem vertrauten User Interface. Da WordPress so beliebt ist, haben schon viele Content Creators damit gearbeitet und kennen sich aus, was die Eingewöhnungszeit merklich verkürzt. Die größten Schwierigkeiten liegen in der Erstellung eines feingliedrigen Content Models. Eigene Inhaltstypen und ihre Attribute können nur über ein Plug-in erstellt werden. Je nach Plug-in werden so auch keine eigenen Endpunkte generiert, sodass diese selbst im Code definiert werden müssen.

Fazit

Wenn es gilt, für die Zukunft mit unterschiedlichsten internetfähigen Geräten gerüstet zu sein, sollte heutzutage ein Headless CMS genutzt werden. Dabei sollte das Hosting in Augenschein genommen werden – es ist wichtig, da von ihm Skalierbarkeit und Datensicherheit abhängen.

Das Herzstück eines Headless CMS ist der Umgang mit dem Inhalt. Wie wird der Inhalt strukturiert und gespeichert? Wie können Inhaltstypen erstellt werden und welche Felder werden benötigt? Wie können die Daten abgerufen werden? Diese Fragen sollten auf jeden Fall vor der Entscheidung für oder gegen ein bestimmtes CMS beantwortet werden, um eine bessere Vorstellung zu haben, wie das Content Model aussehen könnte.

Werden für ein Projekt vor allem große gestalterische Freiheiten für die Redakteur:innen benötigt, sollte man sich über deren Umfang im Klaren sein. Oft ist es ausreichend, das Layout nach Belieben aus Komponenten zusammenzustellen. Mehr Freiheiten könnten WYSIWYG-Editoren bieten, wobei die Herausforderungen der Darstellung auf multimedialen Geräten (Stichwort Responsivität) nicht vergessen werden dürfen. Je nach Projekt und Nutzergruppe sind die Kriterien also unterschiedlich zu gewichten.

Darüber hinaus existieren weitere Architekturen für das Verwalten von (Web-)Inhalten, wie beispielsweise Flat File CMS oder AEM/DXP. Diese haben ihre ganz eigenen spezifischen Vor- und Nachteile und wurden im Rahmen der zugrunde liegenden Arbeit [3] nicht berücksichtigt. Das Web entwickelt sich jedenfalls immer weiter. Wer weiß, welche Geräte in Zukunft daran angeschlossen werden und Informationen benötigen. Ein Headless-CMS bietet hierfür jedenfalls aktuell noch die passenden Möglichkeiten.

The post Der Headless-CMS-Vergleich appeared first on webinale 2025.

Bevor wir allerdings diese Fragestellung erörtern, klären wir vorab erst einmal einige Begrifflichkeiten, um auf der gleichen Wissensbasis zu starten. Ich hole mal ein wenig aus und wandele durch die EDV-chronologischen PC-Zeitalter. In der guten alten Zeit, dem „Cataractär“ oder Wasserfallzeitalter, herrschte das Konzept des BDUF vor, des Big Design Up-Front. Ellenlange Spezifikationen, die über (gefühlte) Äonen hinweg (quasi) auf Steintafeln erarbeitet wurden, bildeten die Grundlage dessen, was im nächsten IT-Zeitalter von Anwender:innenn verwendet werden sollte. Oftmals verloren sich die Unternehmen bei der Entwicklung des digitalen Gewerks in einer Art Innensicht. Man konzentrierte sich zum Zeitpunkt des Schreibens der Spezifikation auf innovative Technik, Unternehmensziele und eben betriebswirtschaftliche Effizienz. Was können wir in kurzer Zeit im Rahmen der vorhandenen Ressourcen und des Budgets anbieten? Manchmal, aber leider nicht allzu oft, konnte das Gewerk sogar noch mit einer ansprechenden grafischen Umsetzung ornamentiert werden. Bei allem Bestreben wurden die Nutzenden erst am Ende der Entwicklungszeit mit den Produkten oder Projekten in Berührung gebracht. Diese Herangehensweise resultierte häufig in Anwendungen, die eine tiefgreifende Einarbeitung und Schulung erforderten, da sie nicht intuitiv bedienbar waren und den Menschen, die damit letztendlich arbeiten sollten, nicht die Funktionalität boten, die von den Betroffenen von Anfang an erwartet wurde. Das Projektteam war glücklich, doch die Nutzenden blieben auf der Strecke.

Viele der schwerfälligen Bewohner des Cataractär haben sich evolutionsbedingt verändert und sahen sich mit den Neuerungen der Zeitalter des „Prä-Agilums“ und des anschließenden „Agilums“ konfrontiert. Wendigkeit und Reaktivität wurden jetzt bei der Projektleitung bzw. Produktentwicklung großgeschrieben. Zwei der bis in das heutige IT-Zeitalter noch vorherrschenden Entwicklungsäste waren das User-centered Design und das später folgende Human-centered Design (oft auch synonym verwendet), das sich hervorragend in die, diesmal nicht vom Autor erfundene, geochronologische Epoche des Anthropozän (altgriechisch: ἄνθρωπος (ánthropos), deutsch: Mensch und καινός: neu) eingefügt hat. Das Human-centered Design orientiert sich nicht in erster Linie an den Unternehmensinteressen und -kompetenzen, sondern stellt die Bedürfnisse, Fähigkeiten und Wünsche der Menschen in den Mittelpunkt. Produkte und Projekte entstehen (so der hehre Wunsch) in einem iterativen Prozess und in engem Austausch mit den späteren Nutzenden. Anmerkung: Was für die Digitalbranche neu war, ist im Produktdesign schon seit den 90er-Jahren des letzten Jahrtausends gängige Praxis. Unter den millisekundenbewussten Digitalschaffenden ist der nutzerzentrierte Ansatz erst in den vergangenen Jahren verstärkt in den Fokus gerückt.

Ok, alle Unklarheiten beseitigt? Diese geowissenschaftlich orientierte Einführung markiert den Punkt unseres aktuellen Schaffens und unserer aktuellen Bestrebungen, den Menschen im Mittelpunkt unseres digitalen Gewerks zu verorten. Anmerkung des Autors: Leider funktioniert noch nicht einmal das flächendeckend befriedigend, aber das ist eine andere Diskussion (#inclusivedesign #ethicaldesign #accessibility #wtfusability). Jetzt aber wieder zurück zu meinem Gedanken: Ist rein nutzerzentriertes Design eigentlich nicht ziemlich anmaßend in der heutigen Zeit?

Wohin uns der Anthropozentrismus gebracht hat, erfahren wir und die nachfolgenden Generationen am eigenen Leib. Dieses Jahr schon am 28. Juli begehen wir den Earth Overshoot Day [2], den Tag, an dem die Menschheit alle biologischen Ressourcen verbraucht hat, die die Erde im Laufe eines Jahres regeneriert. Ok, schlimm, aber da bekommen wir als hartgesottene Nachrichtenschauer doch noch nicht das Zähneklappern. Sollten wir aber! Denn wenn man die vorangehende Aussage in ein wenig anderes Szenario presst, sollte jedem von uns die wahre Tragweite dieses Tages bewusst sein. Stellen wir uns doch einmal die Erde als juristische Person vor, die vor allem an der Sicherung ihrer eigenen wirtschaftlichen Interessen interessiert ist. In einem solchen Szenario würde CEO Erde der Menschheit den Zugang zu ihren natürlichen Ressourcen, Trinkwasser, Atemluft, Nahrungspflanzen, Holz, Fisch, alles, was sie in biologischen Zyklen (aka Geschäftsjahren) produziert, mit sofortiger Wirkung gleich nach dem Überschreitungsdatum abschneiden und den Zugang erst im nächsten Jahr wieder freigeben. Dieses drastische Beispiel aus dem Artikel „Your next persona will be non-human – tools for environment-centered designers“ [3], lässt uns die Bedeutung dieses Tages ungleich besser verstehen.

Lange genug hat sich der Mensch als Mittelpunkt der weltlichen Realität verstanden, und das hat uns an den Punkt geführt, an dem wir heute sind: Klimakrise, Umweltverschmutzung nie dagewesenen Ausmaßes, Wasserknappheit … you name it! Der Designer Mike Montero fasst es treffend zusammen: „The world isn’t broken. It’s working exactly as it was designed to work. And we’re the ones who designed it. Which means we fucked up“ [4]

Umweltorientiertes Design

Heute stehen wir am Abgrund und morgen sind wir vielleicht einen entscheidenden Schritt weiter. Es ist an uns, damit zu beginnen, etwas dagegen zu tun, sowohl individuell als auch systematisch. Es sollte in unser aller Interesse sein, die Auswirkungen des Klimawandels zumindest abzuschwächen, die immer weiter zunehmende Wasserknappheit zu bewältigen und die Tragfähigkeit unseres Planeten auch für künftige Generationen zu sichern. Und ja, auch DevOps-, Frontend- und Backend-Entwickler:innen, Full-Stack- und UI-Designer:innen können einen Beitrag dazu leisten.

Wir brauchen eine neue Perspektive, aus der heraus wir verstehen, was für uns und für alle Lebewesen auf dem Spiel steht. Wenn unser Schaffen weiterhin nur Human-centered bleibt und die Bedürfnisse, Ansprüche und ökologischen Grenzen [5] unserer Umwelt bei der Gestaltung und Bereitstellung unserer Projekte, Produkte und Dienstleistungen nicht gleichwertig berücksichtigt und respektiert werden, fahren wir die Karre (oder eigentlich: den Planeten) an die Wand. Im Gegensatz zu den Digitalschaffenden haben fast alle Industriezweige bereits Richtlinien und Messwerte zur Umweltverträglichkeit etabliert. Auch die Instrumente und Methoden zur Berechnung dieser Messwerte sind standardisiert. Die Gruppe der Entwickler:innen und Webdesigner:innen ist zurzeit noch an keine spezifischen Umweltstandards gebunden, und das muss sich ändern. Es ist an der Zeit, uns Menschen nicht mehr als den Mittelpunkt von allem und jedem zu sehen, oder mit den berühmten Worten von Paul Simon als Host in Saturday Night Live „Why don’t you stop taking yourself so seriously for a while?“ [6].

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Wir brauchen einen neuen Design- bzw. Denkansatz. Weg vom benutzerzentrierten hin zum umweltzentrierten. Umweltorientiertes Design könnte eine praktikable Möglichkeit sein, dem Menschen seine Rolle als Teil der Umwelt und nicht als deren Krönung wieder bewusst zu machen. Das anthropozentrische Design vernachlässigt die Einbeziehung von Umwelt oder nichtmenschlichen Faktoren in den Design- und Managementprozess. Umweltorientiertes Design oder Environment-centered Design zielt darauf ab, diese Lücke zu schließen und dieses fehlende, aber wichtige Element in den Gestaltungsprozess zu integrieren.

In einem interessanten Artikel mit dem Titel „The time for Environment-Centered Design has come“ von Monika Sznel auf UX Collective [7] beschreibt die Autorin „Umweltorientiertes Design“ als „[…] einen Ansatz für die Produkt- oder Dienstleistungsentwicklung, der darauf abzielt, Produkte oder Dienstleistungen ökologisch, sozial und wirtschaftlich nachhaltig zu gestalten, indem er sich auf die Bedürfnisse, Einschränkungen und Präferenzen der menschlichen Zielgruppe und der nichtmenschlichen strategischen Interessengruppen konzentriert. Er umfasst Wissen und Designtechniken, die an der Schnittstelle von menschzentriertem Design, Benutzerfreundlichkeit, Ökologie und Nachhaltigkeitswissenschaft entwickelt wurden.“

Umweltzentriertes Design ist die nächste Evolutionsstufe des menschenzentrierten Designs. Es werden sowohl die menschlichen als auch die nichtmenschlichen Interessengruppen eines Produkts oder einer Dienstleistung von Anfang an in die Prozesse mit einbezogen. Umweltorientiertes Design befähigt alle Projektbeteiligten, innerhalb der Konzeption und der anschließenden Umsetzung der Lösungen sowohl die Bedürfnisse der Menschen als auch die der uns umgebenden Ökosysteme mit einzubeziehen. Seien es Tiere, Auswirkungen auf den Regenwald im Amazonas oder auf indigene Völker, die Fauna der Nordsee und, und, und … Umweltzentriertes Design schafft das befreiende Gefühl, sich als ein Teil von etwas Größerem zu verstehen und nicht als die Krone der Schöpfung. Vielmehr wird jedes Ökosystem gleichermaßen berücksichtigt. Weg von der Pyramide mit dem Menschen an der Spitze und hin zu einer Kreisform, mit dem Menschen als einer von vielen anderen Spezies auf diesem Planeten. Meines Erachtens eine realistischere Sichtweise auf die Welt.

Nichtmenschliche Personas

Als Teil der Spezies Mensch ist beziehungsweise sollte es ein Leichtes sein, sich in die Bedürfnisse der eigenen Gattung hineinzuversetzen. Aber wie schaue ich durch die Brille von Mutter Erde, des Bodens, des Waldes, des Ozeans oder gar eines Wals? Gegenfrage(n): Wie mache ich es denn bisher in meinem Projektalltag? Wie argumentiere ich bisher für eine Benutzergruppe? Welche Tools gibt es dafür? Wenn wir die Worte von Whitney Hess „Acknowledge that the user is not like you” bzw. „erkenne an, dass der Nutzende nicht wie du ist“ [8] bereits beherzigen, dann sind wir schon auf einem guten Weg. Was für uns offensichtlich ist, muss für jemand anderen nicht unbedingt offensichtlich sein. Unsere Denkprozesse und unser Verständnis der Umwelt sind stark kulturell, von unserer Erziehung und von unseren früheren Erfahrungen geprägt. Es ist sehr unwahrscheinlich, dass die Menschen, für die wir etwas designen oder entwickeln, alle unsere Eigenschaften haben.

Eine Möglichkeit dieses Statement von Whitney Hess (Anmerkung des Autors: Auch Josh Brewer hat den Spruch schon verwendet [9], es scheint also etwas dran zu sein) in einen Design- bzw. Entwicklungsprozess zu integrieren, ist die Verwendung von Personas [10]. Personas lassen uns durch ihre Brille schauen und ermöglichen es, Entscheidungen anhand ihrer Bedürfnisse und Ziele zu treffen. Valide und belastbare Personas zu erstellen war schon immer mit Arbeit verbunden, allerdings gut investierter Arbeit. Wer sagt denn, dass Personas immer menschlich sein müssen (das wäre schon wieder anmaßend)? Lasst uns doch aus den bekannten Menschengefilden ausbrechen und lernen, eine andere Perspektive einzunehmen. Die Designerin Monika Sznel hat eine dreiteilige Artikelreihe über das Thema „Environment-centered Design (ECD)“ verfasst, bei der sie sich auch Gedanken zur Verwendung nichtmenschlicher Personas [11] als Design- und Entscheidungstools macht.

Wie bereits beschrieben, ist es gar nicht so einfach, durch die Augen eines anderen (der gleichen Spezies) zu schauen und sich in dessen Gefühlswelt hineinzuversetzen. Jetzt sollen wir uns in einen Wald oder eine Landschaft hineinversetzen? Erfreulicherweise haben hierfür schon einige prominente Schauspieler eine nicht zu verachtende Vorarbeit für uns geleistet, die es uns erleichtert, Empathie mit unserer Umwelt zu empfinden und Inspiration für unsere nichtmenschlichen Personas zu finden. Auf der Website von Conservation International [12], einer Non-Profit-Organisation mit dem Ziel, die weltweite Biodiversität an Pflanzen, Tieren und Landschaftsformen zu erhalten, findet sich eine Rubrik Namens „Nature is Speaking“ [13]. Dort leihen Schauspieler:innen wie Julia Roberts, Harrison Ford, Reese Witherspoon, Edward Norton und viele andere nichtmenschlichen Entitäten wie dem Ozean, dem Boden, Mutter Natur und so weiter auf emphatische Weise ihre Stimmen. Es gibt auch eine deutsche Version [14] mit den Stimmen von Hannelore Elsner, Hannes Jaenicke, Marie Nasemann und anderen.

Wenn das nicht ein guter Start ist! Die nichtmenschlichen Personas sollen uns dabei helfen, das Umfeld, in dem sowohl unsere Zielgruppen als auch unsere Produkte und Dienstleistungen performen sollen, besser zu verstehen und frühzeitig Implikationen zu erkennen. Je besser die Wissensbasis, umso besser und authentischer die nicht-menschliche Persona. Dazu braucht es Fakten, Fakten, Fakten (an der Stelle sei übrigens das Buch „Factfulness“ [15] empfohlen, um faktenbasiertes und datengesteuertes Denken zu trainieren). Es bedarf der Analyse von Sekundärdaten und intensiver Eigenrecherche. Mögliche Quellen sind: Verschmutzungsstatistiken, Daten und Berichte seriöser Organisationen ohne politische oder wirtschaftliche Zugehörigkeit (z. B. UNO [16]), von unserem Unternehmen oder von uns selbst gesammelte Daten (z. B. der CO₂-Fußabdruck unseres digitalen Gewerks, Wasserverbrauch während des Produktionsprozesses oder die Menge an Energie, die benötigt wird, um den Betrieb der Software, des Büros und anderer notwendiger Infrastruktur sicherzustellen). Auch die Befragung von Vertreter:innen von Nichtregierungsorganisationen, die im Umweltbereich tätig sind, von Wissenschaftler:innen oder Kolleg:innen mit Fachwissen in einem bestimmten Bereich oder von faktenorientierten Aktivisten sind hervorragende Quellen zur Datensammlung und zur Vertiefung unseres umweltbezogenen Rucksackwissens.

Wie auch bei den echten Personas, müssen wir bei nichtmenschlichen Personas empirisch, ehrlich und authentisch bleiben und uns nicht dazu verleiten lassen, in Stereotypen, Unwahrheiten und Wunschvorstellungen zu verfallen. Wir benötigen belastbare Fakten zum tatsächlichen Zustand der jeweiligen Ökosysteme und ihrer Bewohner. Nur dann kann die NMP, die nichtmenschliche Persona, einen wirklich positiven und regulierenden Einfluss auf unsere Projekte und schlussendlich auf die Umwelt haben. Ich möchte dieses Format nicht als Tutorial „Wie bastele ich mir eine Persona?“ verwenden. Dazu gibt es reichlich Material, und das Netz liefert zusätzlich noch mannigfaltige Templates zur Erstellung von Personas. Aber ein paar Aspekte möchte ich an dieser Stelle schon ansprechen.

Allen Personatemplates ist gemeinsam, dass sie uns zuallererst mit der Persona visuell bekannt und vertraut machen. Hier lassen sich Dank des Internets viele Fotos unserer NMP finden. Gerne kann auch ein Urlaubsfoto aus dem eigenen Archiv herangezogen werden, was die Erfahrung mit der NMP meines Erachtens noch intensiver macht. Dem Bild folgend beschreiben wir unsere nichtmenschliche Persona und geben einen Einblick, was die Ursache für ihren derzeitigen Zustand ist und welche menschlichen Aktivitäten oder Schadstoffeinträge ihre Existenz bedrohen. Das ist durchaus vergleichbar mit der bekannten Personakategorie „Needs & Goals“ bzw. „Bedürfnisse und Ziele“. Ein überaus praktikables Stilmittel ist es hier (vgl. Julia Roberts als Mutter Erde [17]), der nichtmenschlichen Persona eine Erzählstimme zu geben (Icherzählung, Zitate). Wenn wir unsere NMP gebastelt haben, stellt sich die Frage, wie eine solche NMP eingesetzt werden könnte. Wer meine Artikel [18] und Vorträge [19] kennt, weiß, dass ich sehr häufig über den Ressourcenhunger des Internets und den Ausstoß an CO₂ unserer digitalen Gewerke rede. Bleiben wir also beim CO₂, aber ändern ein wenig die Perspektive.

Ein praktisches Beispiel

Stellen wir uns vor, dass wir eine Plattform für Klein- und Hobbygärtner:innen entwickeln, die europaweit operieren soll. Wir haben sowohl die Technik als auch die Vertriebskanäle unseres Portals gründlich durchdacht und schon ein paar Werbepartner für Gärtnerbedarf mit ins Boot geholt, die saisonal im großen Stil Blumenerde bewerben. Blumenerde ist ein essenzieller Bestandteil des Gärtners, sowohl im Garten wie auch auf dem Balkon und innerhalb der heimischen vier Wände. Im Frühjahr geht es meistens so richtig los und alle wollen raus in den Garten und auf den Balkon. Dann steigt natürlich die Nachfrage nach Blumenerde. Den wenigsten ist dabei bekannt, dass sich in den Plastiksäcken mit der Aufschrift „Erde“ größtenteils Torf befindet. Der Grundbaustein unserer Moore. Moore spielen eine wichtige Rolle für unser Klima. Sie sind effektive Kohlenstoffspeicher und Lebensraum für viele selten gewordenen Tier- und Pflanzenarten. Ihre Fähigkeit zum Speichern massenhafter Mengen an Kohlendioxid sucht ihresgleichen unter den anderen Ökosystemen des Planeten. Moore machen zwar nur drei Prozent der Erdoberfläche aus, dennoch speichern sie rund 30 Prozent des erdgebundenen Kohlenstoffs. Unter anderem nach Angaben des BUND und des Bundesumweltministeriums binden die Moore weltweit doppelt so viel CO₂ wie alle Wälder zusammengenommen. „Jeder Hektar geschütztes Moor spart jährlich rund neun Tonnen CO₂ ein, knapp so viel, wie jeder von uns im Durchschnitt pro Jahr verursacht“, so Michael Zika, WWF-Naturschutzexperte. Weiterhin ist es wichtig zu erwähnen, dass Moore zu 95 Prozent aus Wasser bestehen und dadurch bedeutsame Wasserspeicher sind. Sie helfen dabei, die Wucht von Überschwemmungen zu kompensieren und Flutkatastrophen zu verhindern. Aus diesem Grund sind intakte Moore für den Klimaschutz von zentraler Bedeutung. Ihre Zerstörung verursacht volkswirtschaftliche Schäden in Millionenhöhe. Der Bedarf an Torf im Gartenbau ist riesig. Die Mehrheit aller Setzlinge im professionellen Gartenbau, aber eben auch im Hobbygartenbau, wächst heute noch auf Torferde heran. Ohne es zu wissen, tragen viele Hobbygärtner:innen dazu bei, dass unwiederbringliche Moorlandschaften verloren gehen.

Da in Deutschland der Torfabbau am Auslaufen ist und nur auf landwirtschaftlich vorgenutzten Flächen erlaubt ist, also von Mooren, die bereits vor vielen Jahren trockengelegt wurden, werden große Mengen Torf verstärkt aus den baltischen Staaten importiert, wo der Schwund der Moore rasant voranschreitet. Woher der Torf kommt, der in der durchschnittlichen Blumenerde verarbeitet wird, ist für die Verbraucher:innen bzw. die Besucher:innen unseres Gärtnerportals kaum oder gar nicht zu ersehen. Sicher ist nur, dass dafür wertvolle Moore zerstört werden. Allein in Deutschland sind trockengelegte Moore für geschätzt zwei bis drei Prozent der CO₂-Emissionen verantwortlich. Mehr, als alle Windräder in Deutschland einsparen können, aber wie wir wissen, ist Klimaschutz eine globale Anstrengung. Jetzt mal Hand aufs Herz: Hätten wir uns beim Erstellen eines Gärtnerwebportals über so etwas je Gedanken gemacht? Hätte das für uns eine Rolle gespielt bei der Konzeption des Projekts? Anhand einer NMP wie eines Hochmoors könnten wir die Auswirkungen auf das Ökosystem durchgehen und sie uns ins Bewusstsein rufen. Allein die Recherche für unsere NMP konfrontiert uns mit den Implikationen der Thematik und zwingt uns dazu, eine gesamtheitliche Einordnung des Projekts im Kontext Klima und Umwelt vorzunehmen. Also, was ist gerade passiert? Wir als Digitalschaffende, die doch gar nichts mit Mooren im eigentlichen Sinne zu tun haben, haben in diesem fiktiven Beispiel unsere Verantwortung gegenüber diesem Ökosystem aufgedeckt! Wir haben eine Implikationskette aufgestellt, die eine direkte Beziehung mit unserem Handeln und unserem Gewerk etabliert.

Verantwortung und TORTE

Auch wir im digitalen Sektor tragen Verantwortung an der Entwicklung des Planeten und unserer Umgebung. Nur weil Software bzw. das Internet keinen Auspuff hat, heißt das noch lange nicht, dass es keine negativen Auswirkungen auf die Umwelt hat. Ein weiteres Zitat des Designers Mike Monteiro fasst es sehr treffend zusammen: „We’re no longer pushing pixels around a screen. We’re building complex systems that touch people’s lives, destroy their personal relationships, broadcast words of both support and hate, and undeniably mess with their mental health.“ [4]

Aber nicht nur die psychischen Folgen unseres Handels für den Menschen müssen in unserem Arbeitsalltag stärker Beachtung finden, sondern auch die Implikationen für das Klima und für die Umwelt. Das obige Beispiel ist konstruiert, das gebe ich zu. Aber es zeigt, zu was wir fähig sind, wenn wir uns bewusst mit einer Sache beschäftigen, eben nicht nur technisch. Wir müssen weg von unserem ego- bzw. anthropozentrischen Weltbild und uns wieder als Teil eines Ökosystems verstehen, das leider zurzeit besser ohne uns als mit uns könnte. Ich möchte diese Ausgabe der Kolumne definitiv nicht so pessimistisch enden lassen, sondern eher zum pragmatischen Optimismus animieren. Wir können etwas machen und wir alle können unseren Beitrag dazu leisten, indem wir unseren Horizont erweitern und Produkte und Projekte mit Empathie für die nutzenden Menschen wie auch unsere Umwelt gleichermaßen angehen.

Als Autor des TORTE-Frameworks für Green Webdesign (Testen, Optimieren, Reduzieren, Thematisieren und Engagieren) [20] ermuntere ich Designer:innen, Entwickler:innen und Projektverantwortliche in Vorträgen und Artikeln dazu, TORTE in den Softwareentwicklungsprozess zu integrieren, um nachhaltige Softwarelösungen in die Welt zu entsenden, Green Webdesign bzw. Green Code ins Bewusstsein zu rufen und Nachhaltigkeit zu einem Designprinzip zu machen. Daher hier eine kleine Empfehlung: NMPs lassen sich hervorragend in der Rubrik Testen verorten und erlauben uns einen holistischen Blick auf ganze Ökosysteme statt einzig auf die vermeintliche Krone der Schöpfung, den Menschen. Vielleicht stellt ihr eure nächste Persona ja mit den Worten vor: „Ich bin Gaia, 4,5 Milliarden Jahre alt und Ursprungsort und Heimat aller bekannten Lebewesen …“

Links & Literatur

[1] https://uxdesign.cc/how-user-centered-design-might-be-holding-you-back-535311d64236

[2] https://www.umweltbundesamt.de/themen/erdueberlastungstag-ressourcen-fuer-2022-verbraucht

[3] https://uxdesign.cc/your-next-persona-will-be-non-human-tools-for-environment-centered-designers-c7ff96dc2b17

[4] Monteiro, Mike: „Ruined by Design: How Designers Destroyed the World, and What We Can Do to Fix It“; Mule Books, 2019

[5] https://www.wired.com/2009/09/earth-users-guide

[6] http://snlarchives.net/Episodes/?197611202

[7] https://uxdesign.cc/the-time-for-environment-centered-design-has-come-770123c8cc61

[8] https://whitneyhess.com/blog/2009/11/23/so-you-wanna-be-a-user-experience-designer-step-2-guiding-principles/

[9] https://52weeksofux.com/post/385981879/you-are-not-your-user

[10] https://xd.adobe.com/ideas/process/user-research/putting-personas-to-work-in-ux-design

[11] https://uxdesign.cc/your-next-persona-will-be-non-human-tools-for-environment-centered-designers-c7ff96dc2b17

[12] https://www.conservation.org

[13] https://www.conservation.org/nature-is-speaking

[14] https://www.conservation.org/nature-is-speaking/german

[15] https://www.gapminder.org/factfulness-book

[16] https://www.unep.org/resources/report/action-plan-sustainable-planet-digital-age

[17] https://www.conservation.org/nature-is-speaking/julia-roberts-is-mother-nature

[18] https://entwickler.de/reader/reading/windows-developer/03.2022/c0e3b1ca2c5e949b9bec02d1

[19] https://webinale.de/web-design-development/muell-hat-3r-und-websites-haben-torte

[20] https://www.informatik-aktuell.de/management-und-recht/digitalisierung/green-webdesign-oder-frontendsforfuture-i.html

The post Umweltorientiertes Design appeared first on webinale 2025.