Hochwertige künstliche Pflanzen - sztuczne-rosliny.pl

#sztuczne-rosliny.pl, Online-Shop für hochwertige künstliche Pflanzen

Ein Shop mit diesem Sortiment ist am Starttag nicht fertig. Das Angebot verändert sich mit jeder Lieferung, und die Person, die den Katalog pflegt, arbeitet täglich im Backend. Wenn das Anlegen einer Pflanze einen Entwickler braucht, weicht der Katalog innerhalb einer Saison von der Wirklichkeit ab, unabhängig davon, wie gut er bei der Abnahme aussah. Diese Überlegung stand am Anfang der technischen Entscheidungen, nicht die Optik.

Das Unternehmen importiert und vertreibt künstliche Pflanzen, arbeitet zugleich als Großhandel und liefert Begrünungen für Büros, Hotels, Restaurants, Einkaufszentren und Messestände, samt Montage und Beratung vor Ort. Der Sitz ist Warschau, eine Niederlassung besteht in Białystok. Zum Sortiment gehören Bäume, Gräser, Blumen und Pflanzgefäße, dazu brandhemmende und UV-beständige Varianten sowie begrünte Wände (Quelle: sztuczne-rosliny.pl).

Die Umsetzung dauerte rund sechs Wochen. Technisch steht der Shop auf WordPress mit einem eigenen Produktmodell, Redis als Objekt-Cache, HTML5, CSS3 und SASS im Frontend, AJAX in der Suche, Dateiablage in S3 mit einem CDN davor und Monitoring nach dem Launch. Layout und Platzierung der Elemente kamen vom Kunden.

#Der Katalog als tägliche Arbeit

Das Produktmodell liegt in eigenen Inhaltstypen und benutzerdefinierten Feldern. Höhe, Material, Farbe, Topfart, Hersteller und die Angabe, ob eine Variante brandhemmend oder UV-beständig ist, sind Werte in der Datenbank und keine Sätze in einer Beschreibung. Die Redaktion füllt damit ein Formular aus und schreibt keinen Text, in dem man sich die Reihenfolge der Angaben merken muss. Jeder Eintrag sieht gleich aus, weil das Aussehen Aufgabe des Templates ist und nicht Aufgabe der Person, die Daten einpflegt.

Der zweite Punkt sind die Sprachfassungen. Der Shop führt sein Angebot auch auf Englisch, und damit zerfallen die Daten in zwei Gruppen. Höhe, Topfdurchmesser und Artikelnummer sind in jeder Sprache identisch; sie zu duplizieren heißt, ein späteres Auseinanderlaufen zu bestellen. Name, Beschreibung und Verwendungshinweise sind Übersetzung und brauchen einen eigenen Platz. Diese Trennung vor dem Launch zu ziehen kostet fünf Minuten, sie danach zu ziehen ist eine Migration des gesamten Katalogs.

Der dritte Punkt ist die Ordnung der Kategorien. Pflanzen lassen sich nach Art, Höhe, Verwendung und Einrichtungsstil gleichzeitig sortieren, und es ist verlockend, aus jeder dieser Achsen einen eigenen Kategoriebaum zu machen. Dann hängt dasselbe Produkt aber an vier Stellen, und die Redaktion pflegt vier Listen statt einer. In der Praxis trägt eine Hierarchie die Navigation, und die übrigen Dimensionen sind Attribute, nach denen gefiltert wird. Das sieht nach einer organisatorischen Frage aus und ist eine technische, weil sie bestimmt, wie viele Adressen der Shop nach außen ausspielt.

#Produkte, die keine Einzelstücke sind

Begrünte Wände und fertige Arrangements brechen die Annahme, auf der ein gewöhnlicher Katalog aufbaut, nämlich dass ein Produkt ein Gegenstand mit einem Preis und einem Bestand ist. Eine Wand hat eine Fläche, wird aus Modulen gesetzt, und ihre Verfügbarkeit ergibt sich aus der Verfügbarkeit ihrer Bestandteile. Ein Gefäßarrangement ist ein Satz aus mehreren Pflanzen und einem Topf, verkauft als Ganzes und gelagert in Teilen.

Dafür gibt es zwei Wege, und die Wahl zwischen ihnen ist eine Architekturentscheidung. Der erste behandelt ein solches Produkt als eigenen Eintrag mit eigener Beschreibung und eigenem Bestand, losgelöst von den Komponenten. Er ist einfach und trägt, solange es wenige Sets gibt; er bricht in dem Moment, in dem ein Bestandteil ausläuft, denn das Set wirkt weiterhin lieferbar. Der zweite beschreibt das Produkt als Zusammensetzung und rechnet die Verfügbarkeit aus den Teilen. Er ist korrekter und teurer, weil dann jede Listenansicht mehr rechnen muss, als im Eintrag steht.

Hier verläuft die Grenze dort, wo sie meistens sinnvoll verläuft: Was aus dem Regal gekauft wird, ist ein Eintrag, und was nach Maß entsteht, ist eine Anfrage mit einem Datenblatt und einem Gespräch. So zu tun, als sei eine begrünte Wand mit vorgegebener Fläche ein Produkt mit Kaufen-Knopf, endet in einer Bestellung, die sich ohne Telefonat nicht ausführen lässt. Dann plant man das Telefonat besser in die Seite ein, statt sich später dafür zu rechtfertigen.

#Zwei Lager, eine Produktseite

Warschau und Białystok bedeuten, dass dieselbe Ware an zwei Orten liegen kann. Im Endkundengeschäft ist das gleichgültig, weil die Summe zählt. Im Projektgeschäft ist es das nicht: Vierzig Stück, verteilt auf zwei Standorte, ergeben einen anderen Montagetermin als vierzig Stück an einem Ort.

Technisch folgt daraus, den Bestand nach Standort getrennt zu führen, auch wenn die Produktseite eine Summe anzeigt. Die Summe lässt sich jederzeit aus den Teilen berechnen, die Teile aber nie aus der Summe zurückgewinnen. Das ist dieselbe Regel, die vorher schon für die Attribute galt: Daten so fein speichern, wie es sinnvoll ist, und erst bei der Anzeige vereinfachen.

Bei Projektanfragen kommt ein Detail hinzu, das in diesem Sortiment zählt. Pflanzen aus zwei Lieferungen unterscheiden sich sichtbar im Grünton, weshalb für eine Lobby vierzig Stück aus einer Charge gebraucht werden und nicht vierzig Stück irgendwoher. Diese Angabe gehört auf die Seite, sonst wird sie in jeder einzelnen Anfrage erfragt und die Antwort ist jedes Mal dieselbe.

#Bilder gehören nicht auf den Anwendungsserver

In dieser Branche beschreibt die Fotografie das Produkt, sie illustriert es nicht. Der Käufer beurteilt am Bild den Grünton, die Blattstruktur und den Sitz im Topf, also genau das, was eine überzeugende Kunstpflanze von einer trennt, die aus zwei Metern auffällt. Die Galerien sind entsprechend umfangreich und das Gewicht der Seite liegt fast vollständig bei den Bildern.

Daraus folgt der Ort der Ablage. Die Dateien liegen in S3 und werden über ein CDN ausgeliefert, nicht vom Dateisystem des Anwendungsservers. Die Gründe sind praktisch: Der Anwendungsserver soll Seiten zusammensetzen und keine Gigabyte an Bildern versenden, weil beides um dieselben Prozesse konkurriert. Das Backup der Umgebung wächst nicht mehr mit dem Katalog mit, sodass eine Testumgebung in Minuten statt in einer Stunde steht. Und ein Serverwechsel verschiebt keine Dateihalde mehr, weil die Dateien nicht an die Maschine gebunden sind.

Der Kompromiss gehört dazu. Erweiterungen, die Bilder direkt auf der Platte erwarten, arbeiten nicht mehr selbstverständlich, und die Erzeugung von Vorschaugrößen muss bewusst geplant werden. Der zweite Preis ist die Cache-Invalidierung: Ein ausgetauschtes Bild unter derselben Adresse erreicht einen Browser nicht mehr, der es bereits gespeichert hat, deshalb bekommt eine neue Fassung einen neuen Dateinamen. Ohne diese Regel korrigiert die Redaktion ein Foto, sieht weiterhin das alte und verliert das Vertrauen in das Backend.

In der Listenansicht entscheidet nicht das Gewicht eines Bildes, sondern die Summe. Eine Kategorieseite mit fünfzig Produkten lädt fünfzig Dateien, also werden Vorschaubilder in der Größe erzeugt, in der sie tatsächlich erscheinen, und nicht im Browser aus einer Datei für die Produktseite herunterskaliert. Das ist eine Einstellung und eine der wenigen Änderungen, die man auf einem Mobilgerät im gewöhnlichen Mobilfunknetz spürt.

#Was nach dem Launch sichtbar bleibt

Monitoring war Teil der Umsetzung und nicht ein getrennt verkaufter Zusatz, und es beobachtet drei verschiedene Dinge. Erstens die Erreichbarkeit, also die einfachste Frage, ob die Seite antwortet. Zweitens Anwendungsfehler, die in einem Shop selten die ganze Seite umwerfen und meistens einen einzelnen Weg zerstören: Ein Update kann den Versandschritt verstimmen, während der Rest läuft und eine Woche lang niemand etwas meldet. Drittens die Antwortzeit auf den Ansichten, die wirklich teuer sind, also auf der Kategorieliste mit aktiven Filtern und nicht auf der Startseite.

Der Verkehr verteilt sich über das Jahr ungleich. Er steigt vor den Feiertagen und in den Phasen, in denen Firmen Büros und Ladenflächen herrichten, und einzelne Tage bringen ein Vielfaches der gewöhnlichen Last. Eine Abstimmung auf den Monatsdurchschnitt ist deshalb wenig wert; es zählt die Spitzenstunde. Dort entscheidet vor allem, wie viele Anfragen die Anwendung überhaupt erreichen, denn die Bilder nimmt ihr das CDN ab und der Objekt-Cache in Redis verkürzt den Aufbau der Seiten.

Sicherheit besteht hier aus unspektakulären, regelmäßigen Handgriffen: Aktualisierungen von Kern, Theme und Erweiterungen, Sichtung der Logs, Kontrolle der Zugänge und Prüfung jeder Änderung auf einer Kopie, bevor sie produktiv geht. Wo über ein Formular echte Transaktionen laufen, ist ein direkt auf der Produktion ausgeführtes Update ein Betriebsrisiko und keine Zeitersparnis.

#Die zweite Sprachfassung und die Frage nach den Adressen

Ein zweisprachiger Katalog bringt eine Entscheidung mit sich, die vor der ersten Übersetzung fallen muss: Bekommt jede Sprachfassung eine eigene Adresse, oder tauscht dieselbe Adresse ihren Inhalt je nach Einstellung. Nur die erste Variante ist für Suchmaschinen brauchbar, denn eine Adresse, deren Inhalt sich mit einem Cookie ändert, lässt sich weder verlinken noch indexieren noch sinnvoll cachen.

Daraus folgt die zweite Festlegung, nämlich welche Seiten überhaupt eine Entsprechung haben. Eine Produktseite hat sie, eine Kategorie ebenfalls, ein Filterergebnis eher nicht, weil sonst die Zahl der Adressen mit jeder Kombination in beiden Sprachen wächst. Fehlt diese Grenze, entsteht genau der Zustand, den ein Katalog nicht gebrauchen kann: viele Adressen, die dasselbe zeigen, und keine davon mit klarem Vorrang.

Für die Redaktion hat das eine angenehme Folge. Da die messbaren Felder sprachneutral sind, bleibt für die zweite Sprachfassung nur der Text zu übersetzen, und ein Artikel, dessen Übersetzung fehlt, ist an einem leeren Feld erkennbar und nicht daran, dass jemand ihn zufällig entdeckt. Ein fehlender Text ist damit eine sichtbare Lücke in einer Liste, und Lücken in Listen werden geschlossen, während stille Auslassungen es nicht werden.

#Unsere Maßnahmen

Auf unserer Seite lag die Umsetzung des Shops auf Basis des vom Kunden gelieferten Layouts: das Produktmodell mit parametrischen Feldern, Katalog- und Produktansichten, Suche mit Filtern, die Dateiablage in S3 mit Auslieferung über CDN, die Cache-Schicht, die Vorbereitung des Katalogs für die Indexierung und das Monitoring nach dem Launch. Die Anforderung, die alle übrigen Entscheidungen geordnet hat, war die Pflege des Katalogs ohne Entwickler und ein kurzer Weg vom Einstieg bis zum passenden Produkt.

#Zusammenfassung

Über die Qualität dieser Umsetzung haben drei Entscheidungen bestimmt, und keine davon betraf die grafische Schicht. Produktattribute als Felder statt als Sätze ergeben Filter und die Vorauswahl für Projektanfragen. Die Auslagerung der Dateien nach S3 mit CDN nimmt dem Anwendungsserver Arbeit ab, die er nicht leisten sollte, und hält die Backups klein. Ein Monitoring, das auf die tatsächlich teuren Wege zeigt, verkürzt die Zeit zwischen dem Ausfall eines einzelnen Schritts und seiner Entdeckung. Messwerte zur Wirkung dieser Arbeiten liegen mir nicht vor, also nenne ich keine.

Übertragbar auf das nächste Projekt sind die technische Schicht und die Arbeitsweise: WordPress mit eigenem Produktmodell, Redis, S3 mit CDN, Monitoring und das Prüfen von Filtern und Zahlungen auf einer Produktionskopie. Nicht übertragbar sind das Attributvokabular dieses Shops und seine Integrationen, denn beide entstanden für ein konkretes Sortiment und konkrete Datenformate. Ein zweites Projekt beginnt mit einer Umfanganalyse, das Angebot folgt danach.