E-handelsutvikling: Osiedle Norweskie

Osiedle Norweskie er et lukket boligfelt med frittstående hus i Koszalin, bygget av Firmus Group i bydelen Jamno ved Gradowa-gaten. Arkitekturen har en tradisjonell, tidløs form kombinert med grøntområder og steder laget for barn og foreldre. Fasadene har varme toner, taket er mørkt og litt kontrasterende, detaljene er i tre, og helheten faller rolig inn i omgivelsene. Naturen rundt, nærheten til innsjøen og den friske, nesten sjøaktige luften gir beboerne forhold de ikke finner andre steder i Koszalin. Egen plen, grønt så langt øyet rekker, lyden av natur i stedet for bytrafikk: alt dette innbyr til ro etter jobb og gir de yngste et sted å leke.

#Navnet er ikke tilfeldig, og det er heller ikke husene

For en norsk leser er det verdt å begynne her. Firmus Group er en utbyggergruppe med norsk kapital som opererer i Midt-Pommern, og boligfeltet er det første lukkete feltet med eneboliger i Koszalin. De fire hustypene bærer navn etter norske byer: Alesund på 125,72 kvadratmeter, Bergen på 136,34, Oslo på 152,12 og Trondheim på 178,70. Feltet planlegges med førtiåtte hus på tomter mellom seks hundre og femti og tolv hundre kvadratmeter.

Dette er ikke bare markedsføring. Det er også utgangspunktet for hele innholdsmodellen, og den viktigste avgjørelsen i prosjektet ble tatt før den første mallinjen ble skrevet.

#Hustype som datapost, enkelthus som forekomst

Førtiåtte hus er ikke førtiåtte beskrivelser. Hvis hvert enkelt hus var sin egen post med egen tekst, egen plantegning og eget galleri, ville én endring i standarden for Bergen bety redigering av et dusin oppføringer, og før eller siden ville redaktøren oppdatere bare noen av dem. Med hustypen som post og den enkelte tomten som en forekomst av den, skrives beskrivelsen én gang, mens tomtenummer, tomteareal og tilgjengelighet er felt hvem som helst kan endre uten at innholdet sprikér.

Kostnaden skal også nevnes. Når et atypisk hus dukker opp, for eksempel en speilvendt plan tvunget frem av tomtens form, krever modellen et unntak, og unntak er dyrere i en stram modell enn i en løs. Her var det verdt det, fordi de uvanlige tilfellene er en håndfull og de vanlige flere titalls.

#Nettstedet består stort sett av bilder

Alt teknisk ved osiedlenorweskie.pl følger av én enkel kjensgjerning. Den som kjøper hus, ser på fotografier og plantegninger. Hun leser ikke avsnitt. Det tyngste dette nettstedet sender over nettet er altså bilder, og enhver avgjørelse om hastighet er i realiteten en avgjørelse om bilder.

Størrelsesvarianter betyr mer enn filformat her, selv om det er formatet folk krangler om. Et fotografi på to tusen piksler vist i et kort på fire hundre koster like mye overføring uansett hvor god kodeken er. Først når nettleseren får et sett varianter å velge mellom, betyr en samtale om komprimering noe, og først da gir et moderne format en synlig forskjell.

Husgalleriene ble bygget som egne innholdstyper med plantegninger og fotografier, lastet inn uten full sideoppdatering, med varianter valgt av nettleseren mot faktisk visningsbredde. Nettopp det siste er lett å gjøre feil: en responsiv bildeerklæring som beskriver oppsettet unøyaktig, gir telefonen skrivebordsfilen og rapporterer suksess mens den gjør det.

Plantegningene trengte sitt eget svar. Arkitekten leverer planer som trykksaker, med hårfine streker og påskrifter som er uleselige på telefonskjerm. Å krympe en slik fil løser ingenting, for lesbarheten på målene forsvinner sammen med vekten. Løsningen ble å skille forhåndsvisning fra dokument: huskortet viser en forenklet plan laget for skjerm, mens trykkfilen lastes ned bevisst, med ett klikk, når den besøkende allerede vet at dette huset er interessant.

#Hvem kommer tilbake, og hvor ofte

Ingen kjøper hus i én økt. Den samme personen kommer tilbake et titalls ganger over flere måneder og leter etter noe nytt hver gang: planen for første etasje, så avstanden til skolen, så byggebilder for å se hvor langt arbeidet er kommet. To krav følger av dette. Adressene til huskortene må være varige, for de havner i bokmerker og videresendes til familien. Og byggebildene må være raske og enkle å legge inn ofte, for det er de som er grunnen til at noen kommer tilbake.

Det andre kjennetegnet ved dette publikummet er utstyret. En stor del av besøkene kommer fra telefon, ofte med svakt signal, siden Jamno ligger helt i nordkanten av byen. Et nettsted som laster på ett sekund ved skrivebordet kan bruke mange ganger så lang tid i kanten av dekningen, og den besøkende skiller ikke operatørens feil fra nettstedets.

#Kartet og grensen for nytten av det

En Leaflet-modul viser feltet og omgivelsene med GeoJSON-data. Et kart på en utbyggers nettsted har én oppgave: å svare på hva som ligger i nærheten, og det er et spørsmål en skreven liste svarer dårligere på enn en tegning gjør.

Det er verdt å vite hvor grensen går. Et vektorlag med mange punkter kan låse grensesnittet på en svakere telefon, fordi nettleseren prøver å tegne alt før den gir kontrollen tilbake. Å begrense datamengden til de faktiske omgivelsene og laste kartet først når den besøkende ruller til seksjonen, koster én ekstra forespørsel og sparer flere sekunders hakking ved første åpning. Det er den typen avveining som ser unødvendig ut på rask linje og avgjør om noen blir værende på en treg.

#Tre lag med hurtiglager, og hva som tømmer dem

Mellomlagring skjer på flere nivåer, og hvert nivå tar seg av sin type forespørsel. Cloudflare i kanten leverer statiske filer og anonyme sider, altså praktisk talt all søketrafikk. Varnish foran applikasjonen holder ferdig sammensatte huslistevisninger som koster flere databasespørringer å bygge. Redis korter ned de samme spørringene for alt som uansett må innom PHP.

Tre nivåer på et nettsted av denne størrelsen høres overdrevet ut, helt til man ser på hva som endres og hvor ofte. Beskrivelsen av en hustype endres ikke på et år. Tilgjengelighetsstatusen for ett hus endres den dagen kontrakten signeres, og selgeren forventer at nettstedet viser det med en gang. Lå alt i samme bøtte, ville hver statusendring også kastet ut innholdet som ikke endrer seg, og hurtiglageret ville i praksis ikke eksistert.

Derfor er tømmingen punktvis og knyttet til lagringshendelser på bestemte poster, ikke global. Den enkeltfeilen jeg oftest ser i slike leveranser, er nettopp et hurtiglager som teknisk fungerer og tømmes hver gang hva som helst lagres. Oppsettet ser riktig ut, loggen viser treff, og serveren regner likevel ut alt på nytt flere titalls ganger om dagen.

#Skjemaet og det som skjer med en henvendelse

Skjemaet samler henvendelser om et bestemt hus eller en hustype, med validering på serveren og vern mot søppelpost. Validering i nettleseren er en bekvemmelighet for den besøkende og ikke en kontroll, så den samme regelen kjøres en gang til på serversiden.

Noe annet betyr likevel mer: en henvendelse må vite hvor den kom fra. En melding som sier “ta kontakt”, uten opplysning om at den ble sendt fra huskortet for Oslo, tvinger selgeren til å ringe tilbake for å stille et spørsmål nettstedet allerede kjente svaret på. Huskonteksten legges derfor ved automatisk, og en kopi skrives til databasen uavhengig av om utgående e-post gikk gjennom. E-postservere er utilgjengelige i noen minutter fra tid til annen, og det er ingen grunn til at en henvendelse skal forsvinne sporløst.

#Sikkerhetskopier og oppdateringer, den kjedelige delen som redder prosjektet

Sikkerhetskopiene går til objektlagring hos AWS, kryptert og med rotasjon. Her kommer det som vanligvis forblir usagt: en sikkerhetskopi som aldri er gjenopprettet, er en hypotese og ikke en sikring. At filene finnes i skyen, garanterer ingenting før noen har kontrollert at databasedumpen lar seg importere, og at mediefilene fulgte med og ikke bare tabellene.

Det andre kjedelige og avgjørende punktet er rekkefølgen på oppdateringer. Kjerne og utvidelser oppdateres først i et testmiljø, og det er ikke rituell forsiktighet. På et nettsted med eget tema og egne innholdstyper er det temaet, ikke WordPress-kjernen, som sprekker ved et versjonshopp, som regel akkurat der en mal antok en datastruktur en utvidelse nettopp har endret.

#Hva som bevisst ble utelatt

En prosjektbeskrivelse uten dette avsnittet er en brosjyre. Vi bygde ingen konfigurator for innvendig standard, selv om ideen kom opp ved hvert byggetrinn. En konfigurator gir mening når alternativene er tellbare, dokumentert ett sted hos kunden og lar seg prise uten å ringe en selger. Med fire hustyper og individuelt forhandlet innredning ville verktøyet gitt tall som uansett måtte bekreftes, altså det motsatte av det den lover.

Vi bygde heller ingen reservasjon på nett. I eiendom er en reservasjon uten innbetaling ikke en reservasjon, men en kø, og en offentlig synlig kø skaper flere konflikter enn salg. Tilgjengelighet er derfor informasjon og ikke en handling, og et menneske hos utbyggeren endrer den.

Det tredje som ble utelatt, er uttalelser fra beboere. Fristende, men i et felt der første byggetrinn omfattet seks hus, er enhver publisert uttalelse per definisjon mulig å knytte til en bestemt familie. Nettstedet viser byggefremdrift og bilder av ferdige hus i stedet, som sier det samme uten å be noen om å stå frem offentlig.

#Teknisk støtte, holder harmoni

Osiedlenorweskie.pl er ikke en engangs skisse, det er et nettsted som krever kontinuerlig stell. Kjerne og utvidelser oppdateres med testing utenfor produksjon og sikkerhetskopier hos AWS. Cloudflare, Varnish og Redis holder ytelsen i sjakk, og oppsettet deres gjennomgås når formen på innholdet endres, for det er innholdsendring og ikke tidens gang som ødelegger en hurtiglagerstrategi. Lastekvaliteten overvåkes, databasespørringer justeres og hurtiglageret tømmes når tilbudet endres.

Nettstedet kan utvides, for eksempel med en virtuell rundtur, en kobling mot et salgssystem eller en modul for tilgjengelige hus oppdatert fra ett sted. Hver av delene begynner med det samme spørsmålet, nemlig hvor mye innhold som faktisk må vedlikeholdes etterpå, for det er dette og ikke koden som skaper kostnad i år to.

For et boligprosjekt er det nyttig å beskrive boligtyper, beliggenhetsdata, mediemateriale, salgsflyt, integrasjoner og forventninger til vedlikehold skriftlig først.