Portfolio

Strona osiedla mieszkaniowego: Osiedle Norweskie

Projekt strony osiedlenorweskie.pl dla kameralnego osiedla w Koszalinie, z naciskiem na prezentację inwestycji, czytelne treści i stabilne działanie.

#Strony www
Strona osiedla mieszkaniowego: Osiedle Norweskie

Osiedle Norweskie to kameralne osiedle domów wolnostojących w Koszalinie, realizowane przez Firmus Group w Jamnie, przy ulicy Gradowej. Architekturę cechuje tradycyjna, ponadczasowa forma połączona z otaczającą zielenią i miejscami stworzonymi dla dzieci i ich rodziców. Elewacja domów utrzymana jest w ciepłych tonacjach, lekko kontrastujący z nią ciemny dach, zaakcentowany drewnem, to kompozycja, która harmonijnie wpisuje się w otoczenie i daje poczucie uporządkowania. Relaksująca przyroda, okalająca zieleń, bliskość jeziora oraz świeże powietrze zapewniają mieszkańcom warunki, jakich nie znajdą w innej części Koszalina. Trawnik własnego ogródka, zieleń widoczna aż po horyzont, odgłosy natury zamiast miejskiego ruchu, wszystko to zaprasza do odpoczynku po pracy, a najmłodszym stwarza wymarzone warunki do zabawy.

#Osiedlenorweskie.pl, technologia dla norweskiej oazy w Koszalinie

osiedlenorweskie.pl to projekt strony prezentującej to osiedle. Wdrożenie ruszyło w 2016 roku i zajęło około sześciu tygodni. Miało pokazać charakter inwestycji, ułatwić odbiorcom poznanie oferty i zapewnić prostą obsługę treści po stronie administratora, bez konieczności wzywania wykonawcy przy każdej zmianie w karcie domu.

#Cztery projekty domów, czyli od czego zaczyna się model treści

Najważniejsza decyzja w tym wdrożeniu zapadła przed napisaniem pierwszej linii szablonu i dotyczyła tego, czym jest tu jednostka treści. Inwestycja przewiduje czterdzieści osiem domów o zróżnicowanej powierzchni, na działkach od sześciuset pięćdziesięciu do tysiąca dwustu metrów kwadratowych, ale nie są to czterdzieści osiem różnych projektów. Deweloper oferuje cztery typy, nazwane od norweskich miast: Alesund o powierzchni 125,72 metra kwadratowego, Bergen o powierzchni 136,34, Oslo o powierzchni 152,12 oraz Trondheim o powierzchni 178,70.

To rozróżnienie decyduje o wszystkim, co dzieje się dalej. Gdyby każdy dom był osobnym rekordem z własnym opisem, rzutem i galerią, to każda zmiana w standardzie wykończenia typu Bergen wymagałaby poprawienia kilkunastu wpisów, a redaktor prędzej czy później poprawiłby tylko część. Jeśli natomiast typ domu jest rekordem, a konkretny dom na działce jedynie jego wystąpieniem, to opis pisze się raz, a numer działki, powierzchnia gruntu i status dostępności są polami, które zmienia ktokolwiek, bez ryzyka rozjechania treści.

Koszt tej decyzji też warto nazwać. Gdy pojawia się dom nietypowy, na przykład lustrzane odbicie rzutu wymuszone kształtem działki, model wymaga wyjątku, a wyjątek w dobrze zamkniętym modelu jest droższy niż w luźnym. Uznałem to za opłacalne, bo nietypowych przypadków jest kilka, a zwykłych kilkadziesiąt.

#Po co jest osiedlenorweskie.pl i kto tu zagląda

Strona powstała, żeby pokazać urok tego miejsca, podkreślić jego atuty i ułatwić kontakt z potencjalnymi mieszkańcami. To witryna dla rodzin, osób szukających spokoju i tych, którzy chcą aktywnie wypoczywać blisko natury.

Charakter ruchu jest tu zupełnie inny niż w sklepie internetowym i to zmienia priorytety techniczne. Nikt nie kupuje domu w pierwszej sesji. Ta sama osoba wraca na stronę kilkanaście razy przez kilka miesięcy, za każdym razem szukając innej rzeczy: raz rzutu parteru, raz odległości od szkoły, raz zdjęć z placu budowy, żeby sprawdzić, na jakim etapie są prace. Z tego wynikają dwa wymagania. Adresy kart domów muszą być trwałe, bo zostaną zapisane w zakładkach i podesłane rodzinie. A zdjęcia z postępu prac muszą dać się dodawać szybko i często, bo to one są powodem powrotu.

Druga cecha tego odbiorcy to urządzenie. Znaczna część wizyt to telefon, często przy słabym zasięgu, bo dzielnica Jamno leży na północnym skraju miasta. Strona, która na biurku ładuje się w sekundę, na krawędzi zasięgu potrafi ładować się kilkanaście razy dłużej, a użytkownik nie rozróżnia winy operatora od winy serwisu.

#Galerie, rzuty i dlaczego to najcięższa część serwisu

Największym obciążeniem na tej stronie są obrazy, i to nie jest opinia, tylko konsekwencja tego, czym ta strona jest. Kupujący dom ogląda zdjęcia i rzuty, a nie czyta akapitów. Galerie domów zbudowałem jako niestandardowe typy treści z rzutami i fotografiami, doładowywane bez przeładowania strony, z wariantami rozmiarowymi dobieranymi przez przeglądarkę do faktycznej szerokości widoku.

Warianty rozmiarowe są tu ważniejsze niż format pliku, choć to format budzi więcej emocji. Zdjęcie o szerokości dwóch tysięcy pikseli wyświetlone w kaflu o szerokości czterystu kosztuje tyle samo transferu niezależnie od tego, jak dobry jest kodek. Dopiero po dobraniu właściwego wariantu ma sens rozmowa o kompresji, i dopiero wtedy przejście na nowocześniejszy format daje widoczną różnicę.

Osobnym problemem były rzuty. Plany domów przychodzą od architekta jako pliki przeznaczone do druku, z cienkimi liniami i opisami, które w skali ekranu telefonu są nieczytelne. Zmniejszenie takiego pliku nie rozwiązuje sprawy, bo razem z wagą znika czytelność wymiarów. Rozwiązaniem było oddzielenie podglądu od pełnej wersji: w karcie domu widać uproszczony rzut przygotowany pod ekran, a plik do druku pobiera się świadomie, jednym kliknięciem, wtedy kiedy odwiedzający już wie, że ten dom go interesuje.

#Mapa okolicy i granica jej przydatności

Moduł mapy oparty o Leaflet pokazuje osiedle i jego otoczenie, z danymi w formacie GeoJSON. Mapa w serwisie deweloperskim ma jedno konkretne zadanie: odpowiedzieć na pytanie, co jest w pobliżu, i jest to pytanie, na które opis słowny odpowiada gorzej niż rysunek.

Trzeba jednak wiedzieć, gdzie leży granica. Warstwa wektorowa z dużą liczbą punktów potrafi zablokować interfejs na słabszym telefonie, bo przeglądarka próbuje narysować wszystko naraz, zanim odda sterowanie użytkownikowi. Ograniczenie zakresu danych do rzeczywistego otoczenia inwestycji i doładowywanie mapy dopiero wtedy, gdy odwiedzający przewinie do jej sekcji, kosztuje jedno dodatkowe żądanie i oszczędza kilka sekund zacięcia na pierwszym otwarciu strony. To ten rodzaj kompromisu, który na szybkim łączu wygląda na zbędny, a na wolnym decyduje o tym, czy ktoś zostaje.

#Cache w trzech warstwach i skąd bierze się jego unieważnianie

Wdrożenie korzysta z pamięci podręcznej na kilku poziomach i każdy z nich obsługuje inny rodzaj żądania. Cloudflare jako warstwa brzegowa oddaje pliki statyczne i strony anonimowe, czyli praktycznie cały ruch z wyszukiwarki. Varnish przed aplikacją trzyma gotowe widoki list domów, których złożenie kosztuje kilka zapytań do bazy. Redis skraca same te zapytania dla wszystkiego, co i tak musi trafić do PHP.

Trzy poziomy w tak niedużym serwisie brzmią jak przesada, dopóki nie spojrzy się na to, co się zmienia i jak często. Opis typu domu nie zmienia się przez rok. Status dostępności konkretnego domu zmienia się w dniu podpisania umowy i handlowiec oczekuje, że strona pokaże to natychmiast. Gdyby wszystko było w jednym worku, każda zmiana statusu wyrzucałaby z pamięci również treść, która jest niezmienna, i cache faktycznie by nie istniał.

Dlatego unieważnianie jest punktowe i podpięte pod zdarzenia zapisu konkretnego rekordu, a nie globalne. Największym pojedynczym błędem, jaki widuję w takich wdrożeniach, jest właśnie cache, który technicznie działa i jest czyszczony przy każdym zapisie czegokolwiek. Wygląda poprawnie w konfiguracji, w logach widać trafienia, a mimo to serwer liczy wszystko od nowa kilkadziesiąt razy dziennie.

#Formularz kontaktowy i to, co dzieje się z zapytaniem

Formularz zbiera zapytania o konkretny dom albo o typ domu, z walidacją po stronie serwera i ochroną antyspamową. Walidacja w przeglądarce jest wygodą użytkownika, nie zabezpieczeniem, więc ta sama reguła stoi jeszcze raz po stronie serwera.

Istotniejsze jest jednak coś innego: zapytanie musi wiedzieć, skąd przyszło. Wiadomość o treści “proszę o kontakt” bez informacji, że ktoś wysłał ją z karty domu typu Oslo, wymaga od handlowca oddzwonienia po to, żeby zadać pytanie, na które strona znała już odpowiedź. Kontekst domu jest więc dołączany do zgłoszenia automatycznie, a kopia trafia do bazy niezależnie od tego, czy wysyłka maila się powiodła. Serwer pocztowy bywa niedostępny przez kilka minut i nie jest to powód, żeby lead przepadł bez śladu.

#Kopie zapasowe i aktualizacje, czyli nudna część, która ratuje projekt

Kopie zapasowe trafiają do magazynu obiektowego AWS, z szyfrowaniem i rotacją. Warto powiedzieć rzecz, o której się zwykle milczy: kopia zapasowa, której nigdy nie odtworzono, jest hipotezą, a nie zabezpieczeniem. Sama obecność plików w chmurze nic nie gwarantuje, dopóki ktoś nie sprawdzi, że zrzut bazy da się zaimportować i że razem z nim przyszły pliki mediów, a nie tylko tabele.

Drugą nudną, a kluczową sprawą jest kolejność aktualizacji. Aktualizacje systemu i wtyczek trafiają najpierw na środowisko testowe, i to nie z ostrożności rytualnej. Na stronie z dedykowanym motywem i własnymi typami treści to właśnie motyw, a nie rdzeń WordPressa, rozjeżdża się po podbiciu wersji, najczęściej w miejscu, gdzie szablon zakładał strukturę danych, którą wtyczka właśnie zmieniła.

#Blog i treści lokalne, czyli po co deweloperowi teksty

Blog przy serwisie inwestycji mieszkaniowej bywa traktowany jak obowiązkowy dodatek i zwykle umiera po trzech wpisach. Tutaj miał konkretne zadanie: odpowiadać na pytania, które ludzie zadają przed decyzją, a których nie da się zmieścić w karcie domu. Jak wygląda dojazd do centrum Koszalina o ósmej rano, co oznacza status uzbrojenia działki, czym różni się umowa deweloperska od umowy przedwstępnej, jak wygląda okolica zimą, a nie tylko na zdjęciach z czerwca.

Techniczna strona takiej treści jest prosta, a redakcyjna nie. Wpis, który powtarza opis inwestycji własnymi słowami, konkuruje w wyszukiwarce z kartą inwestycji i przegrywa z nią, jednocześnie osłabiając ją samą. Dlatego każdy tekst musiał mieć własny temat i linkować do karty domu, a nie odwrotnie. Tam, gdzie tematy zaczęły się powielać, lepszym ruchem było rozbudowanie istniejącego wpisu niż napisanie drugiego o tym samym.

Osobną decyzją była rezygnacja z automatycznego zgłaszania nowych adresów do zewnętrznych usług indeksujących. Przy kilkunastu publikacjach rocznie zysk z takiego mechanizmu jest niemierzalny, a każdy dodatkowy integracyjny element to kolejne miejsce, które trzeba utrzymywać i które potrafi po cichu przestać działać. Mapa witryny generowana przy zapisie wystarcza i nie ma własnego trybu awarii.

#Widoczność lokalna i pułapka nazwy własnej

Nazwa Osiedle Norweskie jest wyrazista i to pomaga, dopóki nie przyjrzeć się temu, czego ludzie faktycznie szukają. Osoba, która zna nazwę, trafi na stronę bez naszego udziału. Osoba, która dopiero rozważa przeprowadzkę, wpisuje coś zupełnie innego: domy Koszalin, osiedle zamknięte Koszalin, dom na sprzedaż Jamno. Serwis zbudowany wyłącznie wokół nazwy własnej obsługuje wyłącznie tych, którzy już podjęli decyzję.

Dlatego struktura adresów i nagłówków musiała nieść też to, czym ta inwestycja jest, a nie tylko jak się nazywa. Karta inwestycji mówi o domach wolnostojących w zamkniętej enklawie w Koszalinie, dzielnica jest wymieniona wprost, a nie zakładana jako wiedza czytelnika. To nie jest zabieg pod algorytm, tylko pod człowieka, który nie mieszka w tym mieście i nie wie, gdzie leży Jamno.

Druga pułapka dotyczy danych strukturalnych. Kuszące jest opisanie każdego domu jako oferty z ceną, bo wyszukiwarki lubią takie dane i potrafią je pokazać w wynikach. Problem w tym, że cena domu z działką zmienia się w trakcie etapu, a dane raz wypuszczone do indeksu żyją własnym życiem przez tygodnie. Nieaktualna cena w wyniku wyszukiwania to rozmowa, która zaczyna się od sprostowania, czyli najgorszy możliwy początek. Strona opisuje więc typ, powierzchnię i dostępność, a rozmowę o cenie zostawia człowiekowi.

Trzecia rzecz to zdjęcia w wynikach. Miniatura, którą wyszukiwarka wybiera sama, bywa akurat fragmentem elewacji bez kontekstu. Wskazanie obrazu reprezentacyjnego dla każdej karty kosztuje jedno pole w modelu treści i decyduje o tym, czy w wyniku widać dom, czy kawałek dachu.

#Co na tej stronie zostało świadomie pominięte

Opis wdrożenia bez tej sekcji jest folderem reklamowym, więc zostawiam ją tutaj. Nie zbudowaliśmy konfiguratora wykończenia wnętrz, mimo że pomysł pojawiał się przy każdym kolejnym etapie. Konfigurator ma sens wtedy, gdy warianty są policzalne i opisane w jednym miejscu po stronie klienta, a ceny da się z niego wyprowadzić bez telefonu do handlowca. Przy czterech typach domów i indywidualnych ustaleniach wykończeniowych narzędzie pokazywałoby liczby, które i tak wymagałyby weryfikacji, czyli robiłoby dokładnie odwrotnie, niż obiecuje.

Nie wdrożyliśmy też rezerwacji domu online. W obrocie nieruchomościami rezerwacja bez wpłaty nie jest rezerwacją, tylko kolejką, a kolejka widoczna publicznie generuje więcej konfliktów niż sprzedaży. Status dostępności jest więc informacją, a nie akcją, i zmienia go człowiek po stronie dewelopera.

Trzecia rzecz to opinie mieszkańców. Kuszące, ale przy inwestycji, w której pierwszy etap obejmował sześć domów, każda opublikowana opinia jest z definicji możliwa do przypisania konkretnej rodzinie. Zamiast tego strona pokazuje postęp prac i zdjęcia gotowych realizacji, czyli materiał, który mówi to samo, a nie wymaga od nikogo publicznego wystąpienia.

#Techniczne wsparcie, dbam o harmonię

Osiedlenorweskie.pl to nie jednorazowy szkic, to witryna, która wymaga ciągłej opieki. Wykonuję aktualizacje systemu i wtyczek, testując je najpierw poza produkcją, z kopiami bezpieczeństwa po stronie AWS. Cloudflare, Varnish i Redis trzymają wydajność w ryzach, a ich konfiguracja jest przeglądana wtedy, gdy zmienia się kształt treści, bo to zmiana treści, a nie upływ czasu, psuje strategię cache. Monitoruję wskaźniki jakości ładowania, optymalizuję zapytania do bazy i czyszczę pamięć podręczną przy zmianach oferty.

Stronę da się rozbudować, na przykład o wirtualny spacer, integrację z systemem sprzedażowym czy moduł dostępnych domów aktualizowany z jednego miejsca. Każda z tych rzeczy zaczyna się jednak od pytania, ile treści realnie trzeba będzie utrzymywać po wdrożeniu, bo to ona, a nie sam kod, generuje koszt w drugim roku.

Planujesz stronę dla inwestycji mieszkaniowej? Opisz założenia projektu, a ustalimy zakres strony, która jasno pokaże lokalizację, charakter osiedla i najważniejsze informacje dla odbiorców.

FAQ do artykułu

Często zadawane pytania

Najważniejsze odpowiedzi, które pomagają wdrożyć temat w praktyce.

SEO-readyGEO-readyAEO-ready4 Q&A
Jakiego zakresu dotyczył projekt Osiedle Norweskie?#
Osiedle Norweskie to realizacja z kategorii Strony www, oddana w 2016 roku. Stoi za nią: Redis, AWS, Cloudflare, Varnish oraz iOS.
Jak wyglądał przebieg prac przy Osiedle Norweskie?#
Wdrożenie zajęło około sześciu tygodni i ruszyło w 2016 roku. Stoi na: Redis, AWS, Cloudflare, Varnish oraz iOS. Układ dostarczył klient. Na jego podstawie zbudowałem szablony i model treści, a ścieżki, którymi idzie ruch, sprawdziłem na kopii produkcji, nie na pustej instalacji.
Co było najtrudniejsze technicznie w Osiedle Norweskie?#
Najwięcej uwagi pochłonęło spięcie: Redis, AWS, Cloudflare, Varnish oraz iOS. Treść, konfiguracja i kod siedzą w osobnych warstwach, więc wycofanie zmian po starcie rusza jedną z nich, a nie wszystkie trzy. Przypadki brzegowe wychodzą na kopii produkcji i tam idą testy.
Co z projektu Osiedle Norweskie da się wykorzystać przy kolejnym wdrożeniu?#
Przenosi się warstwa techniczna: Redis, AWS, Cloudflare, Varnish oraz iOS. Na kolejnym wdrożeniu wygląda podobnie. Nie przenosi się model treści tego projektu ani jego integracje, bo powstały pod dane jednego klienta i pod brief z kategorii Strony www. Kolejne wdrożenie zaczyna się od analizy zakresu, a wycena idzie po niej.

Potrzebujesz FAQ dopasowanego do branży i rynku? Przygotujemy wersję pod Twoje cele biznesowe.

Porozmawiajmy