Travel & Tourism Site: DUNE Resort

#DUNE Resort, ekskluzywny kompleks apartamentów nad Bałtykiem

Osoba, która kupuje apartament nad morzem, nie szuka strony. Szuka odpowiedzi na trzy pytania, których deweloperzy zwykle na stronie nie stawiają wprost: który lokal jest jeszcze wolny, co dokładnie widać z jego okna i ile metrów dzieli go od plaży. Dopóki serwis nie odpowiada na te trzy pytania w kilkanaście sekund, pełni rolę folderu reklamowego, a właściwa rozmowa i tak zaczyna się od telefonu do biura sprzedaży, w którym ktoś ręcznie przepisuje to, co powinno stać na stronie.

DUNE Resort powstał we wschodniej części Mielna, przy promenadzie i ulicy Pionierów, a inwestorem jest Firmus Group, grupa deweloperska z kapitałem norweskim działająca na Pomorzu Środkowym. Kompleks docelowo objął trzy budynki i łącznie 330 lokali, baseny zewnętrzne i wewnętrzny, strefę fitness oraz część gastronomiczną. Pierwszy budynek ze 114 lokalami ruszył w 2013 roku, kolejne dwa, na 153 i 63 apartamenty, dołączyły później. Nasze wdrożenie przypadło na 2017 rok i zajęło około sześciu tygodni.

Ta chronologia jest dla serwisu ważniejsza, niż wygląda. Strona nie opisuje jednego zamkniętego budynku, tylko inwestycję, która w trakcie jej życia zmienia liczbę lokali, liczbę kondygnacji i zestaw udogodnień. Model treści musiał to przewidzieć, bo inaczej każdy kolejny etap oznaczałby przebudowę szablonów zamiast dodania rekordów.

#Apartament jako rekord, nie jako podstrona

Najczęstszy błąd w serwisach deweloperskich polega na tym, że lokal jest traktowany jak podstrona z opisem. Wtedy metraż, piętro, liczba pokoi i status sprzedaży żyją w treści, czyli w miejscu, w którym nie da się ich sortować ani porównywać. Po pierwszym kwartale pojawia się prośba o filtr, po drugim o mapę, a każda z nich wymaga wyciągania liczb z akapitów.

Tutaj apartament od początku jest rekordem z polami, a nie tekstem. Metraż, kondygnacja, układ, ekspozycja okien, budynek, status i przypisanie do rzutu to osobne atrybuty. Opis marketingowy jest jednym z pól, a nie nośnikiem danych. Dzięki temu ten sam rekord zasila listę wyników, znacznik na mapie, kartę lokalu i eksport do biura sprzedaży, a zmiana statusu w jednym miejscu jest widoczna we wszystkich czterech naraz.

Konsekwencja tej decyzji dotyczy redakcji po stronie klienta. Osoba, która oznacza lokal jako zarezerwowany, nie edytuje tekstu i nie ma jak przypadkiem zepsuć układu strony. Ma pole wyboru z kilkoma wartościami. To wygląda na drobiazg przy odbiorze projektu i jest jedyną rzeczą, która decyduje o tym, czy po roku dane na stronie nadal zgadzają się z rzeczywistością.

Rekordowa struktura ma jeszcze jedno zastosowanie, które ujawnia się dopiero po kilku miesiącach. Biuro sprzedaży prędzej czy później prosi o zestawienie: ile lokali dwupokojowych zostało w budynku drugim, które z nich mają ekspozycję zachodnią, jak rozkłada się dostępność względem metrażu. Gdy dane siedzą w polach, takie pytanie jest zapytaniem do bazy i odpowiedź powstaje w minutę. Gdy siedzą w opisach, odpowiedź powstaje przez ręczne przeglądanie podstron i po każdej zmianie oferty trzeba ją zrobić od nowa. Ten sam model treści, który obsługuje odwiedzającego, obsługuje więc też pracę wewnętrzną, i to jest główny argument za tym, żeby ponieść jego koszt na starcie, a nie dokładać go później.

#Mapa i wyszukiwanie, czyli gdzie ten projekt naprawdę się rozstrzygał

Interaktywna mapa jest w tym serwisie elementem, który sprzedaje, a nie ozdobą. Pozwala zobaczyć rozkład budynków względem promenady i plaży, wskazać kondygnację i wybrać lokal z rzutu. Techniczne wyzwanie nie leży jednak w samym wyświetleniu mapy, tylko w pogodzeniu dwóch skal: planu sytuacyjnego całego założenia i rzutu pojedynczej kondygnacji. To są dwa różne układy współrzędnych, a użytkownik przechodzi między nimi płynnie i oczekuje, że kliknięty na planie budynek otworzy właściwe piętro, a nie listę wszystkich.

Rzuty przygotowaliśmy jako grafikę wektorową z obszarami klikalnymi powiązanymi z identyfikatorami lokali, zamiast mapować współrzędne na bitmapie. Różnica ujawnia się przy pierwszej zmianie projektu: przy bitmapie każda korekta rzutu unieważnia wszystkie wyznaczone obszary i trzeba je wyklikać od nowa, przy grafice wektorowej podmienia się plik, a powiązania zostają. Przy inwestycji, która rośnie etapami, to nie jest kwestia wygody, tylko tego, czy aktualizacja planu zajmuje godzinę, czy dwa dni.

Wyszukiwanie działa po atrybutach, nie po słowach. Metraż, liczba pokoi, kondygnacja, ekspozycja i status to kryteria z wartościami zamkniętymi, więc zapytanie da się rozstrzygnąć na indeksie, a nie przeszukiwaniem tekstu. Ma to znaczenie przy liście kilkuset lokali, bo naiwna implementacja odpytuje bazę raz na każdy przestawiony filtr. Zestaw dostępnych wartości wyliczany jest raz i trzymany w pamięci podręcznej, a pojedyncza zmiana filtra podmienia listę wyników bez przeładowania strony.

#Dostępność lokali kontra pamięć podręczna

Napięcie architektoniczne tego wdrożenia leży dokładnie na styku cache i statusu sprzedaży. Serwis deweloperski jest w większości statyczny: opisy, zdjęcia, plan założenia i udogodnienia zmieniają się rzadko, więc chce się je oddawać z pamięci podręcznej i w ogóle nie schodzić do PHP. Jednocześnie jedna informacja na tej stronie zmienia się w dowolnym momencie i jest najważniejsza ze wszystkich, czyli to, czy konkretny lokal jest jeszcze wolny.

Oddanie z cache strony z nieaktualnym statusem kosztuje więcej niż wolniejsze ładowanie. Klient dzwoni w sprawie mieszkania, które zostało sprzedane tydzień wcześniej, i pierwsze zdanie rozmowy handlowej brzmi jak sprostowanie. Rozstrzygnięcie polegało na rozdzieleniu warstw: szkielet strony, zdjęcia, opisy i plan są wspólne i buforowane agresywnie, a status i cena dociągają się osobnym, lekkim żądaniem do punktu końcowego, który zwraca wyłącznie listę identyfikatorów ze stanem. Ten fragment ma własny, krótki czas życia i unieważnia się natychmiast po zmianie w panelu, bo jest na tyle mały, że jego ponowne policzenie nic nie kosztuje.

Redis obsługuje tu cache obiektowy dla zapytań budujących listę, a Memcached sesje i fragmenty widoków. Dwie pamięci podręczne w jednym wdrożeniu brzmią jak nadmiar dopóty, dopóki nie zobaczy się, że obsługują różne rodzaje danych o różnym cyklu życia. Sieć CDN stoi przed tym wszystkim i odpowiada przede wszystkim za zdjęcia, których w serwisie tej klasy jest więcej niż całej reszty razem wziętej.

#Integracje i zachowanie przy awarii

Dane o dostępności i rezerwacjach nie powstają na stronie. Powstają w systemie biura sprzedaży, a serwis jest ich odbiorcą. Wymiana idzie przez REST API, asynchronicznie, z walidacją po stronie odbiorcy, bo dane wejściowe z cudzego systemu zawsze prędzej czy później przychodzą w kształcie, którego nikt nie zapowiedział.

Najważniejsza decyzja dotyczyła tego, co się dzieje, gdy integracja przestanie odpowiadać. Domyślne zachowanie większości wtyczek to pokazać błąd albo pustą sekcję, co na stronie sprzedażowej wygląda jak awaria całego serwisu i zniechęca skuteczniej niż brak jakiejkolwiek informacji. Tutaj każdy kanał ma wartość zapasową: ostatnią znaną odpowiedź z pamięci podręcznej, a gdy i tej nie ma, statyczny wariant sekcji z informacją, że stan potwierdza biuro sprzedaży. Odwiedzający widzi wtedy stronę bez jednego modułu, a nie komunikat o błędzie. Niedostępność systemu zewnętrznego jest zdarzeniem dla monitoringu, nie dla użytkownika.

Walidacja po stronie odbiorcy ma jeszcze jedną funkcję, o której się rzadko mówi. Rekord z pustym metrażem albo ze statusem spoza znanego zbioru zostaje odrzucony i zgłoszony, zamiast trafić na stronę jako pusta komórka w tabeli. Lista z jednym wybrakowanym wierszem podważa wiarygodność wszystkich pozostałych, a odwiedzający nie ma jak sprawdzić, który z nich jest poprawny.

#Warstwa prezentacji i to, czego celowo nie ma

Motyw jest autorski, modułowy, zbudowany na HTML5 i SASS. Układ oraz rozmieszczenie elementów dostarczył klient, więc naszą częścią było przełożenie go na szablony, zachowanie responsywne i model treści, który da się utrzymywać po starcie. SASS ma tu wartość nie w skróceniu zapisu, tylko w tym, że kolor marki i typografia mają jedno miejsce, a nie czterdzieści, co przy inwestycji rozbudowywanej etapami przekłada się bezpośrednio na koszt kolejnego budynku.

Zdjęcia są w tym serwisie główną treścią i jednocześnie głównym kosztem. Wizualizacja apartamentu z widokiem na morze nie może być skompresowana do stanu, w którym morze wygląda na plamę, a jednocześnie pełnowymiarowa galeria ładowana z góry potrafi przekroczyć wagę wszystkich pozostałych zasobów strony razem wziętych. Dlatego obrazy schodzą do przeglądarki w kilku rozmiarach, dobieranych do szerokości widoku, a te poniżej linii zgięcia dociągają się dopiero, gdy użytkownik do nich dojedzie.

Czego w tym serwisie nie ma, jest równie istotne. Nie ma licznika sprzedanych lokali, bo taka liczba żyje własnym życiem i po kwartale nikt nie pamięta, co się do niej wliczało. Nie ma kalkulatora stopy zwrotu, bo dawałby wynik, którego nikt nie potwierdzi, a na stronie inwestycyjnej taka liczba jest zobowiązaniem, nie argumentem. Świadome pominięcie jest tu pełnoprawnym wynikiem pracy, a nie luką w zakresie.

#Urządzenie mobilne na wakacjach to inne urządzenie

Serwis inwestycji nadmorskiej ma strukturę ruchu, której nie da się wywnioskować z uśrednionych statystyk. Część odwiedzających ogląda ofertę zimą, z komputera, w spokoju, porównując kilka inwestycji naraz. Druga część wchodzi latem, z telefonu, będąc kilkaset metrów od budynku, po zobaczeniu tablicy albo po rozmowie ze znajomym na plaży. To są dwa różne scenariusze i wymagają dwóch różnych rzeczy od tej samej strony.

Scenariusz zimowy potrzebuje porównania: tabeli, filtrów, rzutów do obejrzenia obok siebie, możliwości zapisania wyników. Scenariusz letni potrzebuje czegoś przeciwnego, czyli najkrótszej drogi od otwarcia strony do numeru telefonu i godzin pracy biura sprzedaży, przy łączu, które w szczycie sezonu w nadmorskiej miejscowości bywa gorsze niż w mieście. Z tego wynika, że waga pierwszego ekranu na widoku mobilnym jest parametrem biznesowym, a nie techniczną ciekawostką. Galeria wysokiej rozdzielczości, która na łączu światłowodowym pojawia się natychmiast, na przeciążonej sieci komórkowej opóźnia pojawienie się numeru telefonu o kilka sekund, a te sekundy są tu jedynym miejscem, w którym serwis realnie traci kontakt.

Dlatego kolejność ładowania jest ustawiona pod scenariusz gorszy, nie pod ten wygodniejszy. Dane kontaktowe i podstawowy opis są w źródle dokumentu, obrazy dociągają się po nich, a moduły zależne od integracji jako ostatnie. Na szybkim łączu różnicy nie widać wcale, i to jest właściwy efekt takiej decyzji.

#Widoczność w wyszukiwarce przy nazwie, której nikt nie zna

Nowa inwestycja ma problem, o którym łatwo zapomnieć: jej nazwa własna nie istnieje w świadomości rynku, dopóki ktoś jej nie zobaczy w reklamie. Zapytania, które realnie prowadzą do takiego serwisu, dotyczą miejscowości, typu nieruchomości i cechy, czyli apartamentu przy plaży w konkretnym kurorcie, a nie marki. Dopiero po czasie i po kampaniach zaczyna się ruch na samą nazwę.

Z tego wynikają dwie decyzje w modelu treści. Po pierwsze, strony opisujące inwestycję muszą nazywać rzeczy językiem odbiorcy, a nie językiem dewelopera, bo kupujący szuka apartamentu z widokiem na morze, a nie lokalu o określonej symbolice projektowej. Po drugie, dane strukturalne opisują tu realne byty, czyli organizację, obiekt i jego położenie, a nie są dosypywane do każdej podstrony na zasadzie, że skoro można, to warto. Znaczniki opisujące coś, czego na stronie nie ma, nie dają żadnego zysku i są pierwszą rzeczą, która rozjeżdża się z treścią przy kolejnej aktualizacji.

Adresy podstron zostały zaprojektowane tak, żeby przeżyły etapy inwestycji. Adres zawierający numer budynku albo rok oddania zestarzeje się w momencie, w którym dojdzie kolejny etap, a każda taka zmiana to przekierowanie do utrzymania przez lata. Adres opisujący rzecz, a nie jej moment w harmonogramie, nie wymaga niczego.

#Nasze działania

Dla dewelopera DUNE Resort przygotowaliśmy serwis z interaktywną prezentacją inwestycji, planem założenia, wyszukiwaniem lokali po atrybutach i mechanizmem utrzymywania statusów zgodnych z systemem biura sprzedaży. Układ strony miał prowadzić użytkownika od widoku całego kompleksu do konkretnego lokalu i stamtąd do kontaktu, bez cofania się i bez ponownego wpisywania kryteriów.

Testy kluczowych ścieżek szły na kopii produkcji, nie na pustej instalacji, i to jest w tym akapicie zdanie najważniejsze. Wydajność serwisu z kilkoma setkami rekordów, galerią i integracją nie ma nic wspólnego z wydajnością świeżej instalacji z motywem demonstracyjnym. Przypadki brzegowe, czyli lokal bez rzutu, budynek w trakcie wprowadzania, status spoza słownika, wychodzą wyłącznie na realnych danych i tylko tam dają się naprawić przed startem.

Po wdrożeniu serwis dostał podstawowy monitoring, analitykę i kontrolę pamięci podręcznej, czyli minimum pozwalające zauważyć, że coś przestało działać, zanim zauważy to biuro sprzedaży.

#Podsumowanie

DUNE Resort jest inwestycją, którą trudno opisać jednym ekranem, bo składa się z trzech budynków oddawanych w różnym czasie, kilkuset lokali o różnych układach i części wspólnej z basenami, strefą fitness i gastronomią. Serwis miał tę złożoność uporządkować, a nie ją powtórzyć, i z tego wynikały wszystkie decyzje techniczne opisane wyżej: apartament jako rekord z atrybutami, rzuty jako grafika wektorowa powiązana z identyfikatorami, status oddzielony od buforowanej reszty strony oraz integracja, która przy awarii degraduje jedną sekcję zamiast całej podstrony.

To, co z tego wdrożenia przenosi się na kolejne projekty deweloperskie, to sposób pracy: model treści wyprzedzający szablon, rozdzielenie danych zmiennych od statycznych na poziomie pamięci podręcznej i testy na kopii produkcji. Nie przenosi się sam model treści ani integracje, bo powstały pod dane jednego klienta i pod kształt jednej inwestycji. Kolejne wdrożenie zaczyna się od analizy zakresu, a wycena idzie po niej.

Dowiedz się więcej na stronie: duneresort.pl