Skal du flytte ditt nettsted?

Du forbinder kanskje flytting med flyttebil, esker fra IKEA, bæring og kasting av eiendeler som du ikke lengre trenger. Det er det praktiske. Så er det det administrative. Skatteetaten og Posten må få beskjed om at du flytter. Det finnes tjenester, som Flytteportalen, som hjelper oss i å formidle til andre at vi har beveget oss fra A til B.

Et burikkvindu som sier at forretningen har flyttet.
Et burikkvindu som sier at forretningen har flyttet.

For bedrifter er det viktig å fortelle kundene at man har flyttet og ikke minst hvor man befinner seg. Dette gjøres i butikkvinduer, i e-poster eller SMS-er, og ved å oppdatere digitale tjenester som egne nettsider og bedriftskataloger. Det beste for kundene ville vært en teleport, slik at man slipper å lete etter den nye adressen. Dessverre er teleportering kun noe som finnes på film, og det er ingenting i fysikkens verden som tilsier at dette kommer til å bli laget. På nett har vi luksusen av å faktisk «teleportere» kundene som kommer på «døra» til direkte til den nye «butikken» – uten at de merker det.

Flyttemelding til Google

Når man flytter et nettsted fra en publiseringsløsning til en annen, eller fra et domene til et annet, er det dessverre lett å glemme å sende «flyttemelding». Nettsider er indekserte i søkemotorer, lagret som bokmerker, og det finnes lenker til dem rundt omkring på det store nettet.

Skjermbilde av en 404-side hos Ryanair
Eksempel på en feilmelding hos Ryanair. Besøk med feilmeldinger konverterer dårlig. Unngå å gi kundene dine slike.

Manglende «flyttemeldinger» resulterer i feilmeldinger, ofte av typen 404. Noen er kryptiske. Noen er behjelpelige. Ingen liker feilmeldinger. Et besøk som starter med en feilmelding er et dårlig utgangspunkt. Et nettsted jeg jobber med har fire KPI-er. Det skal selge medlemskap, gavemedlemskap, informere om tjenester og skaffe ny salgsmuligheter. Deres feilside er pen, og har en gjennomtenkt tekst. Likevel konverterer 0 % av de besøkende som opplever en feilmelding, enten som første side eller i løpet av besøket sitt. Det er fordi feilmeldingen er felles for alle sider. Den forteller ikke noe om hvor den ny informasjonen kan finnes. Det blir som å skrive «Vi har flyttet» i et butikkvindu uten å skrive adressen. Google liker heller ikke når en URL-struktur plutselig er endret uten at de har fått beskjed.

Det kan gå galt

Et eksempel på dette var da Ryanair i 2014 lanserte sine nye nettsider. De hadde jobbet hardt for å forbedre bestilling av billetter. Enklere grensesnitt. Færre klikk. Kortere vei til mål. Før lanseringen var de høyt oppe i Google sine søketreff. For noen destinasjoner var de helt øverst. Etter lanseringen hadde rangeringen falt drastisk. Der de tidligere lå helt i toppen lå de nå ikke engang på topp 100. De gikk glipp av millioner av månedlige besøk og billettsalg. Årsaken var at de hadde glemt å sende «flyttemelding».

Husk å lag videresendinger

En fysisk flytting er fra A til B. Ferdig. På nettsider er det ikke så enkelt. Hver eneste underside og artikkel trenger sin egen lille «flyttemelding».

Selv om fysiske teleporter ikke finnes har vi digitale teleporter. Eller videresendinger som det heter. Google anbefaler å bruke slike.

Tenk deg at Norwegian kjøper Ryanair. Innhold på ryanair.com skal flyttes til norwegian.com. Flyttejobben settes i gang. ryanair.com, altså forsiden, videresendes til norwegian.com. Det er den enkle delen av jobben. Hva med trafikk som går til Ryanairs gavekort? Skal vi sende disse besøkende til Norwegians forside? Nei, da må brukeren på ny lete seg frem til seksjonen om gavekort hos Norwegian. Vi ønsker ikke at brukerne må tenke unødvendig. Det er mye bedre å «teleportere» dem direkte til gavekort hos Norwegian.

1000 videresendinger i siste liten

For store nettsteder kan det bli mange slike videresendinger fra A til B. Hundrevis og noen ganger tusenvis. Ofte kan vi slå flere videresendinger i sammen ved hjelp av regulære uttrykk. Hvordan videresendinger lages kan du lese mer om hos Moz. Selv om ditt CMS har funksjonalitet for å sette opp dette, anbefaler jeg at du heller setter dem opp direkte på webtjeneren. Da er det lettere å beholde dem om du skal bytte CMS.

I mange av prosjektene jeg har vært involvert i blir dessverre slike videresendinger glemt. Kunden har ikke spurt om det, og vi som leverandør har ikke estimert det i vårt tilbud. Da er det frustrerende å bli spurt om SEO noen dager før lansering:

«Er det noe vi bør tenke på før lansering?»

«Ja, vi må sende 1000 flyttemeldinger til Google.»

Ikke glem å teleportere kundene dine. Ikke gi dem låst dør og beskjeden «Eksisterer ikke» når de kommer til butikken din.

Har du forresten lest artikkelen Ta kontroll på feilmeldingene dine?

Feilmeldinger satt i system

Webutvikling i dag er preget av rammeverk og biblioteker. Det er ganske naturlig. Ingen grunn til å finne opp hjulet hver gang. Jeg savner likevel et bibliotek for feilmeldinger. Vennlige, forklarende, og løsningsorienterte feilmeldinger.

På nett blir vi ofte servert feilmeldinger. Noen er kryptiske. Noen er uhøflige. Noen er misvisende. Du kjenner deg igjen?

Volkswagen gir feilmelding at kilometerstand er ugyldig.
Volkswagen synes ikke 12 000 er en gyldig kilometerstand.

På VW sine nettsider skal jeg bestille en time på verksted. I det første feltet registreringsnummer, skriver jeg feil med vilje. VW gir meg feilmeldingen «Ugyldig registreringsnummer». Helt greit, men hvorfor ikke fortelle meg hva som er ugyldig med den? I en menneskelig dialog ville dette vært helt naturlig. En feilmelding skal komme med forslag til løsning. Det er faktisk lovpålagt. Vi skal tilfredsstille krav om universell utforming. WCAG 3.3.3 sier:

Forslag ved feil: Hvis en inndatafeil oppdages automatisk og det finnes forslag til hvordan den kan rettes, presenteres forslagene for brukeren, med mindre dette innebærer risiko for sikkerheten eller formålet med innholdet. (Nivå AA). Kilde: W3C.

I dette eksempelet ville jeg skrevet feilmeldingen: «Et registreringsnummer består av to bokstaver og fem tall. Du har kun skrevet inn én bokstav, og da klarer vi ikke å søke opp bilen din. Prøv igjen.»

Volkswagen gir feilmelding at kilometerstand er ugyldig.
VW sine feilmeldinger i forbedret versjon. Bedre?

I det neste feltet, Ca. kilometerstand, skrev jeg ikke inn feil med vilje, men fikk likevel feilmeldingen «Oppgitt ca. kilometerstand er ugyldig». Hele to ganger. Tallet 12 000 ble skrevet med mellomrom som tusenskille, slik vi skal gjøre på norsk. Da jeg tok vekk mellomrommet forsvant feilmeldingen. Her burde selvfølgelig skjemaet vasket vekk dette mellomrommet, og ikke servert meg feilmelding. Det er en annen diskusjon, å lage så «smarte» skjemaer at vi minimerer sannsynligheten for å måtte vise en feilmelding.

Hva vil jeg med dette? En hver datatype har regler. For registreringsnummer har vi kun én regel – to bokstaver og fem tall. Det finnes riktignok varianter for veteranbiler og tilhengere, men i dette eksempelet forholder vi oss til normalen. Andre land har andre regler. Andre datatyper har flere regler. E-postadresser er litt mer komplekse. Dess flere regler, dess flere mulige feilmeldinger bør en datatype ha. For registreringsnummer kan jeg komme på noen potensielle feilmeldinger:

  • Et registreringsnummer består av to bokstaver og fem tall. Du har kun skrevet inn én bokstav, og da klarer vi ikke å søke opp bilen din. Prøv igjen.
  • Et registreringsnummer består av to bokstaver og fem tall. Du har kun skrevet inn fire tall, og da klarer vi ikke å søke opp bilen din. Prøv igjen.
  • Du har skrevet inn bokstavene VA. Denne bokstavkombinasjonen har vi ikke i Norge. Har du skrevet inn feil? Prøv igjen.

Listen fortsetter, og for noen datatyper kan den bli lang. Veldig lang. VW og alle andre bilverksteder og bilforhandlere i landet har behov for en slik liste, for å kunne gi sine kunder gode feilmeldinger som foreslår konkrete løsninger. Hva om VW her kunne hentet disse feilmeldingene fra et bibliotek, i stedet for å finne dem selv? Det blir sjelden gjort, og kundene blir oppgitte, frustrerte og forbanna – og skriker «jävla skitsystem». Vi trenger et bibliotek for gode feilmeldinger. Slik at det blir lettere for meg å lage gode kundeopplevelser hver gang jeg setter opp et skjema.

E-postadresse med komma gir en feilmelding i Chrome.
E-postadresse med komma gir feilmelding i Chrome.
E-postadresse med komma gir ikke feilmelding i Safari.
E-postadresse med komma gir ikke feilmelding i Safari.

Datatypen e-post er langt vanligere enn registreringsnummer. Derfor er den definert som en egen type i HTML 5. Koden <input type=»email»> forteller nettleseren at feltet kun skal inneholde en e-postadresse. Dette har Chrome utnyttet. De smarte hodene hos Google har altså laget en lang, lang, liste med ulike feilmeldinger for e-post. De har sitt eget bibliotek. Disse serveres til brukeren uavhengig av hvilke validering som er lagt inn i skjemaet av utvikleren som har laget det. Selv den beste kan gjøre feil. Jeg ville bestille en reise med Hurtigruten. Med vilje skrev jeg inn komma i stedet for punktum i min e-postadresse. Dette snappet Chrome opp, og ga meg den behjelpelige feilmeldingen «En del etterfulgt av «@» kan ikke inneholde symbolet «,».». Bra Chrome! Jeg ville nok skrevet det litt enklere, men de får sagt det viktigste – symbolet komma er ikke gyldig. Prøver jeg det samme i Safari får jeg ingen feilmelding, og jeg er da avhengig av at Hurtigruten sjekker om adressen er gyldig før jeg sender inn skjema et.

SAS gir feilmeldingen: feil med fødselsdato, ÅÅÅÅ-MM-DD.
SAS gir feilmeldingen «feil med fødselsdato, ÅÅÅÅ-MM-DD».

I registreringsskjemaet til SAS glemmer jeg å velge dag i min fødselsdato. Dato er på samme måte som e-post en vanlig datatype som har en egen type i HTML 5. Dette har tydeligvis ikke SAS fått med seg, verken på feltet for e-post, telefon eller dato. Det gjør at Chrome ikke har muligheten til å gi meg konkrete feilmeldinger. I stedet prøver SAS å gjøre denne jobben selv. Det får de ikke helt til. «feil med fødselsdato, ÅÅÅÅ-MM-DD» er misvisende. Skjemaet er satt opp med år til slutt, ikke først. Det er et godt valg av SAS å ha denne rekkefølgen i skjemaet, men de må få kontroll på feilmeldingene sine. De trenger et bibliotek, slik at de slipper å snuble.

Det er mange fordeler med å sette riktig datatype i HTML-skjemaer. For eksempel vil mobilene våre velge riktig tastatur.

Eksempler på suksess-, info-, advarsler, og feilmeldinger i Bootstrap.
Bootstrap har ulike visninger av suksess-, info-, advarsler, og feilmeldinger.

Vi kan bruke rammeverk som Bootstrap til å stile våre feilmeldinger. Skjemaguru Luke Wroblewski kan lære oss hvordan skjemaene bør oppføre seg. Hva som skal stå i de røde boksene, det må vi foreløpig finne ut selv.

Skal jeg lage dette biblioteket? Vil du bidra? Hvor begynner vi?

Ta kontroll på feilmeldingene

Nylig fikk jeg høre at én av våre kunder hadde uttalt til en av våre selgere at de ikke hadde behov for UX. Det er godt kjent at det ofte settes et likhetstegn mellom begrepet UX (brukeropplevelse) og UI (brukergrensesnitt). I dette tilfellet var sannheten at de ikke ønsket designere av brukergrensenitt. Vår bransje har mye av skylden i dette, ettersom vi lett slenger rundt oss med fagbegreper uten å nødvendigvis tenke betydning.

Her kommer jeg med en liten historie fra virkeligheten som viser en annen side av UX-faget. Det handler om feilmeldinger. Feilmeldinger gir normalt sett ikke en god brukeropplevelse. Vi har tiltak for å gjøre dem bedre – det er viktig å skrive dem så hyggelige og forståelsesfulle som mulig, og selvfølgelig alltid med et forslag til løsning. Vær ydmyk, ikke legg skylden på bruker din. Rådene er mange.

Det beste er åpenbart å unngå at feilmeldingene oppstår. Det er god brukeropplevelse. En viktig hygienefaktor. Den kanskje vanligste feilmeldingen på et nettsted er 404-feilen. Brukeren havner på en adresse som ikke finnes. Det kan være at akkurat den siden er fjernet, eller at adressen inneholder en skrivefeil. Har du ansvar for et nettsted bør du ha kontroll på disse 404-sidene. Hvor oppstår de, og hvorfor. Dette er lette feil å fikse, og svaret får du i Google Analytics.

Oh no, the page is missing!
Eksempel på en god og ydmyk feilmelding. Skjermbilde fra boagworld.com.

Hver uke sjekker jeg antall 404-feil på et større nettsted jeg jobber med. Jeg har også satt opp varsling som sender meg e-post dersom det plutselig tar seg opp. Da jeg begynte overvåkningen lå antall feil i uken på 200–300. Plutselig en uke steg det til 1800. Neste uke ble det 2700. Feilen lå i et underliggende datasystem som snublet. Det tok noen uker å fikse feilen. I løpet av perioden ble det vist 19000 feilmeldinger. Det er potensielt 19000 misfornøyde kunder som ikke får gjort det de kom for å gjøre. I etterkant ble det også rettet i andre mindre feil, og nå er vi nede i 10–20 feil i uken. Her har vi jobbet med å forbedre brukeropplevelsen, men kun med et analyseverktøy, et regneark og en publiseringsløsning. Ikke grafisk arbeid i det hele tatt.

Har du kontroll på feilmeldingene dine?