Wie fügt man eine neue Funktion zu CSS hinzu? Man könnte sich auf Twitter darüber beschweren und einfach darauf hoffen, dass jemand vom Standardisierungsgremium sich des Anliegens annimmt – und voilà, in ein paar Jahren ist das benötigte Feature vielleicht verfügbar. Oder: Man schreibt selbst einen JavaScript-Polyfill, der aber nicht sonderlich leistungsfähig ist.

CSS ist halt irgendwie auch „magisch“. Wird ein einziger Style verändert, kann das die gesamte Webseite beeinflussen oder den Code beschädigen, sodass Vorsicht angeraten ist. Mit CSS Houdini können Entwickler nun aber ihre eigene „Magie“ erschaffen. Denn durch das Einklinken in die Renderingphasen des Browsers können neue Funktionen zu CSS hinzugefügt und dem Browser so einige neue Tricks beigebracht werden.

Wie funktioniert das Rendering?

Browser haben normalerweise vier Hauptphasen in ihrer CSS-Rendering-Pipeline (Abb. 1). Um die CSS-Stufen zu verstehen, muss mit den Styles begonnen werden. Hier sammelt der Browser alle Stylesheets, die sich im Dokument befinden, und findet dann heraus, welches Element von welchem dieser Styles betroffen ist. Sobald der Browser weiß, wie groß die Elemente sind und an welcher Position sie gerendert werden sollen, beginnt er, die leeren und transparenten Felder auf der Seite anzuordnen. Im nächsten Schritt kann der Browser einfach das Layout der Seite übernehmen und die Pixel „malen“. Dabei handelt es sich in der Regel um Text, Farben, Bilder, Rahmen, Hintergründe usw. Das Malen erfolgt auf mehreren Oberflächen, die als Ebenen bezeichnet werden. Sobald dieser Malprozess fertig ist, werden alle Ebenen an den Compositor übergeben. Der Compositor fügt sie auf der Seite, die wir sehen, zusammen. Wenn sich etwas auf einer eigenen Ebene befindet, können diese Ebenen verschoben und so Animationen erstellt werden.

Abb. 1: Renderingschritte im Browser

Was ist Houdini?

Harry Houdini war ein berühmter Illusionskünstler. Er ist die Inspiration für die Namensgebung dieses CSS API. Houdini ist ein Standard in der CSS-Arbeitsgruppe im W3C (World Wide Web Consortium), um besseren Zugang zur CSS Engine des Browsers zu erhalten und mehr Kontrolle darüber zu haben, wie eine Seite aussieht oder gerendert wird. Mit Houdini kann dem Browser beigebracht werden, Farben oder Layout zu verarbeiten. Das erlaubt es Entwicklern, Layouteffekte, Rahmen, Hintergründe, Bilder oder andere Dinge zu erstellen, die derzeit in CSS nicht möglich sind. Außerdem müssen weniger Polyfills und JavaScript-Abhängigkeiten geschrieben werden und es können reine CSS-Polyfills verfasst und so neue CSS-Funktionen geschaffen werden, ohne darauf warten zu müssen, dass diese nativ im Browser implementiert werden. Damit sind kontinuierliche Verbesserungen möglich.

Houdini ist noch in der Entwicklungsphase, aber die Beschäftigung damit erlaubt einen Einblick in die Entwicklung von CSS und was die Zukunft dahingehend noch bereithält. Zum Zeitpunkt der Erstellung dieses Artikels wurden drei der Houdini APIs in Chromium-basierten Browsern ausgeliefert. Ein aktueller Status findet sich auf der Webseite https://ishoudinireadyyet.com/ (Abb. 2). Ein detaillierter Blick auf diese drei APIs lohnt sich, da sich die anderen APIs möglicherweise noch massiv verändern werden. Alle in diesem Artikel erwähnten Beispiele sind ausführbar, wenn das Chrome-Flag-Experimental-Web-Platform-Feature aktiviert ist oder der Polyfill für CSS Paint hinzugefügt wurde.

Abb. 2: Übersicht auf ishoudinireadyyet.com

Properties and Values API

Um das Properties and Values API zu verstehen, wird im Folgenden eine Schaltfläche mit linearen Farbverläufen animiert, die mit CSS-Variablen definiert wurden.

Abb. 3: Button mit animiertem Farbverlauf

Wenn das in Abbildung 3 gezeigte Stück Code ausgeführt wird, kann man sehen, dass die Schaltfläche nicht fließend in die einzelnen Farben übergeht, sondern dass es einen abrupten Farbwechsel gibt. CSS-Variablen sind praktisch und dynamisch, aber sie können nicht animiert werden. Warum ist das so? Der Browser parst CSS-Variablen immer als Strings. So weiß man nicht, ob eine gegebene Variable eine Farbe oder eine Größe in Pixeln ist. Es gibt also keine semantische Bedeutung für die Variablen. Das Properties and Values API von Houdini bietet die Möglichkeit, einen Typ für CSS-Variablen zu definieren (Abb. 4), und ermöglicht eine direkte Integration mit dem Parser.

Abb. 4: Custom Property mit Houdini

Damit die Animation funktioniert, muss die CSS-Variable mit dem registerProperty API registriert werden. Auf diese Weise wird sie mit Daten angereichert, typisiert und hat nun eine semantische Bedeutung.

Typed Object Model (Typed OM) API

Von allen Houdini APIs hat das Typed OM API den größten Einfluss auf das Tagesgeschäft des Entwicklers. In den guten alten Zeiten wurde getComputedProperty verwendet, um den Stil eines beliebigen DOM Node zu erhalten, wie Abbildung 5 zeigt.

Abb. 5:getComputedProperty

Typed OM gibt ausführliche Informationen über eine Eigenschaft in typisierter JavaScript-Darstellung – mit Wert und Einheit. Das ermöglicht Verbesserungen bei der Performance, da der Browser CSS auf eine strukturiertere Weise versteht und nicht mehr alles von Grund auf tokenisieren muss. So sind berechnete Styles einfach zu lesen und zu analysieren. Typed OM kümmert sich auch um das Fehlerhandling, da die Typen der Elementstyles definiert sind: Wenn ein Entwickler versucht, einem längenbezogenen Attribut einen Farbwert zuzuweisen, wird vom Typed OM ein Fehler angezeigt. Das Rätselraten, ob es sich bei den Namen um Camel Case oder Strings handelt (z. B. el.style.backgroundColor vs el.style[‘background-color’]), hat damit ein Ende. CSS-Eigenschaftsnamen in Typed OM sind immer Strings und entsprechen dem, was auch tatsächlich in CSS geschrieben wird (Abb. 6).

Abb. 6: Typed OM

Außerdem kann typisiertes CSS mit Type-APIs erstellt werden – und Styles können erstellt, gelesen, aktualisiert oder von einem Element gelöscht werden. Es fügt auch weitere funktionale Programmierkonzepte hinzu, wie beispielsweise das Aufrufen von Funktionen innerhalb anderer Funktionen.

Paint API

Geht man einen Schritt weiter und betrachtet ein API auf höherer Ebene, beinhaltet dieses Paint API ein Worklet. Ein Worklet ist von einem Worker zu unterscheiden: Alle Worklets sind Workers, aber nicht alle Worker sind Worklets. Worklets sind vielmehr spezifische Worker. Der Browser verfügt über eine Ereignisschleife, die Ereignisse verarbeitet. Immer wenn ein Ereignis eintritt, prüft die JavaScript Engine, ob es einen Handler für dieses Ereignis in der Codebasis gibt. Sie nimmt den Code für diesen Handler und stellt ihn in eine Warteschlange. Einfach ausgedrückt nimmt die Ereignisschleife bei jeder Umdrehung etwas aus der Warteschlange und führt es aus. Ein Worker ist eine separate Ereignisschleife mit isoliertem Bereich, eigenen Ereignissen und Handlern. Der Aufwand, eine Ereignisschleife zu erstellen und zu pflegen, ist allerdings groß, weshalb nicht einfach Hunderte von Workern zur gleichen Zeit erstellt werden können.

Worklets sind ebenfalls isolierter JavaScript-Code mit eigenem Gültigkeitsbereich, aber sie haben keine Ereignisschleife, sondern hängen sich an eine bereits vorhandene Ereignisschleife. Das macht sie billiger in der Erstellung und Wartung – und es können mehrere Worklets an eine Ereignisschleife angehängt werden. Da die meisten Worklets zustandslos sind, können sie während ihrer Lebensdauer in eine andere Ereignisschleife migriert werden. Ein Worklet ist ein in sich geschlossenes Modul, das eine fertige Arbeitsoberfläche herstellt und neben dem Haupt-Thread laufen kann. Es ist sozusagen eine Klasse, die eine bestimmte Schnittstelle implementiert, damit sie ein Element anpassen kann. Es gibt also einen formalen API Handshake zwischen dem Browser und dem Worklet.

Dieses API ermöglicht es Entwicklern, benutzerdefinierte Funktionen zu bestimmen, die in CSS direkt als Hintergründe, Rahmen, Masken und mehr verwendet werden können. Der Browser leitet die Anfrage, die er von CSS erhält, an das entsprechende Houdini Worklet weiter – eine Erweiterung für den Paint-Rendering-Schritt des Browsers, in dem die visuellen Eigenschaften (Farbe, Hintergrund, Rahmen etc.) bestimmt werden. Das Worklet läuft auf einem eigenen Thread, der den Haupt-Thread entlastet und ihn für andere Dinge freihält.

Im Folgenden wird die in Abbildung 7 gezeigte Wellenlinie, die im nativem CSS nicht existiert, mit dem Houdini Paint API erstellt.

Abb. 7: Wellenlinie

Der erste Schritt ist das Schreiben des Worklet. Um ein Paint Worklet zu schreiben, muss man wissen, wie das Canvas API verwendet werden kann, dank dem man etwas auf der Seite zeichnen kann. Das Paint Worklet ist eine Klasse, die eine Paint-Funktion enthält. Es wird eine Datei namens curved-line.js erstellt (Abb. 8). Dieses Codestück demonstriert, wie man die Wellenlinie zeichnet. Zu beachten ist dabei, dass am Ende der Datei die Paint-Klasse mit der Funktion registerPaint registriert wird. Sie akzeptiert nicht nur die Paint-Klasse, sondern auch eine Zeichenkette. Innerhalb einer CSS-Datei kann dieser String verwendet werden, um das Worklet aufzurufen (Abb. 9). Ein Paint-Worklet-Modul muss im Skript enthalten sein (Abb. 10), damit das CSS weiß, wo dieses hinterlegt ist.

Abb. 8: Paint Worklet

Abb. 9: Paint Worklet aufrufen

Abb. 10: Worklet im Skript

NOCH MEHR ZU WEB DESIGN?

Der Web Design & Development Track

Mehr erfahren

Mit diesem Worklet wird überall dort, wo ein <hr />-Element verwendet wird, eine gebogene Linie gezeichnet. Ein Paint Worklet kann durch die Verwendung von CSS-Variablen noch leistungsfähiger und dynamischer gemacht werden. Das kann über das dritte Argument der Paint-Funktion des Worklet geschehen, das in Abbildung 11 zu sehen ist. Mit lineHeight, lineWidth, lineColor und lineSpread (Abb. 12) können geschwungene Linien in jedem Element des DOM dynamisch gestylt werden.

Abb. 11: Argumente der Paint-Funktion

Abb. 12: Code für individuelle Linien

Layout and Animation APIs

Die Layout and Animation APIs befinden sich noch im experimentellen Stadium. Das Layout API ermöglicht es Entwicklern, ihre eigenen Algorithmen zu schreiben. Im Grunde könnte ein Entwickler damit einen eigenen Layoutalgorithmus wie Flexbox oder Grid erstellen. Er wird dann als Teil des Layoutschrittes im Rendering-Flow ausgeführt.

In ähnlicher Weise bietet das Animation API eine Möglichkeit, die Timing-Funktionen einer Animation zu manipulieren. Dieses API hilft Entwicklern im Wesentlichen beim Schreiben von Parallaxenanimationen oder beliebigen Keyframe-Animationen, die außerhalb des Haupt-Threads arbeiten sollen. Es wird als Teil des Composite-Schritts im Rendering-Flow ausgeführt.

Fazit

Houdini ist so leistungsstark und effizient, sodass es nicht übertrieben ist, es als die „Zukunft von CSS“ zu bezeichnen. Houdini bietet nützliche APIs, um die CSS-Logik von der JavaScript-Logik zu trennen, was eins der kniffligsten Probleme im Web angeht: die Separation of Concerns. Durch die Ermöglichung von Worklets, die nichts anderes als kleine, unabhängige Module sind, wird der gesamte Prozess des Schreibens von CSS-Funktionen leicht wiederverwend- und teilbar.

Houdini eröffnet eine ganze Welt von Möglichkeiten im Web. CSS-Funktionen, die bisher als extrem komplex und nicht performant galten, scheinen mit nur einer Handvoll CSS möglich zu sein. Es ist bemerkenswert, zu sehen, wie Entwickler auf der ganzen Welt mit Houdini experimentieren. Hier einige erstaunliche Beispiele von Houdini-API-Experimenten aus der Community: https://css-houdini.rocks/, https://houdini.how/, https://github.com/GoogleChromeLabs/houdini-samples

The post Houdini: Hausgemachte CSS-Magie appeared first on webinale 2025.

Gerade bei dem Relauch einer neuen Webseite oder einer neuen Version einer Webapplikation hat man oft erst kurz vor dem Relaunch eine Applikation zur Verfügung, die vollständig genug ist, um einen Lasttest durchzuführen. Der Einfachheit halber und weil man oft nicht von vornherein Zeit dafür eingeplant hat, wird dann oft auf einfache Tools wie ab (Apache Benchmark) oder siege zurückgegriffen. Beide Tools erlauben es, einen einzelnen URL oft und parallel aufzurufen und geben einem eine erste Indikation für die Antwortzeiten einer Webseite. Das Resultat beider Tools sind einfache Zahlen, die sich gut kommunizieren lassen: Requests pro Sekunde sowie minimale, maximale und durchschnittliche Antwortzeit.

Ich rate allerdings in den meisten Fällen davon ab, diesen verführerisch einfachen Weg zu gehen. Keines der Probleme, die ich mit realistischen Lasttests bei Kunden gefunden habe, wäre damit aufgedeckt worden, und die genannten Zahlen haben nur eine begrenzte tatsächliche Aussagekraft. Das Gleiche gilt für die Probleme, die einen gescheiterten Relaunch verursacht haben. Auf der anderen Seite konnte ich bislang durch Lasttests zu 100 Prozent sicherstellen, dass die erwartete Last durch die getestete Webseite bewältigt wurde. Wie genau kann man das also erreichen?

Realistische Nutzerszenarien

Der erste und wahrscheinliche wichtigste Aspekt sind realistische Nutzerszenarien. Dazu stellt man sich die Frage, wozu die Webseite verwendet wird, was also Besucher üblicherweise auf der Webseite an Aktionen durchführen und in welchem Mengenverhältnis diese Aktionen zueinander stehen. Am Beispiel eines Onlineshops könnten das zum Beispiel die folgenden Szenarien sein:

• Anonymer Random-Browser
• Anmeldung eines Neukunden
• Eingeloggter Random-Browser
• Check-out eines gefüllten Warenkorbs

Dazu können je nach Onlineshop weitere relevante Nutzerszenarien kommen, wenn zum Beispiel beliebte Konfiguratoren existieren oder Merkzettel eine wichtige Rolle spielen. Zu jedem Szenario sollte dazu bekannt sein, wie hoch der Anteil dieses Szenarios am gesamten Traffic der Webseite ist. Diese Zahlen sind manchmal schwer abzuschätzen, weil man die Nutzerverhalten nach einem Relaunch, einer neuen Webseite oder auch während einer Werbekampagne nicht unbedingt perfekt einschätzen kann. Das Verwenden bisheriger Zahlen oder von üblichen Zahlen aus dem eigenen Geschäftsbereich liefert meist aber eine ausreichend genaue Abschätzung.

Warum diese Szenarien?

Der primäre Grund für realistische Szenarien ist Caching. Damit ist nicht nur eigenes Caching in der Webapplikation oder in Reverse Caching Proxies (varnish, nginx) gemeint, sondern auch das Caching verschiedenster Layer, die man nicht direkt unter Kontrolle hat, wie Datenbankserver, Opcode-Caches oder auch Kernel-Caches. Wenn, wie bei ab und siege, immer wieder eine kleine Zahl gleichbleibender URLs aufgerufen wird, können all diese Layer sehr einfach und effizient die entsprechenden Daten im Speicher vorhalten. Leider entspricht dieses Verhalten nicht dem zu erwartenden Verhalten durch echte Nutzer, sodass diese Tests keine Aussagekraft besitzen.

Wenn man sich die einfache schematische Darstellung eines Onlineshops in Abbildung 1 anschaut, besteht ein solcher Shop heute aus vielen Komponenten, die häufig ihre eigenen Cachelaufzeiten und -kontexte besitzen. Während Kopfzeile und Navigation oft vergleichsweise statisch sind, ändern sich Kommentare, wenn sie freigegeben werden, Produktbeschreibungen, wenn neue Daten aus dem ERP kommen, und der Produktbestand, wenn Produkte verkauft werden. Elemente wie der Warenkorb hängen sogar direkt an dem Nutzer und werden meist gar nicht gecacht.

Oft werden entweder Reverse Caching Proxies mit Edge-side Includes (ESI) eingesetzt, um solche einzelnen Bestandteile zu cachen, oder dies findet in der Webapplikation direkt statt. Selbst wenn all das nicht der Fall ist, cachen Datenbankserver gleiche Queries, oder der Kernel cacht Anfragen an immer gleiche Dateien. Die Berechnung oder Neuberechnung eines Inhalts ist jedoch genau die Aktion, die am meisten Ressourcen auf dem Server kostet, damit den größten Effekt auf die Last der Systeme hat und entsprechend in einem möglichst realistischem Maß simuliert werden muss.

Aus diesem Grund werden Szenarien wie die obigen entworfen und müssen parallel und mit verschiedenen Nutzern und Sessions ausgeführt werden. Dadurch werden dann in allen Systemen Cache Misses verursacht, Caches neuberechnet und eventuelle Cache-Hits sinken auf ein normales Maß.

Anzahl der Aufrufe

Wenn man die Nutzerszenarien kennt, muss man noch wissen, in welcher Anzahl man sie parallel laufen lässt. Grundsätzlich gibt es natürlich die Möglichkeit, die Anzahl an parallelen Nutzern so lange immer höher zu setzen, bis die eigenen Server unter der Last zusammenbrechen. Wirtschaftlich sinnvoller ist jedoch meist, zu verstehen, wie viele Nutzer erwartet werden, um dann die Server daraufhin zu optimieren. Dabei muss beachtet werden, dass die Nutzer bei den meisten Webseiten nicht gleichverteilt über den Tag kommen, sondern es spezifische Kernzeiten gibt, die simuliert werden sollten.

Wenn in einem deutschen Onlineshop mit einer Kernzeit von 18:00 bis 22:00 Uhr zum Beispiel nur bekannt ist dass es 240 000 Page Impressions (PI) pro Tag gibt, sollten wir nicht anpeilen, 10 000 PI/Stunde (1 Request/Sekunde) zu simulieren, sondern wahrscheinlich eher 40 000 PI/Stunde (3 Requests/Sekunde). Wegen fehlender Gleichverteilung im normalen Nutzerverhalten ist man in diesem Fall mit einer Simulation von 5 Requests/Sekunde wahrscheinlich auf der sicheren Seite. Im optimalen Fall stehen Access-Logs zur Verfügung, mit deren Hilfe man nicht nur die sinnvolle Anzahl von Anfragen pro Sekunde herausfindet, sondern gleichzeitig auch die Verteilung auf die einzelnen Nutzerszenarien.

JMeter

Es gibt mittlerweile mehrere Tools und Frameworks, die abseits von ab und siege sinnvolle Lasttests anhand von realistischen Nutzerszenarien durchführen können. Schon lange auf dem Markt, frei verfügbar, Open Source und funktional sehr vollständig ist Apache JMeter [1]. Auch wenn die Erstellung der Nutzerszenarien im Normalfall über ein gewöhnungsbedürftiges Userinterface stattfindet, ist das meiner Meinung nach immer noch das sinnvollste Tool, um größere und realistische Lasttests durchzuführen. JMeter erlaubt die automatische Fernsteuerung von Tests, kann Cluster von Servern nutzen, um die notwendige Last zu erzeugen (was selten notwendig ist), und implementiert alle nur denkbaren Protokolle neben HTTP(S), um auch besondere Webapplikationen testen zu können. Über das Userinterface wird lediglich eine XML-Konfiguration des Testszenarios erzeugt, die dann auf anderen Servern beliebig abgespielt werden kann, versionierbar ist und auch über verschiedene Versionen von JMeter funktioniert. Gewöhnen muss man sich zu Beginn an die Bezeichnungen für die einzelnen Konzepte – allerdings hat sich gezeigt, dass sich darüber sinnvolle und wiederverwendbare Tests erstellen lassen:

• Thread Group: Eine Thread Group ist genau ein Nutzerszenario, wie es oben beschrieben wurde. So kann es zum Beispiel eine Thread Group „Random Surfer“ geben, in
  der wir einen Suchmaschinen-Bot oder einen nicht angemeldeten Nutzer simulieren.
• Timer: Ein Timer definiert die Abstände zwischen mehreren Aktionen in einer Thread-Group. Das ist wichtiger, als man zunächst denkt, denn echte Nutzer warten nicht
  immer den exakt gleichen Zeitraum zwischen zwei Klicks ab. Üblicherweise verteilen sich die Klickintervalle von Nutzern in einer gaußschen Normalverteilung um einen definierten
  Wert. Genau dafür gibt es dann in JMeter auch einen konfigurierbaren Gaussian Timer.
• Configuration Elements: Über Konfigurationselemente werden Daten bereitgestellt. Das kann ein Cookiemanager sein oder Beispieldaten aus eines CSV-Datei, um JMeter
  im Testsystem existierende Nutzerdaten für Log-ins zur Verfügung zu stellen.
• Sampler: Die Sampler führen auf Basis der zuvor genannten Elemente die tatsächlichen Anfragen aus. Bei Webseiten sind das normalerweise HTTPS-Anfragen. JMeter
  unterstützt allerdings auch FTP, SOAP und viele weitere Protokolle.

Mit diesen Elementen lassen sich problemlos auch komplexere Interaktionen wie auszufüllende Formulare oder XMLHttpRequest-basierte Webseiteninteraktionen vollständig simulieren. Relativ einfache und übliche Aufgaben wie das Nachladen von Bildern und anderen Assets oder das Management von Session-Cookies für einzelne Nutzer übernimmt JMeter dabei von sich aus. Eine Interpretation von JavaScript auf der Webseite und die dadurch theoretische automatische Simulation der Nutzung einer Single Page Application unterstützt es aber nicht. Dafür kann man JMeter problemlos clustern, so auch sehr hohe Last generieren und die Resultate sinnvoll aggregieren.

Richtig messen

Zu Beginn wurde davon gesprochen, dass ab und siege einfache und gut zu kommunizierende Zahlen wie Requests pro Sekunde und die durchschnittliche Antwortzeit liefern. Das tut JMeter natürlich auch, aber die Aussagekraft dieser Zahlen ist eher begrenzt. Als aussagekräftiger sehe ich an:

• Fehlerraten: Die Anzahl der Fehler (Statuscode ≥ 500), die einzelne Systeme zurückgeben. Gerade unter hoher Last treten diese oft verstärkt auf und erfordern dann
  eine detailliertere Analyse.
• 95 % Percentile: Als 95 % Percentile wird die Antwortzeit bezeichnet, unter der 95 Prozent aller Antworten lagen. Diese Zahl ist wesentlich relevanter als der
  Durchschnitt aller Antwortzeiten, weil sie eine Abschätzung liefert, wie lange Nutzer tatsächlich warten müssen, und einzelne Ausreißer (Minimum, Maximum) besser ignoriert.
  Zusätzlich werden häufig noch weitere Percentiles wie 50 Prozent, 90 Prozent, 98 Prozent und 99 Prozent betrachtet. Diese lassen sich aus den von JMeter gelieferten Daten korrekt
  berechnen.
• Requests pro Sekunde: Die Requests pro Sekunde betrachten wir eigentlich nur, um festzustellen, ob die avisierte Menge an Anfragen tatsächlich von uns im Lasttest
  erreicht wurde.

Neben diesen Statistiken kommt beim Messen noch ein weiterer entscheidender Punkt hinzu: Wir wollen normalerweise nicht nur wissen ob die Webseite die Last aushält, sondern auch, welche Systeme auf welche Weise an ihre Grenzen kommen.

In Abbildung 2 ist schematisch und vereinfacht eine übliche Serverlandschaft von Webapplikationen zu sehen. An allen relevanten Schnittstellen und auf allen Systemen sollten wir versuchen zu messen, wo die jeweiligen Flaschenhälse sind. Der Netzwerkdurchsatz lässt sich meist einfach mit ifstat oder iftopüberwachen. Die wichtigsten Systemmetriken, wie Speicherauslastung, IO-Wait und Systemlast bekommt man über vmstat. Von externen Systemen will man zumindest die Antwortzeiten messen, wenn man nicht Monitoringlösungen wie Tideways[2] einsetzt, die das für PHP-Code sowieso tun. Je nach Service will man dazu eventuell noch weitere dezidierte Monitoringlösungen wie Tideways, New Relic oder App Dynamics einsetzen.

Wenn man all diese Daten zusammen analysiert hat, kann man in den allermeisten Fällen schon sehr genau auf die Ursachen eventueller Performanceprobleme schließen. Dazu kann es sich lohnen, eigene Experten aus Operations und Entwicklung zusammenzusetzen oder externe Experten hinzuzuziehen.

Tipps und Tricks

Externe Services werden in Abbildung 2 zum ersten Mal erwähnt, und natürlich sollten hier auch die Antwortzeiten unter Last beobachtet werden. Unter externen Services verstehen wir einfache Komponenten wie Mailer, aber auch externe oder eigene Web Services (Microservices), die in die eigene Applikation integriert sind. Bei externen Web Services sollte man die Betreiber auf jeden Fall über einen bevorstehenden Lasttest informieren. Es wäre nicht das erste Mal, dass ein Lasttest der eigenen Systeme einen verwendeten externen Web Service in die Knie zwingt.

Eine andere Option ist das Deaktivieren (Mocken) externer Services während eines Lasttestlaufs. Das kann aus Kostengründen manchmal sinnvoll sein, allerdings ist die Information, ob externe Services die zu erwartende Last aushalten, natürlich auch extrem wichtig für den späteren Betrieb.

Als Hardware während eines Lasttestlaufs sollte in jedem Fall die echte, später produktiv verwendete Hardware für die Webapplikation verwendet werden. Ein Docker-Container oder eine virtuelle Maschine verhalten sich unter Last komplett anders, als es ein Server bei Amazon S3 oder ein Bare-Metal-Server tun. In PHP-Applikationen ist häufig die IO-Wait (warten auf die Festplatte) einer der Flaschenhälse. Gerade virtualisierte Dateisysteme verhalten sich aber genau ganz anders als es echte tun, die auf echten Festplatten oder SSDs operieren.

Die Hardware und die Anbindung der Testserver, also der Server, auf dem zum Beispiel JMeter läuft, ist ebenfalls relevant. Wenn nicht die Netzanbindung des Hosters getestet werden soll, raten wir normalerweise dazu, Testsysteme im gleichen Rechenzentrum wie die Systeme zu stellen, die unter Last gesetzt werden. Primär sorgt es dafür, dass sich die Last zuverlässig simulieren lässt, ohne dass eventuell die Testsysteme durch die DDOS-Erkennung (Distributed Denial of Service) des Hosters blockiert werden. Sekundär ist das auch eine Kostenfrage – ein Lasttest kann natürlich sehr viel Traffic erzeugen. Durch fehlerhaftes Routing eines Hosters, sodass eigentlich interner Traffic über eine externe Leitung ging, sollte ein Kunde zum Beispiel mehrere zehntausend Euro Traffic-Kosten nachzahlen. In jedem Fall sollte man entsprechend auch den Hoster nach Möglichkeit vorab über derartige Tests informieren.

Gefundene Fehler

Viele Fehler, die ich und meine Kollegen durch Lasttests gefunden haben, entsprachen nicht den Erwartungen der Entwickler der Webapplikation, und fast alle wären ohne einen dezidierten Lasttests erst im Produktivbetrieb aufgefallen.

Varnish wird zusammen mit Edge-Side Includes (ESI) eingesetzt, um einzelne Bestandteile der Webseite mit unterschiedlichen Cachekontexten und -laufzeiten zu versehen und entsprechend zu cachen. Auf einem großen Onlineshop wurde dies sehr granular eingesetzt und funktionierte während der Entwicklung und der üblichen Tests wunderbar. Durch den sehr granularen Einsatz der ESIs und die kombinatorische Explosion der Cachekontexte konnte Varnish während des Lasttests allerdings nicht mehr alle notwendigen Varianten im Speicher halten. Eine Cache-Hit-Rate von < 10 % führte dann dazu, dass das PHP-Framework für den Onlineshop nicht nur einmal für die gesamte Seite angefragt wurde, sondern bis zu vierzigmal für einen einzelnen Seitenaufruf eines Besuchers. Diese stark erhöhte Menge an Anfragen war viel zu viel für die Applikationsserver. Über eine starke Reduktion der ESIs ließ sich das Problem aber relativ einfach lösen.

NFS (Network File System) wird in Webapplikationen gerne eingesetzt, um statische Dateien zwischen mehreren Applikationsservern zu synchronisieren. NFS verhält sich unter hoher Last jedoch sehr oft ganz anders als unter niedriger Last, weil mehrere parallele Schreibzugriffe sehr häufig zu kompletten Blockaden führen, die Minuten anhalten können. Ein Effekt, der in normalen Tests nicht auftritt, aber unter Last sehr oft beobachtet werden kann. Vermeiden lässt sich das im Übrigen, wenn man bei der Verwendung von NFS Dateien nur genau einmal schreibt und nie wieder verändert. Mehrere lesende Server sind meist kein Problem.

Ein von einem Hoster vorkonfigurierter Cluster hielt ein weiteres Problem für mein Team bereit, das im Produktivbetrieb für sehr viele Fehler gesorgt hätte, aber im Testbetrieb nicht aufgefallen ist. Der Apache-Server akzeptiert schlichtweg in etwa doppelt so viele Verbindungen wie der MySQL-Server. Das führte dazu, dass unter Last 50 % aller Anfragen mit einem Fehler endeten, weil keine Verbindung mehr zu dem MySQL-Server aufgebaut werden konnte. Ein eigentlich triviales Problem, das aber einen Relaunch oder eine Werbekampagne komplett scheitern lassen kann.

In keinem der von uns getesteten Fälle war im Übrigen der MySQL-Server zu langsam, was die häufigste Annahme der Entwickler ist. Bis auf einen Fall hätten die von uns bislang getesteten Systeme die avisierte Last nie ausgehalten. Nach den Tests, Messungen und entsprechenden Fehlerbehebungen hat dann aber bislang jedes System das geplante Ereignis problemlos überstanden. Auch wenn die Investition über eigenen Wissensaufbau oder externe Experten in einem derartigen Lasttests erst einmal groß wirkt, rentiert sie sich jedoch genau darüber wieder.

Checkliste

Bevor ein Lasttest durchgeführt wird, kann eine Checkliste helfen, die wichtigsten Punkte zu identifizieren:

• Dezidierte Hardware für den Testserver: Die Tests sollten nie auf dem zu testenden System ausgeführt werden – dies würde die Messungen stark verfälschen.
• Ausreichende Testhardware im selben Rechenzentrum: Sowohl Netzwerkdurchsatz als auch die Auslastung sollte auf den Testservern ebenfalls gemessen und beobachtet
  werden, um sicherzustellen, dass die avisierte Last zuverlässig erzeugt werden kann.
• Die reale Hardware testen:Es führt kein Weg daran vorbei, die reale Hardware zu testen, wenn man aussagekräftige Resultate benötigt. Infrastrukturautomatisierung
  (Ansible, Puppet …) kann helfen, eventuell existierende Systeme zu duplizieren.
• Realitätsnahe Daten verwenden:Die Datengrößen und -strukturen in der getesteten Software sollten möglichst nah an denen der realen Umgebung sein. Gerade
  Indexgrößen in Datenbanken und deren entsprechender Speicherverbrauch sind oft entscheidend, wenn es um die Performance der entsprechenden Systeme geht.
• Externe Dienstleister informieren:Auf jeden Fall sollten alle Betreiber eingebundener externer Dienste, die mitgetestet werden, informiert werden. Oft muss
  vereinbart werden, wie mit den im Testzeitraum anfallenden Daten umzugehen ist.
• Realistische Userszenarien definieren:Mit realistischen Userszenarien steht und fällt die Aussagekraft eines Lasttests. Diese sollten zusammen mit dem Product
  Owner ausgearbeitet werden. Dabei ist es ebenfalls wichtig zu verstehen, in welcher Anzahl welche Aktionen vorkommen.

Fazit

Einen wirklich sinnvollen Lasttest aufzusetzen und durchzuführen, ist mehr Arbeit als der Aufruf eines kurzen Skripts. Dafür kann ein solcher Lasttest einem die Sicherheit geben, dass eine Werbekampagne oder ein Relaunch die erwarteten Nutzerzahlen aushält, und er erlaubt eine deutlich genauere Planung der dafür notwendigen Hardware, was langfristig Kosten reduzieren kann. Letztendlich ist eine gescheiterte Werbekampagne oft teurer, als es ein Test vorab sein kann – die Sicherheit und Zuversicht, die ein sinnvoller Lasttest gibt, ist dagegen unbezahlbar.

Links & Literatur

[1] https://jmeter.apache.org/
[2] https://tideways.io/

The post Packt mein Shop das? appeared first on webinale 2025.

Im ersten Teil dieser zweiteiligen Artikelserie haben Sie die Grundlagen sowie einige wichtige Begriffe bei der Entwicklung von Alexa Skills für Amazon Echo kennengelernt. Sie haben Ihren ersten Skill geplant und im Alexa Skills Kit konfiguriert. Zudem haben Sie einige Tipps erhalten, wie Sie den Freigabeprozess für Ihren Skill möglichst fehlerfrei überstehen können.

In diesem zweiten Teil werden Sie zuerst die Beispielanwendung installieren und genauer anschauen. Sie werden den Skill-Code für die beiden geplanten Intents implementieren und zudem erfahren, wie Sie mit Session-Attributen und Slot Types arbeiten können. Zu guter Letzt werden Sie Ihren Skill online bringen und ausführlich testen, bevor Sie den Freigabeprozess starten können.

Beispielanwendung installieren

Nachdem das Frontend im Alexa Skills Kit soweit vorbereitet ist, können Sie sich nun um den Skill-Code kümmern. Doch keine Angst, Sie müssen nun nicht einen eigenen Parser schreiben, der die JSON Service Requests von Alexa verarbeiten und JSON Service Responses erstellen kann. Dafür gibt es bereits eine entsprechende PHP Library sowie eine Skeleton Application, die auf dieser Library und Expressive aufsetzt. Durch die Library sind Sie aber nicht an das Zend Framework und Expressive gebunden. Sie können auch gerne eine Anwendung mit einem anderen Framework aufsetzen und darin die PHP Library nutzen. Sie können die Skeleton Application mit $ composer create-project travello-gmbh/amazon-alexa-skill-skeleton mein-zoo installieren.

Doch statt mit der Skeleton Application sollten Sie mit der Beispielanwendung beginnen. Die Beispielanwendung für den Mein Zoo Alexa Skill setzt auf dieser Skeleton Application auf, damit Sie sich ganz auf die Skill-Entwicklung konzentrieren können. Darin wurden bereits einige Vorbereitungen für Sie getroffen, damit Sie gleich loslegen können. Sie installieren die Beispielanwendung wie folgt:

$ git clone https://github.com/RalfEggert/phpmagazin.alexa
$ cd phpmagazin.alexa
$ composer install
$ sudo chmod -R 777 data/cache/

Danach sollten Sie einen Virtual-Host phpmagazin.alexa einrichten, der auf das Verzeichnis /html/ in diesem Projekt verweist. Um die Funktion der Anwendung nach der Installation und den Virtual-Host zu testen, rufen Sie im Browser den URL http://phpmagazin.alexa/ auf. Sie sollten eine JSON-Ausgabe mit einer kurzen Begrüßung erhalten.
Außerdem empfiehlt es sich, zum Prüfen der Anfragen ein Tool wie Postman [4] zu verwenden. Wenn Sie Postman installiert haben, können Sie die Datei /data/postman/collection.json importieren. Sie sollten in dieser Datei aber vorher alle Stellen für die Application-ID anpassen. Suchen Sie einfach nach amzn1.ask.skill.place-your-skill-id-here und tauschen diese Fundstellen durch Ihre eigene Application-ID aus. Prüfen Sie dann die Abfrage Zoo LaunchRequest. Wenn die Rückgabe in etwa so aussieht wie in Abbildung 1, war die Installation erfolgreich.

Damit Sie sich in der Anwendung etwas orientieren können, ein paar Anmerkungen dazu. Bei der Anwendung handelt es sich wie erwähnt um eine Expressive-Applikation. Wenn Sie noch keinerlei Erfahrungen mit Expressive und dem Zend Framework gemacht haben, sollten Sie zumindest einmal die Dokumentation dazu genauer anschauen [5]. Im Verzeichnis /config/autoload/ finden Sie die beiden Konfigurationsdateien travello-alexa.config.global.php und travello-alexa.config.development.php. Darin können Sie die Signaturvalidierung sowie das Logging der Requests an- und abschalten. Auf dem Liveserver sollten Sie die Signaturvalidierung nur für noch nicht veröffentlichte Skills deaktivieren.

In der Datei /data/texts/zoo.common.texts.php finden Sie alle Texte für den neuen Skill, die Sie mindestens brauchen. Weitere Texte sollten Sie dort einfügen. Wenn Sie Ihren Skill später einmal internationalisieren möchten, dann können Sie dies einfach tun, da alle Texte hier ausgelagert sind. Die Datei /data/zoo/animals.php enthält eine Liste mit Tieren, die nach Tierart unterteilt sind. In den Verzeichnissen /html/cards/ und /html/images/ liegen einige Vorlagen für die Icons, die Sie für Ihren Skill brauchen. Die Größen sollten passen, zudem ist das /html/cards/ durch die .htaccess-Datei für CORS-Zugriffe fertig konfiguriert. Der eigentliche Skill-Code soll im Verzeichnis /module/Zoo/ liegen. Darin finden Sie schon einige Klassen sowie ein Template. In der Klasse /module/Zoo/src/ConfigProvider.php finden Sie die Konfiguration des Skill-Moduls für unseren Zoo. In Listing 1 sehen Sie einen Auszug aus der Konfigurationsdatei, der die Konfiguration des Skills an sich beinhaltet. Dort werden unter anderem die Application-ID des Skills, die Session-Attribute, die Textdateien und die Intents konfiguriert. Zu diesen einzelnen Punkten kommen wir später.

<?php
namespace Zoo;
use TravelloAlexaLibrary\Application\AlexaApplication;
use TravelloAlexaLibrary\TextHelper\TextHelper;
use Zend\Expressive\Application;
use Zoo\Config\RouterDelegatorFactory;
class ConfigProvider
{
  const NAME = 'zoo-skill';
  /** ... */
  public function getSkills(): array
  {
    return [
      self::NAME => [
        'applicationId'    => 'amzn1.ask.skill.place-your-skill-id-here',
        'applicationClass' => AlexaApplication::class,
        'textHelperClass'  => TextHelper::class,
        'sessionDefaults'  => [
          'animals' => [],
        ],
        'smallImageUrl'    => 'https://www.travello.audio/cards/zoo-480x480.png',
        'largeImageUrl'    => 'https://www.travello.audio/cards/zoo-800x800.png',
        'intents'          => [
          'aliases'   => [],
          'factories' => [],
        ],
        'texts'       => [
          'de-DE' => include PROJECT_ROOT . '/data/texts/zoo.common.texts.de-DE.php',
          'en-US' => include PROJECT_ROOT . '/data/texts/zoo.common.texts.en-US.php',
        ],
      ]
    ];
  }
}

Skill-Code mit PHP entwickeln

Bevor Sie mit der Entwicklung der Skill-Application beginnen, sollten Sie noch die erforderlichen Texte erstellen. Alle Standardtexte für die Begrüßung oder das Ende des Skills sind bereits in der Datei /data/texts/zoo.common.texts.de-DE.php vorhanden. Wenn Sie nun noch einmal die Beispieldialoge zu den Antworten von Alexa anschauen, finden Sie noch mindestens zwei Texte, die Sie noch implementieren müssen: Eine Giraffe lebt in deinem Zoo! und In deinem Zoo leben 42 Tiere!. Dabei fällt auf, dass diese Texte mit einem Platzhalter arbeiten müssen.

Als Erstes legen Sie die neuen Texte an. Sie brauchen jeweils eine Nachricht sowie einen Titel, der später in der Alexa-App auf dem Smartphone angezeigt werden soll. Rufen Sie die Datei /data/texts/zoo.common.texts.de-DE.php auf und fügen Sie die neuen Texte ein:

<?php
return [
  /* ... */
  'animalTitle'     => 'Ein Tier',
  'animalMessage'   => '%1$s lebt in deinem Zoo!',
  'countTitle'      => 'Tierzählung',
  'countMessage'    => 'In deinem Zoo leben %1$s Tiere!',
];

Wiederholen Sie dann den Schritt mit der englischsprachigen Datei. Damit sind die Vorbereitungen für die Texte abgeschlossen.

Nun ist die eigentliche Anwendung an der Reihe. Legen Sie das Verzeichnis /module/Zoo/src/Intent und darin die Klasse AnimalIntent an. Schauen Sie dazu in Listing 2. In der Regel müssen Sie in einer Intent-Klasse in der Response mindestens einen Ausgabetext festlegen. Dafür können Sie die sogenannte OutputSpeech festlegen. Dabei haben Sie die Wahl zwischen normalem Text (PlainText) und einer SSML-Definition. Mit der Speech Synthesis Markup Language können Sie die Texte, die Alexa sagt, betonen, bestimmte Effekte verwenden oder MP3-Dateien abspielen lassen. Details finden Sie in der Dokumentation [6]. Zusätzlich zum Ausgabetext können Sie auch eine Card festlegen, die in der Smartphone-App angezeigt wird. Hier haben Sie die Wahl zwischen Simple Cards ohne Bilder und Standard Cards mit Bildern. Details zu den Cards finden Sie ebenfalls in der Dokumentation [7]. Die genannten Varianten für die OutputSpeech sowie für die Cards werden von der Travello Alexa Library unterstützt. Vielleicht fällt Ihnen dabei auf, dass das aktuelle Tier noch festgelegt ist. Um die Varianz kümmern Sie sich aber erst später.

<?php
namespace Zoo\Intent;

use TravelloAlexaLibrary\Intent\AbstractIntent;
use TravelloAlexaLibrary\Response\AlexaResponse;
use TravelloAlexaLibrary\Response\Card\Standard;
use TravelloAlexaLibrary\Response\OutputSpeech\SSML;

class AnimalIntent extends AbstractIntent
{
  const NAME = 'AnimalIntent';

  public function handle(string $smallImageUrl, string $largeImageUrl): AlexaResponse
  {
    $zooMessage = $this->getTextHelper()->getAnimalMessage('Ein Elefant');

    $this->getAlexaResponse()->setOutputSpeech(
      new SSML($zooMessage)
    );

    $this->getAlexaResponse()->setCard(
      new Standard(
        $this->getTextHelper()->getAnimalTitle(),
        $zooMessage,
        $smallImageUrl,
        $largeImageUrl
      )
    );

    return $this->getAlexaResponse();
  }
}

Jetzt geht es um die Konfiguration des Skills. Öffnen Sie die Konfigurationsklasse Zoo\ConfigProvider und scrollen Sie zur Methode getSkills(). Ändern Sie als Erstes den Wert für die applicationId. Erstellen Sie auch die Bilder in den Größen 480 x 480 Pixel sowie 800 x 800 Pixel und laden Sie sie auf den eingerichteten HTTPS-Endpunktserver hoch. Passen Sie die URLs zu den Dateien an, sodass Sie während der Entwicklung schon mit den Bildern arbeiten können.

Nun können Sie den neuen Intent aufnehmen. Damit teilen Sie dem Intent-Manager mit, dass es eine neue Intent-Klasse gibt. Sie müssen dafür einmal die Factory für den Intent definieren und noch einen Alias festlegen, damit der Intent-Manager diesen anhand der NAME-Konstante finden kann. Das Ergebnis sehen Sie in Listing 3.

<?php
namespace Zoo;

use TravelloAlexaZf\Intent\AbstractIntentFactory;
use Zoo\Intent\AnimalIntent;

class ConfigProvider
{
  /** ... */

  public function getSkills(): array
  {
    return [
      self::NAME => [
        'applicationId'    => 'amzn1.ask.skill.place-your-skill-id-here',
        'applicationClass' => AlexaApplication::class,
        'textHelperClass'  => TextHelper::class,
        'sessionDefaults'  => [
          'animals' => [],
        ],
        'smallImageUrl'    => 'https://www.travello.audio/cards/zoo-480x480.png',
        'largeImageUrl'    => 'https://www.travello.audio/cards/zoo-800x800.png',
        'intents'          => [
          'aliases' => [
            AnimalIntent::NAME => AnimalIntent::class,
          ],

           'factories' => [
             AnimalIntent::class => AbstractIntentFactory::class,
            ],
          ],
          'texts'            => [
            'de-DE' => include PROJECT_ROOT . '/data/texts/zoo.common.texts.de-DE.php',
            'en-US' => include PROJECT_ROOT . '/data/texts/zoo.common.texts.en-US.php',
          ],
        ]
      ];
    }
}

Jetzt geht es darum, den AnimalIntent zu testen. Rufen Sie dafür im Postman den Request Zoo AnimalIntent auf und betrachten Sie die Rückgabe. Sollten Sie die Meldung Application Id invalid erhalten, dann müssen Sie im Postman in den Body des Requests noch Ihre eigene Application-ID eintragen. Abbildung 2 zeigt die mögliche Ausgabe.

Wenn Sie nicht alle Änderungen erfolgreich umsetzen konnten, wechseln Sie einfach mit $ git checkout step1 auf den step1-Branch im Projekt.

Mit Session-Attributen arbeiten

Nun sollen natürlich nicht immer nur Elefanten genannt werden. Es gibt ja eine Liste mit Tieren unterteilt nach Tierarten. Diese muss nun in die AnimalIntent injiziert werden, damit ein zufälliges Tier anhand der Liste ausgewählt werden kann. Rufen Sie dafür die Klasse Zoo\Intent\AnimalIntent auf und fügen Sie die Änderungen aus Listing 4 ein. Diese gehen wir nun Schritt für Schritt durch.

Sie müssen eine neue Eigenschaft animalList für das Array mit den Tieren schaffen und eine öffentliche Methode setAnimalList() für das Setzen der Tierliste erstellen. Danach müssen Sie die handle()-Methode anpassen, damit ein zufälliges Tier ausgewählt wird. Listing 4 zeigt eine mögliche Implementation. Dabei wird das Ermitteln des Tiers in eine eigene kleine Hilfsmethode getRandomAnimal() ausgelagert. Wenn Sie im Postman den Request Zoo AnimalIntent nun erneut aufrufen, sollte Ihnen jedes Mal ein anderes Tier genannt werden.

<?php
namespace Zoo\Intent;

use TravelloAlexaLibrary\Intent\AbstractIntent;
use TravelloAlexaLibrary\Response\AlexaResponse;
use TravelloAlexaLibrary\Response\Card\Standard;
use TravelloAlexaLibrary\Response\OutputSpeech\SSML;

class AnimalIntent extends AbstractIntent
{
  const NAME = 'AnimalIntent';

  private $animalList = [];

  public function setAnimalList(array $animalList)
  {
    $this->animalList = $animalList;
  }

  protected function getAnimalList(): array
  {
    return $this->animalList;
  }

  public function handle(string $smallImageUrl, string $largeImageUrl): AlexaResponse
  {
    $randomAnimal = $this->getRandomAnimal();

    $zooMessage = $this->getTextHelper()->getAnimalMessage($randomAnimal);

    $this->getAlexaResponse()->setOutputSpeech(
      new SSML($zooMessage)
    );

    $this->getAlexaResponse()->setCard(
      new Standard(
        $this->getTextHelper()->getAnimalTitle(),
        $zooMessage,
        $smallImageUrl,
        $largeImageUrl
      )
    );

    return $this->getAlexaResponse();
  }

  private function getRandomAnimal()
  {
    $locale = $this->getAlexaRequest()->getRequest()->getLocale();

    $randomType      = array_rand($this->getAnimalList()[$locale]);
    $randomAnimalKey = array_rand($this->getAnimalList()[$locale][$randomType]);
    $randomAnimal    = $this->getAnimalList()[$locale][$randomType][$randomAnimalKey];

    return $randomAnimal;
  }
}

Momentan kann es aber passieren, dass Sie ein Tier, das gerade erst genannt wurde, beim nächsten Aufruf erneut genannt bekommen. Das wäre auf Dauer etwas langweilig. Um zumindest zu verhindern, dass ein Tier kurz hintereinander erneut genannt wird, kommen nun die Session-Attribute zum Einsatz. Hierbei handelt es sich nicht um klassische PHP Sessions. Das Alexa Skill Kit erlaubt den Einsatz von Session-Attributen, die Sie in eine Service Response aufnehmen können und die dann beim nächsten Service Request unverändert zurückgeschickt werden.

Die Travello Alexa Library bietet Ihnen dafür schon alle Funktionen, die Sie für die Nutzung von Session-Attributen brauchen. Sie können die Session-Attribute initialisieren und an die AlexaResponse anhängen. Dafür stehen entsprechende Methoden bereit. Listing 5 zeigt alle erforderlichen Änderungen an der Zoo\Intent\AnimalIntent-Klasse:

• Sie müssen eine neue private Eigenschaft $sessionAnimals zum Ablegen der letzten Tiere aus den Session-Attributen erstellen.
• In der Methode handle() rufen Sie zuerst den aktuellen Wert der Tierliste aus der Session ab, bevor das zufällige Tier ermittelt wird. Bevor die Methode verlassen wird, wird der Wert der Session-Variable auch in der Response vermerkt. Damit wird sichergestellt, dass der Wert beim nächsten Request wieder mitgeliefert wird.
• Die größten Änderungen betreffen die getRandomAnimal()-Methode. Hier wurde die Ermittlung eines zufälligen Tiers in einer do-while-Schleife integriert, die nur verlassen wird, wenn das neue zufällige Tier nicht in der Liste der bisherigen Tiere enthalten ist. Um sicherzustellen, dass die Liste der bisherigen Tiere nicht irgendwann alle Tiere enthält und der AnimalIntent dann nicht mehr funktioniert, wird das Array auf maximal fünf Einträge begrenzt. Danach wird das neue zufällige Tier der Eigenschaft $sessionAnimals hinzugefügt, bevor die Methode es wieder zurückgibt.

<?php
namespace Zoo\Intent;

use TravelloAlexaLibrary\Intent\AbstractIntent;
use TravelloAlexaLibrary\Response\AlexaResponse;
use TravelloAlexaLibrary\Response\Card\Standard;
use TravelloAlexaLibrary\Response\OutputSpeech\SSML;

class AnimalIntent extends AbstractIntent
{
  /** ... */

  /** @var array */
  private $sessionAnimals = [];

  public function handle(string $smallImageUrl, string $largeImageUrl): AlexaResponse
  {
    $this->sessionAnimals = $this->getAlexaResponse()->getSessionContainer()->getAttribute('animals');

    $randomAnimal = $this->getRandomAnimal();

    // ...

    $this->getAlexaResponse()->getSessionContainer()->setAttribute('animals', $this->sessionAnimals);

    return $this->getAlexaResponse();
  }

  private function getRandomAnimal()
  {
    $locale = $this->getAlexaRequest()->getRequest()->getLocale();

    do {
      $randomType      = array_rand($this->getAnimalList()[$locale]);
      $randomAnimalKey = array_rand($this->getAnimalList()[$locale][$randomType]);
      $randomAnimal    = $this->getAnimalList()[$locale][$randomType][$randomAnimalKey];
    } while (in_array($randomAnimal, $this->sessionAnimals));

    if (count($this->sessionAnimals) >= 5) {
      array_shift($this->sessionAnimals);
    }

    $this->sessionAnimals[] = $randomAnimal;

    return $randomAnimal;
  }
}

Als Letztes brauchen wir noch eine Factory-Klasse, die die Liste aller möglichen Tiere in den AnimalIntent injiziert. Legen Sie dafür die Klasse Zoo\Intent\AnimalIntentFactory an und fügen den Inhalt aus Listing 6 ein. Darin wird der AnimalIntent entsprechend konfiguriert und bekommt alle erforderlichen Abhängigkeiten sowie die Daten der Tiere injiziert. Zudem müssen Sie noch die Konfiguration der Factory im ConfigProvider anpassen.

<?php
namespace Zoo\Intent;

use Interop\Container\ContainerInterface;
use TravelloAlexaLibrary\Request\AlexaRequest;
use TravelloAlexaLibrary\Response\AlexaResponse;
use TravelloAlexaLibrary\TextHelper\TextHelper;
use Zend\ServiceManager\Factory\FactoryInterface;

class AnimalIntentFactory implements FactoryInterface
{
  public function __invoke(ContainerInterface $container, $requestedName, array $options = null)
  {
    $alexaRequest  = $container->get(AlexaRequest::class);
    $alexaResponse = $container->get(AlexaResponse::class);
    $textHelper    = $container->get(TextHelper::class);

    $animalList = include PROJECT_ROOT . '/data/zoo/animals.php';

    /** @var AnimalIntent $intent */
    $intent = new $requestedName($alexaRequest, $alexaResponse, $textHelper);
    $intent->setAnimalList($animalList);

    return $intent;
  }
}

Probieren Sie im Postman den Request Zoo AnimalIntent nun erneut aus. In der Response sollte nun unter sessionAttributes auch das zuletzt genannte Tier auftauchen. Probieren Sie nun im Postman auch mal den Request Zoo AnimalIntent (5 last animals) aus. Schauen Sie sich den Body des Requests an und vergleichen Sie ihn mit dem Body der Response. Im Request waren bereits fünf Tiere in den Session-Attributen gespeichert; in der Response sollte das älteste Tier dann herausgeflogen sein.

Sie können den AnimalIntent natürlich auch so umschreiben, dass die Liste nicht nach fünf Tieren gekürzt, sondern so lange fortgeführt wird, bis alle Tiere einmal genannt worden sind. Dann muss Ihr AnimalIntent aber beim nächsten Aufruf eine entsprechende Meldung ausgeben, dass alle Tiere genannt worden sind. Sie sind da vollkommen frei, wie Sie das umsetzen.

Die letzten Änderungen können Sie sich auch einfach durch den Wechsel auf den step2 Branch anschauen, falls Sie diese nicht im Detail selber implementiert haben. Der Befehl dafür lautet $ git checkout step2.

Zweiten Intent implementieren

Sie erinnern sich vielleicht, dass Sie neben dem implementierten AnimalIntent auch einen zweiten Intent im Alexa Skills Kit definiert haben: den CountIntent zum Zählen aller Tiere im Zoo. Mit Ihren bisher erworbenen Kenntnissen sollte Ihnen dies jedoch nicht schwerfallen. Dafür wird eine neue Intent-Klasse CountIntent erstellt. Die entsprechenden Texte für OutputSpeech und Card haben Sie bereits angelegt, sodass dies auch schnell vonstattengehen sollte. Nur für die Berechnung der Anzahl der Tiere würde sich eine eigene Methode anbieten.

In Listing 7 finden Sie eine beispielhafte Implementation. Hierbei wurde die Berechnung für die Tierzählung in die Methode getAnimalCount() ausgelagert. Bitte beachten Sie, dass eine einfache Zählung per count($this->animalList, COUNT_RECURSIVE) auch die Tierarten mitzählen und somit ein falsches Ergebnis liefern würde. Deshalb wurde eine foreach()-Schleife gewählt. Zusätzlich wäre es auch denkbar, das Ergebnis der Tierzählung für spätere Abfragen zu cachen. Für die Demonstration sollte dies aber ausreichend sein. Der Aufbau der handle()-Methode ist im Wesentlichen ähnlich zum AnimalIntent.

<?php
namespace Zoo\Intent;

use TravelloAlexaLibrary\Response\AlexaResponse;
use TravelloAlexaLibrary\Response\Card\Standard;
use TravelloAlexaLibrary\Response\OutputSpeech\SSML;

class CountIntent extends AbstractIntent
{
  const NAME = 'CountIntent';

  public function handle(string $smallImageUrl, string $largeImageUrl): AlexaResponse
  {
    $count = $this->getAnimalCount();

    $zooMessage = $this->getTextHelper()->getCountMessage($count);

    $this->getAlexaResponse()->setOutputSpeech(
      new SSML($zooMessage)
    );

    $this->getAlexaResponse()->setCard(
      new Standard(
        $this->getTextHelper()->getCountTitle(),
        $zooMessage,
        $smallImageUrl,
        $largeImageUrl
      )
    );

      return $this->getAlexaResponse();
    }

    private function getAnimalCount()
    {
      $locale = $this->getAlexaRequest()->getRequest()->getLocale();

      $count = 0;

      foreach ($this->getAnimalList()[$locale] as $type => $typeList) {
      $count += count($typeList);
    }

    return $count;
  }
}

Vielleicht ist Ihnen aufgefallen, dass die CountIntent-Klasse die Klasse Zoo\Intent\AbstractIntent erweitert. In diese abstrakte Klasse wurde die Verarbeitung der Tierliste inklusive Setter und Getter ausgelagert. Eine andere Variante wäre auch ein Trait gewesen. Sie finden diese abstrakte Klasse in Listing 8. Als Ergänzung müssen Sie die bisherige Zoo\Intent\AnimalIntentFactory-Klasse in Zoo\Intent\AbstractIntentFactory umbenennen, um sie für beide Intents verwenden zu können. Beachten Sie auch Listing 9 mit der geänderten Konfiguration für den Intent-Manager.

<?php
namespace Zoo\Intent;

use TravelloAlexaLibrary\Intent\AbstractIntent as BaseAbstractIntent;

abstract class AbstractIntent extends BaseAbstractIntent
{
  private $animalList = [];

  public function setAnimalList(array $animalList)
  {
    $this->animalList = $animalList;
  }

  protected function getAnimalList(): array
  {
    return $this->animalList;
  }
}

<?php
namespace Zoo;

use Zoo\Intent\AbstractIntentFactory;
use Zoo\Intent\AnimalIntent;
use Zoo\Intent\CountIntent;

class ConfigProvider
{
  /** ... */

  public function getSkills(): array
  {
    return [
      self::NAME => [
        /** ... */

        'intents'          => [
          'aliases' => [
            AnimalIntent::NAME => AnimalIntent::class,
            CountIntent::NAME  => CountIntent::class,
          ],

          'factories' => [
            AnimalIntent::class => AbstractIntentFactory::class,
            CountIntent::class  => AbstractIntentFactory::class,
          ],
        ],

        /** ... */
      ]
    ];
  }
}

Sie können diesen neuen Intent im Postman durch den Request Zoo CountIntent ausführen lassen. Im Body der Response sollten Sie dann erfahren, wie viele Tiere in Ihrem Zoo leben.

Nachdem Sie die Grundlagen geschaffen haben, war die Implementation des zweiten Intents für Sie hoffentlich einfach umzusetzen. Durch den Wechsel auf den Branch step3 mithilfe von $ git checkout step3 können Sie auch diese Änderungen leicht nachvollziehen.

Mit Slot Types arbeiten

Bisher haben Sie die beiden Intents noch ohne Slot Types verwendet. Im nächsten Schritt definieren Sie nun einen eigenen Slot Type und setzen ihn auch ein. Loggen Sie sich dafür wieder im Alexa Skills Kit ein und wählen Sie Ihren Skill aus. Wechseln Sie dann auf den Bereich Interaction Model und starten Sie den Skill Builder. Fügen Sie nun einen neuen Slot Type hinzu, den Sie SPECIES nennen. Als Werte tragen Sie Vögel, Säugetiere, Fische und Tiere ein. Tragen Sie für jeden Wert als Synonym auch die Einzahl ein, also entsprechend Vogel, Säugetier, Fisch und Tier. Abbildung 3 zeigt, wie die Einrichtung des Slot Types aussehen sollte.

Nun wählen Sie links in der Liste den AnimalIntent aus und bearbeiten ihn. Zuerst fügen Sie auf der rechten Seite den neuen Slot species hinzu und verknüpfen ihn mit Ihrem Slot Type SPECIES. Nun klicken Sie in der Mitte eine Utterance an, z. B. Welches Tier gibt es noch in meinem Zoo, und tauschen das Wort Tier durch {species} aus. Damit verknüpfen Sie die Utterance mit dem Slot. Dies führen Sie mit allen Utterances durch. Um die grammatikalische Korrektheit der Utterances zu wahren, können Sie auch noch die Utterances Nenne mir einen {species} aus meinem Zoo und Welchen {species} gibt es noch in meinem Zoo hinzufügen. Am Ende sollte der Intent so aussehen wie in Abbildung 4 gezeigt. Danach klicken Sie erst auf Save Model und danach auf Build Model und warten ab, bis der Prozess abgeschlossen ist.

Um sicherzustellen, dass die Änderungen am Interaction Model korrekt waren, können Sie in den Testbereich des Alexa Skills Kit wechseln und die neuen Utterances ausprobieren. Geben Sie im Service Simulator Welches Säugetier gibt es in meinem Zoo ein; im JSON Service Request sollte dann ein Slot mit dem Wert Säugetier angezeigt werden. Im Postman können Sie den AnimalIntent mit Slot testen, indem Sie den Request Zoo AnimalIntent (with slot) ausführen. Ihnen sollten aber immer noch auch Vögel und Fische ausgegeben werden, auch wenn Sie explizit nach einem Säugetier gefragt haben.

Wenn diese Tests erfolgreich waren, können Sie die Umsetzung im Skill-Code beginnen. Dabei ist der zusätzlich zu entwickelnde Code recht überschaubar, da Ihnen der bisherige Aufbau des AnimalIntent bei der Erweiterung sehr entgegenkommt. Listing 10 zeigt alle erforderlichen Änderungen:

• Die neue Methode getSpeciesSlot() hat die Aufgabe, den Wert für den Tierart-Slot-Type zu ermitteln. Dabei greift sie auf den aktuellen Wert aus dem Alexa Request zu. Da sowohl Einzahl als auch Mehrzahl sowie Kleinschrift als auch Großschrift und zudem die Sprache beachtet werden müssen, wird der Schlüssel für die einzelnen Tierarten anhand einer switch-Anweisung ermittelt und zurückgegeben. Wenn keine bekannte Tierart übergeben wurde, wird null zurückgegeben. Zugegeben, das lässt sich sicherlich sauberer implementieren, aber für unsere Zwecke ist die Methode ausreichend.
• Die vorhandene Methode getRandomAnimal() wird um einen Parameter erweitert, der die aktuell gewünschte Tierart enthält. Wird kein Wert für die Tierart übergeben, wird die Tierart zufällig ausgewählt. Ansonsten wird die gewünschte Tierart genommen, um dann ein Tier zufällig auszuwählen. Der Rest der Methode bleibt unverändert.
• In der vorhandenen animalIntent()-Methode wird zu Beginn zuerst die getSpeciesSlot()-Methode aufgerufen und der ermittelte Wert danach an die getRandomAnimal()-Methode übergeben. Der Rest dieser Methode kann ebenfalls unverändert bleiben.

<?php
namespace Zoo\Intent;

use TravelloAlexaLibrary\Request\RequestType\IntentRequestType;
use TravelloAlexaLibrary\Response\AlexaResponse;
use TravelloAlexaLibrary\Response\Card\Standard;
use TravelloAlexaLibrary\Response\OutputSpeech\SSML;

class AnimalIntent extends AbstractIntent
{
  /** ... */

  public function handle(string $smallImageUrl, string $largeImageUrl): AlexaResponse
  {
    $this->sessionAnimals = $this->getAlexaResponse()->getSessionContainer()->getAttribute('animals');

    $speciesSlot = $this->getSpeciesSlot();

    $randomAnimal = $this->getRandomAnimal($speciesSlot);

    /** ... */
  }

  private function getSpeciesSlot()
  {
    /** @var IntentRequestType $intentRequest */
    $intentRequest = $this->getAlexaRequest()->getRequest();

    $speciesSlot = $intentRequest->getIntent()->getSlotValue('species');

    switch ($speciesSlot) {
      case 'Vogel':
      case 'vogel':
      case 'Vögel':
      case 'vögel':
      case 'Bird':
      case 'bird':
      case 'Birds':
      case 'birds':
      return 'V';

      case 'Säugetier':
      case 'säugetier':
      case 'Säugetiere':
      case 'säugetiere':
      case 'Mammal':
      case 'mammal':
      case 'Mammals':
      case 'mammals':
      return 'S';

      case 'Fisch':
      case 'fisch':
      case 'Fische':
      case 'fische':
      case 'Fish':
      case 'fish':
      case 'Fishes':
      case 'fishes':
      return 'F';

      default:
      return null;
    }
  }

  private function getRandomAnimal(string $speciesSlot = null)
  {
    $locale = $this->getAlexaRequest()->getRequest()->getLocale();

    do {
      $randomType = is_null($speciesSlot) ? array_rand($this->getAnimalList()[$locale]) : $speciesSlot;
      $randomAnimalKey = array_rand($this->getAnimalList()[$locale][$randomType]);
      $randomAnimal = $this->getAnimalList()[$locale][$randomType][$randomAnimalKey];
    } while (in_array($randomAnimal, $this->sessionAnimals));

    /** ... */
  }
}

Nun führen Sie im Postman den Request Zoo AnimalIntent (with slot) erneut aus. Jetzt sollten Ihnen auf jeden Fall nur noch Säugetiere zurückgegeben werden. Sie können den Wert für den species-Slot auch anpassen oder sogar einen nicht unterstützten Wert ausprobieren. Versuchen Sie es einfach.

Das Arbeiten mit eigenen Slot Types in Ihrem Skill-Code ist durch die PHP Library Travello Alexa Library recht einfach umzusetzen. Sie sollten sich auf die Werte im Alexa Service Request jedoch nicht komplett verlassen und diese Werte immer in Ihrem Skill-Code aufbereiten. Eine 1:1-Übernahme könnte sonst zu unerwarteten Fehlern führen. Auch diesen Implementierungsschritt können Sie nachstellen, wenn Sie mit $ git checkout step4 direkt den Branch step4 auschecken.

Skill online bringen und testen

Nachdem der Skill-Code nun erst einmal abgeschlossen ist und die Konfiguration im Alexa Skills Kit auch soweit fertig sein sollte, ist es an der Zeit, den Skill-Code auf Ihren HTTPS-Endpunktserver zu deployen. Welchen Weg Sie dafür einschlagen, bleibt Ihnen überlassen. Da gibt es bei der Skill-Entwicklung keine Besonderheiten zu berücksichtigen. Sie sollten nur darauf achten, dass der Skill genau über den URL erreichbar ist, den Sie als URL für Endpunkt unter Configuration im Alexa Skills Kit festgelegt haben.

Wenn Sie z. B. den URL https://www.mein-skillserver.de/zoo/ verwenden möchten, wundern Sie sich nicht, dass der Aufruf des URL im Browser zu einem Fehler oder sogar einer weißen Seite führen kann. Das Routing für die Anwendung ist so eingerichtet, dass nur auf einen POST Request reagiert werden soll. Rufen Sie stattdessen direkt die Datenschutzerklärung mit https://www.mein-skillserver.de/zoo/privacy auf, dann sollte Ihnen diese Seite angezeigt werden.

Alternativ können Sie auch die Aufrufe im Postman so abändern, dass Sie nun den neuen URL verwenden, statt den lokalen Virtual Host zu nehmen. Sollte es hier zu Fehlern kommen, war das Deployment nicht erfolgreich. Vielleicht fehlen PHP Extensions oder Sie haben das Vendor-Verzeichnis nicht mit übertragen – es gibt da unzählige Fehlerquellen. Wenn Sie auch diese Hürde genommen haben, können Sie Ihren ersten Test mit einem Amazon Echo oder Echo Dot machen.

Der Servicesimulator für die Tests muss mit Vorsicht genossen werden. Beim Schreiben dieses Artikels stand nämlich ein deutlicher Fehlerhinweis direkt beim Servicesimulator. Dennoch sollte dies die nächste Anlaufstelle für Ihre Tests sein. Sie müssen im Simulator den Skill mit Alexa starte mein Zoo starten und dann können Sie den Service Request und die Service Response näher betrachten. Danach können Sie einmal Nenne mir ein Tier aus meinem Zoo schreiben. Schauen Sie sich auch hier Request und Response an. Wenn Sie die Phrase wiederholen, sollten nach und nach die letzten genannten Tiere auch in den Attributen bei dem Request auftauchen. Durch Abbrechen können Sie den Skill beenden.

Der nächste wichtige Test sollte dann direkt auf Ihrem Amazon Echo oder Echo Dot erfolgen. Starten Sie den Skill durch Ihre Sprache mit denselben Phrasen, die Sie eben beim Servicesimulator ausprobiert haben. Wenn alles glattgegangen ist, sollte Ihr Test nun lauffähig sein. Nun sollten Sie weitere Tests ausführen, die Funktionalität erweitern und auch mal unerwartet antworten und schauen, wie sinnvoll Ihr Skill dabei reagiert. Auch den im ersten Teil dieser Artikelserie angesprochenen Betatest sollten Sie ausführlich nutzen. Erst dann, wenn alles zufriedenstellend läuft, sollten Sie die Freigabe beantragen.

Fazit

Sie haben in dieser zweiteiligen Artikelserie alle Grundlagen vermittelt bekommen, mit denen Sie eigene Alexa Skills auf Basis von PHP und Expressive umsetzen können. Der Teufel liegt bei der Konfiguration und Implementation aber durchaus im Detail. Ich drücke Ihnen aber dennoch die Daumen, dass Sie bald Ihren ersten eigenen Alexa Skill erfolgreich auf die Beine stellen.

The post Alexa und PHP – ein Dream-Team? Teil 2: Umsetzung des Skill-Codes mit PHP appeared first on webinale 2025.

Warum eigentlich Smart Assistants?

In den letzten Jahren gab es in jeder Dekade neue technologische Entwicklungen, welche die Computertechnologie und unsere Gesellschaft nachhaltig verändert haben. Während in den Anfängen des Computerzeitalters in den 1970er-Jahren der Character Mode den Ton angab, kam in den 1980er-Jahren das GUI (Graphical User Interface) dazu. In den 1990er-Jahren hat das World Wide Web die nächste Stufe der Evolution eingeläutet und in den 2000er-Jahren übernahm das Mobile Web als nächster revolutionärer Meilenstein die Führung. Seit einigen Jahren hat das VUI (Voice User Interface) Einzug gehalten, und damit stehen wir am Anfang der nächsten Revolution.

Doch ist hier etwa nur der Wunsch einer jungen Branche der Vater der Gedanken? Oder steckt da mehr dahinter?

Für die Antwort auf diese Frage lohnt sich ein Blick in die Vergangenheit der Filmgeschichte. Bereits Ende der Sechzigerjahre ließ sich im Film „2001: Odyssee im Weltraum“ ein Computer mit Namen HAL 9000 per Sprache steuern. Ungefähr zur gleichen Zeit sprach auch Captain Kirk mit seiner Crew in „Star Trek“ mit dem Bordcomputer. Und in den Achtzigern konnte der „Knight Rider“ David Hasselhoff sogar schon mit K.I.T.T. sprechen, einem Sportwagen mit künstlicher Intelligenz. In allen Beispielen schlummerte die Vision, die Computertechnologie mit der menschlichen Stimme steuern und beherrschen zu können. Damals waren dies noch Hirngespinste von realitätsfremden Science-Fiction-Autoren. Doch erst jetzt ist die Technologie so weit, um die Visionen der damaligen Zeit real werden zu lassen.

Zugegeben, die ersten Sprachanwendungen sind nett, aber läuten Pupsgeneratoren und langweilige, aber sprachgesteuerte Ratespiele wirklich eine neue Revolution ein?

Seien wir ehrlich, die ersten Websites waren nicht viel mehr als ellenlange Textwüsten, die miteinander per Hyperlink verknüpft werden konnten. Irgendwann wurden die Texte durch Bilder und dynamische Inhalte aufgewertet. Die ersten Smartphone-Apps hatten auch größtenteils den Nutzwert eines kaputten Pappkartons. Das Gleiche erleben wir jetzt gerade, wenn es um Smart Assistants wie Amazon Alexa, Google Assistant oder Apples Siri geht. Einfach strukturierte Alexa Skills mit geringem Nutzwert nehmen aktuell den größten Raum ein. Selbst große Unternehmen starten mit eher durchwachsenen und wenig durchdachten Sprachanwendungen.

Entdecken Sie den Voice Assistants Track der webinale!

Anwendungsfälle für Smart Assistants

Ich bin persönlich davon überzeugt, dass dies nicht der Fall ist. Während die Kinder seit dem Smartphoneboom ganz natürlich mit Touchscreens aufwachsen, steht die aktuell nachwachsende Generation ganz verblüfft vor einem CD-Player und wundert sich, warum dieser nicht auf Sprachkommandos reagiert. Auch für die ältere Generation werden Smart Assistants eine Chance sein, den Kontakt zur Außenwelt nicht abreißen zu lassen. Wer nicht mehr so beweglich wie früher ist oder weniger gut sehen kann, für den kann eine Sprachsteuerung ein wahrer Segen sein.
Hier ein paar Gedanken, wie konkrete Anwendungsfälle abseits von Ratespielchen, Faktenskills oder dem Hinzufügen von Milch zur Einkaufsliste aussehen könnten:

• • Schon heute funktioniert die Versorgung mit Nachrichten und Unterhaltungsmedien wie Musik oder Hörspielen per Sprachassistenten sehr gut. Der Markt der Voice Games ist groß im Kommen, nicht zuletzt seit der Veröffentlichung der Echo-Buttons für Alexa. Interaktive Spiele für ein oder mehrere Personen werden immer beliebter, erfordern aber auch mehr Fantasie bei Nutzern und Entwicklern, da hier schwache Ideen nicht mehr durch opulente Grafik kaschiert werden können.
  • Unter anderem arbeiten Ford und BMW an der Alexa-Integration in ihre neusten Modelle. Damit wird der Fahrer nicht nur bei der Fahrt und der Bedienung seines Automobils unterstützt, sondern er kann sich auf Nachfrage gezielt mit den gewünschten Informationen oder Musik versorgen, ohne eine Hand vom Lenkrad nehmen zu müssen. Zudem besteht auch eine große Chance, die Unsitte des nervösen Herumgetippes des Fahrers auf dem Smartphone nachhaltig einzudämmen. Somit kann ein Smart Assistant auch zu mehr Sicherheit im Straßenverkehr führen.

• Im Arbeitsleben werden Smart Assistants für Erleichterung sorgen, wenn der ölverschmierte Automechaniker während der Reparatur dringend benötigte Ersatzteile nachbestellen kann oder in einem Meeting der digitale Sprachassistent die aktuellen Umsatzzahlen auf Zuruf liefert. Das Smart Business steckt zwar noch in den Kinderschuhen, doch hat Amazon hierfür bereits die technischen und infrastrukturellen Grundlagen geschaffen.
• Und nicht zuletzt steht auch Voice Commerce noch am Anfang. Von den einen verspottet, von den anderen in den Himmel gehypt, liegt besonders hier die Wahrheit irgendwo in der Mitte. Den Verkauf von regelmäßig benötigten Produkten wie Katzenfutter, Klopapier oder Druckertinte wird sicher von Amazon selbst dominiert werden. Auf der anderen Seite werden wohl nur wenige Nutzer nur mit gesprochenen Inforationen ein paar Turnschuhe, ein Auto oder eine Schrankwand kaufen. Dennoch bietet Voice Commerce viele Ansatzpunkte in Sachen Service und Produktberatung, die in Kombination mit einem klassischen Webshop indirekt zu mehr Kundenzufriedenheit und Umsatz führen können. Interaktive Einkaufsberater können hier den Nutzer eine Vorauswahl treffen lassen, die ihn durch bewussten Medienbruch zu einer maßgeschneiderten Auswahl führen.

UX mit Voice

Doch bis die Smart Assistants genauso in unserem privaten wie beruflichen Alltag dieselbe Rolle spielen wie die Smartphones heute, ist es noch ein langer Weg. Eine Sprachanwendung zu konzipieren und zu entwickeln, ist etwas völlig anderes als eine Website oder eine Smartphone-App. Niemand will sich Dutzende Flugangebote oder Hunderte Produkttreffer von Alexa vorlesen lassen. Es gilt die Faustregel, dass der menschliche Verstand sich nur zwischen drei gehörten Varianten entscheiden kann, während er bei einer visuellen Darstellung viel mehr Optionen erfassen kann.
Somit müssen die Smart Assistants in vielen Bereichen eine Filterfunktion übernehmen.

Ein weiterer wichtiger Unterschied liegt in der Steuerung einer Sprachanwendung im Gegensatz zu einer Website oder einer App. Während auf einem Display der Klick auf einen simplen O.K.-Button recht eindeutig zu verarbeiten ist, müssen wir bei eine Sprachanwendung viele verschiedene Varianten abfangen können. Jeder Mensch spricht anders, die einen sind wortgewaltig, andere einsilbig. Zwischen einem bestätigenden O.K. und „Ja, genau, ich will diese grünen Turnschuhe jetzt sofort haben“ gibt es große Unterschiede.

Zudem müssen Voice-Designer und Entwickler immer auf das Unerwartete vorbereitet sein. Wer auf die Frage „Möchtest du Pizza oder Pasta bestellen?“ nicht sauber auf die Antwort „Ja“ des Nutzers reagieren kann, wird viel Frust ernten oder die falsch gestellte Frage umformulieren müssen. Wenn der Nutzer dann auch noch auf dieselbe Frage mit „12 Uhr“ antwortet und die Sprachanwendung dies nicht verarbeiten kann, wird es ganz schwierig. Während in einer Webanwendung oder einer App bestimmte Prozesse linear ausgestaltet werden können, können wir uns bei einer Sprachanwendung nicht darauf verlassen, dass der Nutzer unserem Prozess wirklich folgt.

Ein weiteres Problem stellen auch die Inhalte an. Wer glaubt, dass er nur seine vorhandenen Blogbeiträge oder Produktdaten durch die Stimme von Alexa oder dem Google Assistant unangepasst vorlesen lassen kann, ist auf dem Holzweg. Was visuell funktioniert, funktioniert rein sprachlich wiedergegeben meist nicht. Ein Produktname wie „Lisdon Denim Herren Straight Fit Leg Jeans Hose (W34/L34)“ mag in einer Darstellung durchaus funktionieren. Wer den Produktnamen aber nur hört, wird Schwierigkeiten haben, das Gesagte zu erfassen.

Um einmal bei Alexa zu bleiben: Die meisten Skills arbeiten recht einfach. Man fordert den Skill auf, etwas zu tun, und dieser antwortet mit dem Wetter, einem Witz oder einer mehr oder minder interessanten Information. Wenige Skills sind wirklich interaktiv, führen einen Dialog mit dem Nutzer und bieten auch unterschiedliche Möglichkeiten für die Nutzung. Das größte Potenzial liegt bei interaktiven Skills, die dem Nutzer helfen, Dinge einfacher zu tun oder zu unterhalten. Und das kann schnell sehr komplex werden.

Monetarisierung und Marketing

Wenn es um die Monetarisierung geht, hat sich in der Vergangenheit einiges getan. Zwar sind bei Amazon immer noch alle Alexa Skills kostenfrei zu nutzen und auch Werbung innerhalb eines Alexa Skills muss sehr strikte Auflagen einhalten. So, ist es z.B. nicht erlaubt, die Stimme von Alexa für Werbung zu verwenden. Dies hat bereits einigen Marktteilnehmern das Genick gebrochen, die auf interaktive Werbung mit Alexa gebaut hatten.

Dennoch gibt es verschiedene Ansätze, wie Unternehmen z.B. ihre Alexa Skills monetarisieren können. Zum einen werden erfolgreiche Skills direkt von Amazon vergütet. Dies kann für einzelne Entwickler oder kleinere Agenturen ein lukratives Zusatzgeschäft darstellen. Ein planbares Zukunftsmodell ist dies aber nicht. Interessanter ist die von Amazon in den USA bereits geschaffene Möglichkeit, per In-Skill-Käufe direkt Produkte oder Dienstleistungen bezahlen zu können. Das schafft die Grundlagen für den Kauf von Medienprodukten oder zusätzlichen Inhalten und Features durch den Nutzer.

Auch weiterhin können gut gemachte Sprachanwendungen auch zur Markenpflege oder Nutzergenerierung beitragen und damit zur indirekten Monetarisierung führen. Durchdachte Sprachanwendungen fördern das Image eines Unternehmens, währen schnell herausgebrachte Voice-Anwendungen und Mee-Too-Skills eher dem Image schaden können. Selbst große bekannte Unternehmen sind bei schlechter Leistung nicht davor gefeit, dass die Nutzer unzufrieden sind und diesen Unmut in negativen Rezensionen freien Lauf lassen. Unternehmen sollten also sich ausführliche Gedanken machen und sich nicht durch Schnellschüsse ihrer Chancen berauben.

Fazit

Das Thema Smart Assistants oder neudeutsch Voice steckt zwar immer noch am Anfang und wird auch aufgrund durchwachsener bisheriger Implementationen zu Recht noch belächelt. Dennoch sind digitale Sprachassistenten gekommen, um zu bleiben. Die Visionen, die teilweise ein halbes Jahrhundert alt sind, lassen sich heute aufgrund der modernen Technologien in die Tat umsetzen.
Doch der Weg ist steinig und darf nicht auf die leichte Schulter genommen werden. Die kreativen Möglichkeiten in der Zukunft sind jedoch lediglich durch unsere Fantasie begrenzt.

The post Smart Assistants – die nächste Stufe der (R)evolution? appeared first on webinale 2025.

Der Markt für digitale Sprachassistenten ist stark in Bewegung. Neben Amazon mit Alexa sind auch Google mit Google Home, Apple mit Siri oder Microsoft mit Cortana am Ball. Und auch Facebook hat für Ende 2017 ein eigenes Endgerät angekündigt. Auf dem deutschen Markt hat sich derzeit (Ende Juli 2017) nur Amazon etabliert. Der Start von Google Home war für Anfang August 2017 geplant. Siri auf dem iPhone und Cortana auf Windows 8 und 10 sind zwar verfügbar, aber eben in Deutschland noch auf keinem digitalen Sprachassistenten, den man sich ins Wohnzimmer stellen kann. Deshalb liegt der Fokus dieses Artikels auf Amazons Alexa. Wenn im Folgenden vom Amazon Echo gesprochen wird, sind auch der Echo Dot und der Echo Show gemeint.

Eine kurze Einführung in Alexa

Ein digitaler Sprachassistent wie der Amazon Echo kann Ihnen sowohl im Haus als auch im Büro einige Arbeit abnehmen. Sie können ihn nach dem Wetter oder den neuesten Nachrichten fragen, Blumen oder eine Pizza bestellen und sogar Spiele spielen. Wenn Sie mit beiden Armen tief im Kuchenteig stecken, können Sie Alexa auch fragen, welche Zutat die nächste ist. Sowohl die Eingabe durch Sie als Nutzer als auch die Ausgabe erfolgt über die Sprache. Mit jeder Frage und mit jeder Aufgabe, die Sie stellen, verbessern sich zukünftige Antworten. Die Idee dahinter ist, dass Alexa mit der Zeit immer intelligenter wird und quasi bei intensiver Nutzung stetig dazu lernt.

Entdecken Sie den Voice Assistants Track der webinale!

Die Fähigkeiten von Alexa lassen sich durch die Alexa Skills erweitern. Amazon stellt dafür mit dem Alexa Skills Shop eine entsprechende Plattform bereit. Dies funktioniert ähnlich wie mit den Apps auf dem Smartphone oder den klassischen Programmen auf Ihrem Notebook. Amazon unterstützt die Entwickler durch ausführliche Dokumentation, Tutorials, Codebeispiele und lokale Events. Das Alexa Skills Kit ist quasi das Frontend des Skills, in dem dieser definiert und konfiguriert wird. Das Backend und damit der eigentliche Skill-Code kann auf einer Lambda Function auf den Amazon Web Services (kurz AWS) oder einem eigenen Server als HTTPS-Endpunkt betrieben werden. Die Lambda Functions auf AWS bieten für die Programmiersprachen Java, C#, Node.js und Python entsprechende Runtimes, die die Entwicklung der Skills mit diesen Programmiersprachen stark vereinfachen. Auf einem eigenen HTTPS-Endpunkt können Sie jedoch mit der Programmiersprache Ihrer Wahl arbeiten – somit auch mit PHP.

Generell verläuft die Verarbeitung einer Abfrage über Amazon Echo in mehreren Schritten:

• Der Nutzer sagt zu Amazon Echo das Schlüsselwort „Alexa“, gefolgt einem Sprachbefehl.
• Diese Aufnahme wird von Amazon Echo an die Amazon-Alexa-Service-Plattform gesendet.
• Die Spracherkennung der Amazon-Alexa-Service-Plattform verarbeitet die Anfrage und versucht, die Intention des Nutzers zu erkennen.
• Die Amazon-Alexa-Service-Plattform erstellt daraus einen JSON Request, der dann zum eigentlichen Skill-Code gesendet wird. Dies kann eine AWS-Lambda-Funktion oder ein anderer HTTPS-Endpunkt sein.
• Der Skill-Code verarbeitet die Anfrage und generiert eine JSON Response, die an die Alexa-Service-Plattform zurückgeschickt wird.
• Die Amazon-Alexa-Service-Plattform wandelt den Text der JSON Response wieder in Sprache um und sendet sie an Amazon Echo.
• Außerdem kann an die begleitende Smartphone-App noch eine Response Card mit weiteren Infos gesendet werden, die von der App dargestellt wird.
• Der Amazon Echo spielt die übermittelte Antwort ab, sodass der Nutzer sie hören kann.

Es liegt auf der Hand, dass diese einzelnen Schritte sehr schnell vonstattengehen müssen. Eine schnelle Internetleitung ist dabei genauso wichtig wie ein schneller Server, auf dem der Skill-Code läuft. Die Performance Ihres Skills ist dabei essenziell.

Planungen für Ihren ersten Skill

Bevor Sie in die Entwicklung Ihres ersten Alexa Skill einsteigen können, sollten Sie sich Gedanken machen, was Sie genau entwickeln wollen. Der wichtigste Tipp hierbei ist, dass Sie Ihren ersten Skill immer möglichst einfach halten sollten. Je komplexer Sie zu Beginn denken, desto größer die Gefahr, dass Sie sich verzetteln und elementare Fehler machen. Deshalb hier ein einfacher Vorschlag, den wir in diesem Artikel zusammen umsetzen können.

Neben der Idee für den Skill brauchen Sie einen Namen sowie einen Aufrufnamen (Invocation Name). Name und Aufrufname können identisch sein, und es empfiehlt sich auch, sie identisch zu halten, damit die Nutzer ihn sich leichter merken können. Beim Aufrufnamen gibt es aber einige Einschränkungen. Er muss in Deutschland aus mindestens zwei Worten bestehen – es sei denn, es handelt sich um einen Markennamen und Sie sind Inhaber dieser Marke. Dass der Aufrufname nicht gegen geltendes Recht verstoßen darf, versteht sich von selbst. Weitere Details finden Sie in der Dokumentation. Um den Skill zu starten, muss Alexa dieser Aufrufname zusammen mit dem Aktivierungswort genannt werden. Dies könnte so aussehen, wobei „Alexa“ das Aktivierungswort und „mein Skill“ der Aufrufname ist: Alexa, starte mein Skill.

Der Skill „Mein Zoo“ kennt sich mit Tieren aus. Sie können Alexa nach einem Tier im Zoo fragen und Alexa antwortet dann mit einem zufällig ausgewählten Tier aus einer vorliegenden Liste. Das klingt trivial, aber bei der Implementierung lernen Sie die wichtigsten Grundlagen der Alexa-Programmierung kennen. Später können Sie den Skill ausbauen, indem Sie gezielt nach einem Vogel oder einem Säugetier fragen. Für Ihren ersten Skill „Mein Zoo“ nehmen Sie als Aufrufnamen denselben Namen in Kleinbuchstaben: „mein zoo“.

Wenn Sie einen neuen Skill entwickeln, sollten Sie zu Beginn immer mehrere Beispieldialoge aufschreiben. Das hilft Ihnen bei der Planung und Konzeption. Ein solcher Dialog könnte wie folgt aussehen:

Nutzer: „Alexa, starte mein Zoo.“
Alexa: „Willkommen in deinem Zoo.“
Nutzer: „Nenne mir ein Tier aus meinem Zoo!“
Alexa: „Ein Elefant lebt in deinem Zoo!“
Nutzer: „Gibt es weitere Tiere in meinem Zoo?“
Alexa: „Eine Giraffe lebt in deinem Zoo!“
Nutzer: „Welchen Vogel gibt es noch in meinem Zoo?“
Alexa: „Ein Papagei lebt in deinem Zoo!“
Nutzer: „Danke Alexa!“
Alexa: „Bitte!“

Sie sollten Ihre Beispieldialoge im Vorfeld so detailliert wie möglich notieren und auch viele Varianten einplanen, sowohl bei den Befehlen und Fragen des Nutzers als auch bei den Antworten von Alexa. Auch sollten Sie für jedes Szenario einen oder mehrere eigene Beispieldialoge aufschreiben. Hier eine Variante, mit der der Skill direkt nach einem Tier gefragt werden kann:

Nutzer: „Alexa, frage mein Zoo nach einem Tier aus meinem Zoo.“
Alexa: „Ein Elefant lebt in deinem Zoo!“

Oder an dieser Stelle noch ein anderes Szenario, bei dem Sie nach der Anzahl der Tiere fragen:

Nutzer: „Alexa, starte mein Zoo.“
Alexa: „Willkommen in deinem Zoo.“
Nutzer: „Wie viele Tiere leben in meinem Zoo?“
Alexa: „In deinem Zoo leben 42 Tiere!“
Nutzer: „Danke Alexa!“
Alexa: „Bitte!“

Nach diesen rudimentären Vorbereitungen können Sie mit der eigentlichen Entwicklung beginnen. Sie sollten aber vorher schon einmal einen eigenen Server einrichten und diesen per HTTPS schützen. Dies erleichtert Ihnen die Prüfung der Konfiguration, ohne dass der Skill-Code im Backend schon fertig ist. Im Folgenden gehen wir davon aus, dass Sie die Adresse https://www.mein-skillserver.de/ verwenden möchten.

Begriffe in der Skill-Entwicklung

Es gibt ein paar Fachbegriffe in der Skill-Entwicklung, mit denen Sie sich vertraut machen sollten:

• Ein Intent ist eine bestimmte Aktion oder auch Intention, die vom Skill ausgeführt werden soll. Dies können eingebaute Intents sein, wie z. B. zum Abbrechen oder für eine Hilfe. Es können aber auch eigene Intents sein. Für den Skill „Mein Zoo“ wäre das Nennen eines Tieres ein AnimalIntent, die Berechnung der Anzahl aller Tiere wäre ein CountIntent.
• Die Utterances oder auch Äußerungen sind als Beispielsätze zu verstehen, mit denen ein bestimmter Intent angestoßen werden soll. Sie müssen hierbei nicht alle möglichen Formulierungen und Varianzen angeben, da Alexa mögliche Abweichungen auch selber erkennen kann. Sie sollten aber dennoch möglichst viele unterschiedliche Phrasen und Sätze verwenden. Bezogen auf den Skill „Mein Zoo“ wäre der Satz „Nenne mir ein Tier aus meinem Zoo!“ eine Äußerung, die den AnimalIntent anstoßen soll.
• Unter den Slot Types sind Platzhalter zu verstehen, die Sie in die Utterances einbauen können und deren Wert dann an den Intent übergeben werden kann. Diese Slot Types stellen im Wesentlichen eine Liste von Optionswerten dar, die Sie fest vorgeben können. Alexa bietet auch eingebaute Slot Types z. B. für Nummern, Datum, Zeiten, Städte, Regionen, Länder, Vornamen, Farben und vielem mehr. Eine Liste aller vorhandenen und zukünftigen Slot Types finden Sie in der Dokumentation.

Begriffe in der Skill-Entwicklung

Um das Alexa Skills Kit nutzen zu können, benötigen Sie einen Amazon-Developer-Account. Die Anmeldung bei einem vorhandenen Account sowie das Registrieren eines neuen Accounts können Sie auf der Anmeldeseite für das Amazon-Developer-Portal durchführen. Nach dem Anmelden sollten Sie auf dem Dashboard landen, das wie in Abbildung 1 aussehen sollte. Nun klicken Sie oben in der Navigation auf Alexa und starten danach das Alexa Skills Kit. Während es schon einiges an deutschsprachiger Dokumentation gibt, ist die Oberfläche im Alexa Skills Kit auf Englisch gehalten. Um einen neuen Skill anzulegen, klicken Sie auf den Add a New Skill-Button oben rechts.

Für die Konfiguration des Skills gibt es sieben Abschnitte, die Sie durchlaufen müssen. Unter Skill Information wählen Sie Skill Type. Für den Skill „Mein Zoo“ sollten Sie den Typ Custom Interaction Model anklicken. Als Nächstes wählen Sie die Sprache aus und geben den Namen Mein Zoo und den Invocation Name mein zoo ein. Die Angaben für Global Fields können Sie alle auf der Option No belassen. Speichern Sie die Angaben; nach dem Neuladen der Seite sollte die Ansicht in etwa wie in Abbildung 2 aussehen. Achten Sie besonders darauf, das für Ihren neuen Skill nun eine Application Id ermitteln worden ist. Diese brauchen Sie später noch. Klicken Sie nun auf den Next-Button.

Im Interaction Model definieren Sie die Intents, die Slot Types und die Sample Utterances. Dies können Sie manuell in Form eines JSON Schemas für die Intents oder Listen für die Slot Types und Sample Utterances machen. Komfortabler ist der Einsatz des Skill Builders. Nach dem Start ändert sich die Oberfläche. Legen Sie nun einen neuen Intent an, den Sie AnimalIntent nennen. Nun können Sie für diesen Intent die Sample Utterances eingeben, z. B. „Nenne mir ein Tier aus meinem Zoo“, „Gibt es weitere Tiere in meinem Zoo“ oder „Welches Tier gibt es noch in meinem Zoo“. Tragen Sie ruhig noch weitere Utterances für diesen Intent ein. Abbildung 3 zeigt, wie dieser AnimalIntent aussehen könnte. Legen Sie danach noch einen zweiten Intent an. Dieser sollte CountIntent heißen, mögliche Sample Utterances wären „Sage mir die Anzahl der Tiere“ oder „Wie viele Tiere leben in meinem Zoo“. Danach klicken Sie erst oben auf Save Model, danach auf Build Model. Nun müssen Sie ein paar Minuten warten, bis das Model erstellt worden ist. Im Code Editor können Sie sich links übrigens Ihr Intent-Schema als JSON genauer anschauen (Listing 1). Ganz wichtig: Entfernen Sie nicht die drei voreingestellten Standard-Intents AMAZON.CancelIntent, AMAZON.HelpIntent und AMAZON.StopIntent. Diese sollten auf jeden Fall von Ihrem Skill-Code verarbeitet werden können. Wenn das Speichern beendet ist, klicken Sie oben auf Configuration.

Unter Configuration sind Sie zurück in der alten Oberfläche. Da Sie keine AWS-Lambda-Funktion verwenden möchten, wählen Sie bei Service Endpoint Type die Option HTTPS. Nun wählen Sie die geografische Region des Servers aus, z. B. Europa, und tragen unten die Adresse Ihres Servers ein, z. B. https://www.mein-skillserver.de/. Wenn Sie nicht für jeden Skill eine eigene Second-Level-Domain verwenden wollen, können Sie auch mit Subdomains oder mit Verzeichnissen arbeiten, z. B. mit https://zoo.mein-skillserver.de/ oder mit https://www.mein-skillserver.de/zoo/. Wichtig ist, dass der Server bereits läuft und über HTTPS erreichbar ist. Ihr Skill-Code muss noch nicht darauf laufen. Wenn Sie hier einen nicht vorhandenen Server angeben, kann es sogar sein, dass Sie einen Out of Date-Fehler erhalten und sich im Amazon-Developer-Portal noch einmal neu einloggen müssen. Wenn das Speichern geklappt hat, können Sie die anderen Parameter so belassen und durch den Klick auf Next zum nächsten Schritt gelangen.

Unter SSL Certificate geben Sie Details zu dem eingesetzten SSL-Zertifikat an. Hier finden Sie auch Links mit weiteren Informationen. Nach der Angabe speichern Sie die Seite und weiter geht es mit Next zum nächsten Schritt.

Auf der Seite Test können Sie Ihren Skill testen. Sie müssen dafür nur kurz das Testen des Skills einschalten. Hier können Sie einmal den Voice Simulator ausprobieren, um Texte von Alexa aussprechen zu lassen. Geben Sie dort einfach mal den Satz „In deinem Zoo gibt es einen Elefanten“ ein, um zu hören, wie Alexa diesen aussprechen würde. Im Service Simulator können Sie den Skill schon einmal testen, auch wenn der Skill-Code noch gar nicht existiert. Geben Sie im Reiter Text den Satz „Alexa starte mein Zoo“ ein und klicken Sie dann auf Ask Mein Zoo. Der Service Simulator erstellt nun den JSON-Service-Request, der an Ihren Endpunkt geschickt werden würde. Da dieser noch nicht fertig ist, lautet die lapidare Antwort „There was an error calling the remote endpoint, which returned HTTP 500: Internal Server Error“. Geben Sie auch mal die Beispielsätze „Welches Tier gibt es noch in meinem Zoo?“ oder „Wie viele Tier leben in meinem Zoo?“ ein und schauen Sie sich an, wie sich der JSON-Service-Request verändert. Details zum Format der Service-Requests finden Sie auch in der Dokumentation.

Der vorletzte Schritt ist Publishing Information. Hier weisen Sie dem Skill eine Kategorie zu, geben Hinweise zum Testen des Skills für das Zertifizierungsteam, tragen eine kurze und eine ausführliche Beschreibung ein, geben die drei wichtigsten Beispielphrasen für die Interaktion mit Ihrem Skill an und können ein großes und ein kleines Logo eintragen. Auf dieser Seite sollten Sie viel Sorgfalt walten lassen, weil diese Informationen Ihren Skill den Nutzern schmackhaft machen sollen. Details dazu folgen im nächsten Abschnitt über den Freigabeprozess.

Der letzte Schritt Privacy & Compliance betrifft Angaben zur Privatsphäre und weitere Details. Außerdem können Sie URLs für eine Seite zu den Nutzungsbedingungen Ihres Skills und der Datenschutzerklärung angeben. Es stärkt auf jeden Fall das Vertrauen der potenziellen Nutzer, wenn Sie beide Informationsseiten für Ihren Skill bereitstellen.

Gerade die letzten beiden Schritte werden erst bei der Veröffentlichung Ihres Skills relevant. Damit sollten Sie sich sehr ausführlich befassen, wenn Ihr Skill-Code fertig entwickelt und getestet ist. Andernfalls ist eine Freischaltung Ihres Skills nicht sinnvoll.

{
  "intents": [
    {
      "name": "AMAZON.CancelIntent",
      "samples": []
    },
    {
      "name": "AMAZON.HelpIntent",
      "samples": []
    },
    {
      "name": "AMAZON.StopIntent",
      "samples": []
    },
    {
      "name": "AnimalIntent",
      "samples": [
        "Welches Tier gibt es noch in meinem Zoo",
        "Welchen Tier gibt es noch in meinem Zoo",
        "Nenne mir einen Tier aus meinem Zoo"
      ],
      "slots": []
    },
    {
      "name": "CountIntent",
      "samples": [
        "Wie viele Tier leben in meinem Zoo",
        "Sage mir die Anzahl der Tiere"
      ],
      "slots": []
    }
  ]
}

Freigabeprozess

An dieser Stelle greifen wir schon ein wenig vor, denn der Skill-Code für Ihren ersten Skill steht noch nicht. Dennoch ist es elementar wichtig, dass Sie den Freigabeprozess kennen und verstanden haben, worauf es ankommt. Nicht wenige Entwickler haben die Erfahrung gemacht, dass ihr Skill nicht sofort vom Amazon-Alexa-Team akzeptiert wurde und sie somit mehrfach nachbessern mussten. Im vorherigen Abschnitt haben Sie unter Publishing Information sowie Privacy & Compliance erfahren, dass diese Informationen für den Freigabeprozess sehr wichtig sind. Auch Fehler bei den Informationen unter Skill Information können zu einer Ablehnung führen.

Wie bereits oben erwähnt, muss der Invocation Name aus zwei Worten bestehen und darf nur einen Markennamen enthalten, wenn Sie Eigner dieser Marken sind. Mein erster Skill Empfangsdame ist übrigens im März 2017 abgelehnt worden, weil ich denselben Namen auch als Aufrufnamen verwenden wollte. Deshalb musste ich den Aufrufnamen auf gäste empfang ändern. Den Namen des Skills auch abändern wollte ich nicht, aber unterschiedliche Namen für den Skill und den Aufruf sind auch nicht optimal. Sie sollten sich somit zu Beginn ausführliche Gedanken auch zu diesen beiden Namen machen, um Fehler zu vermeiden.

Um den Freigabeprozess zu beschleunigen, geben Sie möglichst detaillierte Anweisungen bei Testing Instructions an. Diese Angaben sind explizit für das Zertifizierungsteam gedacht und werden nicht veröffentlicht. Dort können Sie unter anderem angeben, wenn spezielle Hardware erforderlich ist, was in der Regel auf Smart Home Skills zutrifft. Bei Custom Skills wird dies relevant, wenn sich Ihr Skill mit einem Account verbinden soll. Bei den Ländern und Regionen sollten Sie einen deutschsprachigen Skill möglichst nur in Ländern veröffentlichen, in denen die deutsche Sprache gesprochen wird. Dies ist auf den ersten Blick logisch, wird aber auch manchmal falsch gemacht. Möchten Sie Ihren Skill international verfügbar machen, so sollten Sie ihn ins Englische übersetzen. Zukünftig werden sicher auch weitere Sprachen neben Deutsch und Englisch unterstützt. Also sollten Sie ein Auge darauf haben, wenn Sie eine möglichst große Reichweite erzielen möchten.

Die Kurzbeschreibung wird vor allem in der Alexa-App verwendet, während die lange Beschreibung auch im Alexa-Skill-Shop auf der Amazon-Website erscheint. Beschreiben Sie hier Ihren Skill so knapp aber so ausführlich wie möglich. Gerade komplexere Skills sollten mehr Informationen in der langen Beschreibung beinhalten, damit der Nutzer zurechtkommt. Beschreiben Sie auf jeden Fall möglichst alle Kommandos, die in Ihrem Skill verwendet werden können und erläutern Sie auch den Ablauf bei Skills, die interaktiv sind. Sie sollten es aber auch nicht übertreiben und einen simplen Skill mit zu viel Text beschreiben.

Bei den Beispielphrasen können Sie auch in einige Fallen tappen. Wenn Sie hier eine Phrase angeben, die nicht einwandfrei funktioniert oder verstanden wird, senken Sie die Wahrscheinlichkeit für die Freigabe Ihres Skills auf ein Minimum. Geben Sie hier verschiedene Möglichkeiten an, wie Ihr Skill genutzt werden kann. Ignorieren Sie auf keinen Fall die Tipps zu den Beispielphrasen, die direkt darunter angezeigt werden und auch ein paar Beispiele beinhalten. Die Keywords dienen dem besseren Auffinden Ihres Skills. Geben Sie sie in einer kommaseparierten Liste an. Auch hier sollten Sie nicht übertreiben und nur Keywords verwenden, die auch tatsächlich Ihren Skill sinnvoll beschreiben. Das in der Vergangenheit aus der Suchmaschinenoptimierung bekannte Keyword Stuffing sollten Sie hier tunlichst vermeiden.

Bei den Images sollten Sie darauf achten, dass Sie transparente PNGs verwenden und die Größen von 108 x 108 bzw. 512 x 512 Pixel exakt umsetzen. Wichtig ist aber vor allem, dass die Icons rund angezeigt werden. Wenn Sie dies in Ihren Icons nicht berücksichtigen, könnten Bereiche des Bilds bei der Darstellung abgeschnitten werden. Bei dem Motiv sind Sie eigentlich frei, sie sollten aber zu komplexe Motive vermeiden. Teilweise werden die Icons auch in 82 x 82 Pixel angezeigt. Zu komplexe Motive können dann kaum noch erkennbar sein.

Bei den Einstellungen zur Privatsphäre werden Sie unter anderem gefragt, ob Nutzer ihres Skills einkaufen oder echtes Geld im Skill ausgeben können, ob Sie persönliche Daten sammeln, ob sich der Skill explizit an Kinder unter 13 Jahren richtet oder ob er Werbung enthält. Hier sollten Sie auf jeden Fall ehrlich antworten, auch wenn dies zu einer Ablehnung Ihres Skills führen kann. Ein Mathetrainer für Grundschüler oder ein Skill mit dem einzigen Daseinszweck, Werbung zu verbreiten, wird sicher kaum eine Chance haben, in den Alexa-Skill-Shop aufgenommen zu werden. Sie können die Chancen auf eine Freigabe auch erhöhen, wenn Sie mit ausgewählten Nutzern einen Betatest machen. Haben Sie Bekannte, die auch Amazon Echo haben? Dann laden Sie sie zum Betatest ein. Meistens reichen drei bis fünf Nutzer, die den Betatest ernst nehmen, um den Großteil der möglichen Fehler in der Anwendung Ihres Skills zu finden.

Wenn Sie alle Angaben sorgfältig gemacht haben und Ihr Skill-Code ausreichend getestet ist, dann können Sie die Zertifizierung beantragen. Nachdem Sie den Skill abgeschickt haben, prüft das Zertifizierungsteam Ihren Skill intensiv. Je nach Aufkommen neuer Skills und der Komplexität Ihres Skills kann es einige Stunden bis Tage dauern, bis Ihr Skill abgelehnt oder freigegeben wird. Bei einer Freigabe ist alles im Lot und Ihr Skill landet nach wenigen Stunden im Skill-Shop.

Bei einer Ablehnung haben Sie die Möglichkeit, nachzubessern. Lesen Sie sich die Hinweise genau durch und versuchen Sie, die Probleme zu lösen. Versuchen Sie nicht, sich irgendwie durchzuwinden. Es gab Fälle, in denen Entwickler ihren Skill drei bis viermal anmelden mussten, da sie die Anmerkungen des Zertifizierungsteams nicht genau genug befolgt haben.

Vorschau auf Teil 2

Somit sind wir am Ende dieses ersten Teils unserer zweiteiligen Artikelserie angelangt. Sie haben erfahren, wie Alexa im Allgemeinen funktioniert und wie Sie einen Skill planen. Zudem haben Sie einige Grundbegriffe bei der Skill-Entwicklung kennengelernt und die Konfiguration Ihres Skills im Alexa Skills Kit umgesetzt. Zudem haben Sie einige Tipps für die Freigabe Ihres Skills erhalten.

Im zweiten Teil geht es dann an die Umsetzung des Skill-Codes mit PHP. Darin werden die Anforderungen aus der Planung sowie die konfigurierten Intents umgesetzt. Zum Einsatz kommt dafür eine PHP-Library für die Entwicklung von Alexa Skills, die vor Kurzem als Open-Source-Lösung veröffentlicht worden ist. Ich hoffe, Sie schauen auch in den zweiten Teil hinein.

The post Alexa und PHP – ein Dream-Team? appeared first on webinale 2025.

Dem Scrum Prinzip „Inspect and Adapt“ folgend, untersuchen die meisten agilen Entwicklungsteams am Ende des Sprints in der Retrospektive ihre Arbeitsmethoden und versuchen anhand von Erfolgen und Misserfolgen, nötige Maßnahmen abzuleiten, um im Folgesprint bessere Bedingungen für sich und das Produkt zu schaffen. Soweit zumindest die Theorie, denn in der Praxis hört man immer wieder, dass sich in der Regel doch nichts ändert. So zeigte eine während eines Vortrags durchgeführte Umfrage (Eigene, nicht zwingend repräsentative Umfrage während des Vortrags „Agile Feedbackkultur“) auf den Magdeburger Developer Days 2017, dass zwar 98 Prozent der Teilnehmer eine Retrospektive durchführen, aber lediglich 75 Prozent einen Nutzen daraus ziehen.

Einer der Gründe mag sein, dass viele Teams mit der Zeit in eine Routine verfallen und die Retrospektive unbewusst zu einem statischen Teil des agilen Prozesses verkommt. Nach dem Motto „sie findet halt statt und man redet ein bisschen über die vergangenen Wochen“. Mittlerweile gibt es diverse alternative Ansätze zur klassischen Methode, auf die im Laufe des Artikels eingegangen wird. Doch ehe man als Scrum Master nun sein Pulver leichtfertig verschießt und dennoch nicht den gewünschten Effekt erzielt, empfiehlt es sich, zunächst den Kern des Problems aus einem anderen Blickwinkel zu betrachten.

Das Problem mit dem Feedback

In der Retrospektive geht es vor allem um Feedback – Feedback zu geben, aber auch Feedback zu erhalten; nicht nur zu inhaltlichen oder prozessbezogenen Problemen, sondern auch zu zwischenmenschlichen. Wenn man in Wikipedia Feedback nachschlägt, erhält man eine sachliche, trockene Definition, bei der man sich mit einem inneren Schmunzeln nicht wundern darf, warum wir Deutschen im Ausland nicht gerade für unsere Feedbackkultur bekannt sind. Unabhängig von kulturellen Unterschieden in diesem Zusammenhang, erhält der ursprüngliche Sender einer Nachricht durch das Feedback seines Gegenübers dabei Informationen darüber, was „der Empfänger wahrgenommen bzw. verstanden hat“ und kann gegebenenfalls ein Missverständnis rechtzeitig aufklären und klarstellen.

Gerade beim Timing des Feedbacks gehen aber viele Teams den Weg des geringsten Widerstands und so fällt häufig der Satz „das ist ein Thema für die Retrospektive“. Aber warum Warten und Zeit verstreichen lassen? In der agilen Entwicklung sollte jedes Meeting als Gelegenheit für einen Austausch verstanden werden, angefangen vom Kick-off-Meeting, dem ersten offiziellen Termin zum Start der Projekt- bzw. Produktentwicklung. So ist es mehr als empfehlenswert, wenn es um die Erläuterung der Produktvision geht, alle Beteiligten an einem Tisch zu versammeln. Dies schließt neben dem Product Owner und dem Entwicklungsteam die Konzepter, Designer, Tester und natürlich auch die Stakeholder mit ein. Sollte es unterschiedliche Ansichten über die Ausrichtung des Produkts oder z. B. technische Bedenken zur Realisierung geben, so sind diese möglichst früh aufzudecken. Denn wie im klassischen Projektmanagement gilt auch hier, dass die Kosten für die Korrektur steigen, je später das Problem identifiziert wird.

Dieser offene und regelmäßige Austausch lässt sich in etwas abgewandelter Form selbstverständlich auch auf die anderen Meetings des agilen Prozesses anwenden. So werden zwar häufig im Planning II (oder alternativ Architecture Session) noch die im Sprint geplanten Stories in Subtasks unterteilt, über den Lösungsansatz selbst wird aber weit seltener diskutiert. Dies hatte schon wiederholt zur Folge, dass erst im Codereview – nach mehreren Tagen Arbeit an einer größeren Story – die Frage gestellt wurde, warum der umsetzende Entwickler denn z. B. die Nutzerdaten in eine JSON-Datei persistiert und nicht in eine Datenbank wie SQLite. Die Antwort mag einfach wie auch verständlich erscheinen: Damit kannte er sich aus. Der PO wird dagegen alles andere als glücklich über den Zeitverlust sein, sollte SQLite doch die bessere Entscheidung gewesen sein und wird vermutlich fragen, warum sich das Team denn nicht vorher besser abgestimmt hat. Wäre in der Architecture Session bereits über Lösungswege gesprochen worden, wäre durch offenes Feedback vermutlich früher aufgefallen, dass das Team noch kein einheitliches Verständnis zur Persistenz der Daten hat und somit unnötigen Zeitverlust hätte vermeiden können.

Wo fachliche Unterschiede noch relativ schnell zu erkennen sein mögen, wird es bei kulturellen Unterschieden deutlich schwieriger. Gerade in internationalen gemischten Teams prallen hier teilweise Welten und Weltanschauungen aufeinander, die weder auf den ersten noch auf den zweiten Blick direkt zu erkennen sind. Während man den Deutschen noch nachsagt, ihre Meinung stets direkt und schonungslos mitzuteilen, neigen z. B. Menschen aus dem asiatischen Raum eher zur Zurückhaltung und Höflichkeit, was zu grundlegenden Missverständnissen im täglichen Umgang führen kann, wenn die kulturellen Unterschiede bei der Art des Feedbacks nicht berücksichtigt werden. Da nicht jeder mit seinen Arbeitskollegen abends auf ein Bier gehen möchte, der Austausch außerhalb des Büros aber dazu beitragen kann, ein besseres Gefühl für die Art des jeweils anderen zu bekommen, bietet sich hier ein regelmäßiger Teamlunch an. Man kann z. B. die Retrospektive und das Planning so legen, dass dazwischen Zeit für das Team bleibt, einmal im Sprint gemeinsam mittags essen zu gehen.

NEWSLETTER

Alle News zu Web Design, UX und Digital Marketing

Leave this field empty if you're human:

Tapetenwechsel

Bei einigen Projektteams dauert es länger, bei anderen kürzer, aber irgendwann machen sich gewisse Ermüdungserscheinungen bei der Retrospektive im Stile von Mad, Sad, Glad breit (Abb. 1). Häufig zeigt sich dies in geringerer Motivation oder zurückgehender Teilnahme der einzelnen Personen. Das Feedback muss regelrecht herausgekitzelt werden oder beschlossene Maßnahmen aus dem vorherigen Sprint werden seltener umgesetzt. Erfahrene Teams und Scrum Master können innerhalb des gewohnten Vorgehens mit Variationen der Fragestellungen gegensteuern. Bei gemischten oder unerfahreneren Teams hat sich jedoch ein kompletter Tapetenwechsel häufig als die beste Lösung erwiesen.

Dabei gilt es zunächst zu verstehen, was genau die Ermüdung ausgelöst hat. Ist es die Länge des Termins zum Abschluss des Sprints? Oder nimmt sich das Team einfach zu viele Maßnahmen vor? Kommt im Grunde am Ende des Sprints immer nur das gleiche Feedback, wie gut man doch zusammenarbeitet, wie toll die Kommunikation ist und dass nun alles viel besser läuft – obwohl das Sprintziel dennoch ein weiteres Mal nicht erreicht wurde? Im Folgenden werden alternative Ansätze erläutert, die eine Lösung für die drei zuvor beschriebenen Probleme darstellen können.

Die Lightning Retro

Ausgangslage ist ein Team, das im Großen und Ganzen funktioniert und auch keine Probleme mit der Kommunikation hat. Nach einem manchmal nervenaufreibenden Sprint ist die Retrospektive zu einer zähen Diskussion verkommen, in der auch mal das Gefühl aufkommt, sich im Kreis zu drehen oder zu Tode zu debattieren. Andere Teammitglieder haben sich längst aus dem Gespräch rausgezogen und verfolgen mehr oder weniger aufmerksam das argumentative Hin und Her der Rädelsführer. Natürlich ist dies eine überspitzte Darstellung, aber wenn man ehrlich ist, saßen vermutlich die Meisten schon in einer Retrospektive, deren Ende man sich lieber früher als später herbeigesehnt hat.

In Anlehnung an Lightning Talks bekommt bei dieser Alternative zum klassischen Modell jeder Teilnehmer eine zeitlich begrenzte Redezeit von wenigen Minuten, in denen er seine Top 5 des Für und Wider über den Sprint zusammenfasst. Das Team entscheidet in einer kurzen Abstimmung, welche dieser Punkte allgemein gültig sind und für welche Maßnahmen man Action Points ableiten muss. Bei einem verteilten Team kommt man nicht daran vorbei, diese To-dos digital in einem Wiki wie z. B. Confluence zu erfassen. Sitzt das Team lediglich an einem Standort, empfiehlt es sich, pro Maßnahme einen Klebezettel zu erstellen, der dann so platziert wird, dass er bei jedem Daily Scrum sichtbar ist. Dadurch wird gewährleistet, dass die geplanten To-dos nicht während des Sprints vergessen werden. Ziel der Lightning Retro ist die Fokussierung auf das Wesentliche.

30-Minute Retrospective

Ähnlich zur Lightning Retro geht Philip Rogers in seiner „30-minute retrospective“ vor. Dieser Ansatz richtet sich an erfahrenere Teams, die aber wiederum dazu neigen können, sich zu viele Maßnahmen für den Folgesprint vorzunehmen. Im Zentrum der Retrospektive stehen die nachfolgenden vier Fragen:

• Was wollen wir verwerfen?
• Was müssen wir hinzufügen?
• Was sollten wir behalten?
• Was können wir verbessern?

Nach der üblichen Einleitung und Begrüßung durch den Scrum Master nimmt sich jeder Teilnehmer fünf Minuten Zeit, für jede dieser Fragestellungen mindestens eine Antwort zu finden und auf einen Klebezettel zu schreiben. Nach Ablauf der Zeit werden alle Zettel auf einem Whiteboard angeordnet – und zwar auf einem vorbereiteten Koordinatenkreuz in ihren zugehörigen Quadranten (Abb. 2). Zur besseren Visualisierung können unterschiedlich farbige Klebezettel je Bereich verwendet werden. Das Team kommt im Anschluss am Whiteboard zusammen und gruppiert mögliche Duplikate, in dem diese Zettel übereinander geklebt werden.

Im anschließenden Teil der Retrospektive mit einer Dauer von zehn Minuten entscheiden sich die Teilnehmer für einen der vier Quadranten und stimmen darüber ab, an welchen der auf den Zettel notierten Punkte sie im nächsten Sprint arbeiten möchten. Dieses Vorgehen wird für einen weiteren Quadranten wiederholt und liefert somit dem Team die beiden wichtigsten Herausforderungen, die sie als Nächstes angehen wollen. Gemeinsam werden nun analog zur Lightning Retro die Maßnahmen inklusive Verantwortlichem definiert, um die beiden wichtigsten Punkte auch umzusetzen.

Da jeder Teilnehmer sein Feedback zunächst für sich notiert, wird mit dieser Methode sichergestellt, dass sich niemand gegenseitig beeinflusst oder unter Umständen wichtige Punkte von stilleren Personen nicht auf den Tisch kommen. Weiterhin wird nicht nur darauf geschaut, was schlecht lief oder verbessert werden sollte, sondern auch was gut lief und z. B. dringend beibehalten werden muss. Ein Risiko ist dagegen, aufgrund der Begrenzung auf die beiden wichtigsten Punkte sowie Beschränkung auf zwei Quadranten pro Retrospektive, dass kritische Themen aufgeschoben werden. Der Vorteil des geringen Zeitaufwands wird so unter Umständen teuer erkauft. Daher ist dieses Vorgehen erfahrenen Teams zu empfehlen, die genug Flexibilität besitzen, situationsbedingt noch einen dritten oder vierten Punkt zur Diskussion zu stellen.

Die Retrospektive als Geschichte

Nachdem die beiden vorherigen Ansätze sich eher für erfahrenere oder kommunikativere Teams eignen mögen, soll zum Schluss noch eine Methode vorgestellt werden, die auch stilleren und unerfahreneren Teilnehmern ihr Feedback entlocken soll. Dies mag vielleicht am einfachsten gelingen, wenn man weit genug vom klassischen Pfad abweicht und für kurze Zeit eine alternative, fiktive Welt schafft. Dazu bedient man sich einer Bildersprache um eine Geschichte zu erzählen, die tendenziell auch Kritik offen formulieren kann, ohne verletzend, sondern stattdessen konstruktiv zu wirken. Um nicht auf der grünen Wiese zu starten und am Ende völlig unterschiedliche Erzählungen zu erhalten, kann man sich Hilfsmitteln wie Story Cubes bedienen. Dabei handelt es sich um gewöhnliche Würfel, die jedoch statt Zahlen Symbole auf allen Seiten haben (Abb. 3). Diese Zeichen sind bekannte Gegenstände aus dem Alltag wie eine Uhr, ein Telefon oder ein Bierkrug.

Zu Beginn der Retrospektive wird gewürfelt und anschließend hat jedes Teammitglied zehn Minuten Zeit, aus demselben Würfelergebnis eine Geschichte zu formulieren, die seine persönlichen Erlebnisse des gerade abgeschlossenen Sprints beschreiben. Die Symbole sollen dabei die Kreativität jedes einzelnen anregen. Und obwohl alle auf die gleichen Würfel schauen, werden sich die Geschichten dennoch unterscheiden, da jeder mit den Bildern etwas anderes im Rahmen seiner Erzählung assoziiert. Während ein Flugzeug bei einer Person z. B. für Geschwindigkeit stehen kann, verbindet vielleicht jemand anderes damit herausragende Ingenieurskunst, und der Nächste denkt womöglich nur an Pilotenstreiks. Nach Ablauf der Zeit hat jeder Teilnehmer zwei Minuten Zeit, seine Geschichte vorzutragen. Dabei sollte es auch erlaubt sein, die vorbereitete Erzählung abzulesen, um auch introvertierten Personen oder internationalen Teammitgliedern mit möglichen Sprachbarrieren, Hemmungen vor dem freien Sprechen zu nehmen. Wie bei der Lightning Retro sollten im Anschluss auf Basis der vorgetragenen Erzählungen Maßnahmen identifiziert und auf Klebezetteln oder im Wiki notiert werden. Hierbei zeigt die Praxis, dass durch die Verwendung von Bildersprache das Feedback häufig bewusster aufgenommen und daher besser gemerkt werden kann.

Wie der Einsatz von Story Cubes in der Praxis aussehen kann, soll das nachfolgende Szenario veranschaulichen. Auf Basis des fiktiv gewürfelten Beispiels aus Abbildung 3 könnte ein Teammitglied folgende kurze Geschichte erzählen:

• Wir haben alle kritischen Bugs unserer Mobile-App beseitigt und rechtzeitig den drohenden Brand vermieden.
• Für den weltweiten Roll-out werden wir jedoch einige Nachtschichten benötigen.
• Das Team ist zwar stolz auf das Ergebnis, leidet aber stark unter dem Druck des Managements und hat zu wenig Klarheit über die nächsten Ziele

Der hier erzählende Teilnehmer beschreibt in seiner Geschichte, was gut lief und welcher Einsatz dafür nötig war. Aus dem positiven Feedback lässt sich daher auch eine Lehre ziehen. In diesem Beispiel waren die Softwarebugs offenbar geschäftskritisch. Aber hätten sie vorab vermieden werden können? Kann das Team nun Maßnahmen ableiten, damit sich dies in Zukunft nicht wiederholt? Darüber hinaus äußert der Erzähler eine Sorge für die weiteren Sprints. Die Arbeitslast aufgrund des nahenden Roll-outs scheint so groß zu sein, dass das bestehende Team nur mit Nachtschichten dagegen ankommt. Sollte diese Einschätzung bestätigt werden, wurde hier rechtzeitig die Hand gehoben, um Maßnahmen zu ergreifen, ehe der Schaden entsteht. Kann man vielleicht den weltweiten Roll-out in kleinere Phasen unterteilen und verschiedene Länder der Reihe nach launchen? Oder Teile der Arbeit auf andere Teams verteilen? Zu guter Letzt wird eine klare Kritik am Management geäußert, die aber wertvolles Feedback enthält. So ist dem Erzähler offenbar nicht immer klar, warum er bestimmte Aufgaben erledigen soll. Wer aber nicht weiß, warum er etwas tut, handelt meist nicht im Sinne des Produkts und ist auch nicht in der Lage, rechtzeitig und proaktiv Probleme aufzuzeigen.

Öfter mal was Neues

Auch wenn die klassische Retrospektive für viele Projektteams vermutlich vollkommen ausreichend erscheinen mag, sollte man regelmäßig einen Schritt zurücktreten und nach Anzeichen für Ermüdungserscheinungen in der täglichen Ausführung, monotone Prozesserfüllung oder ineffiziente Routine Ausschau halten. Da sich trotz Scrum manche Menschen mit Veränderungen schwertun, muss man hier behutsam die bestmöglichen Methoden abwägen. Statt gleich das ganze Vorgehen der Retrospektive zu ändern und damit vielleicht mehr Schaden als Nutzen anzurichten, lässt sich auch im Kleinen anfangen und die anderen Meetings im agilen Entwicklungsprozess wie eingangs beschrieben besser für Feedback und Austausch nutzen. Hat man damit Vertrauen im Team geschaffen, wächst häufig auch die Bereitschaft für größere Schritte, einfach mal etwas auszuprobieren, getreu dem Motto „öfter mal was Neues“. Denn schließlich lehrt uns Scrum, es im Bedarfsfall erneut anzupassen, wenn nicht die gewünschten Verbesserungen erzielt wurden.

The post Immer neu statt wie immer appeared first on webinale 2025.

Am Anfang des Podcasts steht das Wort. Doch gemeint ist an dieser Stelle noch nicht das gesprochene, sondern das geschriebene, und zwar in Form eines Konzepts. Sie sollten sich also zunächst Gedanken über die Länge, die Sendefrequenz und die Inhalte der einzelnen Folgen machen. Formulieren Sie am besten ein Ziel für Ihren Podcast und bleiben Sie dabei realistisch. Das Ziel motiviert Sie, dranzubleiben. Ohne Ziel können Sie den Erfolg im Nachhinein nur schwer einschätzen.

Wenn Sie bereits eine große Leserschaft haben, dann muss das nicht bedeuten, dass Ihnen alle auch hörend folgen. Die Zahl der Podcasthörer ist zwar nicht klein – die letzte Onlinestudie von ARD und ZDF hat 7,3 Millionen Zuhörer gezählt. Doch sind Podcasts kein Massenmedium, sondern eher eine Nische. Genau das ist allerdings ihre Stärke: Podcasts bedienen die Interessen der Menschen sehr zielgerichtet. Sie können Podcasts hören, wann und wo sie wollen, sogar offline und beim Joggen oder Bügeln.

Worüber kann ich reden?

Vielleicht starten Sie erst einmal mit bereits von Ihnen veröffentlichten Texten. Postings mit vielen Screenshots, die für die Nachvollziehbarkeit nötig waren, sind weniger gut für reines Audio geeignet. Ich würde beispielsweise meine Texte über den Audioeditor Audacity nicht in einen Podcast umwandeln, denn Dinge wie „dann wählen Sie in der Menüleiste Spuren und im sich öffnenden Drop-down-Menü Mono …“ klingen nicht besonders ansprechend. Dafür eignen sich schriftliche Tutorials oder Screencasts einfach besser. Doch gibt es sicherlich Beiträge, bei denen das gesprochene Wort einen Mehrwert bietet, weil man Ihr Engagement für den Inhalt in der Stimme hört, Sie eine kleine Geschichte zu erzählen haben (wir lieben Geschichten) oder von eigenen Erfahrungen berichten können.

Damit Sie Ihren Hörern nicht den Eindruck vermitteln, einfach alten Wein in neuen Schläuchen anzubieten, sagen Sie Ihren Hörern, dass es diesen Inhalt bereits als Lesetext auf Ihrem Blog gibt. Auch den Player würde ich genau dort einbinden und keinen neuen Blogbeitrag dafür erstellen. In Ihrem Podcast-Feed erscheint die Episode jedoch mit dem aktuellen Datum und ist in den Podcastverzeichnissen wie iTunes oder podcast.de zu finden. In den Shownotes sollten Sie dann konsequenterweise auf den bestehenden Text verlinken.

Der Vorteil dieser Vorgehensweise ist, dass Sie sich erst einmal keine Gedanken um Inhalte machen müssen. Außerdem können Sie einige Sendungen vorproduzieren und diese in einem schnellen Takt veröffentlichen. Das wird von iTunes positiv bewertet, Ihr Podcast wird gut gerankt und Ihre Fangemeinde vergrößert sich.

Doch vielleicht möchten Sie lieber originäre Inhalte für Ihren Podcast produzieren, Interviews mit Fachleuten führen oder den Beitrag gemeinsam mit einem Kollegen bzw. einer Kollegin einsprechen? Auch diese Überlegungen gehören in Ihr Podcastkonzept.

Entdecken Sie den Online Marketing-Track der webinale!

Achtung, Aufnahme!

Welches das richtige Mikrofon ist, darüber kann man lange reden. Ich bin der Meinung, dass man nicht die Audioqualität eines Podcasts des öffentlich-rechtlichen Rundfunks zum Maßstab nehmen muss. Doch natürlich stehen unsere Podcasts in den Verzeichnissen neben diesen und anderen professionellen Produktionen. Außerdem möchte auch keiner einer verrauschten, dünnen Aufnahme lauschen.

Gute Mikrofone gibt es im Fachhandel heutzutage bereits unter 100 Euro. Die Anschaffung ist zum einen von Ihrem Geldbeutel abhängig und zum anderen von Ihrer Aufnahmesituation. Bewegen Sie sich gerne beim Sprechen, dann eignet sich ein Headset besser als ein Mikrofon auf einem Stativ. Möchten Sie bei der Produktion mobil sein, dann ist ein digitaler Rekorder vielleicht die bessere Wahl. Oder Sie erweitern Ihr Mobiltelefon zu einer smarten Aufnahmeeinheit.

Der Raum der Aufnahme sollte nicht zu hallig sein, denn Raumhall können Sie bei der Bearbeitung kaum noch entfernen. Vorhänge, Wolldecken, Teppiche und Bücherregale schaffen einen guten Raumklang. Von einer Aufnahme im Badezimmer sollten Sie also absehen. Probieren Sie aus, ob Ihre Stimme besser klingt, wenn Sie stehen oder wenn Sie sitzen. Kommen Sie gut rüber, wenn sie frei sprechen und nur mit einer Stichwortliste die Inhalte strukturieren? Oder gibt Ihnen ein ausführliches Skript mehr Sicherheit? Probieren Sie es aus und experimentieren Sie! Und nehmen Sie Dali wörtlich, der sagte: „Hab’ keine Angst vor Perfektion – du wirst sie ohnehin nicht erreichen.“

Egal, ob Sie mit einem Audioeditor oder einem digitalen Rekorder aufnehmen: Achten Sie darauf, dass Ihre Aufnahme gut ausgesteuert ist. Die Aussteuerungsanzeige sollte sich dabei auf der dB-Skala im oberen Drittel, etwa bei -6 Dezibel (dB), bewegen. Dann haben Sie immer noch sogenannten Headroom bis zur Null, falls Sie doch zwischenzeitlich etwas lauter werden. Alles, was über die Null der Skala hinausgeht, ist übersteuert und führt zu einem beschädigten Audiosignal. Eine nachträgliche Senkung der Dezibel hilft dann in der Regel auch nicht mehr. Sicherheitshalber im unteren Bereich der Skala zu bleiben, ist auch keine gute Idee. Denn wenn Sie im Nachhinein das Aufnahmesignal verstärken, verstärken sie ebenfalls sämtliche Nebengeräusche. Ein leises Brummen des Lüfters Ihres Rechners kann dann Ihre ganze Aufnahme ruinieren. Die Aufnahme einfach leise zu lassen, ist natürlich ebenfalls keine Lösung. Ihre Hörer regeln dann selbst die Lautstärke hoch, und wenn der nächste Podcast ordentlich aufgezeichnet wurde, platzt ihnen sprichwörtlich das Trommelfell.

Einen Audioeditor benötigen Sie, um Pausen, „Ähms“ und „Ähs“ oder auch Versprecher zu entfernen, und für das Erstellen einer für das Internet tauglichen Datei. Ihre Aufnahme sollten Sie in einem nicht komprimierten Format aufzeichnen und erst nach dem Audioschnitt in eine komprimierte (in der Regel MP3-)Datei exportieren. So können Ihre Podcastepisoden schnell im Internet hoch- bzw. heruntergeladen werden, und Sie verbrauchen nicht zu viel Speicherplatz im Netz.

Audacity ist eine kostenlose Audioschnittsoftware, und es dauert nicht lange, bis man die Grundlagen des Schneidens von Audioaufnahmen beherrscht. Es läuft unter Mac, Windows und Linux und ist damit recht universell einsetzbar. Die Audiosoftware ist destruktiv und benötigt daher nicht so viele Ressourcen, man kann also auch gut auf älteren PCs oder leistungsschwachen Netbooks damit arbeiten. Alternativ dazu empfehle ich gerne Hindenburg Journalist, eine Software, die speziell für den Audioschnitt entwickelt wurde und nicht durch zu viel Schnickschnack überfrachtet ist.

Last but not least sollten Sie sich noch einen Kopfhörer anschaffen, der Klang neutral wiedergibt. Das schont Ihre Mitmenschen beim Audioschnitt, und alles, was Sie direkt auf die Ohren bekommen, können Sie besser wahrnehmen, also auch Schmatzer und andere Sprechgeräusche.

Musik – woher nehmen?

Möchten Sie Ihre Aufnahme noch mit Musik verschönern? Einen Jingle in das Intro einbauen oder den gesamten Beitrag mit Musik unterlegen? Auch das ist mit einem Audioeditor kein Problem. Im Internet finden Sie viele Quellen, die Musik anbieten, doch ist die Art der Verwendung nicht immer ganz verständlich geregelt.

Auf den jeweiligen Portalen erwerben Sie Lizenzen, die Ihnen die Nutzung eines Titels in Ihrem Podcast erlaubt. Übrigens vergibt auch die GEMA solche Podcaster-Lizenzen. Häufig gelten diese Lizenzen für ein Projekt. Doch nicht immer wird von den Anbietern ein kompletter Podcast als ein Projekt angesehen, sondern jede Episode für sich. Da wachsen dann ein paar Euro für die Nutzung schnell zu einer stattlichen Summe an.

Bei kostenlosen Angeboten, die beispielsweise die Nutzung über Creative-Commons-Lizenzen regeln, achten Sie unbedingt darauf, welche Rechte Ihnen eingeräumt werden. Dürfen Sie die Titel für kommerzielle Zwecke nutzen? Dürfen Sie sie bearbeiten, und gibt es Vorgaben, unter denen dann Ihr Werk weitergegeben werden darf? Müssen Sie den Künstler nennen? Drei sichere Quellen, bei denen Ihnen die Lizenz erlaubt, den Titel in jeder Folge zu spielen, sind z. B. Cayzland Music, gemafrei.media und das Portal Klangarchiv.

Eine Audiodatei macht noch keinen Podcast

Der RSS-Feed ist das, was eine Audiodatei erst zu einem Podcast macht. Dieser Feed, eine XML-Datei, wird nur einmal erstellt und aktualisiert sich dann automatisch mit jeder neuen Episode. Sie können diesen Feed mithilfe eines Podcast-Hosting-Services oder mit einem Podcast-Plug-in auf Ihrer Website erstellen. Der einfachste und schnellste Weg zum Feed ist sicherlich, auf einen Hosting-Service zu setzen. Dieser bietet Ihnen Speicherplatz für Ihre Audiodateien, eine Statistik, einen Player, und er garantiert, dass Ihre Inhalte auch richtig bei Ihren Hörern ankommen.

Der Server muss Byte-Range-Anfragen unterstützen, damit Ihre Beiträge auch gestreamt werden können. iTunes quittiert Ihnen die Anmeldung Ihres Podcasts sonst mit einer Fehlermeldung. Die Services bieten ebenfalls einen Blog an. Wenn Sie aber bereits über eine WordPress-Seite verfügen, können Sie dieses Angebot ignorieren und leiten in den Einstellungen auf Ihre Homepage um. Von dieser verlinken Sie auf die bei dem Hoster hochgeladene Datei oder bekommen – zum Beispiel bei Podigee – einen JavaScript Code, den Sie lediglich auf einer Seite oder in einem Blogbeitrag mit Copy-and-paste platzieren. Der Feed wird durch Informationen von Ihnen erstellt: einer Beschreibung der Inhalte, Angaben zu den Kategorien, unter denen er in den Verzeichnissen gefunden werden soll, das Podcastcover sowie Informationen zu Ihrer Person.

Nutzen Sie keinen Hosting-Service, dann benötigen Sie ein Podcast-Plug-in, das den Feed generiert. Die Angaben dafür sind die gleichen, doch hosten Sie in der Regel dort, wo auch Ihre Seite gehostet wird, und Sie können Ihre Audiodateien über die Mediathek in Ihrem WordPress-Dashboard hochladen. Auch bei den Podcast-Plug-ins gibt es eine größere Auswahl. Sehr beliebt, besonders in der freien Podcastszene, ist der Podlove Podcast Publisher. Nach der Installation und der Aktivierung des Plug-ins sehen Sie unter Beiträge den zusätzlichen Menüpunkt Episoden. Es findet also eine übersichtliche Trennung zwischen Podcastfolgen und Blogbeiträgen statt. Unter Podlove im Dashboard finden Sie die Einstellungen und können dort auch Ihren Feed „füttern“.

Der Podlove Podcast Publisher bietet interessante Features, die modular aufgebaut sind und an die eigenen Anforderungen angepasst werden können. Dazu gehört unter anderem eine aussagekräftige Statistik, die neben den Downloadzahlen auch zeigt, wie Ihre Hörer den Podcast hören: z. B. direkt mit dem Player auf Ihrer Homepage oder über den Feed. Sie können außerdem den Podlove-Subscribe-Button integrieren, der das Abonnieren Ihres Podcasts sehr komfortabel für die Hörerinnen und Hörer macht. Der Podlove Web Player bildet sogar Kapitelmarkierungen ab, sodass man gezielt in der Audiodatei springen kann. Das ist besonders bei längeren Episoden ein tolles Feature. Die Kapitelmarkierungen liefern außerdem zusätzliches Material für die Suchmaschinen, allerdings kann das auch der Player des Podcast-Hosting-Services Podigee.

Der Podlove Podcast Publisher wird stets weiterentwickelt und orientiert sich an den Bedürfnissen der Podcasterinnen und Podcaster. Das Ganze ist übrigens ein Open-Source-Projekt, das sich über Spenden finanziert.

Gute Erfahrungen habe ich mit dem Blubrry-PowerPress-Podcasting-Plug-in gemacht. Verschiedene Modi helfen bei der Erstellung des Feeds. Eine einfache Statistik können Sie sich in Ihrem Dashboard anzeigen lassen, weitere Angaben über die Nutzung sind kostenpflichtig. Das Plug-in erzeugt ein zusätzliches Eingabefeld unter jedem Beitrag, in das Sie den Link zu Ihrer Episode eintragen. Im Beitrag wird dann, je nach Ihren Vorgaben, der Player über oder unter dem Text des Blogs platziert. Mithilfe eines Shortcodes lässt sich der Player auch in der Mitte eines Texts oder auf einer Seite darstellen. Das Blubrry PowerPress Podcasting Plug-in bietet weitere interessante Möglichkeiten, unter anderem eine Unterteilung in Kategorien – wenn Sie mehr als einen Podcast produzieren –, die Erstellung einer Playliste sowie eine Optimierung für die Suchmaschinen.

Blubrry ist Kooperationen mit anderen Unternehmen eingegangen, und so gibt es weitere, zum Teil kostenpflichtige Tools für die Verbreitung Ihres Podcasts. Sie können Ihren Podcast auch kostenpflichtig bei Blubrry selbst hosten. Das Plug-in funktioniert jedoch mit jedem Link, auch mit Links von anderen Podcast-Hosting-Services, wie PodHost oder podcaster.de. Oder eben mit einem Link aus Ihrer Mediathek, wenn Sie lieber alles unter einem Dach haben.

Mein Ratschlag ist: Schauen Sie sich um, was Sie an weiteren Podcast-Plug-ins finden und welche Features Ihren Wünschen entsprechen. Das Buzzsprout-Podcast-Plug-in funktioniert beispielsweise nur über deren Server, und die Dateien werden „optimiert“. In diesem Fall bedeutet das, die Audiodaten werden verkleinert, damit sie geringere Speicherkapazitäten brauchen. Seriously Simple Podcasting ist wirklich „simpel“, bietet jedoch alles, was man zum Podcasten braucht, und auch hier werden Textbeiträge und Podcastepisoden im Dashboard getrennt.

Trommeln Sie für Ihren Podcast

Lange ist die Zeit vorbei, da man einen Podcast veröffentlicht hat, er sogleich in den Podcastverzeichnissen als „neu“ prominent gezeigt wurde und so eine besondere Aufmerksamkeit bekam. Podcasthören ist spätestens seit „Böhmermann und Schulz“ und „Serial“ auch in Deutschland weit verbreitet, und eine aktuelle Studie der ARD-Werbung Sales & Services GmbH zeigt, dass mit Podcasts eine differenzierte Zielgruppenansprache möglich ist.

Der erste Schritt bei der Podcast-Vermarktung ist die Anmeldung Ihres Podcasts in den Podcastverzeichnissen; zu den wichtigsten gehören auf jeden Fall iTunes, podcaster.de und podster. Dort tragen Sie Ihren Podcastfeed ein, der sich dann mit jeder neuen Folge automatisch aktualisiert. Der Eintrag ist kostenlos und nur einmal nötig. Allerdings funktioniert das nur, wenn bereits eine erste Folge veröffentlicht wurde.

Auf keinen Fall sollten Sie auf ein Podcastcover verzichten. Das sollte nach Möglichkeit ein echter Hingucker sein, der Ihren Hörern bereits einen Vorgeschmack gibt und zum Reinhören motiviert. iTunes empfiehlt hier eine Größe von 3000 x 3000 Pixel.

Schnell und preiswert können Sie Ihre Sendungen über die Social-Media-Kanäle verbreiten, in Foren oder Gruppen im Internet auf ihn hinweisen. Besonders zum Start des Podcasts richtet auch eine Onlinepressemeldung die Aufmerksamkeit auf Ihren Podcastblog. Trommeln Sie da, wo Ihre Zielgruppe ist! Treffen Sie sie nicht bei Facebook und Co., dann verteilen Sie Flyer, machen Sie auf Veranstaltungen und in Seminaren auf Ihren Podcast aufmerksam. Informieren Sie die Presse oder gehen Sie Kooperationen mit Organisationen ein, die die gleiche Zielgruppe (jedoch ein anderes Angebot) haben. Seien Sie kreativ bei der Vermarktung Ihres Podcasts und gewinnen Sie viele und vor allem die richtigen Hörer.

The post Hör mir zu! appeared first on webinale 2025.

Auch in der Frontend-Entwicklung sind solche Standards entstanden. Allerdings werden sie kaum beachtet. Sie haben leider nie die normative Kraft entfaltet, die ihnen zustehen würde, denn schließlich arbeiten viele unterschiedliche Entwicklertypen mit Frontend-Code. Insbesondere diejenigen, die wenig Kenntnisse und noch weniger Motivation für guten Frontend-Code haben, würden von guten und verständlichen Standards profitieren.

Vor der hilfreichen Benennungsrichtlinie steht aber der richtige Blick auf den Frontend-Code. Dabei müssen wir immer bedenken, dass wir mit HTML und CSS Designs umsetzen, also primär eine Verbindung zur Optik haben, nicht aber zur Programmierung.

Eine Seite besteht aus vielen LEGO-Steinen

Eine Webseite setzt sich aus vielen unterschiedlichen Einzelteilen zusammen: Es gibt einen Header, meist einen Footer und einen mehr oder minder stark unterteilten Inhaltsbereich. Im Inhaltsbereich können sich eine Fotogalerie, Teaser, ein großer Fließtext und vieles andere mehr befinden. Alle diese Bestandteile können und sollten für sich selbst betrachtet werden.

Eine Webseite ist dann eine Zusammenstellung aus vielen Einzelteilen. Meist werden sie aus einem CMS gespeist. Die Analogie zu LEGO liegt auf der Hand. Auch bei LEGO werden Objekte aus unterschiedlich großen Einzelteilen zusammengesetzt.

Im Grunde entwickeln wir keine Seiten, sondern „Systeme“. Die Einzelteile dieser Systeme bezeichne ich als „Module“. Mittlerweile wird auch gerne der Begriff „Patterns“ benutzt. Die Module sind prinzipiell unabhängig voneinander, jedes ist ein eigenes kleines Universum. Gängige Module sind beispielsweise:

• Navigationen
• Linklisten in Seitenleisten oder im Footer
• Teaserboxen – mit oder ohne Bild
• Slider/Karussell
• in einem Akkordeon organisierte Inhalte
• in einem Tabinterface organisierte Inhalte
• eine eingebettete Landkarte

Abb 1: Einzelne Module der Startseite der ZEIT markiert

Abbildung 1 repräsentiert eine nicht mehr aktuelle Version von ZEIT.de. Sie zeigt die modulare Zusammensetzung der Seite. Mitte 2017 sieht die aktuelle Version von ZEIT ONLINE (www.zeit.de) aus wie in Abbildung 2.

Abb. 2: ZEIT ONLINE Mitte 2017 – einzelne Module markiert

Dave Rupert hat in seinem Screenshot des Microsoft-Designs die gleichartigen Module markiert (Abb. 3). Dabei sollte auffallen, dass das Modul „Linkliste“ durchaus unterschiedlich aussieht. Optische Abweichungen sind also kein Grund, ein neues Modul zu erschaffen. Man sorgt stattdessen dafür, dass ein Standard erstellt wird. Und von diesem gibt es mittels zusätzlicher Klassen die notwendigen optischen Abweichungen.

Abb 3: Der Aufbau der 2012 redesignten Seite von Microsoft (Quelle: http://daverupert.com/2013/04/responsive-deliverables)

Erst der Sinn, dann die Optik

Vergessen Sie bitte nie, dass CSS und JavaScript nur die Erweiterungen für die gute Basis, das semantische HTML sind. Bevor Sie also anfangen, die Gestaltung mit CSS umzusetzen, sollten Sie zuerst sinnvolles HTML erzeugen.

Wenn Sie Designentwürfe zur Verfügung haben, drucken Sie sie am Besten aus, schneiden die Module aus und gruppieren diese dann nach Ähnlichkeit. Ähneln sich zwei Module sehr stark – gibt es nur geringe Abweichungen –, so ist die Wahrscheinlichkeit hoch, dass Sie nur ein Modul und eine kleine Modifikation erstellen müssen. Dazu später mehr.

Setzen Sie als Nächstes diese Module in semantischem HTML um. Suchen Sie sich also aus dem größer gewordenen Sprachumfang die passenden Elemente für die jeweiligen Inhalte heraus. Es gibt wesentlich mehr als nur div, p und span. Für die Gestaltung sollten Sie den einzelnen Bestandteilen der Module noch passende Klassennamen geben.

Erst wenn Sie sich Gedanken über das korrekte HTML gemacht haben, sollten Sie sich mit CSS und JavaScript beschäftigen. Und denken Sie immer daran, welches HTML-Element dem Sinn nach genutzt werden sollte, nicht der Optik nach. Schließlich besteht ein Teil der späteren Arbeit darin, die eigentlich gewohnte Optik von Elementen stark zu verändern. Bei Navigationen machen wir dies immer. Niemand sieht ihnen an, dass sie eigentlich Listen sind. Mit ein wenig CSS können auch Absätze ganz schnell wie Listen aussehen (Abb. 4).

Abb. 4: Absätze können wie Listen aussehen (https://goo.gl/tWtyYc)

Layout und Design

Die einzelnen Module sollen später auf der Webseite platziert werden. Diese horizontale und vertikale Verteilung von Inhalten nennen wir „Layout“. Üblicherweise nutzen wir hierfür Grids, meist auf der Basis von Floats. Wenn den einzelnen Modulen dann eine Optik verpasst wird, so sprechen wir von „Design“. Design ist also im Idealfall „schön“.

Das Layout ist unabhängig vom jeweiligen Design, das sich im Wesentlichen mit Farben, Größen und Abständen beschäftigt. Es ist auch unabhängig von den zu verteilenden Inhalten. Deshalb sollten Sie beide Ebenen trennen. Erstellen Sie erst ein Layoutraster, in dessen leere Container Sie dann die Module platzieren. Den Modulen sollte dabei die exakte Platzierung egal sein. Wenn Sie alles richtig gemacht haben, sieht die Navigation immer noch korrekt aus, wenn man sie (auch gerne zusätzlich) in den Seiten-Footer platziert. Ein Beispiel für ein Layoutgerüst (ohne Inhalte) zeigt Listing 1.

Listing 1: Layoutgerüst

<div class="ym-grid">
  <div class="ym-g60 ym-gl">
    <!-- Hier kommt das Inhaltsmodul hin! -->
  </div>
<div class="ym-g40 ym-gr">
    <!-- Hier kommt das Inhaltsmodul hin! -->
  </div>
</div>

Wir diskutieren hierbei nicht über die korrekte Verwendung von Klassen. Mir ist nur wichtig zu zeigen, dass mit dieser einfachen Struktur und diesen wenigen Klassen ein Grid erzeugt wurde. In diesem Fall ist der erste Container 60 % breit und der zweite 40 %. Das Beispiel wurde dem CSS-Framework YAML entlehnt.

In obigem Beispiel sind die Grid-Container ungleich. Nutzen Sie solche Konstrukte, um die Flexibilität Ihrer Module zu testen. Ein Teaser sollte in beiden Containern gut aussehen. Geben Sie den Modulen selber niemals eine Breite und am Besten auch niemals eine Höhe. Angesichts der Vormachtstellung der Smartphones beim globalen Internetzugriff ist Flexibilität eine der Kerneigenschaften für gute Module.

Jedes Modul ist eine eigene Welt

Damit wir im Frontend wirklich modular entwickeln, müssen wir auch die entstehenden Module als eigene Einheiten verstehen. Im CSS beginnen die Selektoren dementsprechend mit dem Modul selber oder einem seiner Bestandteile. Sie sollten immer verhindern, einen Teil des umgebenden DOM mit in die Selektoren zu schreiben (Listing 2).

/* --------- So macht man das! ------------ */
/* Das Modul steht für sich. */
.videowrapper {
  /*  Eigenschaften */
}
.videowrapper iframe {
  /* Eigenschaften */
}

/* ----------- keine gute Idee! ------------ */
/* Was, wenn der Videowrapper demnächst in einem
   anders benannten Container stecken sollte? */

.maincnt .videowrapper {
  /*  Eigenschaften */
}
.maincnt .videowrapper iframe {
  /* Eigenschaften */
}

Die zweite hier vorgestellte Vorgehensweise ist sehr stark verbreitet. Dabei wird der Selektor meist noch viel mehr aufgebläht. Manchmal wird fast das gesamte DOM abgebildet. Das hat zwei Nachteile:

1. Die Spezifität wird (stark) erhöht, sodass es immer schwerer wird, Abweichungen zu definieren. Selbst die Modifikatorklassen würden einen ähnlich komplexen Selektor benötigen. Oder man resigniert und verteilt !important.
2. Die Abbildung von Selektoren vor dem Modul macht das Modul schwer transportabel. Man könnte es in einem anderen Projekt nur dann nutzen, wenn auch dort eine gleich benannte, ähnlich aussehende Struktur existierte. Sollte sich die Struktur der Webseite zwischen Planung und Endversion oder zwischen zwei Projekten grundlegend ändern, ist die Wahrscheinlichkeit hoch, dass solche Selektoren nicht mehr ziehen werden.

Jedes Modul sollte für sich selbst stehen. Erfolgreiche UI-Frameworks wie Bootstrap oder Foundation funktionieren exakt so. Auf den jeweiligen Übersichten stehen beispielsweise mehrere Navigationen untereinander, denen Formulare und Tabellen folgen können. Alle sind aus einem etwaigen Zusammenhang gerissen und sehen trotzdem wie gewünscht aus.

Machen Sie den Test mit Ihrem eigenen Projekt: Erstellen Sie eine Datei ohne den üblichen Rahmen. Nutzen Sie ein vollkommen neues Grid, das Sie in Ihrem Projekt nicht nutzen, und platzieren Sie dann mehr oder minder willkürlich die Module Ihrer Webseite auf dieser Testseite. Sie werden nun auf einen Blick sehen, welche Module eine bestimmte Struktur benötigen, damit sie wie gewünscht aussehen. Mit dem CSS dieser Module beginnen Sie dann die Überarbeitung Ihres Projekts.

Klassen benennen

Es gibt unterschiedliche Methodiken, die sich mit der Benennung von Klassen, dem Aufbau von Selektoren und der Struktur des CSS befassen. Doch bevor Sie sich über die passende Methodik Gedanken machen, sollten Sie für sich (und Ihr Team) ein paar Grundregeln abstimmen:

1. Nutzen Sie englisch- oder deutschsprachige Klassennamen? Englischsprachige haben den Vorteil, dass sie keine Hürde darstellen, wenn Sie einmal bei Stackoverflow eine Frage mit Codebeispielen haben. Entscheiden Sie sich für eine Sprache und bleiben Sie dabei konsistent.
2. Die Klassennamen sollten nicht eng an die Optik gekoppelt sein. Eine Klasse .blue ist nur so lange praktisch, bis man die damit verbundene Gestaltung auf Kunden- oder Designerwunsch in rot ändern muss.
3. Zu enge inhaltliche Verknüpfungen sind aber auch nicht praktisch, denn eine .sponsortable kann prima auch für eine Tabelle genutzt werden, in der Kundenlogos stehen. .imagetable wäre evtl. eine bessere Wahl. Der Name sollte also eine gesunde Balance zwischen Abstraktion und inhaltlicher Beschreibung wahren. Das ist nicht einfach, aber ein erreichbares Ziel.

Klassennamen nach BEM

Die Systematik BEM (Block Element Modifier) hat sich in den letzten Jahren als Quasistandard im Frontend durchgesetzt. Ersonnen wurde BEM von Entwicklern der russischen Suchmaschine Yandex. Das System ist in Wahrheit sehr viel größer und umfassender, uns interessiert nur der CSS-Teil. Der Charme von BEM sind sicherlich seine rigiden Benennungsregeln. Sie sind Vor- und Nachteil zugleich.

Ein Modul einer Webseite wird als „Block“ bezeichnet. Ein Block besteht wiederum aus mehreren Elementen. Die Darstellung dieser Elemente kann durch Modifier verändert werden. In der Dokumentation fungiert eine Navigation als Beispiel. Die Navigation ist hierbei der Block. Die einzelnen Links – egal wie sie gestaltet sind – sind die Elemente. Die Formatierung als vertikale oder horizontale Navigation, als Reiter oder Buttons, geschieht dann über die Zuweisung der passenden Modifier.

Wir haben also eine Trennung zwischen Grundstyles und Modifikationen. Auch der BEM-Ansatz geht davon aus, dass wir kein komplett neues Modul benötigen, nur weil es ein wenig anders aussieht als ein in der Struktur ähnliches oder gleiches.

Die Namensgebung erfolgt bei BEM durch schlichte und strikte Regeln. Die drei Bestandteile des BEM-Ansatzes sind sauber durch die Benennungsregeln identifizierbar. Dabei werden doppelte Binde- und Unterstriche genutzt. Die Grundidee ist Folgende:

.block {}
.block__element  {}
.block--modifier {}
.block__element--modifier {}

In einem praktischen Beispiel kann das dann so aussehen:

.speech-bubble{}
.speech-bubble__header{}
.speech-bubble__text{}
.speech-bubble__text--link{}

Die einzelnen Elemente und Modifier werden im Grunde genommen mit dem Namen des Moduls als Namespace versehen. Das passiert, um eine niedrige Spezifität zu bewahren. Denn je mehr Bestandteile ein Selektor hat, desto spezifischer ist eine Regel. Auch eine ID kann eine sehr hohe, fast nicht zu schlagende Spezifität darstellen.

Die Idee hinter allen bekannten Benennungsrichtlinien ist, die Spezifität der Selektoren so klein wie möglich zu halten. Bei BEM wird eine Klasse nur innerhalb eines Moduls genutzt. Die mehrfache Verwendung einer Klasse innerhalb verschiedener Module ist nicht vorgesehen, schließlich arbeiten alle Klassen mit einem Modulpräfix.

Keine starren Regeln

Die rigiden Regeln von BEM funktionieren dann besonders gut, wenn Sie ein großes Team haben, in dem die CSS-Kenntnisse sehr unterschiedlich verteilt sind. Wenn Sie hingegen Entwickler mit sehr guten CSS-Kenntnissen haben, können diese rigiden Regeln auch störend wirken. Denn sehr geübte Frontend-Entwickler möchten auch gerne schlanken Code schreiben. Bei einer einfachen Navigation ohne Unternavigation wäre es unnötig, den Listenelementen und Links eigene Klassen zu geben. HTML würde unnötig vollgemüllt werden. Über einfache Kontextselektoren und eine Klasse auf der Navigationsliste könnte man jedes Element der Navigation erreichen und gestalten. Nach BEM sähe die Navigation folgendermaßen aus:

<ul class="navigation">
  <li class="navigation__item">
    <a href="#" class="navigation__link">Link</a>
  </li>
  <li class="navigation__item">
    <a href="#" class="navigation__link">Noch ein toller Link</a>
  </li>
  <li class="navigation__item">
    <a href="#" class="navigation__link">Der ist noch besser!</a>
  </li>
</ul>

Das dazugehörige CSS sähe dann so aus:

.navigation {/* Eigenschaften */}
.navigation__item {/* Eigenschaften */}
.navigation__link {/* Eigenschaften */}

Die meisten Klassen sind allerdings unwichtig, deshalb könnten Sie das HTML auch folgendermaßen auszeichnen:

<ul class="navigation">
  <li>
    <a href="#">Link</a>
  </li>
  <li>
    <a href="#">Noch ein toller Link</a>
  </li>
  <li>
    <a href="#">Der ist noch besser!</a>
  </li>
</ul>

Das dazugehörige CSS:

.navigation {/* Eigenschaften */}
.navigation li {/* Eigenschaften */}
.navigation a {/* Eigenschaften */}

In solch eng abgrenzbaren Fällen, in denen wir eine klare, nicht zu verändernde Struktur erwarten können, empfinde ich es als wohltuend, Klassen in HTML einzusparen und die in CSS aus guten Gründen vorgesehenen Elementselektoren zu nutzen. Aber schon bei einer Navigation mit Subnavigation(en) nehme ich wieder Abstand von der oben beschriebenen Ausnahme. Der Nutzen von Klassen ist in solchen Momenten einfach zu hoch, wie Listing 3 illustriert.

<ul class="navigation">
  <li class="navigation__first-level-item">
    <a href="#" class="navigation__first-level-link">Link</a>
  </li>
  <li class="navigation__first-level-item">
    <a href="#" class="navigation__first-level-link">Noch ein toller Link</a>
    <ul class="navigation__second-level">
      <li class="navigation__second-level-item">
        <a href="#" class="navigation__second-level-link">Link im Submenü</a>
      </li>
      <li class="navigation__second-level-item">
        <a href="#" class="navigation__second-level-link">Noch ein Link im Submenü</a>
      </li>
      <li class="navigation__second-level-item">
        <a href="#" class="navigation__second-level-link">Link im Submenü</a>
      </li>
    </ul>
  </li>
  <li class="navigation__first-level-item">
    <a href="#" class="navigation__first-level-link">Der ist noch besser!</a>
  </li>
</ul>

Ich sehe durchaus den Nutzen strikter Regeln. Sollten aber die Projektbeteiligten genügend CSS-Wissen besitzen, empfinde ich begründete Ausnahmen von der Regel als einen Segen. Sie vermeiden unnötig aufgeblähtes HTML.

Achten Sie darauf, bei BEM nicht mit den Klassennamen das DOM abzubilden. Vergeben Sie also niemals Enkelelemente. Schauen wir uns etwa das Beispiel aus Listing 4 an.

<div class="teaser">
  <header class="teaser__headercontainer">
    <h3 class="teaser__headercontainer__header">Überschrift</h3>
  </header>
  <div class="teaser__content">
    <p class="teaser__content__paragraph">Lorem Dingenskirchen und so weiter, ihr wisst schon ....</p>
  </div>
  <footer class="teaser__footer">
    <a href="linkziel.html" class="teaser__footerlink">weiterlesen ...</a>
  </footer>
</div>

Alle Klassennamen beziehen sich in diesem Beispiel auf das jeweilige Elternelement. Dadurch wird eine konkrete Struktur festgelegt. Sollte das header-Element nicht mehr benötigt werden, würde sich eine einsame h3 auf ein nicht existentes Element beziehen. Das Gleiche gilt für den Absatz. Alle Klassennamen sollten sich ausschließlich auf den Namen des Moduls beziehen. Aus .teaser__headercontainer__header würde dann .teaser__header. Der bessere Code sähe also wie in Listing 5 aus.

<div class="teaser">
  <header class="teaser__headercontainer">
    <h3 class="teaser__header">Überschrift</h3>
  </header>
  <div class="teaser__content">
    <p class="teaser__paragraph">Lorem Dingenskirchen und so weiter, ihr wisst schon ....</p>
  </div>
  <footer class="teaser__footer">
    <a href="linkziel.html" class="teaser__footerlink">weiterlesen ...</a>
  </footer>
</div>

Eine weitere Einschränkung der Klassennamen ergibt sich aus der Natur der Texterstellung. Wird der Absatz im obigen Beispiel direkt vom Redakteur erstellt, und könnte es sich dabei auch um mehrere Absätze oder eine Liste handeln? Wenn ja, dann können Sie nur noch sinnvoll mit Kontextselektoren arbeiten. Schließlich müssen Sie verhindern, dass Redakteure Klassen in ihren WYSIWYG-Editoren vergeben oder gar HTML schreiben/überprüfen müssen. Nur wenn Sie die komplette Kontrolle über den Quellcode haben, können Sie jedem Element eine Klasse geben. Für alle anderen Fälle gibt es Kontextselektoren. Diese gehören zum CSS-Sprachumfang und sind nicht giftig.

Unterschiedliche Arten zu stylen

Grundsätzlich stehen uns viele unterschiedliche Arten zur Verfügung, um mittels CSS Gestaltung in die HTML-Elemente und ihre Inhalte zu bringen. Alle haben ihre Berechtigung, keine ist wirklich falsch. Wir können beispielsweise mit Klassen gestalten, mit Kontextselektoren oder mit Pseudoselektoren. Egal, wie wir vorgehen, diese beiden Aspekte sind zu beachten:

1. Wiederverwendbarkeit innerhalb des Projektes und zwischen Projekten
2. Module im Sinne abgekapselter Inhalte

Da mir diese beiden Aspekte sehr wichtig sind, fällt für mich die Möglichkeit aus, nur mit Element- und Pseudoselektoren unter Ausnutzung unterschiedlicher Kombinatoren zu gestalten. Wir haben in meinen Augen zwei grundsätzlich unterschiedliche Ansätze zur Verfügung, wie wir Module unseres Designs gestalten und modifizieren können:

1. Wir vergeben eine Basisklasse und ergänzen sie optional durch einen oder mehrere Modifikatoren. Damit gestalten wir also durch eine Klasse oder eine Kombination mehrerer.
2. Wir regeln alle Abweichungen und Standards im CSS und vergeben nur jeweils eine einzelne Klasse.
3. Ein gern zitiertes Beispiel sind hier Buttons. Im Modifikatoransatz würden wir eine Basisklasse vergeben, die schon eine Designvariante darstellt. Der Modifikator ändert dann Details wie Größe, Farben oder Icons (Listing 6).

<!-- Standardbutton -->
<button class="btn">Klick mich!</button>

<!-- Button mit warnender Farbe -->
<button class="btn btn-warning">Warnung</button>

<!-- Link als Button formatiert, mit Icon -->
<a href="#" class="btn btn-ico-print">drucken</a>

Der auf CSS fokussierte Ansatz ist dann besonders praktisch, wenn man einen Präprozessor wie Sass nutzt. Mit Sass könnten Sie ein Mixin oder einen Platzhalter schreiben, in dem Sie die allgemeinen Regeln für Buttons definieren. Diese werden dann allen Buttonvarianten zur Verfügung gestellt, ohne selbst als Klasse ausgegeben zu werden. Dadurch können Sie einem Element immer exakt eine Klasse geben (Listing 7).

@mixin btn { 
/* Platzhalter mit allgemeiner Buttondefinition */
}

/* Standardbutton */
/* Mit @include werden die Eigenschaften des Mixins btn übernommen.
   Am Ende werden mehreren kommaseparierten Selektoren
   die Eigenschaften zugewiesen, die identisch sind. */
.btn {
  @include btn;
}

/* Button mit warnender Farbe */
.btn-warning {
  @include btn;
  color: $btn-warning-col;
  background-color: $btn-warning-bgcol;
}

/* Link als Button formatiert, mit Icon */
.btn-ico-print {
  @include btn;
  color: $btn-ico-print-col;
  padding-left: 10px;
  background: $btn-ico-print-bgcol image-url($btn-ico-print-icon) no-repeat left center;
}

Dieses Beispiel verzichtet auf Platzhalter zugunsten von Mixins. Platzhalter haben den Nachteil, dass sie nicht am Ort des Aufrufs in das CSS geschrieben werden sondern dort, wo der Platzhalter generell importiert wird. So werden die Regeln für ein Modul zwangsweise auseinandergerissen.

Der erste Ansatz, bei dem durch Klassen in HTML gestaltet wird, ist sehr gut für Rapid Prototyping geeignet, da man sich auf Inhalt und Struktur konzentrieren kann. Zur Gestaltung muss CSS weder geschrieben noch modifiziert werden. Einfache Regeln ermöglichen ein grundsätzliches Design, an dem dann später eventuell weitergearbeitet wird. Allerdings werden viele Klassen in HTML geschrieben. Und eine Designänderung erfordert eine Änderung an HTML (Austausch einer Klasse), anstatt sie in CSS vorzunehmen.

Beim zweiten, auf CSS konzentrierten Ansatz werden wenige Regeln dupliziert. CSS wächst unweigerlich an, dafür bleibt HTML ein wenig kompakter. Es ist unnötig, sich theoretisch für eine der beiden Varianten zu entscheiden. Aus der konkreten Projektsituation heraus sollte einer der beiden Wege eingeschlagen, dann aber auch konsequent zu Ende gegangen werden.

Jedes Modul eine Datei

Präpozessoren haben einen weiteren immensen Vorteil für die Entwicklung modularer Systeme: Als Entwickler können Sie jedem Modul eine eigene Datei geben und in eine zentrale Datei importieren lassen. Am Ende wird eine einzige CSS-Datei erzeugt, die dann mit dem Webprojekt verknüpft wird. Sie selber arbeiten aber in vielleicht hundert oder zweihundert Einzeldateien. Das macht die Organisation des eigenen Codes einfacher und fördert die Arbeit im Team. Es erleichtert auch den Transport von Code zwischen Projekten, denn Sie sollten niemals aus den Augen verlieren, dass Sie einmal geschriebenen Code mehrfach verwenden können und auch sollten.

Fazit

Mit der richtigen gedanklichen Herangehensweise schaffen Sie es, Ihren Frontend-Code wartbar zu machen und zu halten. Dafür benötigen Sie Wissen über die Grundlagen von CSS und Willen zu semantisch genutztem HTML. All dies muss stringent durchgehalten werden. Wenn Sie Frontend-Code genauso ernst nehmen wie Backend-Code, sollte dies kein Problem sein. Je weniger Detailwissen zu CSS vorliegt, umso wichtiger ist es, dass ein System wie BEM strikt gehandhabt wird. Einigen Sie sich im Team auf Coding-Richtlinien und kontrollieren Sie sie. Diese Kontrolle können Sie teilweise auf Linter (mit Grunt oder gulp gesteuert) auslagern, eine persönliche Kontrolle ist hingegen besser.

The post LEGO im Frontend appeared first on webinale 2025.

Wie layouten wir heute?

Doch nach all den Jahren gab es nie eine echte Layouttechnik mittels CSS, die als solche gedacht war. Wie erstellen wir denn heute unsere Layouts und gestalten die einzelnen Module? Wir nutzen Eigenschaften, die dafür meist nicht gedacht waren:

1. Floats
2. display: table
3. display: inline-block

Floats wurden ursprünglich in CSS integriert, um Bilder innerhalb von Absätzen nach links oder rechts fließen zu lassen; das hatte man bislang mit dem align-Attribut direkt in HTML ermöglicht. Einzig die Positionierungstechniken eröffnen planmäßig Chancen für Layout. Echtes, flexibles Seitenlayout ist damit aber nur schwer und mit zu großen Einschränkungen möglich. Wir können also zusammenfassen: Es ist 2016, wir schicken selbstfahrende Roboter auf den Mars, die Selfies nach Hause senden. Aber wir haben keine generell einsetzbare Technik, um Seiten mittels CSS zu layouten.

Das sollte sich ab etwa 2009 ändern, denn da begannen die Arbeiten am Standard für Flexbox. Dieser neue Standard sollte mit anderen parallelen Entwicklungen endlich eine echte Layoutmethode für das Web darstellen.

Flexbox ist mittlerweile in allen aktuellen Browsern implementiert und der IE unterstützt ihn bis hinunter zur Version 10. Laut Can I use kann Flexbox von gut 97 Prozent aller Browser verwendet werden [1]. Nur der IE 9 und vorherige Versionen können mit dieser Technik nichts anfangen. Doch trotz oft sehr langsamer Prozesse in den IT-Abteilungen großer Unternehmen und Behörden sollten gerade diese beiden Browser in Kürze das Zeitliche segnen. Es spricht mittlerweile also nichts mehr dagegen, Flexbox zu nutzen.

Sollten Sie noch zahlreiche Nutzer mit alten IEs haben, verwenden Sie Flexbox als Erweiterung, als progressive enhancement. Wenn die IE 9 und 8 dann endlich ausgestorben sind, haben Sie erste Erfahrungen mit Flexbox sammeln können und können die Sonderbehandlung für die alten Browser einfach entfernen.

Was ist Flexbox, und wie viele?

Flexbox ist eine neue Technik, um Layout für Seiten und deren Module zuzuweisen. Es funktioniert ebenso für die gesamte Seite wie für eine Navigation oder einen Teaser. Über die Jahre haben sich drei unterschiedliche Versionen von Flexbox angesammelt. Es ist hierbei nicht mit schlichtem Austausch von Vendor Prefixes getan; es werden meist unterschiedliche Begriffe zwischen den Versionen genutzt. Doch eine Beschäftigung mit diesen Versionen ist müßig.

Die erste Version wird nur noch von alten Android-Browsern bis Android 4.3 und dem mobilen Safari bis iOS 6.1 unterstützt. Die mittlere Version wird ausschließlich vom IE 10 verstanden; alle aktuellen Browser verstehen die aktuelle Version (Kasten „Die Unterstützung des aktuellen Standards“). Nur für einige wenige Nachzügler muss diese mit dem webkit-Präfix versehen werden:

.flexcontainer {
display: -webkit-box; /* alte Android-Browser */
display: -ms-flexbox; /* IE 10 */
display: -webkit-flex;
display: flex; 
}

Doch die unterschiedlichen Versionen und Schreibweisen sollte sich niemand merken und schreiben müssen – es gibt Tools für diese undankbare Aufgabe. Für Nutzer von Node.js-Tools bietet sich Autoprefixer [2 ] an, das es übrigens auch als Onlinetool [3] gibt. In der Onlineversion bekommt man einen guten Eindruck über die vielen Codezeilen, die das Tool dem Entwickler erspart. Für Stylus, Less und Sass gibt es zudem passende Mixins.

So funktioniert Flexbox

Flexbox basiert auf einer sauberen und schlanken HTML-Struktur. Einem Container wird mittels display: flex mitgeteilt, dass es ein Flex-Container sei. Dadurch sind dessen Kindcontainer automatisch Flex-Items. Alles zusammen nennen wir dann eine Flex-Umgebung.

In Code gegossen, sieht das in etwa so aus wie in Listing 1 dargestellt. Im CSS ist die Definition schnell erledigt:

.ich-bin-der-flexcontainer {
display: flex;
}

Und so beginnt es:
 

<section class="ich-bin-der-flexcontainer">
<article>Toller Inhalt</article> <!-- Flexitem -->
<article>Noch mehr toller Inhalt</article> <!-- Flexitem -->
<article>Ihr wisst schon ...</article> <!-- Flexitem -->
</section>

Leider gibt es noch immer Content-Management-Systeme – vor allem im teuren Enterprise-Bereich – die einfach von sich aus HTML um Templates packen. Diese Unart würde die Flex-Umgebung zerstören.

<div class="ich-bin-der-flexcontainer">
<div class="vom-CMS-eingefuegtes-dingens"> <!-- Flexitem -->
<div>Toller Inhalt</div> <!-- Kein Flexitem -->
<div>Noch mehr toller Inhalt</div> <!-- Kein Flexitem -->
<div>Ihr wisst schon ...</div> <!-- Kein Flexitem -->
</div>
</div>

Keine Schlüsselwörter

Eine echte Neuerung von Flexbox ist der Verzicht auf die üblichen Schlüsselwörter für die Richtung. In einer Flex-Umgebung gibt es weder links, rechts, oben oder unten. Es gibt nur zwei Achsen und möglicherweise umgedrehte Reihenfolgen. Wir sprechen von der Hauptachse und der Kreuzachse. Die Ausrichtung beider ist unterschiedlich, je nach Leserichtung der Webseite. Denn schließlich gibt es nicht nur Webseiten, deren Inhalte von links nach rechts gelesen werden. Es gibt auch Kulturen, in denen von rechts nach links oder von oben nach unten gelesen wird.

Bleiben wir der Einfachheit halber jedoch bei der uns gewohnten Leserichtung. Für uns interpretiert der Browser standardmäßig die Hauptachse als horizontal von links nach rechts (und die Kreuzachse von oben nach unten) (Abb. 2). Als CSS-Eigenschaft übersetzt lautet das:

.flexcontainer {
flex-direction: row;
}

Wollen wir die Reihenfolge umdrehen und die Flex-Items von rechts nach links laufen lassen, dann schreiben wir flex-direction: row-reverse; (Abb. 3). In beiden Fällen ist die Kreuzachse vertikal. Wollen wir die Hauptachse vertikal haben schreiben wir:

.flexcontainer {
flex-direction: column;
}

Die umgedrehte Reihenfolge in der Vertikalen heißt dann logischerweise flex-direction: column-reverse;. Die Kreuzachse ist dann in beiden Fällen horizontal.

Diese neue Herangehensweise ist sehr gewöhnungsbedürftig, aber sie entwickelt mit der Zeit einen gewissen Charme. Wenn Sie es lange Jahre gewohnt sind, mit rechts oder links floatenden Containern zu arbeiten, kann die Umgewöhnung langwierig sein. Positiv ist, dass nun einfache und schnelle Lösungen für immer wieder auftretende Probleme zur Verfügung stehen. Philip Walton führt die bekanntesten auf seiner Seite „Solved by Flexbox“ [4] auf. Und auch der Präsentation „Fixed with Flexbox“ [5] von Matt Soria können Sie einige Anregungen entnehmen.

Reihenfolge ändern

Eine sehr charmante Eigenart von Flex-Items ist es, dass Sie ihre Reihenfolge beeinflussen können. Nehmen wir an, Sie haben vier Flex-Items und möchten gerne, dass bei der Linearisierung auf schmalen Bildschirmen das vierte an erster Stelle stehen soll, alle anderen aber in der gewohnten Reihenfolge dargestellt werden sollen. Sie erreichen dies recht einfach mit folgendem Code:

/* Die Breite ist nur ein Beispiel! */

@media screen and (max-width: 400px) {

.flex-item:nth-child(4) {
order: -1;
}
}

Die Eigenschaft order, die man den Flex-Items direkt zuweist, definiert die Reihenfolge der Darstellung. Der Standardwert ist 0. Deshalb wird ein Item mit der Ordnungsnummer -1 vor den „normalen“ Flex-Items dargestellt.

Kritisch wird die Umsortierung allerdings, wenn es sich um Links handelt. Denn alle Browser bis auf Firefox geben die Tabreihenfolge nach der visuellen Reihenfolge wieder. Egal, welcher Container mit order wohin definiert wurde, die Tabreihenfolge ist immer so, wie wir die Container im Browser sehen. Das ist in meinen Augen das zu erwartende Verhalten, denn schließlich weiß der Nutzer nichts von den zugrunde liegenden Techniken und kann sich deshalb nur optisch orientieren. Im Firefox richtet sich die Tabreihenfolge strikt nach der Reihenfolge im Quellcode. Wir können nur hoffen, dass sich dies schnellstmöglich ändert.

Wofür sollte ich Flexbox nutzen?

Flexbox eignet sich sowohl für das Seitenlayout als auch für das Layout einzelner Module. Sehr beliebt sind hierbei Bildergalerien, Navigationen und Teaser(-gruppen).

Wenn wir keine speziellen Flexbox-Eigenschaften für unser Seitenlayout nutzen wollen, lohnt sich in meinen Augen eine Abschaffung der bewährten Float Grids und -Spalten nicht. Diese Technik funktioniert und wir können mit ihr umgehen. Was wollen wir mehr?

Wollen wir hingegen einzelne Features ausnutzen, beispielsweise das automatische Strecken der Flex-Items über die Kreuzachse, dann gibt es einen guten Grund für den Einsatz von Flexbox.

Ein wichtiger Grundsatz ist in meinen Augen, keine Technik nur deshalb zu nutzen, weil sie neu ist. Wenn eine bewährte Technik bereits existiert, sollten wir diese so lange nutzen, wie es sinnvoll ist.
 

Links & Literatur zum Text:

[1] http://caniuse.com/#feat=flexbox

[2] https://github.com/postcss/autoprefixer

[3] http://autoprefixer.github.io/

[4] http://philipwalton.github.io/solved-by-flexbox/

[5] http://slides.com/matt-soria/flexbox#/

The post Flexbox | Layout in flexibel appeared first on webinale 2025.