Facebook dreper nettstedet ditt

Min kollega Remi får forespørsler fra bedrifter om å lage enkle nettsteder. Han spurte meg om han heller burde anbefale dem å lage en god Facebookside, i stedet for å lage en nettside som ikke blir vedlikeholdt.

Dette fikk meg til å tenke. Mange har utdaterte nettsider, men er flinke på Facebook. Kjenner du deg igjen?

Du er ikke alene.

Viral Media skriver:

Det er bedre å ikke være på Facebook i det hele tatt, enn å være der – men ikke være til stede. En «død» facebookside kan være mer skadelig for bedriften enn til nytte.

Mitt svar til Remi, var i samme gate:

Det er bedre å ikke ha nettsider i det hele tatt, enn å ha utdaterte sider som kan være mer skadelig for bedriften enn til nytte.

Terskelen for å oppdatere Facebook er lavere enn å logge inn i publiseringsløsningen som du verken husker passordet til, eller husker hvordan fungerer. Du velger minste motstands vei. På Facebook får du umiddelbar respons fra dine kunder med kommentarer og tomler. Valget er enkelt.

I Stavanger finner du Ullandhaug Økologiske Gård som i tolv år har solgt mat, miljøvennlige husholdningsprodukter og naturkosmetikk. De har en fin og oppdatert side på Facebook. Toppbildet viser et utvalg av varene. Jeg ser at tre av mine venner liker butikken, og jeg får lyst å ta en tur. Det er lenge siden jeg var der nå.

Skjermbilde av Facebooksiden til Ullandhaug Økologiske Gård.
Fine og oppdaterte sider på Facebook. Jeg får lyst å besøke Ullandhaug Økologiske Gård.

På Facebook lenker de til sitt nettsted mat-med-mening.no. Sidene ser ut til å være fra 90-tallet. Det står riktignok at de er oppdatert i dag. Jeg tviler.

Skjermbilde av nettstedet Mat Med Mening.
Nettstedet Mat Med Mening fremstår gammeldags og utdatert.

Mitt råd til Økologiske Dagligvarer vil være å legge ned nettsidene, og kun fokusere på å fortelle verden om sine gode og meningsfulle produkter på Facebook.

Kun Facebook?

Noen har erkjent at Facebook som sin primære kommunikasjonskanal. Tegneserien Nemi sender all trafikk fra nemi.no til sin Facebookside. Er dette et alternativ for deg?

Fordeler

  • Du slipper dårlig samvittighet for å ikke holde nettsidene i live.
  • Du sparer penger. Drift og vedlikehold av nettsider koster.
  • Du slipper å lære deg webfaget.

Ulemper

  • Du går glipp av trafikk fra Google.
  • Innhold du publiserer har kort levetid.
  • Skal du ha unikt innhold i egne undersider (tabber) må innholdet ligge utenfor Facebook, på en ekstern løsning.
  • Du har ikke full kontroll. Facebook eier deg, og plutselig har konkurrenten din annonser på din side.
  • Du satser alle kort på én kanal. Du vet ikke hva Facebook gjør i morgen.

Hva med Google?

Ved å utelukkende satse på Facebook vender du ryggen til Google. Det kan være en dårlig idé. Interessen for Google er stabil høy. Dersom du jobber i en nisje kan det være lurt å satse på Google. Jobber du i et lite selskap i en bransje med store, tunge konkurrenter, kan kampen om Google-trafikken være for tung.

Uansett hva du går for vil jeg uansett anbefale deg å bruke Google My Business. Da vil du bli synlig, uten å nødvendigvis ha et nettsted. Fra Google My Business kan du sende kundene dine til din Facebook.

Dine kunder bestemmer

Det er behovet til kundene dine som bestemmer hvilke kanaler du skal satse på. Du trenger ikke en egen nettside for å fortelle kunden om åpningstidene. Ei heller adressen og telefonnummeret ditt. Du trenger et nettsted hvis du har en portefølje eller et arkiv med referanseprosjekter du vil skryte om. Spør dine kunder og potensielle kunder – hva forventer de av din digitale tilstedeværelse? Hvor vil de finne deg?

Anbefalingen min er dessverre ikke klokkeklar. Har du et nettsted som kun inneholder tekst om selskapet ditt, kontaktinformasjon, åpningstider og et bildegalleri? Da kan du vurdere Facebook. Vil du over tid bygge opp mengder med godt innhold, såkalt innholdsmarkedsføring, som skal være søkbart i Google? Få deg et godt nettsted. Mål og optimaliser.

Noen tanker til slutt

Jeg lever av å lage nettsider. Mine kunder har ofte behov som er vanskelige å tilfredsstille gjennom Facebook. Jeg er òg skeptisk til at Facebook får mer og mer makt. Den åpne og frie webben lukkes sakte igjen. Hossein Derakhshan skriver (fritt oversatt):

Den rike, mangfoldige webben jeg elsket, er døende.

Jobber du med web, er hans artikkel obligatorisk lesning.

Hva mener du? Kan det være en god anbefaling å droppe nettsider, og heller satse på Facebook? Har du eksempler på bedrifter som sender trafikken fra domenet til Facebook?

Kilder

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?

Hotjar – automatiske brukertester

Få e-poster gjør meg så spent som når jeg får beskjed fra Hotjar at et nytt opptak er klart. Den store grønne knappen «View recordings» får hele min oppmerksomhet. Et kjapt museklikk sender meg inn til alle skjermopptakene jeg har bestilt. Da er det bare å finne frem notisblokken og skrible ned alle de gode ideene jeg får av å titte på video etter video etter video.

Hotjar?

Et knakende godt verktøy som hjelper deg til å bedre forstå dine besøkende ved hjelp av varmekart, skjermvideoer og små spørreundersøkelser. Jeg digger det. Det er riktignok ikke helt gratis, men e-postene det sender ut oppleves slik.

På nett jobber jeg for evolusjon, ikke revolusjon. Sider, maler skjema, tekster og prosesser skal forbedres. Kontinuerlig. Hele tiden. Hver uke kikker jeg på nye filmer. Akkurat nå har jeg 16075 skjermopptak liggende. Det er mange timer. Jeg må finne frem popcornet.

I dag fant jeg en film av en forvirret Lyse-kunde. Han er inne på artikkelen «Hva er målernummer?». Etter at han har lest den korte artikkelen, klikker han seg videre til sakens eneste lenke – «Hva er målepunkt-ID?». Også den blir lest. Bevegelsesmønsteret er likt, han klikker på den eneste lenken han finner – «dine fakturaer». Her blir han sendt til innloggingen, men returnerer kjapt til forrige side. Han har kanskje ikke brukerkonto på lyse.no? Dette er en tålmodig bruker. Tydeligvis forvirret, men han gir ikke opp med det første. Han navigerer seg tilbake til siden han opprinnelig var på, og leser denne igjen. Nøye. Vi ser så at muspekeren beveger seg diagonalt opp til høyre hjørne. Opptaket stopper. Det kan tyde på at han ga opp, og lukket nettleseren.

Se filmen selv.

Hva får jeg ut av dette? Først lager jeg en hypotese. Jeg vet at mange ikke vet forskjell på målernummer og målepunkt-ID. Det er derfor disse artiklene er skrevet. Et forsøk på å oppklare denne usikkerheten. Jeg vet også at mange har manuelle målere med et nummer som skal leses av, og meldes inn hver måned. Måler med et nummer. Målernummer. Kan det være at denne kunden tror at målernummer er tallet han skal lese av hver måned? Absolutt. Det som Lyse kaller «målerstand», et kanskje litt mindre folkelig begrep? Det er min hypotese i dette eksempelet. Han er nå på lyse.no, for å utføre sin plikt. Datoen viser at det er i slutten av måneden, og det er da Lyse oppfordrer sine kunder å lese av strømmen. Dette styrker hypotesen.

Jeg spør meg selv om det er grunn til å tro at flere tenker som denne kunden? Her føler jeg meg trygg på at svaret er ja. Jeg legger derfor til et avsnitt i artikkelen «Hva er målernummer?»:

Tallet som står på skjermen er din målerstand. Det er målerstanden du skal melde inn dersom du har manuell måler.

Forhåpentligvis har jeg gjort en liten forbedring i dag. Nå legger jeg inn i forvaltningsplanen at jeg skal sjekke om den nye lenken blir brukt. Dette sjekker jeg i Google Analytics om noen uker. Hvis lenken ikke brukes var kanskje hypotesen min feil, og jeg kan fjerne teksten igjen.

Det var dagens lille brukertest. Sånn, nå er det ikke mer popcorn igjen. Nå gleder jeg meg bare til neste e-post fra Hotjar som forteller at jeg har flere videoer i vente.

Bruker du Hotjar eller tilsvarende verktøy? Hvilke erfaringer har du?