E-Commerce-Entwicklung: nehrebeccy.pl

#Eine Umsetzung aus der Zeit vor der clientseitigen Bildauswahl

Projektbeschreibungen nennen gern den heutigen Stand und lassen offen, womit die Umsetzung eigentlich gestartet ist. Damit verschwindet der Unterschied zwischen einer Entwurfsentscheidung und einem späteren Austausch, den irgendein Anbieter erzwungen hat. Diese Umsetzung entstand, bevor Browser und WordPress die Auswahl der Bildvariante selbst übernahmen, und mehrere Lösungen darin waren unter dieser Bedingung notwendig, während sie heute ein Fehler wären.

Das deutlichste Beispiel sind Bilder. Zum Zeitpunkt des Baus kannten Browser noch keinen Mechanismus, mit dem sich die passende Bildvariante auf der Clientseite auswählen ließ, und in WordPress kam diese Fähigkeit erst Jahre später an. Die Entscheidung, welche Fassung eines Fotos ausgeliefert wird, fiel also auf dem Server, anhand registrierter Bildgrößen. Eine Galerie, die direkt aus der Kamera einer Fotografin hochgeladen wurde, brauchte deshalb im Voraus definierte Zwischengrößen, sonst lud ein Telefon die Datei herunter, die für einen Schreibtischbildschirm gedacht war.

Das zweite Beispiel ist das Layout selbst. Native Raster standen in Browsern noch nicht zur Verfügung, also beruhten Spalten auf umfließenden Elementen und Prozentbreiten. Bei einer Galerie mit wechselnder Elementzahl verlangt das Sorgfalt beim sauberen Abschluss der Reihen, ein Problem, das eine heutige Rasterdefinition in zwei Zeilen erledigt. Der Stylesheet-Präprozessor war in dieser Lage kein Schmuck, sondern das Werkzeug, das die Umbruchpunkte an einer einzigen Stelle hielt. Ohne ihn verteilen sich Breitenschwellen über das gesamte Stylesheet, und jede Änderung am Raster berührt ein Dutzend Stellen gleichzeitig.

#Der Kunde: eine Agentur aus Gdynia

R&K Nehrebeccy ist eine Künstleragentur aus Gdynia, geführt von Renata und Krystian Nehrebecki und seit 1994 ununterbrochen tätig. Sie entwickelt und betreut künstlerische Veranstaltungen: Begegnungen mit bekannten Persönlichkeiten, Konzerte, Bühnenprogramme, feierliche Eröffnungen, Jahrestage und Jubiläen, vom Einfall über das Drehbuch und die Verpflichtung der Künstler bis zu Bühnenbild und Projektion. Ein eigener, wiedererkennbarer Teil des Angebots sind literarische Abende mit Buchautorinnen und Buchautoren. Das Umfeld ist die Dreistadt: Klubs, Kulturhäuser, Bibliotheken.

Wer auf der anderen Seite einer Anfrage sitzt, ist keine Privatperson. Es ist die Programmkoordination eines Kulturhauses oder einer Bibliothek, oder die Person in einem Unternehmen, der das Jubiläum zugeteilt wurde. Diese Person kommt mit einem Namen im Kopf, prüft, ob die Agentur bereits mit diesem Namen gearbeitet hat, und schreibt erst danach. Die Navigation musste daher von einem Namen zu einer Veranstaltung und von einer Veranstaltung zurück zu einem Namen führen, nicht von der Startseite in einen Reiter mit dem Leistungsangebot.

#Hauptfunktionen der Webseite

Das Künstlerportfolio ist die zentrale Ansicht. Jedes Profil bündelt Fotos, eine Beschreibung des Werks und die Geschichte der Zusammenarbeit. Die Reihenfolge der Informationen folgt einer einzigen Aufgabe: in wenigen Sekunden beurteilen zu können, ob diese Person zu dem Abend passt, den jemand gerade plant. Deshalb stehen Foto und Kurzbeschreibung über der vollständigen Biografie, und die Liste der Auftritte ist sichtbar, ohne bis zum Seitenende zu scrollen.

Veranstaltungskalender und Archiv sind dieselben Daten aus zwei Blickrichtungen. Kommende Termine sind Information für ein Publikum, vergangene sind Beleg für eine Auftraggeberin. Eine Veranstaltung verschwindet nach ihrem Datum also nicht, sie wechselt die Ansicht.

Multimediale Inhalte liegen im Eintrag selbst und sind nicht am Ende angehängt. Die Galerie eines Abends überzeugt die nächste Kundin häufiger als jeder Angebotstext, sie muss sich also leicht ergänzen und schnell öffnen lassen. Diese beiden Anforderungen stehen gegeneinander, und die gesamte Leistungsarbeit in diesem Projekt bestand darin, sie zu versöhnen.

Redigiert wird im gewöhnlichen WordPress-Backend, mit Feldern, die zu den Inhaltstypen passen. Ein Seitenbaukasten fehlt hier bewusst. Wer zwischen zwei Autorenbegegnungen eine Veranstaltung einträgt, soll Felder ausfüllen und kein Layout entwerfen, denn ein Layoutentwurf bei jedem Eintrag ist der kürzeste Weg zu einer Seite, deren zwanzig Unterseiten wie zwanzig verschiedene Seiten aussehen.

Das Teilen in sozialen Netzwerken zählt in diesem Zusammenhang zur Funktion und nicht zur Dekoration. Die Nachricht über eine Autorenbegegnung verbreitet sich über die Profile der Beteiligten und über die Seiten der gastgebenden Einrichtungen, jeder Eintrag braucht also korrekte Angaben für die Freigabe: Titel, Beschreibung und ein Bild, das kein zufälliger Ausschnitt des Hintergrunds ist.

#Das Inhaltsmodell als eigentliche Entscheidung

Die Umsetzung läuft auf WordPress, und die erste Festlegung betraf die Frage, was in der Datenbank eine Künstlerin ist und was eine Veranstaltung. Der scheinbar günstigste Weg, beides als gewöhnliche Beiträge oder gar als Seiten zu führen, spart einen Nachmittag beim Bau und kostet bei jeder späteren Änderung. Ein einfacher Beitrag hat keinen Platz für ein Veranstaltungsdatum, einen Ort oder die Rolle, die eine bestimmte Person an genau diesem Abend hatte. All das landet dann im Fließtext, also in einem einzigen Textfeld, aus dem sich programmatisch nichts herauslesen lässt.

Künstler und Veranstaltung sind hier deshalb eigene Inhaltstypen, verbunden über eine Beziehung. Eine Veranstaltung hat mehrere Mitwirkende, eine mitwirkende Person hat viele Veranstaltungen, und genau diese Struktur erlaubt es, aus einem Datenbestand zwei Ansichten zu erzeugen: das Profil mit der Liste der Auftritte und die Veranstaltungsseite mit der Liste der Beteiligten. Wären diese Listen auf beiden Seiten von Hand gepflegt, verlangte jede Änderung zwei Bearbeitungen, und nach einem Jahr wäre die Hälfte davon still auseinandergelaufen.

Taxonomien ordnen das aus einer dritten Richtung. Die Aufteilung der Mitwirkenden in Autorinnen, Schauspieler und Journalistinnen sowie die Aufteilung der Veranstaltungen in Konzert, Autorenbegegnung, Eröffnung und Jubiläum ergibt Listen, die niemand pflegen muss. Ein neuer Eintrag mit passender Kategorie erscheint von selbst an der richtigen Stelle. Das klingt nach einer Kleinigkeit, entscheidet aber bei einer Seite, die zwei Personen neben ihrer eigentlichen Arbeit betreuen, darüber, ob sie nach drei Jahren noch stimmt.

#Herausforderungen und implementierte Programmierlösungen

Die erste Herausforderung war das Durchsehen eines umfangreichen Angebots ohne vollständiges Neuladen. Das Filtern nach Kategorie und das Nachladen weiterer Abschnitte der Liste läuft über AJAX, was hier einen konkreten Mechanismus bedeutet: Die Anfrage erreicht den gemeinsamen Einstiegspunkt von WordPress für asynchrone Aufrufe. Was das kostet, erklärt die übrigen Entscheidungen. Jede solche Anfrage startet WordPress samt Plugins vollständig, kostet also etwa so viel wie das Erzeugen einer ganzen Seite, obwohl nur ein Listenausschnitt zurückkommt. Über eine Sitzung hinweg, in der jemand mehrfach Filter umschaltet, summiert sich das.

Daraus folgt die Konstruktion: Die Liste bleibt kurz, der Filter verengt die Menge in der Abfrage und nicht im Browser, und das Ergebnis einer Filterkombination lässt sich zwischenspeichern. Die Alternative, alle Mitwirkenden auf einmal zu laden und im Browser zu sieben, ist verlockend, weil der Code einfacher ausfällt, und hört genau dann auf zu funktionieren, wenn der Bestand groß genug ist, dass seine vollständige Übertragung mehr kostet als die zusätzlichen Anfragen.

Die zweite Herausforderung war die Leistung einer medienlastigen Seite. Ein Objekt-Cache im Arbeitsspeicher verkürzt die Datenbankarbeit für alles, was ohnehin durch PHP muss: Beitragsmengen, Taxonomiebegriffe, Optionen. Ein Auslieferungsnetz übernimmt die Dateien, also Fotos und Aufnahmen, und in diesem Projekt kommt von dort der größere Teil des spürbaren Unterschieds, weil Aufnahmen aus Konzertsälen das Schwerste sind, was hier ausgeliefert wird. Das sind zwei verschiedene Probleme mit zwei verschiedenen Werkzeugen: Ein Objekt-Cache beschleunigt keinen Bilddownload, und ein Randnetz verkürzt keine Datenbankabfrage.

Bei den Galerien kommt eine dritte Überlegung hinzu, die mit keinem der beiden Werkzeuge zu tun hat. Ein Abend bringt Aufnahmen in einer Menge mit, die niemand auf einmal ansieht, und das Laden aller Dateien beim Seitenaufbau bezahlt die Besucherin für Bilder, die sie nie erreicht. Die Galerie liefert deshalb zunächst Vorschauen und holt die großen Fassungen erst beim Öffnen. Das klingt selbstverständlich, war es damals aber nicht, weil die Verzögerung des Nachladens eigener Code war und keine Angabe im Bild-Element, die der Browser von sich aus beachtet.

Die vierte Herausforderung war die einfache Pflege, und die Antwort darauf ist organisatorisch statt technisch. Felder statt freier Inhalte, aus Beziehungen erzeugte Listen statt getippter, festgelegte Bildgrößen statt einer Einzelfallentscheidung bei jedem Hochladen. Eine Seite, bei der die redigierende Person drei Regeln im Kopf behalten muss, um das Layout nicht zu zerlegen, ist eine Seite, die in der ersten Woche nach der Übergabe zerlegt wird.

Die fünfte Herausforderung betraf das Zurücknehmen von Änderungen. Inhalt, Konfiguration und Code liegen getrennt, und diese Eigenschaft zeigt sich erst bei der ersten missratenen Änderung nach dem Start. Hängt das Aussehen eines Abschnitts davon ab, was jemand in den Fließtext geschrieben hat, dann ist eine optische Korrektur eine inhaltliche Änderung und lässt sich nicht zurücknehmen, ohne redaktionelle Arbeit zu verwerfen. Getrennte Schichten bedeuten dagegen, dass eine Rücknahme genau eine davon berührt.

#Das Archiv als Verkaufsargument

Auf den meisten Seiten mit Kalender ist eine vergangene Veranstaltung Abfall. Hier verhält es sich umgekehrt, und diese Umkehrung bestimmt, wie das Datum gespeichert werden muss.

Der naheliegende Griff ist ein Zusatzfeld am Eintrag. In WordPress landet ein solches Feld in der Metadatentabelle, deren Werte als Text und nicht als Datum abgelegt sind. Eine Abfrage nach künftigen Terminen ist dann kein Datumsvergleich mehr, sondern ein Zeichenkettenvergleich, der bei tagesorientierter Schreibweise am Monatswechsel Unsinn liefert. Zusätzlich fügt jede dieser Abfragen eine Verknüpfung mit der Metadatentabelle hinzu, und Filtern und Sortieren über dasselbe Feld fügt weitere hinzu.

Es gibt zwei saubere Auswege, und beide verlangen eine Festlegung zu Beginn statt nach einem Jahr. Entweder wird das Datum in einer Form geschrieben, die als Text korrekt sortiert, also Jahr zuerst und ohne Trennzeichen, oder das Veröffentlichungsdatum des Eintrags trägt das Veranstaltungsdatum und der Umgang mit zukünftig datierten Einträgen wird angepasst, womit die gesamte Auswahl auf eine indizierte Spalte der Beitragstabelle wandert. Bei fünfzig Einträgen ist der Unterschied unsichtbar, nach zehn Jahren Archiv sehr deutlich, und Letzteres ist der Zweck des Archivs.

Die zweite Falle betrifft Adressen. Die Seite einer drei Jahre alten Veranstaltung wird oft von der Bibliothek oder dem Kulturhaus verlinkt, das sie ausgerichtet hat. Richtet sich die Adresse danach, ob eine Veranstaltung bevorsteht oder vorüber ist, dann ändert der Datumswechsel die Adresse und alle diese Verweise brechen. Eine Adresse muss beschreiben, was die Veranstaltung ist, nie, in welchem Reiter sie gerade erscheint.

#Support und Wartung der Webseite

Die Betreuung umfasst Aktualisierungen von Kern und Theme, die Durchsicht der Protokolle und Sicherungen. Die Reihenfolge ist hier keine Formsache: Eine Sicherung, die nie jemand zurückgespielt hat, ist keine Sicherung, sondern eine Datei. Die Prüfung der Wiederherstellung gehört zur Arbeit und nicht als Zugabe dazu.

Aktualisierungen bergen bei einer Seite mit Beziehungen zwischen Inhaltstypen ein eigenes Risiko. Wird die Verbindung zwischen Mitwirkenden und Veranstaltung über eine Zwischenschicht gehalten, kann deren Änderung die Ablage dieser Verbindungen umstellen, und die Listenansicht wirkt danach genau so lange korrekt, bis jemand einen neuen Eintrag anlegt. Aktualisierungen laufen deshalb zuerst auf einer Kopie, und die Prüfung besteht darin, eine neue Verknüpfung anzulegen, nicht darin, die Startseite anzusehen.

Kleinere optische und funktionale Änderungen während der Wartung folgen derselben Regel wie der Aufbau: Eine Änderung geht in die Schicht, zu der sie gehört. Eine neue Veranstaltungsart ist ein Taxonomiebegriff und kein neues Template. Andere Proportionen in der Galerie sind eine Änderung der registrierten Bildgrößen samt Neuerzeugung und keine Stilregel, die an eine einzelne Unterseite geklebt wird.

#Ablauf des Projekts

Das Ganze dauerte rund sechs Wochen, vom Festlegen des Umfangs bis zur Veröffentlichung. Layout und Anordnung der Elemente kamen vom Kunden, die Phase also, die in anderen Projekten den meisten Kalender frisst, entfiel hier. Die Zeit floss in das Inhaltsmodell und in die Teile, die ein Entwurf nicht zeigt: die Beziehung zwischen Person und Veranstaltung, die Speicherung des Datums, die Bildgrößen und das Verhalten der Listen beim Filtern.

Getestet wurde gegen eine Kopie der Produktion, nicht gegen eine leere Installation. Bei einer Seite dieser Form ist der Unterschied greifbar: Eine leere Installation kennt keinen Eintrag mit achtzig Fotos in einer Galerie, keine Person, deren Auftritte über mehrere Jahre verstreut sind, und keine Einträge, in denen das Datumsfeld uneinheitlich gefüllt wurde, weil es jemand einmal von Hand in einem anderen Format eingetragen hat. Alle drei Fälle zeigen sich erst an echten Daten, und jeder von ihnen kann eine Listenansicht umwerfen.

Nach dem Start ging die Seite in die Pflege auf Seiten der Agentur über, mit unserer Unterstützung bei Aktualisierungen und bei Änderungen, die über das Redigieren hinausgehen.

#Zusammenfassung

nehrebeccy.pl ist die Seite einer Künstleragentur, aufgebaut um zwei Einheiten, die mitwirkende Person und die Veranstaltung, sowie um deren Beziehung. Aus dieser Struktur stammen sämtliche Ansichten: das Profil mit den Auftritten, die Veranstaltungsseite mit den Beteiligten, die Listen nach Kategorien und das Archiv, das in dieser Branche ein Argument und kein Ballast ist.

Technisch ruht die Umsetzung auf WordPress, einem Objekt-Cache im Arbeitsspeicher, einem Auslieferungsnetz für Medien und einem responsiven Layout aus einer Zeit, in der Responsivität noch Handarbeit an jeder Bildvariante bedeutete. Organisatorisch ruht sie auf etwas Einfacherem: Eine Seite, die zwei Personen neben ihrer eigentlichen Arbeit führen, muss es überstehen, dass sich niemand an die Regeln von der Übergabe erinnert.