E-handelsutvikling: QUALITY WATCH

#Innholdsmodellen kom først, designet etterpå

De fleste nettstedprosjekter starter med et utseende og finner ut av datamodellen underveis. Her gikk det motsatt vei, og det var riktig. Quality Watch selger seks tjenester som overlapper hverandre, og hele vanskeligheten i prosjektet lå i hvordan de skulle skilles fra hverandre uten å bli seks nesten like sider.

Quality Watch er et Warszawa-basert analysebyrå. Den registrerte hovedvirksomheten er marked og opinionsundersøkelser, og den mest kjente delen av tilbudet er Mystery Shopping, ved siden av tilfredshetsundersøkelser og kunnskapstester for service og salgspersonale. Nettstedet ble bygget i 2016 og 2017 og tok omtrent seks uker, på WordPress med et eget tema.

#Seks navn, én mekanisme

Legg tjenestenavnene ved siden av hverandre, så ser man problemet med én gang. Mystery Shopper, Mystery Client, Mystery Caller og Mystery E-mail beskriver den samme undersøkelsesmetoden brukt på fire ulike kontaktkanaler. Kundereisekartlegging og kvalitetsrevisjon er noe helt annet, kjøpt av en annen budsjetteier over et annet tidsrom. En side som slenger alle seks inn i én punktliste, forteller leseren at selskapet gjør mange ting og ingenting bestemt.

Derfor skiller modellen metode fra anvendelse. Metoden er én post og beskriver mekanismen: hvem som observerer, i hvilken rolle, hva som noteres og i hvilken form resultatet kommer tilbake. Anvendelsen er en egen post og beskriver bransjesammenhengen. Malen setter dem sammen først når siden vises.

Prisen for dette er reell og bør sies rett ut. Redaktøren må forstå oppdelingen før hun skriver noe nytt, og et uvanlig enkelttilfelle er tregere å publisere enn et ferdig avsnitt hadde vært. Gevinsten kommer rundt den femtende varianten, altså etter omtrent et år. Alternativet, én lang side med trekkspill, holder helt til byrået begynner å selge den samme metoden inn mot flere bransjer. Da skiller varehandelsteksten og bilbransjeteksten seg i tre avsnitt av tjue, og vedlikeholdt hver for seg gir de tre steder der én rettelse må gjøres tre ganger.

#Anonyme referanser som normaltilstand

Kasusbeskrivelsene krevde mest avklaring, og nesten alt av det foregikk utenfor koden. Et analysebyrå arbeider med data det som regel ikke får navngi. Posten behandler derfor den anonyme versjonen som normaltilstanden og ikke som unntaket: bransje og nettverksstørrelse er egne felt, merkenavnet er valgfritt. Når merkefeltet står tomt, lar malen være å etterlate et hull der en logo skulle stått, den setter kortet annerledes. Det høres ut som en detalj helt til halve referanselisten har tomt felt.

Det samme prinsippet gjelder tallene i kasusbeskrivelsene. Der kilden ikke kan navngis, kan heller ikke resultatet etterprøves, og da hører det ikke hjemme på siden som en påstand. Strukturen gjør det mulig å beskrive omfanget av et oppdrag, altså hva som ble undersøkt og hvordan, uten å påstå noe om utfallet som leseren ikke har mulighet til å kontrollere.

#Hvem leser dette, og hva det betyr for koden

Den som bestiller en servicekvalitetsundersøkelse, er sjelden den som signerer. I praksis sitter det en kvalitetsleder eller en salgsdirektør der, og hun samler materiale for å overbevise noen andre. Det endrer kravene til nettstedet mer enn noen beslutning om farger gjør.

Teksten må tåle å bli løftet ut av nettleseren og limt inn i en intern presentasjon: hva metoden er, hvordan revisorene velges, hva rapporten inneholder, hvordan et besøksscenario ser ut. Derfor fikk hver metode sin egen varige adresse, sin egen H1 og sine egne strukturerte data. En lenke som skal leve i andres innboks i årevis, kan ikke peke på en side der mottakeren først må lete etter riktig fane.

Den andre følgen handler om lengde. Rådgivningsinnhold av dette slaget er langt av natur, fordi kunden vil vite hvordan et besøk i bilforretningen skiller seg fra en telefon til kundesenteret. Samtidig skal den samme siden kunne skumles på to minutter av noen som bare setter opp en leverandørliste. Løsningen er ikke å korte ned, men å legge innholdet i lag.

#AJAX og REST API på et presentasjonsnettsted

Under arbeidet møtte vi utfordringer med å integrere dynamisk innhold og presentere en bred tjenesteportefølje på en ryddig måte. Vi brukte AJAX-mekanismer og dedikerte REST API-endepunkter, som gjorde det mulig å laste inn informasjon jevnt og vise kasusbeskrivelser og kundeuttalelser interaktivt. I 2017 var ikke dette et opplagt valg for et presentasjonsnettsted, og jeg ville ikke anbefalt det generelt.

Her fulgte det av formen på tilbudet. Fordi tjenestene overlapper, leser ingen dem i rekkefølge. Noen åpner Mystery Shopping, går tilbake, sjekker Mystery Caller, sammenligner rapportomfang, går tilbake igjen. Med klassiske sideoppdateringer koster hvert av disse stegene en full syklus: ny forespørsel, fullstendig gjengivelse av malen, de samme ressursene hentet på nytt.

Kostnaden ved valget kan ikke skjules, og den har to deler. Hver filtertilstand trenger sin egen adresse, ellers kan ikke en besøkende sende en kollega det hun ser på, og en søkemotor indekserer ingenting utover standardvisningen. Og datalaget må virke uten JavaScript, fordi rådgivningsnettsteder åpnes i bedriftsmiljøer med streng nettleserpolicy. Grunnvisningen gjengis derfor på serveren, og den asynkrone veien korter bare ned turen der den er tilgjengelig.

Endepunktene gjorde nytte på en mindre synlig måte også. Kundeuttalelser og publiserte funn endres oftere enn selve tilbudet og går gjennom en annen intern godkjenning. Å flytte dem til en egen ressurs betydde at en oppdatering ikke lenger rører malene for tjenestesidene eller tømmer hurtiglageret deres.

#Ytelse målt mot en kopi av produksjon

Flaskehalsen i prosjektet var oppførsel under reell trafikk og tømming av hurtiglageret, ikke lastetiden på forsiden. Forskjellen betyr noe. En tom WordPress-installasjon med det samme temaet svarer raskt fordi det ikke er noe å regne ut: liten database, grunne relasjoner, en tjenesteliste som får plass i én spørring. Den samme koden mot en kopi av produksjon, med hele katalogen av metoder, anvendelser, kasusbeskrivelser og taksonomier, oppfører seg annerledes, fordi en filtrert liste berører flere tabeller samtidig.

Derfor ble trafikkveiene prøvd på en produksjonskopi og ikke på en ren instans. Regelen koster noen timers forberedelse og sparer en uke med overraskelser etter lansering. En produksjonskopi viser ting en tom installasjon ikke kan vise: en spørring som er usynlig ved tre poster og er sidens dyreste operasjon ved to hundre, eller et hurtiglager som teknisk virker, men tømmes hver gang noe som helst lagres, og dermed i praksis ikke finnes.

Den arkitektoniske spenningen ligger nøyaktig mellom hurtiglager og ferskhet. Tjenestesider kan mellomlagres hardt fordi de endres sjelden. Blokken med nyheter og uttalelser endres ofte, og redaktøren forventer å se endringen sin med det samme. Løsningen var å skille de to: skallet og tjenestesidene mellomlagres lenge, mens de flyktige fragmentene hentes i en egen forespørsel med kort levetid og tømmes per post ved lagring i stedet for globalt.

#Utformingen kom fra kunden

Plasseringen av elementene og det visuelle laget kom fra kunden. Vår del var å gjøre det om til maler, responsiv oppførsel og en innholdsmodell som lar seg vedlikeholde etter lansering. Estetikken var ikke omstridt, rekkefølgen på informasjonen var det.

Nettstedet er responsivt av en konkret grunn og ikke fordi det hører med: en stor del av trafikken er noen som har fått lenken på e-post og åpner den på telefonen mellom to møter. På en liten skjerm slutter rekkefølgen på seksjonene å være en smakssak, for den besøkende ser to skjermer og forstår enten hva selskapet driver med, eller går tilbake til innboksen. HTML5, CSS3 med SASS-preprosessor og JavaScript gir et ryddig oppsett og stabil oppførsel, men de avgjør ikke for noen hva som skal stå øverst.

Sammenligningstabellene fikk egen oppmerksomhet. Oppstillingen av undersøkelsesmetoder er hovedinnholdet på dette nettstedet, og en tabell der overskriftscellene ikke er knyttet til datacellene, er for en skjermleser en rekke ord uten struktur. Den koblingen er billig når malen bygges og dyr å ettermontere, så den kom inn med en gang.

#Skjemaer og det som skjer etter klikket

Dette nettstedet samler forespørsler om tilbud, ikke bestillinger, og det synes i koden. Et Mystery Shopping-oppdrag lar seg ikke prise ut fra tre felt, fordi summen avhenger av antall lokasjoner, besøk per syklus, kanaler som inngår, og om kunden vil ha én samlerapport eller en fordeling per sted. Et skjema som spør om alt med en gang, skremmer folk vekk. Et skjema som ikke spør om noe, gir henvendelser som bare kan besvares med et nytt spørsmål.

Kompromisset skiller førstekontakt fra kvalifisering. De obligatoriske feltene er korte, og utvidelsene dukker opp bare når den besøkende selv signaliserer at hun vet hva hun leter etter. Teknisk betyr det validering på serveren og ikke bare i nettleseren, fordi validering i nettleseren er bekvemmelighet og ikke en kontroll. Det betyr også et spamvern som ikke bygger på å skrive av tegn fra et bilde, siden hvert ekstra steg på veien her koster en henvendelse.

Én beslutning til hører hjemme her: lengdegrensen på meldingsfeltet ligger høyt nok til ikke å kutte en ekte henvendelse. Det ser trivielt ut og er det ikke. En kort grense klipper en melding midt i setningen, og avsenderen får aldri vite det, for hun ser bare kvitteringssiden. Den feilen dukker ikke opp i noen logg og ingen test, bare i en samtale som aldri fant sted.

#Strukturerte data og det søkemotoren ikke gjetter

Arkitekturen er forberedt for søk og strukturerte data, og med denne typen innhold betyr det noe konkret. En søkemotor skiller ikke av seg selv mellom beskrivelsen av en undersøkelsesmetode og en bloggartikkel om den samme metoden. Det er to ulike leserhensikter og hører hjemme i to ulike resultater. Å merke innholdstypen er billig når malen bygges, og nesten umulig å rette meningsfullt når femti sider allerede står i indeksen med feil type.

Det andre punktet gjelder navngiving. Selskapet bruker begreper som finnes i flere skrivemåter samtidig, fordi mange av dem er lånord fra engelsk som bransjen har tatt inn på ulikt vis. Siden må treffe leserens språk uten å spre det samme innholdet over fire adresser som bare skiller seg i en ordform. Løsningen var én kanonisk adresse per metode, og konsekvente varianter inne i brødteksten, i stedet for en egen side per skrivemåte.

Det tredje punktet handler om hva siden sier om seg selv til en maskin. Et kompakt faktakort i de strukturerte dataene beskriver hva denne leveransen var, hvilket omfang den hadde og hva den står på teknisk. Det koster noen linjer i malen og avgjør om en språkmodell som oppsummerer siden, gjengir omfanget eller dikter det opp ut fra overskriften.

#Det som ikke virket på første forsøk

En prosjektbeskrivelse uten dette avsnittet er en brosjyre. Den første versjonen av tjenestefilteret husket valget i adressen, men ikke rulleposisjonen. Den som åpnet en metode og trykket tilbake, havnet øverst i listen og måtte finne plassen sin på nytt. Med seks oppføringer merker ingen det. Med en liste som vokste til flere titalls oppføringer etter at bransjevariantene kom til, er det nøyaktig derfor noen slutter å bla.

Den andre rettelsen gjaldt bilder. Referansefotografiene ble lastet opp i den oppløsningen de kom i fra kunden, altså langt større enn noen visning på nettstedet. Størrelsesvarianter lages automatisk, men bare for filer lastet opp etter at riktig oppsett er på plass, så materiale flyttet fra det gamle nettstedet ble liggende med originalene. Det ble oppdaget ved å se på overføringsstørrelsen for en bestemt underside, ikke ved å måle forsiden, som tilfeldigvis var lett.

Det tredje punktet var ikke en feil, men et kompromiss jeg fortsatt mener var riktig. Vi droppet å tilpasse innholdet etter den besøkendes bransje automatisk. Det var teknisk gjennomførbart og hørtes forlokkende ut, men ville krevd å skille besøkende på et nivå der mellomlagring mister mening, og nytten ville først vist seg ved mangedobbel trafikk av det nettstedet faktisk har. Bransje er i stedet et valg den besøkende tar bevisst, i ett klikk, og det valget følger med i lenken.

#Teknisk vedlikehold etter lansering

For å holde tjenesten på nivået den ble levert på, tilbyr vi løpende teknisk vedlikehold med regelmessige oppdateringer, loggovervåking, systematiske sikkerhetskopier og fortløpende funksjonelle endringer. Oppdateringer går først til et testmiljø, for på et nettsted med eget tema og egne endepunkter er det nettopp temaet og endepunktene, ikke WordPress-kjernen, som pleier å sprekke ved et versjonshopp.

Det som lar seg føre videre fra dette prosjektet, er det tekniske laget: JavaScript, HTML5, CSS3, SASS og AJAX ser omtrent likt ut hver gang. Det som ikke lar seg føre videre, er innholdsmodellen og integrasjonene, fordi begge ble laget for én kundes data og ett oppdrag. Neste prosjekt starter derfor med en gjennomgang av omfanget, og tilbudet kommer etter den, ikke før.

Klient: Quality Watch
Omfang av arbeid: Webutvikling, layout

For mer informasjon, besøk nettstedet: qualitywatch.pl