Tech Platform: car-mechanic-huntington.co.uk

#car-mechanic-huntington.co.uk - Website für eine lokale Kfz-Werkstatt

Diese Seite entstand 2012, und dieses Datum erklärt mehr an ihr als jede Funktionsliste. Ein responsives Layout war damals ein eigener Posten im Leistungsumfang und keine Selbstverständlichkeit. Flexbox war nicht in verbreitetem Einsatz, CSS Grid existierte nicht, also wurden Spalten über gefloatete Blöcke gesetzt und Umbruchpunkte gegen die Bildschirmbreiten der Geräte gewählt, die die Leute tatsächlich in der Tasche hatten. Daher stammt das Raster aus dem Bootstrap-Framework: nicht aus Mode, sondern weil die Alternative darin bestand, dasselbe selbst zu schreiben und anschließend jahrelang allein zu pflegen.

Das Projekt car-mechanic-huntington.co.uk stellt das Leistungsangebot einer Kfz-Werkstatt dar und erlaubt die Terminbuchung. Angesprochen sind Autobesitzer aus der Umgebung, Menschen mit einem konkreten Defekt und kleine Betriebe, die mehrere Fahrzeuge im Einsatz halten. Die Umsetzung dauerte etwa sechs Wochen.

#Der Kalender ist kein Formularfeld

Wer auf eine Werkstattseite kommt, kommt selten aus Neugier. Er kommt, weil am Auto etwas nicht stimmt, und bringt drei Fragen bereits fertig mit: Könnt ihr das reparieren, wann habt ihr Zeit, wo seid ihr. Die Buchung beantwortet die zweite davon, und sie ist der technisch anspruchsvollste Teil dieser Seite.

Eine Werkstatt hat keinen Kalender in dem Sinn, in dem ein Berater einen Kalender hat. Sie hat Hebebühnen und sie hat Mechaniker, und ein Termin ist eine Kombination aus beidem über eine Dauer, die von der Arbeit abhängt. Ein Ölwechsel und ein sporadischer Elektrikfehler belegen völlig unterschiedliche Teile eines Tages. Ein Datenmodell, das eine Buchung als Datum und Uhrzeit ablegt, scheitert am ersten Morgen, an dem zwei Leute acht Uhr wollen und eine Bühne da ist.

Daraus folgt die Entscheidung, um die es in diesem Modul eigentlich geht. Die im Browser angezeigte Verfügbarkeit ist eine Aufnahme eines bereits vergangenen Moments. Zwischen dem Rendern der Liste und dem Klick auf den Knopf vergehen gern zehn oder fünfzehn Minuten, weil der Besucher erst klärt, ob er sich freinehmen kann. Die Prüfung muss also beim Schreiben erneut auf dem Server laufen, und zwar so, dass nicht zwei Anfragen durch dieselbe freie Stunde hindurchkommen. Eine Oberfläche, die belegte Zeiten nur ausgraut, sieht richtig aus und erzeugt die erste Doppelbuchung, sobald zwei Leute gleichzeitig auf der Seite sind.

Die zweite Folge betrifft den Zwischenspeicher. Das meiste an einer Werkstattseite ist stabil: Leistungsbeschreibungen, Anfahrt, Öffnungszeiten. Solche Inhalte dürfen lange im Cache liegen. Die Verfügbarkeitsansicht ist das genaue Gegenteil, denn ihr einziger Wert besteht darin, aktuell zu sein. Eine Konfiguration, die ausnahmslos alles zwischenspeichert, liefert bereitwillig ein eine Woche altes Bild des Terminbuchs, und niemand merkt es, bis ein Kunde vor dem geschlossenen Tor steht. Die Buchungsansicht ist deshalb ausdrücklich vom Caching ausgenommen.

#Warum eigene Endpunkte statt eines Buchungs-Plugins

Buchungs-Plugins gibt es reichlich, und die meisten bilden einen Friseur oder eine Praxis ab: eine Person, ein Stuhl, eine feste Slotlänge. Dieses Modell so zu verbiegen, dass es eine zweite Achse und eine variable Dauer akzeptiert, kostet mehr als den Schreibpfad selbst zu bauen, und es hinterlässt fremde Annahmen genau dort, wo eine falsche Annahme einen Kunden erzeugt, dem neun Uhr zugesagt wurde und der nicht drankommt.

Der Kalender spricht deshalb über eigene Endpunkte mit der Datenbank. Der Browser sammelt Parameter und zeigt ein Ergebnis an; entschieden wird dort nichts. Diese Trennung hält nebenbei die tatsächliche Kapazität der Werkstatt aus der Öffentlichkeit heraus, und das wiegt schwerer, als es klingt: Anzahl der Bühnen und die je Arbeitsart angesetzte Dauer sind Betriebsinformationen, und ein Widget, das Verfügbarkeit im Browser berechnet, veröffentlicht sie vollständig.

#Öffnungszeiten sind schwerer als sie aussehen

Öffnungszeiten wirken wie das einfachste Feld der ganzen Seite und sind in einem Buchungssystem die häufigste Fehlerquelle. Sie sind keine Zeichenkette, sondern eine Regel mit Ausnahmen, und die Ausnahmen sind es, die zählen.

Eine Werkstatt schließt an Feiertagen, macht Betriebsferien, nimmt samstags nur halbe Tage an und sperrt einzelne Bühnen, wenn jemand krank ist. Wird das als Text in der Fußzeile gepflegt und die Verfügbarkeit getrennt davon berechnet, laufen beide Angaben binnen weniger Monate auseinander, und der Widerspruch fällt einem Kunden auf, nicht dem Betrieb. Deshalb kommen Anzeige und Buchungslogik aus derselben Quelle: es gibt eine reguläre Woche und darüber gelegte Ausnahmen für einzelne Tage, und die angezeigten Zeiten werden daraus erzeugt statt separat gepflegt.

Dazu kommt ein Detail, das in der Werkstattarbeit anders liegt als bei Terminen im Büro. Der letzte buchbare Termin eines Tages ist nicht der Schließzeitpunkt minus die Slotlänge, denn das Fahrzeug muss abgeholt oder die Bühne geräumt werden. Die letzte Annahme liegt also früher, und um wie viel, hängt an der Art der Arbeit. Ein System, das diese Grenze aus der Schließzeit ableitet, verkauft regelmäßig den letzten Termin des Tages und erzeugt genau dort Ärger, wo eine Werkstatt ihn am wenigsten gebrauchen kann.

#Die Karte ist das teuerste Element der Kontaktseite

Eine eingebettete Karte bestellt der Kunde in einem Halbsatz, und sie kostet mehr als der restliche Inhalt der Kontaktseite zusammen.

Sie besteht aus fremdem Skript, fremden Stilen und einer Reihe von Anfragen nach Bildkacheln, alles von Infrastruktur, auf die wir keinen Einfluss haben. Auf einer kleinen Seite ist diese eine Komponente regelmäßig schwerer als jeder Inhalt darauf. Und sie läuft bei jedem Besucher, auch bei dem, der wegen der Telefonnummer gekommen ist und nach zehn Sekunden wieder weg sein wird.

Die Lösung besteht darin, sie nicht mit der Seite zu laden. Standardmäßig erscheint ein statisches Bild mit markiertem Standort und der Adresse als Text daneben; die interaktive Karte startet erst bei Berührung. Wer die Adresse brauchte, hat sie sofort, wer eine Route will, tippt einmal mehr und bekommt das vollständige Werkzeug. Diese Reihenfolge ist die Umkehrung der intuitiven, weshalb die schwere Variante so oft als Standard endet.

#Zentrale Funktionen und verwendete Technologien

Das responsive Layout stellt auf schmalen Bildschirmen das nach vorn, was am Telefon gebraucht wird: Nummer, Adresse, Anfahrt. Die Angebotstexte kommen danach, weil die Frage nach einer Werkstatt meist vom Parkplatz oder vom Straßenrand aus gestellt wird und nicht vom Schreibtisch.

Die Anbindung an soziale Netzwerke holt Beiträge und Bewertungen auf die Seite. Hier macht sich eine Website von einem Server abhängig, den niemand hier kontrolliert, also war das Verhalten im Fehlerfall schon beim Bau zu klären. Antworten werden zwischengespeichert, und wenn die Quelle nicht antwortet, zeigt der Abschnitt den letzten bekannten Stand oder gar nichts. Ein leerer Kasten mit Fehlermeldung auf der Startseite einer Werkstatt liest sich wie ein Totalausfall und nicht wie eine fremde Schnittstelle mit einem schlechten Nachmittag.

Die Suchmaschinenarbeit stützte sich auf semantisches HTML5, saubere Metadaten und strukturierte Daten für ein lokales Unternehmen. Bei einer örtlichen Dienstleistung zählen maschinenlesbar vor allem drei Dinge: Name, Anschrift und Telefonnummer in einer einzigen, unveränderlichen Schreibweise, die Öffnungszeiten und das Einzugsgebiet. Eine Abweichung zwischen der Adresse auf der Seite und der in externen Verzeichnissen ist ein klassischer langlebiger Defekt, weil beide Fassungen für einen menschlichen Leser in Ordnung aussehen.

WordPress als Redaktionsoberfläche hat bei diesem Kunden einen konkreten Grund. Eine Werkstatt hat keine Redaktion. Änderungen macht der Inhaber oder wer gerade im Büro sitzt, zwischen zwei Aufträgen. Das Ändern der Öffnungszeiten muss also ohne technisches Wissen möglich sein und ohne jedes Risiko, dabei das Layout zu zerlegen.

#Herausforderungen und Programmierlösungen

Das Ladegewicht wurde an drei Stellen angegangen: Bildkompression, Zwischenspeichern der selten wechselnden Inhalte und Reduzieren der Zahl von Stil- und Skriptdateien. Der letzte Punkt hatte 2012 ein Gewicht, das er heute nicht mehr hat, weil Browser pro Datei eine Verbindung aufbauten und dabei eine niedrige Grenze paralleler Abrufe einhielten. Zehn Stylesheets zu einem zusammenzuführen war damals keine Kosmetik, sondern das Streichen von neun Rundläufen zum Server.

Die Inhaltsmigration war das zweite große Stück. Eine ältere Fassung der Seite existierte, und Teile davon lagen nur noch als archivierte Kopien vor, die wir über Web Archive zurückgeholt haben. Die leichte Hälfte einer solchen Migration ist der Text. Die Hälfte, die übersprungen wird, sind die Adressen. Eine Seite, die Jahre online war, hat Verweise in örtlichen Verzeichnissen, in Branchenlisten und in bereits verschickten Mails, und keinen davon wird jemand nachziehen. Jede alte URL braucht deshalb eine bestimmte neue und eine dauerhafte Weiterleitung statt einer pauschalen Umlenkung auf die Startseite. Die pauschale Variante sieht im Browser gut aus, weil kein Fehler erscheint, und wirft weg, was die alte Adresse angesammelt hatte.

Personalisierte Module standen zuletzt an und stehen in direktem Widerspruch zum Caching, denn Caching lohnt sich gerade deshalb, weil viele Besucher dasselbe Dokument bekommen. Die Auflösung liegt in der Trennung: Seitengerüst und Angebotstexte sind gemeinsam und werden zwischengespeichert, die besucherabhängigen Fragmente werden nach dem Laden separat nachgeholt. Ohne diese Trennung entwertet jede Personalisierung den Zwischenspeicher der gesamten Website, und man muss sich für eines von beidem entscheiden.

#Werkzeuge und Technologien

WordPress für die Redaktion, PHP und MySQL auf dem Server, HTML5, CSS3 und JavaScript in der Darstellungsschicht, Raster und Komponenten aus Bootstrap für das responsive Layout, dazu automatische Sicherungen, Versionskontrolle für den Code und die Beobachtung der Sichtbarkeit in der Suche. Für die Sicherungen gilt hier derselbe Vorbehalt wie überall: eine Sicherung, die nie jemand zurückgespielt hat, ist eine Datei und keine Absicherung. Das Zurückspielen muss mindestens einmal auf einer getrennten Umgebung stattgefunden haben, denn Lücken zeigen sich ausschließlich dabei, und in dem Moment besteht meist ein Grund zur Eile. Bei einer Werkstattseite mit Terminbuch heißt das konkret, dass die Prüfung auch die Buchungstabellen umfasst und nicht nur die Seiteninhalte.

Eine Anmerkung zu Plugins gehört ebenfalls hierher, weil sich an ihr eine Entscheidung festmacht: funktionale Erweiterungen werden dort eingesetzt, wo sie sich rechnen, die Sicherheit aber ruht nicht auf einem Plugin, denn ein Sicherheits-Plugin ist Code innerhalb der Anwendung, die es schützen soll, und arbeitet erst, wenn die Anfrage diese Anwendung bereits erreicht hat. Verkehr vor der Anwendung zu filtern, den Kern aktuell zu halten, den Zugang zur Verwaltung einzuschränken und eine erprobte Sicherung vorzuhalten bringt deshalb mehr als eine Anzeige mit gezählten Anmeldeversuchen.

#Support und Wartung der WordPress-Seite

Wartung ist hier eine Liste mit einer Grenze und kein offenes Versprechen. Sie umfasst das Beheben von Störungen, das Einspielen von Aktualisierungen für Kern, Theme und Plugins, die Durchsicht der Protokolle, Sicherungen nach vereinbarter Richtlinie und kleinere Änderungen an Inhalt und Darstellung. Was sie nicht enthält, gehört genauso deutlich dazu. Sie enthält keine Zusage, dass eine Aktualisierung nie etwas kaputt macht, denn diese Zusage kann keine Website geben, die aus Bausteinen unabhängiger Teams besteht. Sie enthält, dass Änderungen zuerst außerhalb der Produktion laufen und dass der Rückweg vorbereitet ist, bevor er gebraucht wird, statt unterwegs erfunden zu werden.

Eine Seite mit Buchungsmodul bringt zusätzlich eine Pflicht mit, die eine reine Informationsseite nicht kennt. Jede Aktualisierung, die Formularverarbeitung oder Datumslogik berührt, wird gegen eine Kopie der Produktion mit echten Buchungen getestet und nie gegen eine leere Installation. Der Grund ist banal statt grundsätzlich. Auf einer leeren Installation ist das Terminbuch immer frei, also berührt kein Test den Pfad, auf dem das Modul wirklich brechen kann. Dieser Pfad besteht aus Kollisionen zweier Anfragen für denselben Termin und aus den Randfällen an den Grenzen eines Arbeitstags. Aus derselben Überlegung liegen die Wartungsfenster außerhalb der Öffnungszeiten, denn ein Buchungsformular, das gerade dann nicht antwortet, wenn jemand einen Termin will, kostet einen Auftrag und keinen Seitenaufruf.

#Zusammenfassung und erste Anforderungsanalyse

Die Planung begann mit Fragen, die vor dem ersten Handgriff zu beantworten waren. Sie stehen hier, weil die Reihenfolge der Arbeit sich vollständig aus ihren Antworten ergab.

Wozu die Seite dient und wen sie anspricht, stand am Anfang. Danach, was bereits auf der Anforderungsliste des Kunden stand, dort nämlich Terminbuchung, Verbindungen zu sozialen Profilen und an den Besucher angepasste Inhalte. Es folgten die Anbindung an die vorhandene Datenbank, der Zeitplan, die Beispiele, auf die der Kunde zeigen wollte, und die Entscheidung, wie viel der alten Seite mitgenommen wird. Am Ende der Rahmen des Budgets, also die Frage, ob ein Umfang auf einmal oder in Etappen geliefert wird.

Zuerst entstand das, wofür Leute eine Werkstattseite überhaupt öffnen: Leistungen, Anfahrt, Kontakt. Danach die Buchung, das komplexeste Element und das einzige, das die Arbeit im Büro wirklich verändert. Zum Schluss die externen Anbindungen, weil sie am wenigsten kritisch sind und sich am leichtesten nach dem Start ergänzen lassen.

Übertragbar ist aus diesem Projekt die Arbeitsweise. Die Verfügbarkeit einer endlichen Ressource wird beim Schreiben auf dem Server geprüft, zeitabhängige Ansichten bleiben aus dem Zwischenspeicher heraus, schwere fremde Komponenten laden erst, wenn jemand sie anfordert, und alte Adressen werden bei einer Migration einzeln zugeordnet. Nicht übertragbar sind das Inhaltsmodell dieses Projekts und seine Anbindungen, entstanden für eine Werkstatt und ein Briefing aus der Kategorie Websites. Ein weiteres Projekt beginnt deshalb mit einer Analyse des Umfangs, und das Angebot folgt danach.