E-handelsutvikling: DUNE CITY

#Dune City, en side som må være rask og fersk samtidig

De fleste nettsider kan velge. Enten er innholdet tungt og sjelden i endring, og da kan alt ligge i hurtigbuffer i ukevis, eller så er det lett og ferskt, og da koster hvert sidevisning en tur til databasen. En nettside for en boligutvikler får ikke det valget. Beskrivelsen av prosjektet, planskissene og bildene tåler å ligge lagret i lang tid, mens status og pris på en enkelt leilighet ikke tåler en time. Legger man begge lagene under samme regel, må regelen følge det korteste intervallet, og da forsvinner hurtigbufferen for det meste av innholdet som aldri trengte ferskhet i utgangspunktet.

Dune Resort i Mielno ligger på sandbanken som skiller Østersjøen fra Jamno-sjøen, omtrent ti kilometer nord for Koszalin. Utbygger er Firmus Group, og arkitekturen kom fra kontorene SAS og Mellon. Komplekset rommer tre hundre og tretti leiligheter, fra ett til fire rom, og bygg B har en helårs velværesone med innendørs bassenger. Oppdraget dekket både identitetsarbeidet og selve nettstedet, og derfor står denne oppføringen i to kategorier.

Tre hundre og tretti leiligheter er et tall som ser ufarlig ut i en brosjyre og helt annerledes ut i en innholdsmodell. Hver leilighet har areal, etasje, himmelretning, planløsning, bygg, salgstrinn, status og pris. Minst halvparten av de feltene endrer seg underveis, og noen av dem endrer seg mens en besøkende leser siden. Arbeidet gikk over omtrent seks uker og ble satt i drift i 2017. Kunden leverte layouten og plasseringen av elementene, og på det grunnlaget bygde jeg malene og innholdsmodellen.

#Hovedfunksjoner og moduler

Kartmodulen kombinerer integrasjon mot Google Maps API med Leaflet.js-biblioteket, og betjener både områdekartet og de interaktive planskissene. At disse to er skilt fra hverandre, er et bevisst valg. Områdekartet svarer på hvor dette ligger i forhold til stranden og promenaden, og der gir geografiske data mening. En planskisse er ikke et kart over verden, den er et bilde med klikkbare felt, og å drive den gjennom samme mekanisme som et kart ender i skalering som brekker sammen på telefon.

Søk og sortering hviler på egendefinerte felt og taksonomier, med resultater hentet asynkront over AJAX. Filtrering på flere dimensjoner samtidig er punktet der en eiendomskatalog som regel velter, fordi hvert nye attributt multipliserer antall kombinasjoner. En naiv implementasjon spør databasen én gang per bryter, og med tre hundre og tretti enheter og seks filtre blir det flere titalls spørringer per klikk. Her regnes settet av tilgjengelige verdier ut én gang og holdes i hurtigbuffer, og en enkelt filterendring bytter ut resultatlisten i stedet for å laste siden på nytt.

Integrasjonen mot eksterne systemer over REST API synkroniserer tilgjengelighet, reservasjonsstatus og oppdateringer i tilbudet. Dette er den mest ømfintlige delen av hele bygget, for sannheten om status ligger ikke på nettstedet, men i utbyggerens salgssystem. Enhver forsinkelse i den synkroniseringen har en helt konkret pris: noen ringer om en leilighet som ble solgt i går, og første setning i salgssamtalen blir en korreksjon.

Analyseverktøyene viser hvilke leiligheter som blir sett på oftest og hvordan interessen fordeler seg mellom trinnene. For en utbygger er det driftsinformasjon og ikke en rapport til et møte. Når en bestemt planløsning samler mange visninger uten at noen tar kontakt, ligger problemet i prisen eller i beskrivelsen, og begge deler kan endres samme uke.

Ytelseslaget hviler på hurtigbuffer i form av Redis og Memcached, med innholdsdistribusjon gjennom CDN. Delingen fra første avsnitt er det som gjør dette lagets arbeid mulig i det hele tatt: sideskallet og galleriet kommer fra ytterkanten av nettet, mens fragmentet med status hentes i en egen og billig forespørsel.

Et siste poeng om modulene henger sammen med hvem som ser dem. Kartet, søket og statusfeltet leser samme datasett, men brukes av tre ulike grupper: en kjøper som leter, en megler som kontrollerer hva som står ute, og en utbygger som vurderer hvilket trinn som skal annonseres neste måned. Når de tre visningene hentes fra hver sin kilde, begynner de å motsi hverandre innen få uker, og da er det ingen som stoler på noen av dem.

#Tekniske løsninger og avveininger

Temaet ble bygget fullt responsivt og modulært, på HTML5 og SASS. Modularitet er ingen arkitektonisk pynt her, men et svar på livsløpet til et slikt prosjekt. Trinnene lanseres etter tur, hvert av dem får sitt eget bygg, sin egen pott med enheter og sin egen kampanje, og nettstedet må ta imot et nytt trinn uten at malene skrives om. Et prosjekt der bygg A er skrevet fast et dusin steder, koster en uke ved bygg C i stedet for en time.

Geodata krevde egne endepunkter som returnerer posisjon og parametere for hver enhet, slik at de kan tegnes dynamisk på kartet. Vanskeligheten ligger ikke i å tegne punkter. Den ligger i at planskissen og resultatlisten må vise samme tilstand. En besøkende som filtrerer på toroms, forventer at nøyaktig de leilighetene lyser opp i planskissen. Å holde én kilde til tilstand for to så ulike visninger er den egentlige jobben.

Asynkron behandling over AJAX og REST API gjør navigeringen behagelig og koster noe på et sted som er lett å glemme. Filterresultater som lastes uten sideoppdatering, har ingen egen adresse, og kan dermed verken deles eller indekseres. Svaret er å speile filtertilstanden i URL-en og returnere et fullt serversvar ved direkte inngang, samtidig som den asynkrone veien beholdes for de neste bryterne. Det er omtrent dobbelt så mye arbeid som AJAX-laget alene, og den eneste måten resultatene finnes utenfor én nettleserøkt.

Adressestrukturen fortjener et eget avsnitt, fordi den avgjør om prosjektet finnes i søk utover sitt eget navn. Ingen søker etter navnet på et boligprosjekt før de kjenner det. De søker etter en toroms i Mielno med utsikt mot sjøen. Det betyr at filterkombinasjoner har reelt søkepotensial, men bare noen av dem. Alle på én gang gir tusenvis av nesten identiske adresser, som er den klassiske måten å tynne ut et nettsted på. Løsningen er å plukke ut et dusin kombinasjoner som svarer til spørsmål folk faktisk skriver, gi dem egen adresse og eget innhold, og holde resten av filterrommet utenfor indeksen.

Ytelsesmåling betyr noe annet her enn på en bedriftsside. Den tyngste visningen er ikke forsiden, men resultatlisten etter at filtrene er brukt, og den visningen har ingen fast adresse. En standard forsidegjennomgang når den aldri. Testingen må derfor følge de veiene trafikken faktisk går, og helst mot en kopi av produksjon med hele porteføljen lastet inn. På en tom installasjon med ti eksempelenheter går alt fort, og man lærer ingenting.

Kampanjeoppførsel er den andre målingen det lønner seg å planlegge for. Utbygger starter annonsering på ett trinn, og i løpet av en time tar én underside mer trafikk enn den tok hele forrige måned. Mønsteret er forutsigbart, og kan derfor håndteres billig: trinnsiden er i sin helhet bufrbar bortsett fra statusfragmentet, og statusfragmentet er lett. Uten den delingen betyr samme kampanje at man betaler for serverkapasitet for én dag.

Mobilen fortjener en merknad, for den første kontakten med tilbudet skjer på telefon mens selve kjøpet avsluttes på en datamaskin. En planskisse på en skjerm som er fire hundre piksler bred, er uleselig hvis den behandles som et bilde man skal rulle i. Klikkbare felt må ha fingerstørrelse og ikke markørstørrelse, og på en liten skjerm betyr det som regel at planskissen slutter å være et kart og blir en liste med utheving. Det er ingen forenklet mobilversjon, det er et annet svar på det samme spørsmålet fra brukeren.

Redigeringssiden av dette er verdt et avsnitt for seg, for det er den som avgjør om løsningen overlever uten utvikler. En megler skal kunne endre status på en enhet, laste opp et nytt bilde og flytte en leilighet fra ett trinn til et annet uten å åpne en mal. Derfor ligger hvert av de feltene som endrer seg hyppig, som et eget felt med sin egen rolle i grensesnittet, framfor å være skrevet inn i en fritekst. Prisen for den beslutningen er et mer omstendelig oppsett i starten. Gevinsten er at det daglige arbeidet ikke går gjennom oss.

#Hva kjøperen faktisk leter etter

Den som kjøper en leilighet ved sjøen, beveger seg gjennom et nettsted motsatt vei av den som bestiller et rom. Vedkommende ser ikke på tilbudet, men eliminerer det. Inngangen skjer med én hard begrensning, som regel budsjett eller areal, mesteparten av porteføljen forsvinner i løpet av første minutt, og først da begynner bildene å bety noe. Det snur den vanlige hierarkiet på hodet: filteret er primærinnhold, og det visuelle laget gjør først nytte når listen er nede i et titalls oppføringer.

Det andre kriteriet er romlig og lar seg ikke uttrykke i et skjema. På et prosjekt bygget på en sandbanke er det avgjørende hvilken side av bygget enheten ligger på, for det bestemmer om utsikten går mot havet, mot innsjøen eller mot nabobygget. Ingen glidebryter stiller det spørsmålet, og derfor må valget også kunne gjøres i planskissen og på områdekartet.

Det tredje forholdet er knyttet til stedet. Mielno er et sesongsted, men et leilighetskjøp er ingen sesongbeslutning, og en stor andel av kjøperne behandler kjøpet som en utleieinvestering framfor en feriebolig. Det er to helt ulike samtaler ført på de samme sidene. Den som kjøper til seg selv, spør om planløsning og ro. Den som kjøper for utleie, spør hvor mange uker i året enheten lar seg leie ut, og om bygget har noe som forlenger sesongen. Helårs velværesone med bassenger i bygg B svarer nettopp på det andre spørsmålet, og kan derfor ikke stå som nok en fasilitetsrute ved siden av parkeringen.

Tillit er det fjerde. Et boligprosjekt selger noe som på kjøpstidspunktet ofte ikke finnes ennå, i hvert fall ikke i den tilstanden det skal overleveres i. Alt nettstedet framstiller som faktum, må derfor enten være etterprøvbart eller tydelig merket som visualisering. Det er en redaksjonell avgjørelse med teknisk konsekvens: visualiseringer og byggeplassbilder må kunne skilles fra hverandre i innholdsmodellen, ikke havne i samme galleri.

#Våre handlinger

For Dune City leverte vi nettstedet med kartmoduler, søk og synkronisering mot eksterne systemer, slik at en besøkende kan sjekke gjeldende tilbud uten å gå gjennom et dusin undersider manuelt. Til det kom identitetslaget, i samsvar med prosjektets øvrige materiell.

Arbeidet skilte seg fra en vanlig bedriftsside fordi innholdet ble produsert parallelt med byggingen. Planskisser endret seg underveis, enkelte enheter fikk nye numre, og fotomateriale kom etappevis. Innholdsmodellen måtte tåle at samme oppføring først bærer en visualisering, deretter et byggeplassbilde og til slutt et bilde av ferdig interiør, uten at noen av disse byttene krever at noen rører en mal.

Nummereringen av enheter er det som oftest ryker et år etter lansering, ikke på lanseringsdagen. Den endres under bygging langt oftere enn noen antar mens datamodellen tegnes, og hvis enhetens identifikator samtidig er nummeret kunden ser, brekker hver endring lenker som allerede sirkulerer i e-poster og i salgsdokumenter. Å skille intern identifikator fra synlig etikett koster ett felt i databasen og sparer en uke med opprydding.

Bilder er det andre slike stedet. Interiørfotografering skjer som regel etter at første bygg er overlevert, så nettstedet lever på visualiseringer i over et år. Selve byttet er kritisk for troverdigheten. Ligger visualisering og foto i samme galleri, sitter man igjen med en blanding der ingen vet hva de ser på, og derfor har de to materialtypene hver sin status i modellen.

Prislisten er det tredje. Utbyggere endrer priser trinnvis og vil ofte ikke publisere dem i sin helhet, men utlevere dem etter kontakt. Det krever at pris er et eget felt med egen synlighetsregel, ikke et avsnitt skrevet inn i beskrivelsen. Alle tre tilfellene har samme natur: det som endrer seg uavhengig, må være sitt eget felt, ellers blir hver endring redaksjonelt arbeid et dusin steder samtidig.

#Oppsummering

Dune City er et prosjekt der presentasjonslaget er den minst interessante delen av jobben. Vanskeligheten sitter i datamodellen, i å holde én tilstand på tvers av liste, planskisse og kart, i synkroniseringen mot salgssystemet og i å skille det som kan bufres fra det som må være ferskt.

Denne siden inneholder ingen resultattall. Antall henvendelser, salgstakt og prosentvis vekst tilhører investoren og ikke leverandørens prosjektbeskrivelse, og ingen av dem kunne knyttes til en etterprøvbar kilde her. Det som flyttes videre til neste prosjekt, er rekkefølgen på spørsmålene: finn ut hva som endrer seg og hvor ofte, og velg teknologi etterpå.

En del av komplekset drives av en utleieoperatør, City Apartments, som forvalter nær to hundre og femti enheter. Den samme adressen tjener altså et annet formål etter at salget er avsluttet enn den gjorde i utbyggingsfasen, og informasjonsarkitekturen måtte ta høyde for det framfor å anta at nettstedet dør med siste solgte enhet. De to vanlige retningene videre er dypere integrasjon mot salgssystemet, som fjerner det manuelle oppdateringssteget, og støtte for fasen etter salg. Begge er egne oppdrag, priset etter analyse.

Én begrensning bør sies rett ut, for den gjelder fortsatt. Så lenge salgssystemet er kilden til sannhet om status, kan nettstedet aldri bli ferskere enn intervallet det systemet lar seg spørre på. Alt vi gjør på vår side, flytter grensen nærmere, men den forsvinner ikke før synkroniseringen går andre veien og systemet varsler om endringen selv.