Fintech Solution: Norwegische Wohnsiedlung

Norwegische Wohnsiedlung ist eine Anlage freistehender Häuser in einer privaten, geschlossenen Wohnsiedlung. Gebaut wird sie von Firmus Group im Stadtteil Jamno in Koszalin, an der Gradowa-Straße am nördlichen Rand der Stadt. Die Architektur zeichnet sich durch eine traditionelle, zeitlose Form aus, kombiniert mit der umgebenden Natur und Räumen, die für Kinder und ihre Eltern geschaffen wurden. Die Fassaden sind in warmen Tönen gehalten, mit einem leicht kontrastierenden dunklen Dach, das durch Holz akzentuiert wird. Entspannende Natur, umgebendes Grün, die Nähe zum See und frische Luft bieten den Bewohnern Bedingungen, die sie sonst nirgendwo in Koszalin finden. Ein Rasen im eigenen Garten, Grün soweit das Auge reicht, Naturklänge statt Stadtlärm, all das lädt zur Entspannung nach der Arbeit ein und bietet Kindern ein ideales Umfeld zum Spielen.

#Osiedlenorweskie.pl, Technologie für die norwegische Oase in Koszalin

osiedlenorweskie.pl ist die Präsentationsseite dieser Wohnanlage. Der Aufbau dauerte rund sechs Wochen. Das Layout und die Platzierung der Elemente kamen vom Auftraggeber, der für jede Ansicht festgelegt hat, welche Bausteine wo erscheinen. Meine Arbeit begann danach, bei dem, was ein Layout nicht zeigt: dem Inhaltsmodell, dem responsiven Verhalten der Vorlagen und der Frage, wie eine Redakteurin ein Haus ändert, ohne den Dienstleister anzurufen.

#Vier Haustypen, und was daraus für das Inhaltsmodell folgt

Die wichtigste Entscheidung fiel vor der ersten Zeile Template-Code und betraf die Frage, was hier eigentlich eine Inhaltseinheit ist. Geplant sind achtundvierzig Häuser auf Grundstücken zwischen sechshundertfünfzig und zwölfhundert Quadratmetern. Es sind aber nicht achtundvierzig verschiedene Entwürfe: der Bauträger bietet vier Typen an, benannt nach norwegischen Städten, Alesund mit 125,72 Quadratmetern, Bergen mit 136,34, Oslo mit 152,12 und Trondheim mit 178,70.

Wäre jedes einzelne Haus ein eigener Datensatz mit eigener Beschreibung, eigenem Grundriss und eigener Galerie, dann zöge jede Änderung am Ausstattungsstandard des Typs Bergen ein Dutzend Korrekturen nach sich. Irgendwann korrigiert jemand nur die Hälfte davon, und die Seite widerspricht sich selbst. Ist dagegen der Haustyp der Datensatz und das konkrete Haus nur sein Vorkommen, wird die Beschreibung einmal geschrieben, während Grundstücksnummer, Grundstücksfläche und Verfügbarkeit Felder bleiben, die jeder ändern kann.

Der Preis dieser Entscheidung gehört ebenfalls in den Text. Sobald ein untypisches Haus auftaucht, etwa ein wegen des Grundstückszuschnitts gespiegelter Grundriss, braucht das Modell eine Ausnahme, und eine Ausnahme in einem sauber geschlossenen Modell kostet mehr als in einem lockeren. Ich habe das in Kauf genommen, weil es einige wenige Sonderfälle gibt und mehrere Dutzend gewöhnliche.

Aus derselben Entscheidung folgt, wie die Adressen aufgebaut sind. Eine Hauskarte gehört zum Typ und nicht zur Bauphase, weshalb sich ihre Adresse auch dann nicht ändert, wenn ein weiterer Abschnitt beginnt. Hätte ich die Phase in den Pfad aufgenommen, wäre die Struktur beim Start des zweiten Abschnitts sauberer gewesen und jede gespeicherte Adresse aus dem ersten unbrauchbar.

#Bilder sind die Last dieser Seite, nicht der Text

Wer ein Haus sucht, sieht sich Fotos und Grundrisse an und liest keine Absätze. Damit steht fest, woran diese Seite technisch gemessen wird. Die Hausgalerien sind benutzerdefinierte Inhaltstypen mit Grundrissen und Fotografien, nachgeladen ohne vollständigen Seitenwechsel, in Größenvarianten, die der Browser anhand der tatsächlichen Breite der Ansicht auswählt.

Diese Größenvarianten wiegen schwerer als das Dateiformat, obwohl das Format die lebhaftere Diskussion auslöst. Ein Foto mit zweitausend Pixeln Breite, das in einer Kachel von vierhundert Pixeln erscheint, kostet unabhängig vom Codec dieselbe Datenmenge. Erst wenn die richtige Variante ausgeliefert wird, lohnt das Gespräch über Kompression, und erst dann bringt der Wechsel auf ein modernes Format wie AVIF einen sichtbaren Unterschied.

Eine zweite Eigenheit dieser Bilder ist ihre Herkunft. Fotos einer Baustelle entstehen bei wechselndem Licht, mit dem Telefon des Bauleiters, und landen ohne Zwischenschritt in der Mediathek. Sie lassen sich nicht wie Katalogaufnahmen behandeln, deren Ausschnitt jemand vorher geprüft hat. Deshalb schneidet die Vorlage nichts automatisch mittig zu, sondern arbeitet mit einem festen Seitenverhältnis und überlässt der Redaktion die Wahl des Bildausschnitts. Der automatische Zuschnitt spart im Alltag Zeit und köpft dafür zuverlässig genau die Häuser, die das Bild zeigen sollte.

Die Galerien laden zudem nicht alle Aufnahmen auf einmal. Bei einem Haustyp mit zwei Dutzend Fotografien wäre der erste Aufruf sonst eine Datenmenge, die auf dem Land niemand freiwillig abwartet. Nachgeladen wird in Blöcken, sobald der Besucher weiterscrollt, was den Einstieg leicht macht und den Preis dafür bei denen erhebt, die wirklich alles sehen wollen. Dieser Preis ist gerechtfertigt, weil die Mehrzahl der Besuche nach den ersten Bildern endet.

#Grundrisse aus dem Architekturbüro und ihr Zielkonflikt

Grundrisse kommen als Druckvorlagen, mit feinen Linien und Bemaßungen, die auf einem Telefondisplay unlesbar sind. Die Datei einfach zu verkleinern löst nichts, weil mit dem Gewicht auch die Lesbarkeit der Maße verschwindet.

Die Lösung bestand darin, Vorschau und Volldokument zu trennen. In der Hauskarte liegt ein vereinfachter, für den Bildschirm aufbereiteter Grundriss, und die druckbare Datei lädt der Besucher bewusst mit einem Klick herunter, sobald für ihn feststeht, dass ihn dieses Haus interessiert. Diese Trennung ist Mehrarbeit in der Redaktion, denn jeder Typ braucht zwei Dateien statt einer. Sie verhindert dafür, dass jede mobile Ansicht ein Druck-PDF mitschleppt, das niemand am Telefon lesen kann.

#Das Kontaktformular und der Weg einer Anfrage

Das Formular sammelt Anfragen zu einem konkreten Haus oder zu einem Haustyp, mit serverseitiger Prüfung und Spam-Schutz. Eine Prüfung im Browser ist Komfort für den Absender und keine Sicherheitsmaßnahme, deshalb steht dieselbe Regel ein zweites Mal auf dem Server.

Wichtiger als die Prüfung ist die Herkunft. Eine Nachricht mit dem Text “bitte um Rückruf” zwingt den Vertrieb zu einem Anruf, dessen einziger Zweck die Frage nach dem Haustyp ist, obwohl die Seite die Antwort bereits kannte. Der Hauskontext wird der Anfrage deshalb automatisch beigelegt.

Eine Kopie jeder Anfrage landet in der Datenbank, unabhängig davon, ob der Mailversand geklappt hat. Ein Mailserver ist gelegentlich für ein paar Minuten nicht erreichbar. Das ist kein Grund, einen Interessenten spurlos zu verlieren.

Der Spam-Schutz verdient eine eigene Bemerkung, weil er bei Bauträgerseiten regelmäßig zu scharf eingestellt wird. Ein Formular, das eine echte Anfrage mit vielen Zeilen Text oder einer eingefügten Grundstücksnummer als verdächtig einstuft, verliert genau die Interessenten, die am weitesten gekommen sind. Ich bevorzuge deshalb eine Prüfung, die ohne zusätzliche Aufgabe für den Absender auskommt, und nehme eine höhere Zahl aussortierter Nachrichten im Posteingang in Kauf.

Auch die Länge der Felder ist eine Entscheidung mit Folgen. Wer ein Haus anfragt, schreibt manchmal drei Sätze und manchmal eine ganze Seite über die Familie, die einziehen soll. Eine zu knapp gesetzte Zeichengrenze schneidet diese Seite mitten im Satz ab, und der Vertrieb liest eine Anfrage, die unvollständig wirkt.

#Drei Cache-Schichten und ihre Invalidierung

Die Installation nutzt Zwischenspeicher auf mehreren Ebenen, und jede bedient eine andere Art von Anfrage. Cloudflare liefert als Randschicht die statischen Dateien und die anonymen Seiten aus, also praktisch den gesamten Suchmaschinenverkehr. Varnish hält vor der Anwendung die fertig zusammengesetzten Listenansichten, deren Aufbau mehrere Datenbankabfragen kostet. Redis verkürzt genau diese Abfragen für alles, was ohnehin durch PHP muss, Fastly übernimmt Bilder und Grundrisse im parallelen Abruf, Memcached die kleinen API-Antworten.

Drei Ebenen klingen bei einer Seite dieser Größe nach Übertreibung, solange man nicht betrachtet, was sich wie oft ändert. Die Beschreibung eines Haustyps bleibt ein Jahr lang gleich. Die Verfügbarkeit eines einzelnen Hauses ändert sich am Tag der Vertragsunterschrift, und der Vertrieb erwartet, dass die Seite das sofort zeigt. Läge beides im selben Topf, würde jede Statusänderung auch den unveränderlichen Inhalt verwerfen, und der Cache existierte praktisch nicht mehr.

Die Invalidierung hängt deshalb punktuell am Speichern des jeweiligen Datensatzes und nicht am Speichern von irgendetwas. Der häufigste Fehler, den ich in vergleichbaren Installationen sehe, ist genau ein Cache, der technisch funktioniert und bei jeder Textkorrektur komplett geleert wird. In der Konfiguration sieht das sauber aus, in den Protokollen sind Treffer sichtbar, und trotzdem rechnet der Server alles mehrere Dutzend Mal am Tag neu.

#Die Karte und wo ihr Nutzen endet

Das Kartenmodul beruht auf Leaflet, die Umgebungsdaten liegen als GeoJSON vor, die Kacheln kommen von Mapbox. Eine Karte auf einer Bauträgerseite beantwortet eine einzige Frage, nämlich was in der Nähe liegt, und diese Frage beantwortet eine Zeichnung besser als jede Aufzählung im Fließtext.

Die Grenze dieses Nutzens ist bekannt. Eine Vektorebene mit vielen Punkten blockiert auf einem schwächeren Telefon die Oberfläche, weil der Browser alles zeichnen will, bevor er die Steuerung zurückgibt. Die Daten auf das tatsächliche Umfeld zu begrenzen und die Karte erst zu laden, wenn der Besucher bis zu ihrem Abschnitt scrollt, kostet eine zusätzliche Anfrage und erspart mehrere Sekunden Stillstand beim ersten Aufruf. Auf einer schnellen Leitung wirkt dieser Kompromiss überflüssig, auf einer langsamen entscheidet er darüber, ob jemand bleibt.

#Wer wiederkommt, und über welche Verbindung

Niemand kauft ein Haus in der ersten Sitzung. Dieselbe Person kehrt über mehrere Monate ein Dutzend Mal zurück und sucht jedes Mal etwas anderes, einmal den Grundriss des Erdgeschosses, einmal die Entfernung zur Schule, einmal die Fotos von der Baustelle, um den Stand der Arbeiten zu prüfen.

Daraus folgen zwei Anforderungen, die in keinem Briefing stehen. Die Adressen der Hauskarten müssen dauerhaft sein, weil sie in Lesezeichen landen und per Nachricht an die Familie weitergereicht werden. Und Baustellenfotos müssen sich schnell und häufig einstellen lassen, denn sie sind der Grund für die Rückkehr.

Das zweite Merkmal dieser Zielgruppe ist das Gerät. Ein großer Teil der Besuche kommt vom Telefon, oft bei schwachem Empfang, weil Jamno am nördlichen Stadtrand liegt. Eine Seite, die am Schreibtisch in einer Sekunde erscheint, braucht am Rand des Empfangsbereichs ein Vielfaches davon, und der Besucher unterscheidet nicht zwischen der Schuld des Mobilfunkanbieters und der Schuld der Website.

#Lokale Sichtbarkeit und die Falle des Eigennamens

Der Name Norwegische Wohnsiedlung ist einprägsam, und das hilft, bis man nachsieht, wonach die Leute tatsächlich suchen. Wer den Namen kennt, findet die Seite ohne unser Zutun. Wer einen Umzug erst erwägt, tippt etwas ganz anderes ein, nämlich Häuser Koszalin, geschlossene Siedlung Koszalin oder Haus zu verkaufen Jamno. Eine Seite, die ausschließlich um den Eigennamen herum gebaut ist, bedient nur die bereits Entschiedenen.

Struktur und Überschriften mussten deshalb auch tragen, was dieses Projekt ist, und nicht nur, wie es heißt. Die Projektseite spricht von freistehenden Häusern in einer geschlossenen Anlage in Koszalin und nennt den Stadtteil ausdrücklich, statt ihn als Leserwissen vorauszusetzen. Das ist kein Kunstgriff für einen Algorithmus, sondern eine Rücksicht auf Menschen, die nicht in dieser Stadt wohnen und nicht wissen müssen, wo Jamno liegt.

Bei den strukturierten Daten liegt die zweite Falle. Es ist verlockend, jedes Haus als Angebot mit Preis auszuzeichnen, weil Suchmaschinen dieses Format gern aufgreifen. Der Preis eines Hauses samt Grundstück ändert sich jedoch im Lauf des Bauabschnitts, während eine einmal in den Index gegebene Angabe wochenlang ihr eigenes Leben führt. Ein veralteter Preis im Suchergebnis eröffnet das Gespräch mit einer Richtigstellung, und das ist der denkbar schlechteste Anfang. Die Seite beschreibt deshalb Typ, Fläche und Verfügbarkeit, und überlässt den Preis einem Menschen.

#Was bewusst nicht gebaut wurde

Ohne diesen Abschnitt wäre eine Projektbeschreibung ein Werbeprospekt. Ein Ausstattungskonfigurator wurde nicht gebaut, obwohl die Idee in jeder Bauphase wiederkam. Ein Konfigurator ergibt Sinn, wenn die Varianten abzählbar und an einer Stelle beim Kunden dokumentiert sind und sich daraus ein Preis ohne Rückfrage beim Vertrieb ableiten lässt. Bei vier Haustypen und individuell verhandelter Ausstattung zeigte das Werkzeug Zahlen an, die ohnehin jemand bestätigen müsste.

Eine Online-Reservierung gibt es ebenfalls nicht. Im Immobilienhandel ist eine Reservierung ohne Anzahlung keine Reservierung, sondern eine Warteschlange, und eine öffentlich sichtbare Warteschlange erzeugt mehr Streit als Abschlüsse. Der Verfügbarkeitsstatus ist hier eine Information und keine Handlung, geändert von einem Menschen beim Bauträger. Dieser Mensch weiß, ob eine Anzahlung eingegangen ist, und die Website weiß es nicht.

Der dritte Verzicht betrifft Bewohnerstimmen. Der erste Abschnitt umfasste sechs Häuser, weshalb sich jede veröffentlichte Meinung rein rechnerisch einer konkreten Familie zuordnen ließe. Stattdessen zeigt die Seite den Baufortschritt und Fotos fertiger Häuser. Dieses Material trägt dieselbe Aussage, ohne von jemandem einen öffentlichen Auftritt zu verlangen.

#Technischer Support, die Harmonie bewahren

Osiedlenorweskie.pl braucht laufende Pflege. System und Plugins werden aktualisiert, getestet zuerst außerhalb der Produktion, mit täglichen Sicherungen über UpdraftPlus in verschlüsselten S3-Buckets. Dazu gehört ein Satz, den man selten hört: eine Sicherung, die nie zurückgespielt wurde, ist eine Hypothese und kein Schutz. Dass Dateien in der Cloud liegen, garantiert nichts, solange niemand geprüft hat, ob sich der Datenbankabzug importieren lässt und ob die Mediendateien mitgekommen sind.

Die Reihenfolge der Aktualisierungen ist der zweite langweilige Punkt, der ein Projekt rettet. Bei einer Seite mit eigenem Theme und eigenen Inhaltstypen bricht nach einem Versionssprung fast nie der WordPress-Kern, sondern das Theme, und zwar genau dort, wo eine Vorlage eine Datenstruktur voraussetzte, die ein Plugin gerade geändert hat. Yoast SEO verwaltet Metadaten und Sitemap, Lighthouse prüft die Ladequalität innerhalb der Pipeline, und die Cache-Konfiguration wird überprüft, wenn sich die Form der Inhalte ändert, denn nicht die verstrichene Zeit ruiniert eine Cache-Strategie, sondern der Inhalt.

Erweiterungen sind möglich, vom virtuellen Rundgang über eine Anbindung an das Vertriebssystem bis zu einem Bereich verfügbarer Häuser, gepflegt an einer einzigen Stelle. Jede davon stößt allerdings an dieselbe Grenze: keine dieser Funktionen pflegt ihre Inhalte selbst, und der Aufwand dafür fällt im zweiten Jahr an, wenn das Bauvorhaben in eine Phase kommt, in der niemand mehr täglich an die Website denkt.