Real Estate Platform: DUNE Resort

#Drei Personen, eine Seite, drei verschiedene Erwartungen

Eine Website für ein Apartmentprojekt wird von drei Gruppen benutzt, die selten zusammen gedacht werden. Die erste ist der Kaufinteressent, der wissen will, welche Wohnung noch frei ist, was man aus ihrem Fenster sieht und wie weit es bis zum Strand ist. Die zweite ist der Vertrieb des Bauträgers, der am Telefon sitzt und die Seite als Nachschlagewerk benutzt, während der Anrufer dieselbe Seite offen hat. Die dritte ist die Person, die Inhalte pflegt und einen Status ändern muss, ohne dabei ein Layout zu zerstören.

Diese drei Gruppen ziehen in verschiedene Richtungen. Der Interessent will vergleichen, der Vertrieb will belastbare Angaben, die Redaktion will möglichst wenige Stellen, an denen sich etwas ändern lässt. Eine Seite, die nur für die erste Gruppe gebaut wird, sieht bei der Abnahme gut aus und ist nach einem Jahr nicht mehr aktuell, weil niemand die Pflege durchhält. Deshalb beginnt dieser Text nicht bei der Optik, sondern bei der Frage, wer hier eigentlich womit arbeitet.

#DUNE Resort, Apartmentkomplex an der polnischen Ostseeküste

DUNE Resort liegt im östlichen Teil von Mielno, direkt an der Promenade an der ul. Pionierow. Investor ist die Firmus Group, eine Entwicklergruppe mit norwegischem Kapital, die in Mittelpommern tätig ist. Der Komplex umfasst drei Gebäude mit insgesamt 330 Einheiten, Außen- und Innenpools, einen Fitnessbereich sowie Gastronomie auf dem Gelände. Das erste Gebäude mit 114 Einheiten ging 2013 in Betrieb, zwei weitere mit 153 und 63 Apartments folgten. Unsere Umsetzung fiel in das Jahr 2017 und dauerte rund sechs Wochen.

Diese Reihenfolge ist für die Website wichtiger, als sie aussieht. Die Seite beschreibt kein fertiges Gebäude, sondern ein Projekt, das während seiner eigenen Laufzeit die Zahl der Einheiten, die Grundrisse und die Liste der Annehmlichkeiten verändert. Ein Inhaltsmodell, das von einem festen Bestand ausgeht, erzwingt bei jedem Bauabschnitt einen Umbau der Templates, und genau an diesem Punkt werden Bauträgerseiten üblicherweise ersetzt statt erweitert.

#Die Wohnung als Datensatz

Der häufigste Fehler in dieser Kategorie besteht darin, eine Wohnung als Unterseite mit Beschreibung zu behandeln. Fläche, Geschoss, Zimmerzahl und Verkaufsstatus leben dann im Fließtext, also dort, wo sich nichts sortieren und nichts vergleichen lässt. Im ersten Quartal kommt die Bitte um einen Filter, im zweiten die um eine Karte, und beide verlangen, Zahlen wieder aus Absätzen herauszuziehen, die inzwischen mehrere Personen von Hand bearbeitet haben.

Hier ist eine Wohnung von Anfang an ein Datensatz mit Feldern. Fläche, Geschoss, Grundrisstyp, Ausrichtung der Fenster, Gebäude, Status und die Verknüpfung zum Grundriss sind eigene Attribute, der Verkaufstext ist eines der Felder und nicht der Träger der Daten. Derselbe Datensatz speist die Ergebnisliste, die Markierung im Lageplan, die Detailkarte und den Export für den Vertrieb, und eine einzige Statusänderung wird an allen vier Stellen gleichzeitig sichtbar.

Für die Pflege bedeutet das: Wer eine Wohnung als reserviert kennzeichnet, bearbeitet keinen Text und kann kein Layout beschädigen. Es ist ein Auswahlfeld mit wenigen erlaubten Werten. Bei der Abnahme wirkt das wie eine Nebensache und ist die einzige Eigenschaft, die darüber entscheidet, ob die Angaben auf der Seite nach einem Jahr noch mit der Wirklichkeit übereinstimmen.

Der zweite Nutzen zeigt sich später. Der Vertrieb fragt früher oder später: Wie viele Zweizimmerwohnungen sind im zweiten Gebäude noch frei, welche davon liegen nach Westen, wie verteilt sich die Verfügbarkeit über die Flächen. Liegen die Daten in Feldern, ist das eine Abfrage und die Antwort entsteht in einer Minute. Liegen sie in Beschreibungen, entsteht sie durch manuelles Durchklicken und muss nach jeder Angebotsänderung neu erarbeitet werden.

#Verfügbarkeit gegen Cache

Fast alles auf einer Bauträgerseite ist statisch. Visualisierungen, Beschreibungen, Lageplan und Ausstattungsliste ändern sich vielleicht zweimal im Jahr. Ein einziger Wert tut das nicht, nämlich die Frage, ob eine bestimmte Wohnung noch verfügbar ist. Er kann sich an einem Dienstagvormittag ändern, und er ist das Einzige auf der Seite, was ein ernsthafter Interessent vor dem Anruf tatsächlich braucht.

Diese Asymmetrie bestimmt den Aufbau. Seiten aus dem Cache auszuliefern ist das, was eine bildlastige Website schnell macht, und eine gecachte Seite, die eine verkaufte Wohnung als verfügbar zeigt, ist schlimmer als eine langsame. Der Interessent ruft wegen einer Wohnung an, die vergangene Woche weg war, und das erste Wort des Verkaufsgesprächs ist eine Richtigstellung. Die Lösung hieß deshalb nicht weniger Cache, sondern: Die Seite wird in den Teil zerlegt, der lange gecacht werden darf, und in den kleinen Teil, der gar nicht gecacht werden darf, und dieser zweite Teil wird so klein gehalten, dass seine Neuberechnung nichts kostet.

Konkret sind Seitengerüst, Bildmaterial, Beschreibungen und Lageplan für alle Besucher gleich und werden aggressiv gecacht. Verfügbarkeit und Preis kommen über einen eigenen, bewusst winzigen Endpunkt, der nichts als Kennungen und Zustände zurückgibt. Er hat eine kurze Lebensdauer und wird in dem Moment ungültig, in dem jemand im Backend einen Status ändert. Redis trägt den Objekt-Cache hinter den Abfragen, die die Listen aufbauen, Memcached hält Sessions und Ansichtsfragmente, und ein CDN steht davor, vor allem für Bilder, die auf einer solchen Seite alles andere zusammen überwiegen.

#Was die Karte wirklich lösen musste

Die interaktive Karte verkauft hier, sie ist kein Schmuck. Sie zeigt die Lage der Gebäude zur Promenade und zum Strand, erlaubt die Wahl eines Geschosses und die Auswahl einer Wohnung aus dem Grundriss. Die eigentliche Schwierigkeit liegt nicht in der Darstellung einer Karte, sondern im Zusammenführen zweier Maßstäbe: des Lageplans der gesamten Anlage und des Grundrisses eines einzelnen Geschosses. Das sind zwei Koordinatensysteme, und der Besucher wechselt zwischen ihnen mit der Erwartung, dass ein im Überblick angeklicktes Gebäude das richtige Geschoss öffnet und nicht eine Liste aller Geschosse.

Die Grundrisse wurden als Vektorgrafik mit klickbaren Flächen umgesetzt, die an Wohnungskennungen gebunden sind, statt Koordinaten auf eine Bitmap zu legen. Der Unterschied zeigt sich bei der ersten Planänderung. Bei einer Bitmap macht jede Korrektur sämtliche Flächen ungültig und sie müssen neu gesetzt werden, bei Vektorgrafik wird die Datei getauscht und die Verknüpfungen bleiben bestehen. Bei einem Projekt in Bauabschnitten ist das der Unterschied zwischen einer Stunde und zwei Tagen pro Planaktualisierung.

Die Suche arbeitet über Attribute und nicht über Wörter. Fläche, Zimmerzahl, Geschoss, Ausrichtung und Status sind Kriterien mit geschlossenen Wertelisten, eine Anfrage lässt sich also über einen Index beantworten statt über eine Textsuche. Bei mehreren hundert Einheiten ist das erheblich, denn die naive Umsetzung fragt die Datenbank bei jedem umgelegten Filter erneut ab. Die Menge der verfügbaren Werte wird einmal berechnet und im Cache gehalten, und das Umschalten eines Filters tauscht die Ergebnisliste ohne Neuladen der Seite.

#Pflege nach dem Start, der eigentliche Prüfstein

Eine Bauträgerseite wird nicht am Tag der Veröffentlichung beurteilt, sondern etwa achtzehn Monate später. Zu diesem Zeitpunkt hat der Bestand sich mehrfach verändert, mindestens eine Person im Vertrieb ist gewechselt, und es steht die Frage im Raum, ob die Angaben auf der Seite noch stimmen. Die meisten Projekte dieser Art verlieren genau hier, und zwar nicht an der Technik, sondern an der Zumutbarkeit der Pflege.

Deshalb wurde das Backend so eingerichtet, dass alltägliche Änderungen genau einen Handgriff verlangen. Ein Status ist ein Auswahlfeld, ein Preis ein Zahlenfeld, ein neuer Grundriss ein Dateitausch an einer Stelle. Nichts davon erfordert Kenntnisse über das Template, und nichts davon kann mehr als den eigenen Datensatz beschädigen. Wo das nicht gilt, wo also eine Änderung an zwei Stellen gepflegt werden muss, entsteht innerhalb weniger Monate ein Widerspruch, und danach traut die Redaktion der Seite nicht mehr und pflegt sie erst recht nicht.

Die zweite Vorkehrung betrifft Begriffe, die sich mit dem Baufortschritt verschieben. Der Pool bedeutet in einem Abschnitt einen Außenpool und in einem anderen zwei Außenpools und einen Innenpool. Die Anlage bedeutet zuerst ein Gebäude und später drei. Ein Text, der den Endzustand vorwegnimmt, liest sich am ersten Tag wie ein Versprechen und am vierhundertsten wie ein Fehler. Alles Zählbare gehört deshalb in die Daten und nicht in einen Satz, damit eine veränderliche Angabe in einem Feld aktualisiert wird, statt in Absätzen gesucht zu werden, die mehrere Personen bearbeitet haben.

Das Gleiche gilt für Adressen. Eine URL mit Gebäudenummer oder Fertigstellungsjahr verfällt in dem Moment, in dem ein weiterer Abschnitt dazukommt, und jede solche Änderung wird zu einer Weiterleitung, die jahrelang jemand pflegen muss. Eine Adresse, die die Sache benennt und nicht ihren Platz im Zeitplan, braucht nichts davon.

#Schnittstellen und das Verhalten im Störungsfall

Verfügbarkeits- und Reservierungsdaten entstehen nicht auf der Website. Sie entstehen im System des Vertriebs, die Seite ist ihr Abnehmer. Der Austausch läuft asynchron über eine REST-Schnittstelle, mit Prüfung auf der Empfängerseite, weil Daten aus einem fremden System irgendwann in einer Form ankommen, die niemand angekündigt hat.

Die wichtigste Entscheidung betraf den Störungsfall. Das Standardverhalten der meisten Plugins ist eine Fehlermeldung oder ein leerer Abschnitt, was auf einer Verkaufsseite wie ein Ausfall der gesamten Website wirkt und mehr Schaden anrichtet, als gar nichts anzuzeigen. Hier hat jeder Kanal einen Rückfallwert: die letzte bekannte Antwort aus dem Cache und, wenn auch die fehlt, eine statische Variante des Abschnitts mit dem Hinweis, dass der Vertrieb den aktuellen Stand bestätigt. Der Besucher sieht eine Seite ohne ein Modul und keine Fehlermeldung. Ein nicht erreichbares Fremdsystem ist ein Ereignis für das Monitoring, nicht für den Nutzer.

Die Prüfung auf der Empfängerseite leistet noch etwas, das selten erwähnt wird. Ein Datensatz ohne Fläche oder mit einem Status außerhalb der bekannten Werte wird abgewiesen und gemeldet, statt als leere Tabellenzelle auf der Seite zu landen. Eine einzige fehlerhafte Zeile beschädigt die Glaubwürdigkeit aller korrekten Zeilen daneben, und der Besucher kann nicht unterscheiden, welche welche ist.

#Darstellung, Bilder und bewusste Auslassungen

Das Theme ist eine Eigenentwicklung, modular, auf HTML5 und SASS aufgebaut. Layout und Anordnung der Elemente kamen vom Kunden, unsere Aufgabe war die Übersetzung in Templates, responsives Verhalten und ein Inhaltsmodell, das sich pflegen lässt. SASS verdient seinen Platz nicht durch kürzere Schreibweise, sondern dadurch, dass Markenfarbe und Typografie einen Ort haben statt vierzig, was bei einem in Abschnitten wachsenden Projekt unmittelbar die Kosten des nächsten Gebäudes beeinflusst.

Bilder sind hier zugleich der Hauptinhalt und der Hauptaufwand. Eine Visualisierung mit Meerblick darf nicht so weit komprimiert werden, dass das Meer zum Fleck wird, und eine vollständig vorab geladene Galerie kann alle übrigen Ressourcen zusammen überwiegen. Bilder werden deshalb in mehreren Größen ausgeliefert, passend zur Breite des Viewports, und alles unterhalb des sichtbaren Bereichs wartet, bis der Besucher dort ankommt.

Was bewusst fehlt, gehört ebenfalls hierher. Es gibt keinen Zähler verkaufter Einheiten, weil eine solche Zahl ein Eigenleben entwickelt und nach einem Quartal niemand mehr weiß, was hineingerechnet wurde. Es gibt keinen Renditerechner, weil er einen Wert erzeugen würde, den später niemand bestätigt, und auf einer Investitionsseite ist eine unbestätigbare Zahl eine Verpflichtung und kein Argument. Ein bewusster Verzicht ist hier ein vollwertiges Arbeitsergebnis und keine Lücke im Leistungsumfang.

#Unsere Maßnahmen

Für den Bauträger von DUNE Resort entstand eine Website mit interaktiver Darstellung des Projekts, Lageplan, attributbasierter Wohnungssuche und einem Mechanismus, der die Status mit dem System des Vertriebs in Übereinstimmung hält. Die Seitenführung bringt den Besucher vom Blick auf die Gesamtanlage zur konkreten Wohnung und von dort zum Kontakt. Wer aus einer Wohnung in die Liste zurückgeht, findet seine Kriterien unverändert vor, statt sie ein zweites Mal einzugeben. Nach dem Start kamen grundlegendes Monitoring, Analytik und Cache-Kontrolle hinzu, also das Minimum, um zu bemerken, dass etwas nicht mehr funktioniert, bevor es der Vertrieb bemerkt.

Der wichtigste Satz dieses Abschnitts betrifft die Tests, denn sie liefen gegen eine Kopie der Produktion und nicht gegen eine leere Installation, und die Geschwindigkeit einer Seite mit mehreren hundert Datensätzen, einer Galerie und einer laufenden Schnittstelle hat nichts mit der Geschwindigkeit einer frischen Installation mit Demo-Theme zu tun. Grenzfälle wie eine Wohnung ohne Grundriss, ein Gebäude mitten in der Erfassung oder ein Status außerhalb des Wörterbuchs treten ausschließlich an echten Daten auf und lassen sich auch nur dort vor dem Start beheben.

#Zusammenfassung

Drei zu verschiedenen Zeiten übergebene Gebäude, mehrere hundert Wohnungen unterschiedlicher Grundrisse und ein gemeinsamer Bereich mit Pools, Fitness und Gastronomie lassen sich auf einem Bildschirm schlecht beschreiben. Die Website sollte diese Komplexität ordnen und nicht wiederholen, was in der Praxis heißt, dass die Seite weniger zeigt als das Projekt enthält, und zwar an jeder Stelle genau das, was der Besucher an dieser Stelle braucht.

Daraus folgen alle oben beschriebenen Entscheidungen, von der Wohnung als Datensatz mit Attributen über Grundrisse als an Kennungen gebundene Vektorgrafik bis zur Verfügbarkeit, die getrennt vom cachebaren Rest der Seite ausgeliefert wird. Schnittstellen degradieren im Störungsfall einen Abschnitt und nicht eine ganze Seite, weil ein Besucher mit einer fehlenden Statusanzeige weitersucht und einer mit einer leeren Seite den Reiter schließt.

Auf das nächste Bauträgerprojekt überträgt sich die Arbeitsweise, also das Inhaltsmodell vor dem Template, die Trennung veränderlicher von statischen Daten auf der Cache-Ebene und Tests gegen eine Kopie der Produktion. Das Inhaltsmodell selbst und die Schnittstellen übertragen sich nicht, denn sie sind um die Daten eines Kunden und die Form eines Projekts herum entstanden, weshalb die nächste Umsetzung mit einer Analyse des Umfangs beginnt und das Angebot erst danach folgt.

Weitere Informationen finden Sie auf der Website: duneresort.pl