Real Estate Platform: DUNE CITY

#Dune City, kompleksowa strona inwestycji nad Bałtykiem

Serwis powstał dla kompleksu apartamentowego Dune Resort w Mielnie, położonego na mierzei oddzielającej Morze Bałtyckie od Jeziora Jamno, około dziesięciu kilometrów na północ od Koszalina. Inwestorem jest Firmus Group, a projekt architektoniczny powstał w pracowniach SAS i Mellon. Kompleks liczy trzysta trzydzieści apartamentów, od jednopokojowych po czteropokojowe, a budynek B mieści całoroczną strefę wellness z basenami wewnętrznymi. Zakres prac obejmował warstwę identyfikacyjną i sam serwis, co w portfolio odpowiada kategoriom Logotypy oraz Strony www.

Trzysta trzydzieści lokali to liczba, która wygląda niewinnie w broszurze i zupełnie inaczej w modelu danych. Każdy apartament ma metraż, piętro, ekspozycję, układ, budynek, etap sprzedaży, status i cenę, a przynajmniej połowa tych pól zmienia się w czasie. Strona dewelopera nie jest więc witryną wizerunkową ze zdjęciami. Jest interfejsem nad bazą, która żyje.

Jako WordPress developer przygotowałem niestandardowy motyw wraz z modułami prezentującymi ofertę. Wdrożenie zajęło około sześciu tygodni i ruszyło w 2017 roku. Układ i rozmieszczenie elementów dostarczył klient.

#Co sprzedaje deweloper i czego szuka kupujący

Kupujący apartament nad morzem porusza się po stronie zupełnie inaczej niż gość szukający noclegu. Nie ogląda oferty, tylko ją eliminuje. Wchodzi z jednym twardym kryterium, zwykle budżetem albo metrażem, odcina większość zasobu w pierwszej minucie i dopiero potem zaczyna patrzeć na zdjęcia. To odwraca typową hierarchię strony: filtr jest tu treścią pierwszorzędną, a warstwa wizualna działa dopiero wtedy, gdy lista skurczy się do kilkunastu pozycji.

Drugie kryterium jest przestrzenne i nie da się go wyrazić w formularzu. Przy inwestycji na mierzei liczy się, po której stronie budynku leży lokal, bo to decyduje, czy widok idzie na morze, na jezioro, czy na sąsiedni budynek. Tego nie zapyta się suwakiem. Dlatego wybór musi być możliwy na rzucie i na mapie terenu, a nie tylko na liście wyników.

Trzecia rzecz dotyczy zaufania. Inwestycja deweloperska sprzedaje coś, czego w momencie zakupu często jeszcze nie ma, a przynajmniej nie w stanie, w jakim ma być oddane. Wszystko, co strona pokazuje jako stan faktyczny, musi być więc albo prawdą sprawdzalną, albo wyraźnie oznaczone jako wizualizacja. To decyzja redakcyjna, ale ma konsekwencję techniczną: wizualizacje i zdjęcia z budowy muszą być rozróżnialne w modelu treści, a nie wrzucone do jednej galerii.

Jest jeszcze czwarty czynnik, specyficzny dla tej lokalizacji. Mielno jest miejscowością sezonową, ale zakup apartamentu sezonowy nie jest, a znaczna część kupujących traktuje go jako inwestycję pod wynajem, nie jako drugi dom. To dwie zupełnie różne rozmowy prowadzone na tej samej stronie. Kupujący dla siebie pyta o rozkład i o ciszę. Kupujący pod wynajem pyta o to, ile tygodni w roku lokal da się wynająć i czy budynek ma coś, co przedłuża sezon. Całoroczna strefa wellness z basenami w budynku B jest odpowiedzią dokładnie na to drugie pytanie, więc w strukturze serwisu nie może być kolejnym kaflem udogodnień obok parkingu.

#Kluczowe funkcjonalności i moduły

Moduł mapowy łączy integrację z Google Maps API i bibliotekę Leaflet.js, i obsługuje zarówno mapę terenu, jak i interaktywne rzuty budynków. Rozdzielenie tych dwóch rzeczy jest celowe. Mapa terenu odpowiada na pytanie, gdzie to jest względem plaży i promenady, i tu dane geograficzne mają sens. Rzut kondygnacji nie jest mapą świata, tylko obrazem z obszarami klikalnymi, i próba obsłużenia go tym samym mechanizmem co mapy kończy się skalowaniem, które rozjeżdża się na telefonie.

Wyszukiwanie i sortowanie opiera się na niestandardowych polach i taksonomiach, a wyniki pobierane są asynchronicznie przez AJAX. Filtrowanie po kilku wymiarach naraz jest miejscem, w którym katalog nieruchomości najczęściej się przewraca, bo każdy dołożony atrybut zwielokrotnia liczbę kombinacji. Naiwna implementacja odpytuje bazę raz na każdy przełącznik i przy trzystu trzydziestu lokalach oraz sześciu filtrach robi się z tego kilkadziesiąt zapytań na jedno kliknięcie. Zestaw dostępnych wartości jest tu wyliczany raz i trzymany w pamięci podręcznej, a pojedyncza zmiana filtra podmienia listę wyników, nie przeładowuje strony.

Integracja z zewnętrznymi systemami przez REST API synchronizuje dostępność lokali, statusy rezerwacji i aktualizacje oferty. To najbardziej newralgiczny element całego serwisu, bo źródłem prawdy o statusie nie jest strona, tylko system sprzedażowy dewelopera. Każde opóźnienie w tej synchronizacji ma bardzo konkretny koszt: klient dzwoni w sprawie lokalu, który sprzedano wczoraj, i pierwsze zdanie rozmowy handlowej jest sprostowaniem.

Narzędzia analityczne pozwalają śledzić, które lokale są oglądane najczęściej i jak rozkłada się zainteresowanie w obrębie etapów. Dla dewelopera to informacja operacyjna, a nie raport do prezentacji: jeśli konkretny układ ogląda wielu odwiedzających i nikt nie zostawia kontaktu, problem leży w cenie albo w opisie, i jedno i drugie da się zmienić w tym samym tygodniu.

Warstwa wydajnościowa opiera się na pamięci podręcznej (Redis, Memcached) i dystrybucji treści przez CDN, z infrastrukturą po stronie AWS. Napięcie jest tu dokładnie odwrotne niż na stronie wizerunkowej: strona dewelopera musi być jednocześnie szybka i aktualna, a te dwie cechy w architekturze cache stoją naprzeciw siebie.

Struktura adresów zasługuje tu na osobny akapit, bo decyduje o tym, czy inwestycja istnieje w wyszukiwarce poza własną nazwą. Ludzie nie szukają nazwy inwestycji, dopóki jej nie poznają. Szukają apartamentu dwupokojowego w Mielnie z widokiem na morze. To znaczy, że kombinacje filtrów mają realny potencjał wyszukiwawczy, ale tylko niektóre. Wszystkie naraz dają tysiące adresów o niemal identycznej treści, co jest klasycznym sposobem na rozmycie serwisu. Rozwiązanie polega na wybraniu kilkunastu kombinacji, które faktycznie odpowiadają pytaniom zadawanym w wyszukiwarce, nadaniu im własnych adresów i treści, i zostawieniu reszty przestrzeni filtrów poza indeksem.

Warto dodać, jak to wygląda na telefonie, bo tam odbywa się pierwszy kontakt z ofertą, a zakup finalizuje się na komputerze. Rzut kondygnacji na ekranie o szerokości czterystu pikseli jest nieczytelny, jeśli potraktować go jak obrazek do przewijania. Obszary klikalne muszą mieć rozmiar palca, a nie kursora, i to zwykle oznacza, że na mniejszym ekranie rzut przestaje być mapą, a staje się listą z podświetleniem. To nie jest uproszczenie wersji mobilnej, tylko inna odpowiedź na to samo pytanie użytkownika.

#Rozwiązania techniczne i wyzwania

Motyw powstał jako w pełni responsywny i modułowy, na HTML5 i SASS. Modułowość nie jest tu ozdobnikiem architektonicznym, tylko odpowiedzią na cykl życia takiej inwestycji. Etapy uruchamiane są kolejno, każdy z nich dostaje własny budynek, własną pulę lokali i własną kampanię, a serwis musi przyjąć nowy etap bez przebudowy szablonów. Projekt, w którym budynek A jest zakodowany na sztywno w kilkunastu miejscach, przy budynku C wymaga tygodnia pracy zamiast godziny.

Integracja danych geolokalizacyjnych wymagała dedykowanych endpointów zwracających położenie i parametry lokali, a następnie wyświetlenia ich dynamicznie na mapie. Główny problem nie leży w rysowaniu punktów, tylko w tym, że rzut kondygnacji i lista wyników muszą pokazywać ten sam stan. Użytkownik, który odfiltruje lokale dwupokojowe, oczekuje, że na rzucie podświetlą się dokładnie te same mieszkania, które widzi na liście. Utrzymanie jednego źródła stanu dla dwóch tak różnych widoków jest tu właściwą trudnością.

Asynchroniczne przetwarzanie przez AJAX i REST API poprawia komfort przeglądania, ale kosztuje w miejscu, o którym łatwo zapomnieć. Wyniki filtrowania ładowane bez przeładowania strony nie mają własnego adresu, więc nie da się ich wysłać znajomemu ani zaindeksować. Rozwiązaniem jest odwzorowanie stanu filtrów w adresie URL i zwracanie pełnej odpowiedzi serwera dla wejścia bezpośredniego, przy zachowaniu ścieżki asynchronicznej dla kolejnych przełączeń. To dwa razy więcej pracy niż sama warstwa AJAX i jedyny sposób, żeby wyniki wyszukiwania w ogóle istniały poza sesją przeglądarki.

Skalowalna architektura oparta na niezależnych modułach pozwala dokładać kolejne integracje. Warto jednak nazwać kompromis cache i aktualności wprost, bo to on definiuje ten projekt. Opis inwestycji, zdjęcia, rzuty i treści marketingowe mogą leżeć w pamięci podręcznej tygodniami. Status i cena lokalu nie mogą leżeć tam nawet godziny. Jeżeli obie warstwy trafią pod jedną politykę, trzeba ustawić ją według krótszej, czyli zrezygnować z cache dla dziewięćdziesięciu procent treści, która wcale go nie potrzebuje. Rozdzielenie ich oznacza, że szkielet strony i galeria idą z brzegu, a fragment ze statusem dociągany jest osobnym, tanim żądaniem.

Na tej stronie nie ma wskaźników wyniku: liczby leadów, tempa sprzedaży ani procentowego wzrostu czegokolwiek. Dane sprzedażowe inwestycji należą do inwestora, a nie do studium przypadku wykonawcy, i żadnej takiej liczby nie dałoby się tu potwierdzić źródłem. To, co przenosi się na kolejny projekt, to sposób ułożenia modelu danych i decyzje o tym, co wolno cache’ować.

Pomiar wydajności ma przy takim serwisie inny sens niż przy stronie firmowej. Najcięższy widok to nie strona główna, tylko lista wyników po zastosowaniu filtrów, a ten widok nie ma stałego adresu, więc typowy audyt strony głównej go nie obejmuje. Testy trzeba więc prowadzić na tych ścieżkach, którymi faktycznie idzie ruch, i najlepiej na kopii produkcji z pełnym zasobem lokali. Na pustej instalacji z dziesięcioma przykładowymi pozycjami wszystko jest szybkie i nic się nie dowiadujemy.

Druga rzecz to zachowanie przy kampanii. Deweloper uruchamia reklamę na konkretny etap i w ciągu godziny na jedną podstronę trafia ruch większy niż przez cały poprzedni miesiąc. Ten wzorzec jest przewidywalny, więc da się go obsłużyć tanio: podstrona etapu jest w całości cache’owalna poza fragmentem ze statusem, a fragment ze statusem jest lekki. Bez tego rozdzielenia ta sama kampania oznacza dokładanie mocy serwera na jeden dzień.

#Nasze działania

Dla inwestycji Dune City przygotowaliśmy serwis z modułami mapowymi, wyszukiwaniem i synchronizacją danych z systemami zewnętrznymi, tak żeby użytkownik mógł sprawdzić aktualną ofertę bez ręcznego przeglądania kilkunastu podstron. Do tego doszła warstwa identyfikacyjna, spójna z materiałami inwestycji.

Praca wyglądała inaczej niż przy typowym serwisie firmowym, bo treść powstawała równolegle z budową. Rzuty zmieniały się w trakcie projektu, część lokali zmieniała numerację, a materiał zdjęciowy pojawiał się etapami. Model treści musiał więc znieść sytuację, w której ta sama pozycja ma najpierw wizualizację, potem zdjęcie z budowy, a na końcu zdjęcie gotowego wnętrza, i żadne z tych podmienień nie może wymagać dotykania szablonu.

Osobnym wątkiem było to, kto obsługuje serwis po starcie. Częścią apartamentów zarządza operator najmu, City Apartments, który prowadzi blisko dwieście pięćdziesiąt lokali. Oznacza to, że po zakończeniu sprzedaży ten sam adres zaczyna służyć innemu celowi niż w fazie deweloperskiej, i architektura informacji musiała to przewidzieć, zamiast zakładać, że strona umiera razem z ostatnią sprzedaną pozycją.

Warto zatrzymać się przy tym, co w takim serwisie najczęściej psuje się po roku, a nie w dniu startu. Pierwszym miejscem jest numeracja lokali. W trakcie budowy zmienia się częściej, niż ktokolwiek zakłada na etapie projektowania modelu danych, a jeśli identyfikator lokalu jest jednocześnie jego numerem widocznym dla klienta, każda taka zmiana zrywa linki, które już krążą w mailach i w ofertach handlowców. Rozdzielenie identyfikatora wewnętrznego od etykiety pokazywanej użytkownikowi kosztuje jedno pole w bazie i oszczędza tydzień prostowania.

Drugim miejscem są zdjęcia. Materiał z sesji wnętrzarskiej pojawia się zwykle po oddaniu pierwszego budynku, więc przez kilkanaście miesięcy serwis żyje wizualizacjami. Moment podmiany jest krytyczny dla wiarygodności: jeśli wizualizacja i zdjęcie leżą w jednej galerii, po podmianie zostaje mieszanka, w której klient nie wie, na co patrzy. Dlatego oba rodzaje materiału mają w modelu treści osobny status, a widok potrafi pokazać je równolegle z jasnym podpisem, zamiast po cichu jedno zastąpić drugim.

Trzecim miejscem jest cennik. Deweloper zmienia ceny etapami i najczęściej nie chce ich pokazywać publicznie w całości, tylko udostępniać po kontakcie. To wymaga, żeby cena była polem osobnym od reszty opisu, z własną regułą widoczności, a nie akapitem wpisanym w treść. Wszystkie trzy przypadki mają tę samą naturę: to, co zmienia się niezależnie, musi być osobnym polem, bo inaczej każda zmiana staje się pracą redakcyjną w kilkunastu miejscach naraz.

#Podsumowanie

Dune City jest przykładem projektu, w którym warstwa prezentacyjna jest najmniej interesującą częścią pracy. Trudność siedzi w modelu danych, w utrzymaniu jednego stanu dla listy, rzutu i mapy, w synchronizacji z systemem sprzedażowym i w rozdzieleniu tego, co wolno trzymać w pamięci podręcznej, od tego, co musi być świeże.

Trzeba też powiedzieć, czego z tego wdrożenia nie da się przenieść. Konkretny model treści powstał pod jeden układ etapów, jedną numerację budynków i jeden system po stronie dewelopera, więc kolejna inwestycja dostanie inny. Przenosi się sposób pracy: zacząć od tego, co się zmienia i jak często, a dopiero potem decydować o technologii. Przy inwestycji deweloperskiej to pytanie jest ważniejsze niż wybór frameworka, bo odpowiedź na nie decyduje, czy po dwóch latach ktokolwiek jest w stanie dodać nowy budynek bez udziału programisty.

Kolejne kierunki rozbudowy takiego serwisu są zwykle dwa: głębsza integracja z systemem sprzedażowym, żeby zniknął ręczny krok aktualizacji, oraz obsługa fazy po sprzedaży, czyli najmu i obsługi właścicieli. Każdy z nich jest osobnym zakresem, wycenianym po analizie.