Travel & Tourism Site: DUNE Resort

#Det som bevisst ikke ble bygget

En del av arbeidet med en nettside for et boligprosjekt består i å la være å bygge ting, og den delen kommer sjelden med i prosjektbeskrivelser, selv om den er like mye en beslutning som enhver funksjon som faktisk ble laget.

Det finnes ingen teller over solgte enheter. Et slikt tall lever sitt eget liv, og etter et kvartal husker ingen hva som ble regnet med: om reservasjoner telte, om avbestillinger ble trukket fra, fra hvilken dato tellingen startet. Et tall der opprinnelsen ikke lenger lar seg rekonstruere, er verdiløst som dokumentasjon og pinlig når noen spør.

Det finnes ingen avkastningskalkulator. Omfanget av en slik beregning avhenger av utleiemodell, sesong, driftskostnader og skatteforhold hos kjøperen, og en kalkulator på en prosjektside ville produsert et tall ingen senere bekrefter. På en investeringsside er et ubekreftet tall en forpliktelse, ikke et argument.

Det finnes heller ingen automatisk nyhetsstrøm fra eiendomsmarkedet. Slike moduler eldes dårlig. De ser levende ut den første måneden og ut som en forlatt bygning i tredje år, fordi kilden har endret format eller er slått av. Et tomt felt på en prosjektside sier mer om leverandøren enn innholdet som en gang sto der.

Fellesnevneren er den samme for alle tre: hver av dem ville sett bra ut ved lansering og blitt en forpliktelse over tid. Et bevisst fravalg er her et fullverdig arbeidsresultat.

#DUNE Resort, leilighetskompleks ved den polske Østersjøkysten

DUNE Resort ligger i den østlige delen av Mielno, ved promenaden i ul. Pionierow. Investoren er Firmus Group, en utviklergruppe med norsk kapital som opererer i Midt-Pommern. Komplekset omfatter tre bygg med til sammen 330 enheter, uten- og innendørs bassenger, treningsområde og servering på anlegget. Det første bygget med 114 enheter åpnet i 2013, to bygg til med 153 og 63 leiligheter kom senere. Vår leveranse falt i 2017 og tok rundt seks uker.

Rekkefølgen betyr mer for nettstedet enn den ser ut til. Siden beskriver ikke ett ferdig bygg. Den beskriver et prosjekt som endrer antall enheter, planløsninger og fasiliteter i løpet av sin egen levetid. En innholdsmodell som forutsetter en fast beholdning, tvinger fram en ombygging av malene ved hvert byggetrinn, og det er nettopp der slike nettsteder vanligvis blir erstattet i stedet for utvidet.

#Leiligheten som datapost

Den vanligste feilen i denne kategorien er å behandle en leilighet som en underside med tekst. Areal, etasje, antall rom og salgsstatus lever da inne i brødteksten, altså der ingenting lar seg sortere eller sammenlikne. I første kvartal kommer ønsket om et filter, i andre om et kart, og begge krever at tall hentes ut igjen av avsnitt som flere personer har redigert for hånd i mellomtiden.

Her er en leilighet en datapost med felter fra starten. Areal, etasje, planløsningstype, vindusretning, bygg, status og koblingen til plantegningen er egne attributter, mens salgsteksten er ett av feltene og ikke bæreren av dataene. Den samme posten mater resultatlisten, markøren i situasjonsplanen, detaljkortet og eksporten salgskontoret bruker, og én statusendring blir synlig alle fire steder samtidig.

Den andre gevinsten viser seg senere. Salgskontoret spør før eller siden: hvor mange toroms er igjen i bygg to, hvilke av dem vender vestover, hvordan fordeler tilgjengeligheten seg på areal. Når dataene ligger i felter, er dette en spørring og svaret tar et minutt. Når de ligger i beskrivelser, tar svaret en ettermiddag med klikking, og det må gjøres på nytt etter hver endring i tilbudet.

For den som drifter siden, er konsekvensen at det å merke en leilighet som reservert verken innebærer tekstredigering eller kan ødelegge et oppsett. Det er et nedtrekksfelt med noen få tillatte verdier. Det ser ut som en bagatell ved overlevering, og det er den eneste egenskapen som avgjør om opplysningene på siden fortsatt stemmer med virkeligheten et år senere.

#Tilgjengelighet mot mellomlager

Nesten alt på en slik side er statisk. Illustrasjoner, beskrivelser, situasjonsplan og fasilitetsliste endres kanskje to ganger i året. Én verdi gjør ikke det, nemlig om en bestemt leilighet fortsatt er ledig. Den kan endre seg klokka elleve på en tirsdag, og den er det eneste på siden en seriøs kjøper faktisk trenger før han tar telefonen.

Denne skjevheten former hele leveransen. Å levere sider fra mellomlager er det som gjør et bildetungt nettsted raskt, og en mellomlagret side som viser en solgt leilighet som ledig, er verre enn en treg side. Kjøperen ringer om en enhet som gikk forrige uke, og første setning i salgssamtalen blir en korreksjon. Løsningen var derfor ikke å mellomlagre mindre, men å dele siden i den delen som kan ligge lenge, og den lille delen som ikke kan mellomlagres i det hele tatt, og så gjøre den andre delen så liten at det ikke koster noe å regne den ut på nytt.

I praksis er sidestrukturen, bildene, beskrivelsene og situasjonsplanen felles for alle besøkende og mellomlagres hardt. Tilgjengelighet og pris kommer gjennom et eget, bevisst lite endepunkt som ikke returnerer annet enn identifikatorer og tilstand. Det har kort levetid og blir ugyldig i det øyeblikket noen endrer en status i administrasjonen. Redis bærer objektmellomlageret bak spørringene som bygger listene, Memcached holder økter og visningsfragmenter, og et CDN står foran det hele, først og fremst for bilder, som på et slikt nettsted veier tyngre enn alt annet til sammen.

#Hva kartet faktisk måtte løse

Det interaktive kartet selger her, det er ikke pynt. Det viser hvordan byggene ligger i forhold til promenaden og stranden, lar den besøkende velge etasje og plukke en leilighet fra plantegningen. Det vanskelige er ikke å tegne et kart. Det er å forene to målestokker: situasjonsplanen for hele anlegget og plantegningen for en enkelt etasje. Dette er to koordinatsystemer, og den besøkende beveger seg mellom dem med en forventning om at et bygg som klikkes i oversikten, åpner riktig etasje og ikke en liste over alle.

Plantegningene ble laget som vektorgrafikk med klikkbare flater knyttet til leilighetsidentifikatorer, i stedet for koordinater lagt oppå et punktbilde. Forskjellen viser seg ved første planrevisjon. Med punktbilde gjør enhver korreksjon alle flatene ugyldige og de må settes på nytt, med vektorgrafikk byttes filen og koblingene består. På et prosjekt som leveres i trinn, er det forskjellen mellom en time og to dager per planoppdatering.

Søket går på attributter, ikke på ord. Areal, romantall, etasje, retning og status er kriterier med lukkede verdilister, så en forespørsel kan besvares mot en indeks i stedet for et tekstsøk. Ved flere hundre enheter betyr det mye, fordi den naive løsningen spør databasen på nytt for hvert filter som slås av og på. Settet av tilgjengelige verdier beregnes én gang og holdes i mellomlager, og det å endre ett filter bytter resultatlisten uten at siden lastes på nytt.

#Integrasjoner og oppførsel ved feil

Data om tilgjengelighet og reservasjoner oppstår ikke på nettstedet. De oppstår i salgskontorets system, og siden er mottaker. Utvekslingen går asynkront over et REST API, med validering på mottakersiden, fordi data fra et annet system før eller siden kommer i en form ingen har varslet om.

Den viktigste beslutningen gjaldt hva som skjer når integrasjonen slutter å svare. Standardoppførselen til de fleste utvidelser er en feilmelding eller en tom seksjon, noe som på en salgsside leses som et fullstendig driftsavbrudd og gjør mer skade enn å vise ingenting. Her har hver kanal en reserveverdi: siste kjente svar fra mellomlageret, og når heller ikke det finnes, en statisk variant av seksjonen med opplysning om at salgskontoret bekrefter gjeldende status. Den besøkende ser en side uten én modul, ikke en feilmelding. Et utilgjengelig fremmedsystem er en hendelse for overvåkingen, ikke for brukeren.

Validering på mottakersiden gjør i tillegg noe som sjelden nevnes. En post uten areal, eller med en status utenfor det kjente settet, avvises og rapporteres i stedet for å havne på siden som en tom tabellcelle. Én mangelfull rad undergraver troverdigheten til alle de riktige radene rundt, og den besøkende har ingen mulighet til å se hvilken som er hvilken.

#Presentasjon og bilder

Temaet er egenutviklet, modulært, bygget på HTML5 og SASS. Oppsettet og plasseringen av elementene kom fra kunden, så vår del var å oversette det til maler, responsiv oppførsel og en innholdsmodell som tåler å bli vedlikeholdt. SASS gjør nytten ikke ved kortere skrivemåte, men ved at merkefargen og typografien har ett sted i stedet for førti, noe som på et prosjekt som vokser i trinn slår direkte ut i kostnaden for neste bygg.

Bildene er både hovedinnholdet og hovedkostnaden. En illustrasjon av en leilighet med havutsikt kan ikke komprimeres til havet blir en flekk, og et fullt oppløst galleri lastet på forhånd kan veie mer enn alle andre ressurser til sammen. Bildene leveres derfor i flere størrelser valgt mot bredden på visningsflaten, og alt under første skjerm venter til den besøkende kommer dit.

#To besøkende med motsatt behov

Et nettsted for et kystprosjekt har en trafikkform som ikke lar seg lese ut av gjennomsnittstall. Én gruppe ser på tilbudet om vinteren, fra en datamaskin, i ro, og sammenlikner flere prosjekter samtidig. En annen gruppe kommer om sommeren, fra telefonen, noen hundre meter fra bygget, etter å ha sett et skilt eller snakket med noen på stranden. Dette er to ulike situasjoner, og de krever motsatte ting av den samme siden.

Vintersituasjonen trenger sammenlikning: tabell, filtre, plantegninger ved siden av hverandre, mulighet til å ta vare på et utvalg. Sommersituasjonen trenger det motsatte, altså korteste vei fra åpnet side til telefonnummer og åpningstider hos salgskontoret, over en forbindelse som i høysesongen på et badested gjerne er dårligere enn i byen. Av dette følger at vekten på første skjermbilde i mobilvisning er en forretningsparameter og ikke en teknisk kuriositet. Et galleri i full oppløsning som på fiber dukker opp umiddelbart, utsetter på et overbelastet mobilnett telefonnummeret med noen sekunder, og de sekundene er det eneste stedet der nettstedet faktisk mister en kontakt.

Lasterekkefølgen er derfor satt opp for det dårligste tilfellet og ikke for det behagelige. Kontaktopplysninger og grunnleggende beskrivelse ligger i dokumentkilden, bildene hentes etter dem, og modulene som avhenger av integrasjonen kommer sist. På en rask forbindelse merkes ingen forskjell, og det er riktig utfall av en slik avveining.

Den samme todelingen preger språkbruken. Vinterleseren tåler og etterspør presise opplysninger om areal, etasje og retning. Sommerleseren vil ha ett bilde, én avstand og ett telefonnummer. Begge finnes på samme side, men ikke i samme rekkefølge, og det er derfor kontaktveien ligger fast tilgjengelig i stedet for å bli et mål man klikker seg fram til.

#Våre handlinger

For utbyggeren av DUNE Resort laget vi et nettsted med interaktiv presentasjon av prosjektet, situasjonsplan, attributtbasert leilighetssøk og en mekanisme som holder statusene i takt med salgskontorets system. Sideføringen tar den besøkende fra oversikten over hele anlegget til en konkret leilighet og derfra til kontakt. Den som går tilbake fra en leilighet til listen, finner kriteriene sine urørt i stedet for å taste dem inn på nytt.

Den viktigste setningen i dette avsnittet handler om testingen, som gikk mot en kopi av produksjonen og ikke mot en tom installasjon, for ytelsen til et nettsted med flere hundre poster, et galleri og en aktiv integrasjon har ingenting med ytelsen til en fersk installasjon med demotema å gjøre. Grensetilfellene er en leilighet uten plantegning, et bygg under registrering og en status utenfor ordlisten, og ingen av dem dukker opp uten ekte data foran seg. Etter lansering fikk nettstedet grunnleggende overvåking, analyse og kontroll over mellomlageret, altså minimumet som skal til for å oppdage at noe har sluttet å virke før salgskontoret oppdager det.

#Oppsummering

Tre bygg levert til ulik tid, flere hundre leiligheter med forskjellige planløsninger og et fellesareal med bassenger, trening og servering. Dette lar seg vanskelig beskrive på én skjerm, og nettstedet skulle ordne kompleksiteten i stedet for å gjenta den.

Alle de tekniske valgene over følger av det kravet. Leiligheten er en datapost med attributter, plantegningene er vektorgrafikk knyttet til identifikatorer, og tilgjengeligheten er skilt fra den mellomlagrede resten av siden. Integrasjonene svekker ved feil én seksjon i stedet for en hel side, fordi en besøkende som mangler ett statusfelt fortsetter å lete, mens en besøkende som møter en tom side lukker fanen. Ingen av valgene er interessante hver for seg, og til sammen er de grunnen til at siden holder seg lesbar mens prosjektet endrer seg under den.

Det som overføres til neste eiendomsprosjekt, er arbeidsmåten, altså innholdsmodellen før malen, skillet mellom foranderlige og statiske data i mellomlagerlaget og testing mot en kopi av produksjonen, mens selve innholdsmodellen og integrasjonene blir igjen her fordi de ble bygget rundt én kundes data og formen på ett prosjekt, og derfor starter neste leveranse med en gjennomgang av omfanget og prisen kommer etter den.

Besøk nettstedet: duneresort.pl