E-Commerce-Entwicklung: haveabook.pl

#Vier Sprachen sind nicht vier Übersetzungssätze

Der häufigste Fehler in mehrsprachigen Projekten besteht darin, Sprache als Etikett über denselben Daten zu behandeln. Auf einem nordischen Markt bricht diese Abkürzung an einer Stelle, die vor der Übergabe niemand prüft: beim Sortieren von Listen.

Das schwedische und das dänisch-norwegische Alphabet enthalten Buchstaben, die das englische nicht kennt, und stellen sie zudem in unterschiedlicher Reihenfolge. Das ist kein typografischer Zierrat, sondern eine Sortierregel. Eine Liste von Titeln oder Kunden, die für alle Sprachen nach einer Regel sortiert wird, ist für einen Teil des Publikums schlicht unsortiert, und die Katalogsuche legt einen zweiten Fehler darauf: Ein ohne diakritisches Zeichen getippter Ausdruck findet den Eintrag nicht, der es trägt. Die Lösung besteht darin, die Vergleichsregel für Text zu einer Eigenschaft der Sprachfassung zu machen und nicht zu einer globalen Einstellung der Datenbank.

Der zweite Punkt ist der Unterschied zwischen Sprache und Markt. Eine Kundin in Norwegen und eine Kundin in Schweden können die Seite beide auf Englisch lesen und trotzdem andere Papierformate und eine andere Begrifflichkeit für Bindearten brauchen. Das Inhaltsmodell muss deshalb zulassen, dass Sprache und Markt zwei Achsen sind und nicht eine. Seiten, die beides verschmelzen, übersetzen am Ende dieselben Daten ein zweites Mal, nur um eine einzige Tabelle auszutauschen.

Der dritte Punkt betrifft Adressen. Jede Sprachfassung braucht eine eigene, dauerhafte Adresse und eine erklärte Verbindung zu den übrigen, sonst zeigt eine Suchmaschine dem schwedischen Verlag die englische Fassung, und das heißt in der Praxis: eine Anfrage, die nicht ankommt.

#Der Kunde: Have a Book aus Gdynia

Have a Book arbeitet seit 2007 von Gdynia aus, von einer Adresse in der Wierzbowa-Straße, mit einer Belegschaft im zweistelligen Bereich. Das Unternehmen beschreibt sich als einzige Anlaufstelle für Bildungsverlage in Europa: Satz und Druckvorstufe, Gestaltung, Druck und Bindung sowie die Umwandlung gedruckter Titel in elektronische Formate mit Rücksicht auf Barrierefreiheit nach WCAG. Zu den Kunden gehören Bildungsverlage in Norwegen, Frankreich, der Schweiz und Belgien.

Dieses Profil bestimmt die Form der Seite. Ein Bildungsverlag kauft nicht spontan und kauft nicht ein einzelnes Buch. Er kauft eine Reihe von Titeln in mehreren Varianten, und die Entscheidung trifft eine Gruppe: Eine Person sieht auf das Budget, eine zweite auf den Termin, eine dritte darauf, ob diese Druckerei eine bestimmte Bindung bei einem Schulbuch beherrscht, das drei Jahre lang täglich aufgeschlagen wird. Eine Seite, die diese Entscheidung bedient, braucht dreierlei gleichzeitig: einen Preis, einen Termin und einen Beleg für die Verarbeitungsqualität.

#Der Preis ist eine Funktion und keine Zahl im Katalog

Der tiefste Unterschied zwischen diesem Projekt und einem gewöhnlichen Shop liegt an einer Stelle: Das Produkt hat hier keinen Preis. Ein zu druckendes Buch ist ein Satz von Parametern, und der Preis ist das Ergebnis einer Rechnung auf diesem Satz. Format, Papiergewicht, Seitenzahl, Bindung, Farbe oder Schwarzweiß, Auflage, Veredelung. Jeder Parameter verändert das Ergebnis, mehrere verändern es sprunghaft.

Eine Preisliste fängt das nicht auf. Die Zahl der Kombinationen wächst multiplikativ, das Ausschreiben als Katalogpositionen wird also nach dem dritten Parameter undurchführbar. Die Kalkulation muss auf Anfrage aus einer Tarifstruktur entstehen statt aus einer Liste abgelesen zu werden, und das legt die übrige Architektur fest, denn die Eingaben kommen aus einem Formular und das Ergebnis soll sofort erscheinen und nachvollziehbar sein.

Die zweite Eigenschaft dieses Fachgebiets ist weniger offensichtlich und im Code leicht zu übersehen. Druckkosten steigen nicht linear mit der Auflage, denn das Einrichten der Maschine kostet bei hundert Exemplaren dasselbe wie bei zehntausend und verteilt sich auf die Auflage. Dazu kommt, dass ein Formatwechsel den Auftrag auf eine andere Maschine oder einen anderen Bogen verschieben kann, was die Kosten in einer Stufe verändert und nicht entlang einer Kurve. Eine naive Umsetzung, die zwischen zwei Punkten der Tariftabelle interpoliert, liefert in der Mitte eines Bereichs richtige Werte und genau an den Schwellen falsche, also dort, wo am häufigsten nachgefragt wird. Die Rechnung muss die Stufen abbilden und nicht eine Kurve durch sie hindurch.

#Katalog und Referenzen

Der Katalog der Druck- und Verlagsleistungen ist eine nach Kategorie, Leistungsart und Spezifikation gefilterte Ansicht. Gefiltert wird in der Abfrage und nicht im Browser, aus demselben Grund wie in jedem technischen Katalog: Der Bestand wächst, und das Übertragen des ganzen Bestands lohnt früher nicht mehr, als es beim Testen mit Beispieldaten auffällt.

Es gibt eine weitere Eigenschaft, die diesen Katalog von einem Produktkatalog trennt. Eine Position im Angebot einer Druckerei ist keine Sache, sondern eine Fertigungsfähigkeit, und Fähigkeiten beschreiben sich in Bereichen: von so vielen bis so vielen Seiten, in diesen Formaten, auf Papier dieses Gewichts, mit diesen Bindungen. Ins Inhaltsmodell übertragen heißt das, dass ein Attribut häufig ein Intervall ist und kein Wert, und dass ein Spezifikationsfilter nach der Zugehörigkeit zu einem Intervall fragen muss und nicht nach Gleichheit. Auf Gleichheit gebaute Filter wirken beim Bau korrekt und blenden still die Hälfte des Angebots aus, sobald jemand eine Seitenzahl eingibt, die keiner der aufgezählten Varianten entspricht.

Die Referenzen erfüllen hier eine Aufgabe, die sie auf den meisten Dienstleistungsseiten nicht haben. Ein Verlag beurteilt eine Druckerei danach, wie das fertige Buch aussieht, und eine Coveraufnahme in geringer Auflösung sagt nichts darüber, wie sich der Rücken nach einem Jahr Gebrauch verhält oder wie eine Farbe auf einem bestimmten Papier ausfällt. Galerien müssen also Details zeigen, was große Dateien bedeutet, und daher stammt die eigene Arbeit daran, dass die Galerieseite nicht alles auf einmal lädt. Vorschauen zuerst, vollständige Fassungen erst beim Öffnen, und die Dateien selbst kommen aus der Auslieferungsschicht und nicht vom Anwendungsserver.

#Herausforderungen und Programmierlösungen

Die erste Herausforderung war die Kalkulation hinter eigenen Schnittstellenpunkten. Das Formular schickt einen Parametersatz, der Server liefert ein Ergebnis. Die entscheidende Frage lautet, wo die Rechenlogik wohnt. Den Preis im Browser zu rechnen ist verlockend, weil das Ergebnis sofort erscheint und keine Anfrage kostet. Verlockend und falsch: Die Tarifstruktur wird damit öffentlich, und die Kopie der Logik im Browser läuft bei der ersten Tarifänderung aus dem Takt, die niemand in beide Richtungen nachzieht. Gerechnet wird deshalb auf dem Server, der Browser sammelt nur Parameter ein und zeigt das Ergebnis.

Die zweite Herausforderung war die Nachvollziehbarkeit einer Kalkulation. Ein am Montag genannter Preis muss am Donnerstag rekonstruierbar sein, auch wenn sich die Tariftabelle zwischenzeitlich geändert hat. Gespeichert wird deshalb neben der Kalkulation der vollständige Parametersatz und die Version der Tarifstruktur, aus der sie stammt, und nicht nur die Zahl. Ohne das entwertet jede Tarifänderung die Historie, und die einfache Frage, warum die Kundin diesen Betrag gesehen hat, bleibt unbeantwortbar. Dieselbe Entscheidung ordnet das Zwischenspeichern: Der Schlüssel eines gespeicherten Ergebnisses muss die Tarifversion enthalten, sonst liefert die Seite nach einer Aktualisierung eine Weile alte Beträge aus, und zwar ohne Spur in den Protokollen.

Die dritte Herausforderung war die Leistung bei vielen Medien. Ein Cache im Arbeitsspeicher verkürzt die Datenbankarbeit für alles, was ohnehin durch die Anwendungsschicht muss: Katalogmengen, Tariftabellen, Einstellungen. Ein Auslieferungsnetz übernimmt die Dateien. Zwei verschiedene Probleme, die es ausdrücklich zu trennen lohnt, weil sie oft verwechselt werden: Ein Cache im Arbeitsspeicher beschleunigt keinen Download eines Bildes in voller Auflösung, und eine Randschicht verkürzt keine Datenbankabfrage.

Die vierte Herausforderung war die Anbindung an die betriebseigenen Systeme, also Produktionspläne und Angaben zur Materialverfügbarkeit. Die Anwendung fragt das Produktionssystem nicht während des Seitenaufbaus. Daten werden unabhängig geholt und mit einer je Quelle gewählten Lebensdauer zwischengespeichert, denn ein Plan ändert sich in einem anderen Rhythmus als eine Tariftabelle. Wichtig ist das Verhalten im Fehlerfall: Ist eine Quelle nicht erreichbar, zeigt die Ansicht den zuletzt bekannten Wert oder eine Fassung ohne diesen Abschnitt, nie eine Fehlermeldung. Eine Besucherin hat keinen Anlass zu erfahren, dass gerade ein internes System nicht antwortet.

#Dateien annehmen ist kein Warenkorb

Ein Druckauftrag ist kein Einkaufskorb, sondern ein Fertigungsauftrag, dem Material beiliegt. Eine druckfertige Datei ist oft groß, und ihr Weg durch ein gewöhnliches Formular scheitert an serverseitigen Grenzen und an abbrechenden Verbindungen. Der Upload musste deshalb den Abbruch überstehen und nicht bei jedem Versuch von vorn beginnen.

Darüber hinaus kann eine Datei, die im Browser tadellos aussieht, in der Produktion unbrauchbar sein, weil der Farbraum nicht stimmt oder der Beschnitt fehlt. Eine Prüfung bei der Annahme gehört deshalb zum Ablauf und ist keine Zugabe: Diesen Fehler bei der Auftragsannahme zu finden kostet eine Minute, ihn an der Maschine zu finden kostet die Auflage.

#Barrierefreiheit gehört zum Angebot des Kunden

Eine Sache, die in Projektbeschreibungen selten vorkommt, gehört hier ausdrücklich hin. Have a Book wandelt Publikationen in elektronische Formate um und achtet dabei auf Barrierefreiheit nach WCAG, verkauft also eine Fähigkeit, die die Seite selbst vorführen muss. Die Folge ist einfach und unbequem: Die Seite eines Unternehmens, das barrierefreie Publikationen verkauft, darf keinen Katalog haben, der sich nicht mit der Tastatur bedienen lässt, und keine Spezifikationstabellen, deren Kopfzellen nicht mit den Datenzellen verknüpft sind.

Eine Tabelle technischer Parameter ohne diese Verknüpfung ist für einen Screenreader eine Folge bedeutungsloser Zahlen, und auf dieser Seite sind Spezifikationstabellen der Hauptinhalt. Für das Kalkulationsformular gilt dasselbe: Felder, die logisch voneinander abhängen, müssen auch im Markup verbunden sein, sonst erreicht die Nachricht, dass die Wahl der Bindung die verfügbaren Formate eingeschränkt hat, nur die Person, die gerade auf den richtigen Bildschirmausschnitt blickt.

#Werkzeuge

Das Backend läuft auf PHP und MySQL, die interaktive Schicht auf JavaScript und eigenen Schnittstellenpunkten, die schnellen Lesewege auf einem Cache im Arbeitsspeicher. Die Infrastruktur liegt in der Cloud, der Code unter Versionskontrolle, was hier eine konkrete Bedeutung hat: Die Tariftabelle ist Datenbestand, die Regeln ihrer Anwendung sind Code, und erst die Trennung erlaubt eine Preisänderung ohne Auslieferung und eine Regeländerung ohne Anfassen der Preise.

Die Darstellungsschicht ruht auf responsiven Standards und einem Präprozessor, der die Umbruchpunkte an einer Stelle hält. Auf einer Seite mit einem Formular aus einem Dutzend Feldern ist das nicht kosmetisch. Das Kalkulationsformular ist die wichtigste Ansicht des Projekts und zugleich die auf schmalen Bildschirmen am schwersten zu ordnende, weil die Felder voneinander abhängen und eine Änderung an einem oft in einem anderen sichtbar wird.

#Wartung

Die Betreuung umfasst Aktualisierungen, Überwachung und laufende Änderungen. Eine Seite mit Kalkulation trägt eine Pflicht, die eine gewöhnliche Broschüre nicht hat: Änderungen an der Tarifstruktur müssen gegen historische Daten geprüft werden. Eine Änderung, die an einem Beispiel richtig aussieht, kann das Ergebnis an einer anderen Auflagenschwelle verschieben, und bemerken wird es zuerst eine Kundin mit einem Betrag, der dem der Vorwoche widerspricht.

Aktualisierungen laufen zuerst auf einer Produktionskopie, und das ist keine Formsache. Eine leere Installation hat keinen Katalog dieser Größe, keine vier Sprachfassungen desselben Eintrags, keine Galerie mit Dateien in Produktionsauflösung und keine gespeicherten Kalkulationen aus mehreren Tarifversionen. An genau diesen vier Dingen scheitern Aktualisierungen, und keines davon existiert in einer von Grund auf gebauten Testumgebung.

Für Sicherungen gilt die Regel wie überall: Eine, die nie jemand zurückgespielt hat, ist keine Sicherung, sondern eine Datei. Hier kommt ein zweiter Punkt hinzu, denn von Kunden hochgeladene Dateien sind Produktionsmaterial und kein Seiteninhalt, ihr Verlust ist ein Ereignis anderer Klasse als der Verlust einer Leistungsbeschreibung.

#Ablauf des Projekts

Der Bau dauerte rund sechs Wochen, vom Festlegen des Umfangs bis zur Veröffentlichung. Layout und Anordnung der Elemente kamen vom Kunden, die Zeit floss also in die Teile, die ein Entwurf nicht zeigt: ein Inhaltsmodell, das Sprache von Markt trennt, die Tarifstruktur samt Anwendungsregeln, die Schnittstellenpunkte der Kalkulation sowie Annahme und Prüfung der Dateien.

Getestet wurde gegen eine Produktionskopie. Bei einer Kalkulation wiegt das besonders schwer, denn die Richtigkeit eines Preises ist keine Eigenschaft, die man auf dem Bildschirm sieht. Sie wird geprüft, indem Ergebnisse mit dem verglichen werden, was das Unternehmen von Hand ausrechnen würde, und sie wird an den Schwellen geprüft und nicht in der Mitte der Bereiche. Ein Testfall je Parameter erzeugt den Eindruck von Abdeckung und sagt nichts über das Verhalten beim Übergang zwischen Maschinen oder Bogenformaten.

Nach dem Start ging die Seite in die Pflege über: Aktualisierungen, Überwachung, Änderungen an der Tarifstruktur und Ausbau des Katalogs, während sich das Angebot veränderte.

#Zusammenfassung und Anforderungsanalyse

Die Seite haveabook.pl musste vier Anforderungen gleichzeitig erfüllen. Erstens die Darstellung eines Angebots, das sich mit einer Preisliste nicht beschreiben lässt, weil der Preis das Ergebnis einer Rechnung auf Parametern ist. Zweitens vier Sprachfassungen, drei davon nordisch, mit den jeweils eigenen Regeln zur Textsortierung. Drittens die Verbindung zu den betriebseigenen Systemen auf eine Weise, die deren Ausfälle nicht an die Seite weiterreicht. Viertens die Annahme von Produktionsmaterial und nicht nur von Bestellungen.

Aus diesen vier folgt der gesamte Aufbau: Rechnen auf dem Server, Versionierung der Tarifstruktur neben jeder gespeicherten Kalkulation, ein Cache-Schlüssel, der diese Version enthält, Sprache und Markt als getrennte Achsen im Inhaltsmodell und eine Dateiauslieferung, die vom Anwendungsserver ferngehalten wird. Das Ergebnis unterstützt die tägliche Arbeit eines Verlags und einer Druckerei, statt nur zu beschreiben, was dort geschieht.