E-Commerce-Entwicklung: DUNE CITY

#Dune City, umfassende Website für eine Investition an der Ostsee

Schnell und aktuell zugleich. Diese beiden Anforderungen ziehen in jeder Cache-Architektur gegeneinander, und bei einer Bauträger-Website entscheidet genau diese Spannung über das ganze Projekt. Beschreibungen, Fotos, Grundrisse und Marketingtexte dürfen wochenlang im Zwischenspeicher liegen. Status und Preis einer Wohnung dürfen dort keine Stunde liegen. Wer beides unter dieselbe Regel stellt, muss sich nach der kürzeren richten und verzichtet damit auf den Cache für neunzig Prozent der Inhalte, die ihn nie gebraucht hätten.

Das Projekt entstand für den Apartmentkomplex Dune Resort in Mielno, auf der Landzunge zwischen Ostsee und Jamno-See, etwa zehn Kilometer nördlich von Koszalin. Bauträger ist die Firmus Group, der Entwurf stammt aus den Büros SAS und Mellon. Der Komplex umfasst dreihundertdreißig Apartments mit einem bis vier Zimmern, und Gebäude B beherbergt einen ganzjährigen Wellnessbereich mit Innenbecken. Der Auftrag umfasste neben der Website auch die Identitätsebene, weshalb dieser Eintrag in den Kategorien Logos und Websites steht.

Dreihundertdreißig Einheiten sehen in einer Broschüre harmlos aus und im Datenmodell völlig anders. Jede Wohnung hat Fläche, Geschoss, Ausrichtung, Grundriss, Gebäude, Vertriebsstufe, Status und Preis, und mindestens die Hälfte dieser Felder verändert sich im Lauf der Zeit. Eine Bauträgerseite ist deshalb keine Imagewebsite mit Bildern, sondern eine Oberfläche über einer Datenbank, die sich bewegt, während jemand sie liest. Die Umsetzung lief 2017 und dauerte etwa sechs Wochen. Layout und Elementanordnung kamen vom Kunden.

#Wer hier kauft und wonach gesucht wird

Wer eine Ferienwohnung kauft, bewegt sich in die entgegengesetzte Richtung zu jemandem, der ein Zimmer bucht. Das Angebot wird nicht durchgesehen, es wird ausgeschlossen. Man kommt mit einer harten Vorgabe, meist Budget oder Fläche, streicht in der ersten Minute den Großteil des Bestands und schaut sich erst danach Bilder an. Das kehrt die übliche Hierarchie um: Der Filter ist hier Inhalt erster Ordnung, und die Bildebene beginnt erst zu wirken, wenn die Liste auf ein Dutzend Einträge geschrumpft ist.

Das zweite Kriterium ist räumlich und passt in kein Formular. Bei einer Anlage auf einer Landzunge zählt, auf welcher Gebäudeseite eine Einheit liegt, denn davon hängt ab, ob der Blick auf die See, auf den See oder auf den Nachbarbau geht. Danach fragt kein Schieberegler. Die Auswahl muss deshalb auch auf einem Grundriss und auf einem Lageplan möglich sein und nicht nur in einer Ergebnisliste.

Der dritte Faktor ist für diesen Ort spezifisch. Mielno ist saisonal, der Kauf einer Wohnung ist es nicht, und ein erheblicher Teil der Käufer betrachtet den Erwerb als Vermietungsinvestition und nicht als Zweitwohnsitz. Das sind zwei völlig verschiedene Gespräche auf denselben Seiten. Wer für sich kauft, fragt nach Schnitt und Ruhe. Wer zur Vermietung kauft, fragt, wie viele Wochen im Jahr sich die Einheit vermieten lässt und ob das Gebäude etwas bietet, das die Saison verlängert. Der ganzjährige Wellnessbereich in Gebäude B beantwortet genau die zweite Frage und darf in der Informationsarchitektur deshalb keine weitere Ausstattungskachel neben dem Parkplatz sein.

Der vierte Faktor ist Vertrauen. Ein Bauträger verkauft etwas, das zum Kaufzeitpunkt häufig noch nicht existiert, jedenfalls nicht in dem Zustand, in dem es übergeben wird. Alles, was die Seite als Tatsache darstellt, muss deshalb entweder überprüfbar oder eindeutig als Visualisierung gekennzeichnet sein. Das ist eine redaktionelle Entscheidung mit technischer Folge: Renderings und Baustellenfotos müssen im Inhaltsmodell unterscheidbar sein und nicht gemeinsam in einer Galerie liegen.

#Schlüsselfunktionen und Module

Das Kartenmodul verbindet eine Anbindung an die Google Maps API mit der Bibliothek Leaflet.js und bedient sowohl den Lageplan als auch die interaktiven Grundrisse. Die Trennung ist Absicht. Der Lageplan beantwortet, wo das Objekt im Verhältnis zu Strand und Promenade liegt, und dort sind Geodaten am Platz. Ein Geschossgrundriss ist keine Weltkarte, sondern ein Bild mit klickbaren Bereichen, und wer ihn über denselben Mechanismus betreibt, landet bei einer Skalierung, die auf dem Telefon auseinanderfällt.

Suche und Sortierung laufen über eigene Felder und Taxonomien, die Ergebnisse werden asynchron per AJAX geholt. Mehrdimensionales Filtern ist die Stelle, an der ein Immobilienkatalog am häufigsten kippt, denn jedes zusätzliche Attribut vervielfacht die Zahl der Kombinationen. Eine naive Umsetzung fragt die Datenbank pro Schalter einmal ab, und bei dreihundertdreißig Einheiten und sechs Filtern werden daraus Dutzende Abfragen pro Klick. Hier wird die Menge der verfügbaren Werte einmal berechnet und im Zwischenspeicher gehalten, ein einzelner Filterwechsel tauscht die Ergebnisliste aus, statt die Seite neu zu laden.

Die Anbindung externer Systeme über REST API synchronisiert Verfügbarkeit, Reservierungsstatus und Angebotsänderungen. Das ist der empfindlichste Teil der ganzen Umsetzung, denn die Wahrheit über den Status liegt nicht auf der Website, sondern im Vertriebssystem des Bauträgers. Jede Verzögerung dort hat einen sehr konkreten Preis: Ein Interessent ruft wegen einer gestern verkauften Einheit an, und der erste Satz des Verkaufsgesprächs ist eine Richtigstellung.

Analysewerkzeuge zeigen, welche Einheiten am häufigsten angesehen werden und wie sich das Interesse über die Stufen verteilt. Für einen Bauträger ist das eine Betriebsinformation und kein Bericht für eine Sitzung: Wenn ein bestimmter Schnitt viele Aufrufe und keine Anfragen erzeugt, liegt das Problem beim Preis oder bei der Beschreibung, und beides lässt sich in derselben Woche ändern. Die Leistungsebene stützt sich auf Zwischenspeicher (Redis, Memcached) und Auslieferung über ein CDN, mit Infrastruktur auf AWS.

#Technische Lösungen und Herausforderungen

Das Theme entstand vollständig responsiv und modular, auf HTML5 und SASS. Modularität ist hier kein architektonischer Zierrat, sondern eine Antwort auf den Lebenszyklus solcher Vorhaben. Die Stufen starten nacheinander, jede bekommt ihr Gebäude, ihren Bestand und ihre Kampagne, und die Seite muss eine neue Stufe aufnehmen, ohne dass Templates umgebaut werden. Ein Projekt, in dem Gebäude A an einem Dutzend Stellen fest verdrahtet ist, kostet bei Gebäude C eine Woche statt einer Stunde.

Die Geodaten erforderten eigene Endpunkte, die Lage und Parameter der Einheiten liefern und deren dynamische Darstellung auf der Karte erlauben. Die eigentliche Schwierigkeit liegt nicht im Zeichnen von Punkten, sondern darin, dass Grundriss und Ergebnisliste denselben Zustand zeigen müssen. Wer auf Zweizimmerwohnungen filtert, erwartet, dass im Grundriss genau diese Wohnungen aufleuchten. Einen einzigen Zustand für zwei so unterschiedliche Ansichten zu halten, ist die eigentliche Arbeit.

Asynchrone Verarbeitung über AJAX und REST API verbessert das Erlebnis und kostet an einer leicht übersehenen Stelle. Ohne Neuladen geladene Filterergebnisse haben keine eigene Adresse, lassen sich also weder weitergeben noch indexieren. Die Antwort besteht darin, den Filterzustand in der URL abzubilden und beim Direkteinstieg eine vollständige Serverantwort zu liefern, während der asynchrone Weg für weitere Wechsel erhalten bleibt. Das ist etwa doppelt so viel Arbeit wie die AJAX-Ebene allein und der einzige Weg, auf dem Suchergebnisse außerhalb einer Browsersitzung überhaupt existieren.

Die Adressstruktur verdient einen eigenen Absatz, denn sie entscheidet, ob das Vorhaben in der Suche jenseits seines eigenen Namens vorkommt. Nach dem Namen einer Anlage sucht niemand, bevor er ihn kennt. Gesucht wird nach einer Zweizimmerwohnung in Mielno mit Meerblick. Filterkombinationen tragen also echtes Suchpotenzial, aber nur einige davon. Alle zusammen ergeben Tausende fast gleicher Adressen, der klassische Weg, eine Website zu verwässern. Die Lösung besteht darin, ein Dutzend Kombinationen auszuwählen, die tatsächlich gestellten Fragen entsprechen, ihnen eigene Adressen und Inhalte zu geben und den Rest des Filterraums außerhalb des Index zu lassen.

Auf dieser Seite stehen keine Ergebniszahlen. Anfragezahlen, Verkaufstempo und prozentuale Steigerungen gehören dem Investor und nicht der Fallstudie seines Dienstleisters, und keine dieser Zahlen ließe sich hier belegen. Was sich überträgt, ist die Reihenfolge der Fragen: erst klären, was sich wie oft ändert, dann die Technik wählen.

#Unsere Maßnahmen

Für Dune City haben wir die Website mit Kartenmodulen, Suche und Synchronisation mit externen Systemen umgesetzt, damit ein Besucher das aktuelle Angebot prüfen kann, ohne ein Dutzend Unterseiten von Hand durchzugehen, dazu die Identitätsebene im Einklang mit den übrigen Materialien des Vorhabens.

Die Arbeit unterschied sich von einem gewöhnlichen Firmenauftritt, weil die Inhalte parallel zum Bau entstanden. Grundrisse änderten sich während des Projekts, ein Teil der Einheiten wurde neu nummeriert, und Bildmaterial kam in Etappen. Das Inhaltsmodell musste also aushalten, dass derselbe Eintrag zuerst ein Rendering trägt, später ein Baustellenfoto und am Ende ein Foto des fertigen Innenraums, und kein einziger dieser Wechsel darf einen Eingriff ins Template verlangen.

Die Nummerierung der Einheiten ist erfahrungsgemäß das, was ein Jahr nach dem Start bricht und nicht am Starttag. Sie ändert sich während des Baus häufiger, als beim Entwurf des Datenmodells jemand annimmt, und wenn der interne Bezeichner zugleich die für Kunden sichtbare Nummer ist, zerreißt jede Änderung Links, die längst in E-Mails und Verkaufsunterlagen kursieren. Die Trennung von Bezeichner und Beschriftung kostet ein Datenbankfeld und spart eine Woche Korrekturen.

Beim Bildmaterial ist es ähnlich. Innenaufnahmen entstehen meist nach Übergabe des ersten Gebäudes, also lebt die Seite über ein Jahr lang von Renderings. Der Moment des Austauschs ist für die Glaubwürdigkeit entscheidend: Liegen Rendering und Foto in einer Galerie, bleibt danach eine Mischung, bei der niemand weiß, was er sieht. Dritter Fall ist die Preisliste, die stufenweise geändert und oft nicht vollständig veröffentlicht, sondern erst nach Kontaktaufnahme herausgegeben wird. Alle drei Fälle haben dieselbe Natur: Was sich unabhängig ändert, braucht ein eigenes Feld.

#Zusammenfassung

Dune City ist ein Projekt, in dem die Darstellungsebene der am wenigsten interessante Teil der Arbeit ist. Die Schwierigkeit liegt im Datenmodell, im Halten eines gemeinsamen Zustands über Liste, Grundriss und Karte, in der Synchronisation mit dem Vertriebssystem und in der Trennung dessen, was zwischengespeichert werden darf, von dem, was frisch sein muss.

Auch die Leistungsmessung bedeutet hier etwas anderes als bei einer Firmenseite. Die schwerste Ansicht ist nicht die Startseite, sondern die Ergebnisliste nach gesetzten Filtern, und diese Ansicht hat keine feste Adresse, weshalb ein üblicher Startseiten-Audit sie nie erreicht. Getestet wird deshalb auf den Wegen, die der Verkehr tatsächlich nimmt, und am besten gegen eine Produktionskopie mit vollständigem Bestand. Auf einer leeren Installation mit zehn Beispielwohnungen ist alles schnell und nichts gelernt.

Ein Teil der Anlage wird von einem Vermietungsbetreiber geführt, City Apartments, mit nahezu zweihundertfünfzig Einheiten. Dieselbe Adresse dient nach Abschluss des Verkaufs also einem anderen Zweck als in der Vertriebsphase, und die Informationsarchitektur musste das vorsehen, statt anzunehmen, die Seite ende mit der letzten verkauften Einheit. Die üblichen Ausbaurichtungen sind zwei: eine tiefere Anbindung an das Vertriebssystem, damit der manuelle Aktualisierungsschritt entfällt, und die Unterstützung der Phase nach dem Verkauf. Beides ist ein eigener Umfang, der nach Analyse kalkuliert wird.