Travel & Tourism Site: car-mechanic-huntington.co.uk

#car-mechanic-huntington.co.uk, profesjonell nettside for et bilverksted

Prosjektet car-mechanic-huntington.co.uk presenterer tjenestene til et bilverksted og lar besøkende bestille time. Målgruppen er bileiere i nærområdet, folk som jakter på en bestemt feil, og små bedrifter som holder noen få biler i drift. Nettstedet gikk i produksjon i 2012, og arbeidet tok omtrent seks uker.

#En gammel nettside etterlater adresser, ikke bare tekst

Dette var ikke et blankt ark. Verkstedet hadde en eldre nettside, og deler av innholdet fantes bare som arkiverte kopier, som vi hentet tilbake via Web Archive. Den delen av jobben folk husker er teksten. Den delen som pleier å bli hoppet over, er adressene.

En nettside som har stått ute i noen år, har lenker i lokale kataloger, i bransjeoversikter og i e-poster som allerede er sendt til kunder. Ingen av dem kommer til å bli oppdatert av noen. Derfor trenger hver gamle URL en bestemt ny URL og en permanent videresending, ikke en samlet omdirigering til forsiden. Den samlede varianten ser fin ut i nettleseren, fordi det ikke dukker opp noen feilmelding, og den kaster samtidig bort alt den gamle adressen hadde rukket å samle opp.

Det er verdt å si hvorfor jeg begynner her og ikke med funksjonene. En migrering er det eneste steget i et slikt prosjekt der man kan ødelegge noe som allerede virket. Alt annet legger til. Derfor er kartleggingen av gamle adresser den første oppgaven som blir ferdig, ikke den siste som blir husket.

#Time hos et verksted er ikke et skjemafelt

Bestillingsmodulen ser ut som et kontaktskjema med et datofelt. Den oppfører seg ikke i nærheten av det, fordi den deler ut noe det finnes en endelig mengde av.

Et verksted har ikke en kalender slik en rådgiver har en kalender. Det har løftebukker og det har mekanikere, og en time er en kombinasjon av begge over en varighet som avhenger av arbeidet. Et oljeskift og en sporadisk elektrisk feil legger beslag på svært ulike deler av en dag. En datamodell som lagrer en bestilling som dato og klokkeslett, ryker den første morgenen to personer vil ha klokken åtte og det finnes én bukk.

Derav følger avgjørelsen som hele modulen egentlig handler om. Tilgjengeligheten som vises i nettleseren, er et bilde av et øyeblikk som allerede er passert. Det går gjerne ti eller femten minutter mellom at listen tegnes og at knappen trykkes, fordi den besøkende først må finne ut om hen får fri. Kontrollen må derfor kjøre på nytt på serveren i det øyeblikket raden skrives, og den må kjøre på en måte som ikke slipper to forespørsler gjennom den samme ledige timen. Et grensesnitt som bare gråer ut opptatte tider, ser riktig ut og produserer dobbeltbooking første gang to personer er inne samtidig.

Den andre følgen gjelder mellomlagring. Det meste på en verkstedside er stabilt: tjenestebeskrivelser, veibeskrivelse, åpningstider. Slikt innhold kan ligge lenge i cache. Tilgjengelighetsvisningen er det stikk motsatte, siden hele verdien dens er at den er fersk. En konfigurasjon som mellomlagrer alt uten unntak, serverer villig et uke gammelt bilde av timeboken, og ingen merker det før en kunde står foran en stengt port. Bestillingsvisningen er derfor holdt utenfor cachen med vilje, ikke ved et uhell.

Og til slutt grunnen til at dette ble skrevet fra bunnen i stedet for satt opp med en ferdig utvidelse. Bestillingsutvidelser modellerer stort sett en frisør eller en klinikk: én behandler, én stol, én fast lengde. Å bøye den modellen til å ta en akse til og en varierende varighet koster mer enn å skrive skriveveien selv, og det etterlater andres antakelser nøyaktig der en feil antakelse ender med en kunde som fikk klokken ni og ikke slipper inn.

#Nøkkelfunksjoner og benyttede teknologier

Det responsive oppsettet setter det folk faktisk trenger på telefon først: nummer, adresse og veibeskrivelse. Tilbudsteksten kommer etterpå, fordi spørsmålet om et verksted som regel stilles fra en parkeringsplass eller en veikant, ikke fra et skrivebord.

Det er også verdt å plassere dette i tid. I 2012 var responsivt oppsett en egen post i leveransen og ikke en selvfølge. Flexbox var ikke i alminnelig bruk og CSS Grid fantes ikke, så kolonner ble satt med flytende blokker og bruddpunktene valgt mot faktiske skjermbredder på telefonene folk gikk rundt med. Der kommer rutenettet fra Bootstrap inn: ikke som mote, men fordi alternativet var å skrive det samme selv og deretter vedlikeholde det alene i årevis.

Integrasjonen mot sosiale medier henter innlegg og omtaler inn på siden. Her gjør et nettsted seg avhengig av en server ingen her rår over, så oppførselen ved svikt måtte avklares mens det ble bygget. Svarene mellomlagres, og når kilden ikke svarer, viser seksjonen siste kjente innhold eller ingenting. En tom boks med feilmelding på forsiden til et verksted leses som at hele nettstedet er nede, ikke som at et fremmed grensesnitt har en dårlig ettermiddag.

Søkearbeidet hvilte på semantisk HTML5, ryddige metadata og strukturerte data som beskriver en lokal virksomhet. For en lokal tjeneste teller tre ting mest i maskinlesbar form: navn, adresse og telefonnummer i én uforanderlig skrivemåte, åpningstidene, og området som betjenes. Avvik mellom adressen på nettstedet og adressen i eksterne oppføringer er en klassisk langlivet defekt, nettopp fordi begge versjonene ser greie ut for et menneske.

WordPress som redigeringsflate har en konkret begrunnelse hos denne kunden. Et verksted har ingen redaksjon. Endringer gjøres av eieren eller av den som sitter på kontoret, mellom to oppdrag, så det å endre åpningstider må være mulig uten teknisk kunnskap og uten noen risiko for å rive ned oppsettet.

#Kartet er det dyreste elementet på kontaktsiden

Et innebygd kart bestilles av kunden i en halv setning, og det koster mer enn resten av kontaktsiden til sammen.

Det er fremmed skript, fremmede stiler og en rekke forespørsler etter bildefliser, alt fra infrastruktur utenfor vår kontroll. På et lite nettsted er denne ene komponenten rutinemessig tyngre enn alt innholdet på siden. Den kjører også for hver eneste besøkende, også for den som kom for et telefonnummer og er borte etter ti sekunder.

Løsningen er å ikke laste det sammen med siden. Standardvisningen er et statisk bilde med stedet markert og adressen som tekst ved siden av, mens det interaktive kartet starter først når noen tar på det. Den som trengte adressen, har den umiddelbart, og den som vil ha kjørerute, bruker ett trykk til og får hele verktøyet. Rekkefølgen er den omvendte av den intuitive, og det er nettopp derfor den tunge varianten så ofte havner som standard.

#Telefonen vinner over skjemaet, og det må designet tåle

Et bestillingsskjema på en verkstedside konkurrerer ikke først og fremst med andre verksteder. Det konkurrerer med telefonnummeret på samme side. En del av kundene kommer aldri til å fylle ut noe som helst, fordi de har et symptom de ikke klarer å sette navn på, og en samtale løser det på tretti sekunder mens et skjema krever at de velger en tjeneste fra en liste de ikke forstår.

Det betyr to ting for hvordan siden er bygget. For det første er nummeret en lenke som starter en samtale på telefon, og det ligger over bretten i den mobile visningen, ikke i bunnteksten. For det andre har skjemaet en vei ut for dem som ikke vet hva de skal velge: et felt for fritekst der man kan beskrive lyden bilen lager, i stedet for en obligatorisk nedtrekksliste over tjenestetyper. En liste som tvinger et valg produserer enten feil valg eller ingen henvendelse, og verkstedet oppdager bare det første av de to.

Den samme tankegangen styrer hva som skjer etter innsending. Bekreftelsen sier hva som skjer videre og hvor lenge det tar, ikke bare at meldingen er mottatt. En kvittering uten neste steg får folk til å ringe likevel for å høre om det gikk gjennom, og da har skjemaet lagt til arbeid i stedet for å fjerne det.

#Utfordringer og programmeringsløsninger

Sidevekten ble angrepet tre steder: bildekomprimering, mellomlagring av innholdet som sjelden endres, og reduksjon av antall stil- og skriptfiler. Det siste hadde en vekt i 2012 som det ikke har nå, fordi nettlesere åpnet en forbindelse per fil mot en lav grense for parallelle nedlastinger. Å slå ti stilark sammen til ett var ingen kosmetikk den gangen, det fjernet ni rundturer til serveren.

Personaliserte moduler sto i direkte motstrid til mellomlagring, siden cache lønner seg nettopp fordi mange besøkende får det samme dokumentet. Løsningen ligger i å skille de to: sidens skjelett og tjenestetekstene er felles og mellomlagres, mens de besøkeravhengige fragmentene hentes separat etter at siden er lastet. Uten det skillet ugyldiggjør enhver personalisering cachen for hele nettstedet, og da må man velge det ene eller det andre.

#Verktøy og teknologier

WordPress som redigeringsflate, PHP og MySQL på serveren, HTML5, CSS3 og JavaScript i presentasjonslaget, rutenett og komponenter fra Bootstrap for det responsive oppsettet, i tillegg automatiske sikkerhetskopier, versjonskontroll på koden og oppfølging av synligheten i søk. Ordet sikkerhetskopi bærer det samme forbeholdet her som overalt, for en kopi ingen noensinne har tilbakeført er en fil og ikke en sikring, og tilbakeføringen må være gjennomført minst én gang i et eget miljø, siden hullene bare viser seg da og det som regel haster i det øyeblikket.

Utvidelser fortjener en egen merknad. Funksjonelle utvidelser brukes der de gjør nytte for seg. Sikkerheten hviler derimot ikke på en utvidelse, for en sikkerhetsutvidelse er kode inne i applikasjonen den skal beskytte. Den begynner å virke først når forespørselen allerede har nådd den applikasjonen. Å filtrere trafikk foran applikasjonen, holde kjernen oppdatert, begrense tilgangen til administrasjonen og ha en prøvd sikkerhetskopi gir mer enn et panel som teller blokkerte innloggingsforsøk.

#Support og vedlikehold på WordPress

Vedlikeholdet er en liste med en ytterkant, ikke et åpent løfte.

Det dekker feilretting, installasjon av oppdateringer for kjerne, tema og utvidelser, gjennomgang av logger, sikkerhetskopier etter avtalt regel og mindre endringer i innhold og utseende. Det inneholder ingen garanti for at en oppdatering aldri ødelegger noe, for den garantien kan ikke gis av et nettsted satt sammen av byggeklosser som vedlikeholdes av uavhengige team. Det inneholder derimot at endringer kjøres utenfor produksjon først, og at veien tilbake er forberedt før den trengs i stedet for improvisert mens telefonen ringer.

Et nettsted med bestillingsmodul får i tillegg en plikt en ren informasjonsside ikke har. Enhver oppdatering som berører skjemabehandling eller datohåndtering, testes mot en kopi av produksjon med reelle bestillinger. Grunnen er triviell og ikke prinsipiell. På en tom installasjon er timeboken alltid ledig, så ingen test treffer veien der modulen faktisk kan ryke. Den veien består av kollisjoner mellom to forespørsler om samme tid og av randtilfellene ved grensene av en arbeidsdag.

Av samme grunn ligger vedlikeholdsvinduene utenfor åpningstiden. Et bestillingsskjema som ikke svarer akkurat når noen vil ha time, koster en jobb og ikke en sidevisning. Det regnestykket avgjør også hvilke endringer som venter på neste planlagte vindu og hvilke som er verdt å gjøre samme dag. Verkstedet merker forskjellen i kontoret, ikke i statistikken.

#Oppsummering og foreløpig analyse av kundekrav

Planleggingen begynte med spørsmål som måtte besvares før noe ble bygget. Hva nettstedet er til for og hvem det betjener, og hva som allerede sto på kundens kravliste, altså bestilling, kobling mot sosiale profiler og innhold tilpasset den besøkende. Hvordan det skulle kobles mot den eksisterende databasen, hva tidsplanen tillot og hvilke eksempler kunden ville peke på. Hvor mye av den gamle siden som skulle videreføres, og hva budsjettet ga rom for, som er spørsmålet som avgjør om et omfang leveres i ett eller i etapper.

Svarene satte rekkefølgen. Først det folk kommer til en verkstedside for, altså tjenester, veibeskrivelse og kontakt, så bestillingen, som er det mest sammensatte elementet og det eneste som faktisk endrer hvordan kontoret jobber, og til slutt de eksterne integrasjonene, som er minst kritiske og enklest å legge til etter lansering.

Det som følger med videre, er arbeidsmåten. Tilgjengeligheten av en endelig ressurs kontrolleres på serveren i skriveøyeblikket. Tidsavhengige visninger holdes utenfor cachen, tunge fremmede komponenter utsettes til noen ber om dem, og gamle adresser kartlegges én for én ved migrering. Det som ikke følger med, er innholdsmodellen og integrasjonene i dette prosjektet, skrevet for ett verksted og en brief i kategorien Nettsider. Den som har mest igjen for denne arbeidsmåten, er kontoret som slipper å ringe tilbake for å flytte en dobbeltbooket time. Et nytt prosjekt begynner derfor med en analyse av omfanget, og tilbudet kommer etter den.