E-Commerce-Entwicklung: led-lumina.pl

#Zwei Besucher, ein Katalog

Auf led-lumina.pl treffen zwei Personen mit sehr unterschiedlichen Fragen auf dieselbe Produktseite. Die eine sucht eine Leuchte für die Küche und entscheidet nach Aussehen, Lichtfarbe und Preisrahmen. Die andere plant die Beleuchtung einer Halle und liest zuerst Lichtstrom, Abstrahlwinkel, Schutzart und Farbwiedergabeindex, weil in gewerblichen Projekten Normen wie DIN EN 12464-1 die Zielwerte vorgeben und nicht der persönliche Geschmack.

Diese Spaltung ist der eigentliche Ausgangspunkt des Projekts. Ein Katalog, der nur der ersten Person dient, wird von der zweiten nach zwei Klicks verlassen. Ein Katalog, der nur der zweiten dient, sieht aus wie ein Datenblattarchiv und verkauft nichts. Die Umsetzung wurde 2012 übergeben, sie dauerte rund sechs Wochen, und der größte Teil der konzeptionellen Arbeit lag darin, beide Lesarten auf denselben Datenbestand zu stellen.

#Technische Daten gehören nicht in Fließtext

Die naheliegende Lösung wäre, alle Angaben in die Produktbeschreibung zu schreiben. Sie funktioniert genau so lange, bis jemand alle Leuchten mit neutralweißer Lichtfarbe oberhalb eines bestimmten Lichtstroms sehen will. Dann zeigt sich, dass diese Information zwar vorhanden, aber in Sätzen eingeschlossen ist, und Sätze lassen sich nicht sortieren.

Deshalb wurden die technischen Merkmale aus dem Beschreibungstext herausgelöst. Numerische Werte wie Lichtstrom oder Leistung liegen als Zahlen vor und lassen sich über Bereiche eingrenzen. Aufzählbare Eigenschaften wie Lichtfarbe oder Schutzart sind Taxonomien, also Begriffe, die an vielen Produkten hängen und sich später an einer einzigen Stelle korrigieren lassen. Der Unterschied wirkt wie eine Verwaltungsfrage und entscheidet darüber, ob ein Filter nach Leistungsbereich eine Datenbankabfrage ist oder eine Textsuche.

Dieselbe Leuchte existiert außerdem in mehreren Lichtfarben und Leistungsstufen. Für die Kundschaft sind das Varianten einer Sache, für das Lager getrennte Positionen mit getrennten Beständen. Beide Sichtweisen sind richtig, und das Inhaltsmodell muss beide bedienen, ohne sich für eine zu entscheiden. Bekäme jede Variante einen eigenen Beitrag, vervielfachte sich die Produktseite zu einem Dutzend fast identischer Dokumente mit denselben Fotos. Gäbe es Varianten gar nicht, ließe sich keine Verfügbarkeit zeigen. Die Lösung war ein übergeordneter Eintrag mit Beschreibung und Galerie und untergeordnete Varianten, die ausschließlich Parameter und Bestand tragen.

#Der Widerspruch zwischen Cache und Lagerbestand

An dieser Stelle steht die schwierigste Entscheidung des ganzen Projekts, und sie betrifft zwei Anforderungen, die sich gegenseitig ausschließen.

Eine Seite ist schnell, wenn sie fertig aus einem Zwischenspeicher kommt, ohne PHP zu starten und ohne die Datenbank zu befragen. Eine Seite ist korrekt, wenn die Verfügbarkeit neben dem Produkt in diesem Moment stimmt, und die Verfügbarkeit ändert sich außerhalb der Website. Hält der Cache das Dokument eine Stunde, verspricht er eine Stunde lang Ware, die es womöglich nicht mehr gibt. Hält er es gar nicht, zahlt jeder einzelne Aufruf den vollen Aufbau der Seite.

Aufgelöst wurde das, indem die Produktseite nicht mehr als ein Objekt behandelt wird. Beschreibung, Fotos, technische Angaben und begleitende Texte sind über Wochen stabil und dürfen aggressiv zwischengespeichert werden. Bestand und Verfügbarkeit werden getrennt nachgeladen, nachdem die Seite bereits sichtbar ist, und nur sie entscheiden darüber, ob die Bestellschaltfläche aktiv ist. Das Dokument, das der Browser erhält, ist damit für alle identisch, und das einzige zeitkritische Element darauf ist klar abgegrenzt.

#Wenn das Fremdsystem nicht antwortet

Bestände und Sortimentsänderungen kommen über eine Schnittstelle aus einem externen System. Im Architekturbild ist das ein Pfeil. Im Betrieb ist es der Teil, dessen Verhalten man nicht kontrolliert, und genau deshalb liegt zwischen Website und Fremdsystem eine eigene Schicht.

Redis dient hier weniger dazu, einzelne Abfragen zu beschleunigen, als dazu, den Ausfall eines Dritten zu überstehen. Antwortet die Quelle nicht, liefert die Zwischenschicht die zuletzt bekannte Antwort statt einer leeren Fläche oder einer Fehlermeldung. Die Besucherin sieht eine Seite, die möglicherweise etwas hinterherhinkt, und keine Seite, die kaputt aussieht. Der Unterschied zwischen diesen beiden Zuständen ist der Unterschied zwischen einem verschobenen und einem verlorenen Auftrag.

Die Aktualisierungsintervalle richten sich danach, wie schnell eine Angabe tatsächlich altert, und nicht nach einem einzigen Wert für alles. Katalogstruktur und technische Parameter ändern sich selten und kommen im Sammellauf. Der Bestand ändert sich innerhalb von Stunden und läuft über einen eigenen, schlanken Kanal, der ausschließlich das Bestandsfeld berührt. Diese Trennung ist billiger, als einen großen Import schneller zu machen, weil sie nicht die Laufzeit verkürzt, sondern den Umfang dessen, was überhaupt berechnet werden muss.

Dazu kommt eine Regel, die sich erst nach Monaten im Betrieb aufdrängt: ein vollständiger Import darf niemals überschreiben, was auf der Website entstanden ist. Werbetexte, Anwendungsfotos, Verweise auf verwandte Produkte und suchmaschinenorientierte Abschnitte stammen nicht aus einem Lagersystem. Wenn der Import sie nicht ausdrücklich ausspart, frisst er sie irgendwann auf.

#Bilder sind das Gewicht, nicht der Code

Eine Leuchte verkauft sich über das Foto, und Fotos von Leuchten sind fotografisch anspruchsvoll und in der Übertragung teuer. Meist gibt es mehrere Ansichten, oft vor dunklem Hintergrund, manchmal in einer Raumsituation. Ein Katalog mit einigen hundert Positionen ist dadurch eine Bildbibliothek mit angeschlossener Website, und das Markup ist daneben eine Randgröße.

Die Performancearbeit ging deshalb dorthin, wo die Masse liegt. Dateien werden beim Hochladen in genau die Größen umgerechnet, die auf der Seite tatsächlich vorkommen: Vorschaubild in der Liste, mittlere Ansicht auf der Produktkarte, volle Auflösung in der Vergrößerung. Das Vorschaubild ist nie die skalierte Zoomdatei, denn eine Skalierung im Browser spart Pixel und keine Bytes, und auf die Bytes wartet die Besucherin.

Die Verteilung übernimmt eine CDN-Schicht. Bilder ändern sich nach dem Hochladen nicht mehr, dürfen also sehr lange in den Randknoten liegen, und ein zweiter Aufruf einer Übersichtsseite erreicht den Ursprungsserver gar nicht erst. Die AWS-Seite trägt das, was sich nicht vom Rand ausliefern lässt: Ablage der Originaldateien, Sicherungen und die aufwendigen, aber einmaligen Verarbeitungsschritte.

#Filtern, ohne die Adresszeile zu verlieren

Die Oberfläche lädt Ergebnisse asynchron nach, damit ein Filterwechsel nicht die ganze Seite neu aufbaut. Das ist eine unspektakuläre Verbesserung, und sie birgt eine Falle, in die viele Kataloge dieser Zeit getappt sind.

Hat eine gefilterte Ergebnisliste keine eigene Adresse, lässt sie sich nicht als Lesezeichen sichern, nicht weiterschicken und nicht indexieren. Die dynamische Schicht arbeitet dann direkt gegen die Sichtbarkeit, die dasselbe Projekt aufbauen soll. Der Filterzustand wird deshalb in der Adresse abgebildet, obwohl kein Seitenaufbau stattfindet, und wer diese Adresse kalt aufruft, bekommt dieselbe Liste wie jemand, der sich dorthin geklickt hat.

Die Bedienbarkeit gehört zum selben Punkt. Filter müssen sich mit der Tastatur bedienen lassen, und eine Tabelle mit technischen Daten braucht Kopfzellen, die mit den Datenzellen verknüpft sind. Ohne diese Verknüpfung liest ein Screenreader die Spezifikation als Folge unbeschrifteter Zahlen vor, und die Spezifikation ist auf dieser Seite der Inhalt und nicht die Dekoration darum herum.

#Sichtbarkeit bei Texten, die alle haben

Ein redaktionelles Angebot schreibt seine Texte selbst, ein Handelsangebot erbt sie. Herstellerbeschreibungen gehen an jeden Händler, dieselben Sätze stehen also auf einem Dutzend konkurrierender Seiten, und eine Suchmaschine sucht sich aus einem Dutzend fast gleicher Dokumente eines aus. Der kleinste Anbieter dieser Gruppe gewinnt dabei selten.

Die Antwort liegt in der Schicht, die kein Hersteller liefert. Kategorie- und Filteransichten bekommen eigene Einleitungstexte, geschrieben entlang der Frage, die Kaufende tatsächlich stellen: worin sich warmweiß und neutralweiß im Wohnraum unterscheiden, ab wann die Schutzart wirklich zählt, was es bedeutet, wenn eine Spezifikation zur Dimmbarkeit schweigt. Nichts davon steht in einem Herstellerfeed, weil ein Hersteller ein Produkt beschreibt und Kaufende eine Entscheidung treffen.

Strukturierte Daten beschreiben das Produkt in einer für Suchmaschinen lesbaren Form, semantisches HTML5 ordnet das Dokument so, dass die technischen Angaben eine Tabelle sind und nicht optisch angeordnete Zeilen. Der zweite Punkt ist derselbe Barrierefreiheitspunkt von weiter oben, nur aus einer anderen Richtung, und wenn ein Argument zweimal unabhängig auftaucht, war die Entscheidung meist richtig.

#Zahlung, Versand und die Grenze der eigenen Zuständigkeit

Zahlungsdienstleister und Versandsysteme bringen eine Fehlerklasse mit, die es sonst nirgends im Projekt gibt. Jeder andere Fehler lässt sich beheben und der Vorgang wiederholen. Eine Zahlung geschieht einmal, ihr Ergebnis kommt von außen, oft verzögert und gelegentlich zweimal.

Die Bestätigung einer Bestellung darf sich deshalb nicht darauf stützen, dass jemand auf der Dankeseite ankommt. Er kommt an oder nicht: Tab geschlossen, Verbindung weg, Zurück-Taste gedrückt. Über den Bestellstatus entscheidet allein die eingehende Benachrichtigung des Anbieters, und deren Verarbeitung muss mehrfache Zustellung vertragen, weil ein Anbieter im Zweifel erneut sendet. Verträgt sie das nicht, entsteht aus einer Zahlung eine zweite Bestellung.

Beim Versand verläuft die Grenze ähnlich. Die Website kennt Gewicht und Maße des Warenkorbs und kann daraus Kosten berechnen. Sie kennt weder die aktuelle Auslastung des Dienstleisters noch dessen kurzfristige Einschränkungen und tut auch nicht so. Diese Grenze auszusprechen ist nützlicher als eine Angabe, die gelegentlich selbstbewusst falsch ist.

#Absicherung dort, wo sie günstig ist

Die Absicherung erfolgt im Code und auf dem Server, nicht durch ein Plugin, das Schutz verspricht. Die Begründung ist technischer Natur: ein Sicherheits-Plugin läuft im selben PHP-Prozess wie der Rest der Seite und kann erst reagieren, wenn eine Anfrage diesen Prozess bereits erreicht hat. Ratenbegrenzung und Filterung an der Randschicht halten dieselbe Anfrage früher und billiger auf.

Innerhalb der Anwendung zählt der Umgang mit Eingaben. Formulare werden serverseitig geprüft, denn eine Prüfung im Browser ist Bedienkomfort und keine Kontrolle. Zustandsverändernde Aktionen sind gegen Auslösung von fremden Seiten geschützt. Datenbankabfragen sind parametrisiert, damit eingegebener Text niemals Teil der Abfragesyntax wird.

#Betreuung nach dem Start

Zur laufenden Betreuung gehörten Aktualisierungen von Kern, Theme und Plugins, die Durchsicht der Protokolle und regelmäßige Sicherungen. Diese Aufzählung klingt nach Routine, deshalb lohnt der Hinweis, worin sie sich in einem Shop von derselben Aufzählung auf einer Visitenkartenseite unterscheidet.

Eine Aktualisierung in einem Katalog, der an ein Fremdsystem angebunden ist, ist kein Vorgang mit einem Klick. Eine Änderung im Kern kann das Verhalten der Schnittstelle berühren, und das zeigt sich erst beim nächsten Abgleich. Änderungen liefen deshalb über eine Testumgebung mit einer Kopie echter Daten und nicht über eine saubere Installation mit Demo-Theme. Ein Katalog mit hunderten Positionen und mehreren Schnittstellen verhält sich völlig anders als ein leeres WordPress, und Randfälle treten nur bei realistischer Datenverteilung auf.

Sicherungen haben hier eine zweite, seltener genannte Aufgabe. Wertvoll sind in einem Shop nicht die Dateien, sondern die Datenbank mit den Bestellungen, also muss die Wiederherstellung geübt und nicht nur behauptet werden. Eine Sicherung, die niemand je zurückgespielt hat, ist eine Vermutung.

#Was bleibt und was nicht

Übertragbar ist die Arbeitsweise: stabile von schnell veränderlichen Daten trennen, Merkmale als Felder und Taxonomien statt als Fließtext führen, eine Zwischenschicht vor jedes Fremdsystem setzen und gegen eine Kopie der Produktion testen. Diese Entscheidungen sehen in jedem Katalog gleich aus, unabhängig von der Branche.

Nicht übertragbar sind das Inhaltsmodell dieses Projekts und seine Schnittstellen. Sie entstanden für die Daten eines Kunden und für einen Auftrag aus der Kategorie Strony www. Ein Merkmalssatz für Beleuchtung ergibt außerhalb der Beleuchtung keinen Sinn, und die Form eines Datenaustauschs hängt davon ab, was auf der anderen Seite steht. Die nächste Umsetzung beginnt mit einer Analyse des Umfangs, und das Angebot folgt darauf und nicht umgekehrt.