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?

5 kommentarer om “Feilmeldinger satt i system”

    1. De bibliotekene er rene valideringsbibliotek. Min første tanke var å ha et innholdsbibliotek som var uavhengig av valideringsfunksjonen. Etter nærmere ettertanke er det kanskje best å bygge videre på et eksisterende og utbredt valideringsbibliotek. Hva tror du?

  1. For ren validering av datatyper (i skjemaer) kan et valideringsbibliotek være nyttig, men veldig ofte vil behovet for validering-/feil-/kvitteringsmeldinger være knyttet opp mot hver enkelt kundes forretningslogikk og bransjeterminologi.

    Ta eksemplet ditt med registreringsnr – med en gang bedriften har forretningslogikk til hva slags reg.nr som er gyldig (UTOVER 2 bokstaver og 5 tall), vokser listen over påkrevde valideringsmeldinger.

    Som utviklere er det sjeldent vi får en komplett liste med slike meldinger fra designerne, og dermed blir det gjerne vi som må avdekke behovet for disse og etterspørre dem fra kunden.

    Jeg har skrevet en liten artikkel om viktigheten av slik mikrotekst her: https://www.epinova.no/en/blog/why-developers-need-to-take-microcopy-seriously/

    1. Takk for tilbakemelding Arild. Når det gjelder registreringsnummer ser jeg det ikke som sannsynlig at ulike bedrifter har spesielle forretningslogikk for registreringsnummer. Alle bilverksteder vil ha samme krav. For andre tilfeller handler det om å finne en balansegang. Noen viktige regler, og noen viktige valideringsmeldinger.
      Fin artikkel om mikrotekster. Når jeg tester løsninger på brukere er det ofte mikrotekster som skaper usikkerhet. De er undervurderte. Jeg er enig med deg at utviklere bør ta et større ansvar til brukeropplevelsen, noe jeg har skrevet noen ord om på http://funger.no/torr-du-a-kalle-deg-en-ux-utvikler/

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *