Vurdering av uu.difi.no

Difi har definert hvilke kriterier innen universell utforming norske nettsteder må følge for å være i henhold til regelverket. Jeg har sjekket hvordan Difi selv ligger ann.

Jeg har tatt utgangspunkt i sjekklisten fra Wuhcag. Denne forklarer WCAG bedre enn W3C selv, og har gode eksempler.

Hensikten med denne artikkelen er ikke å henge ut Difi. De gjør en god og viktig jobb. Og hvem er jeg til å kritisere? Universell utforming på nett er ikke sort-hvitt. Mine vurderinger og kommentarer kan være feilaktige. Jeg håper at saken viser at vi alle gjør feil og at vi alle kan lære noe nytt om uu.

Konklusjon

Av de 35 kriteriene som Difi sier at vi skal innfri, bommer de selv på ti. La meg ta deg gjennom hele listen.

1.1.1 Ikke-tekstlig innhold

For å sjekke de alternative tekstene på bilder åpner jeg Chrome-utvidelsen Web Developer. Under Images finner jeg valget Display Alt Attributes. Dette viser merkelapper på alle bilder. Hos Difi er de fleste merkelappene kun røde, små streker uten innhold. Dette tyder på bildene mangler alt-tekst. Kan virkelig Difi ha snublet på det første og mest elementære kriteriet?

Små streker tyder på at Difi har tomme alt-tekster.
Små streker tyder på at Difi har tomme alt-tekster.

Her er det noe som skurrer, så jeg åpner kildekoden og søker etter «<img». Null treff. Inneholder ikke siden Løsningsforslag for web noen bilder? Logoen er satt inn som et bakgrunnsbilde. Det er ikke mulig å sette inn alternative tekster på bakgrunnsbilder. I dette tilfellet skjønner jeg ikke hvorfor Difi har valgt å bruke bakgrunnsbilde. For brukere med bildevisning avskrudd vil logoen ikke vises. Chrome på Android kommer med en modus for å spare datatrafikk som blant annet fjerner bilder.

Forsiden inneholder to bilder. Det første er en illustrasjon som viser ulike personer. Illustrasjonen står i sammenheng til teksten «Enklare digital kvardag for alle». Dette en en god illustrasjon fordi den gjør et poeng av at universell utforming ikke kun handler om å utforme for mennesker med permanente funksjonshemninger. Det handler òg om midlertidige funksjonshemninger som en brukken arm eller dårlig syn som følge av skarpt sollys. Illustrasjonen mangler en påkrevd alt-tekst. Her ville jeg skrevet inn teksten «Universell utforming er for alle, for eksempel rullestolbrukere, innvandrere, barn, de med brukken arm, mobilbrukere og eldre.». Ikke godkjent.

Skjermbilde av uu.difi.no som viser to illustrasjoner.
Difi har brukt to bildefiler på forsiden av uu.difi.no

Det andre bildet på forsiden viser fire ikoner. En hånd, en høyttaler, en hjerne og et øye. Dette illustrerer fire typer funksjonsnedsettelser. Ikonene står i sammenheng med teksten «Finn løsningsforslag for web». I dette eksempelet har Difi en tom alt-tekst. Her er jeg enig. Det gir ingen merverdi å legge inn en tekst om hva ikonene viser eller hva de betyr. For eksempel at hånden betyr nedsatt førlighet.

1.2.1 Bare lyd og bare video (forhåndsinnspilt)

Etter å ha gjennomgått en god mengde sider og videoer, finner jeg ingen innholdselementer som består av kun lyd eller kun video. Eksempler på dette kunne vært podcaster eller animasjoner. Jeg fant riktignok videoer som inneholdt lyd i form av bakgrunnsmusikk, som denne:

Hensikten med kriterie 1.2.1 er at synshemmede skal kunne få ut informasjon av filmer, eller at hørselshemmede skal kunne lese lydfiler. Bakgrunnslyden i eksempelet er kun der for å sette en stemningen, ikke for å formidle informasjon slik en fortellerstemme vil gjøre. I et uu-perspektiv vil derfor videoer av denne typen være likestilt med en film helt uten lyd.

Videoen skal ha et alternativ i form av tekst- eller lyd. Det har den ikke. Verken på Vimeo eller på Difis side om Innovasjonsprisen 2016. Besøkende med synsnedsettelser har derfor ingen mulighet å få vite at søknadsfristen er 1. mars.

Løsningen er enkel. Vimeo har et godt verktøy for å lage undertekster på videoer. Et eksempel på en film jeg har tekstet er denne demofilmen for Lyses energioversikt for bedrifter. Tekstede filmer får et CC-ikon på linjen med lydstyrke og bildekvalitet.

1.2.2 Teksting (forhåndsinnspilt)

Difi sin kanal på Vimeo har mange videoer uten teksting. Her er et eksempel:

På Youtube er de flinkere:

1.3.1 Informasjon og relasjoner

Difi skriver at dette kort fortalt betyr ting skal være kodet som det ser ut som. Denne setningen sier ikke meg så mye. For meg handler dette om at HTML-koden skal være skrevet semantisk, det vil si at de riktige taggene brukes for å markere innhold. Et eksempel på dette er sitatet i første setning i dette avsnittet. Her har jeg brukt taggen <q> for å si at dette er et sitat, og attributtet cite for å si hvor jeg har hentet det fra. Andre eksempler er å bruke h-tagger i ulike nivå for å markere overskrifter, skrive feilfri HTML og bruke etiketter på alle skjemafelter.

To advarsler og én feil i HTML-koden på difi.no.
Feil i HTML-koden på uu.difi.no

Det første jeg gjør er å sjekke om HTML-koden inneholder feil. Dette gjør jeg med en validator. På forsiden finner validatoren én feil og to advarsler. Nettsteder har vanligvis mye mer feil enn dette, så her har koderne til Difi gjort en god jobb. Den ene feilen går på en illustrasjon som mangler alt-tekst.

Den første advarselen er at Difi bruker h1-taggen to ganger. Dette er ikke nødvendigvis feil, men i dette eksempelet vil jeg si at det er feil. Første h1 er uu.difi.no og andre h1 er Enklare digital kvardag for alle. Jeg ser ingen grunn til å skrive nettadressen uu.difi.no her. Det er godt mulig Difi har noen gode argumenter her.

Andre advarsel er at det brukes en <section>-tagg som ikke inneholder en overskrift. I følge HTML5 Doctor er dette en vanlig tabbe.

1.3.2 Meningsfylt rekkefølge

Jeg tar tre tilfeldige undersider og tabber meg gjennom dem for å se at fokuset flytter seg i en logisk rekkefølge. Deretter skrur jeg av CSS for å sjekke at innholdet gir mening i den rekkefølgen det da presenteres.

Dette er som det skal. Jeg finner ikke noe å utsette.

Skjermbilde som vises uten CSS.
Slik ser nettsiden ut uten CSS.

1.3.3 Sensoriske egenskaper

Jeg tar noen stikkprøver. Finner ingen bruk av «sensoriske egenskaper». Difi bruker ikke instruksjoner med lyd, ei heller instruksjoner som bruker farge, plassering eller form.

1.4.1 Bruk av farge

Heller ikke her har jeg funnet noe feil i mine stikkprøver. Ingen instruksjoner eller annen informasjon krever fargesyn.

1.4.2 Styring av lyd

Har ikke funnet bruk av lyd som starter automatisk.

1.4.3 Kontrast

På siden Kvifor universell utforming av IKT? finner jeg en illustrasjon som ikke tilfredsstiller minimumskravet til kontrast.

Skjermbilde av en illustrasjon på difi.no som ikke har god nok fargekontrast.
Illustrasjon med tekst som ikke har god nok kontrast.

De hvite ordene «endre» og «styrke» står på piler med bakgrunnsfarge RGB 92,192,54. Dette gir en kontrastverdi på 2,3 som ikke tilfredsstiller minstekravet på 4,5. Kravet gjelder også bilder og illustrasjoner, ikke kun ren tekst.

1.4.4 Endring av tekststørrelse

Vanligvis bruker jeg nettleseren Chrome, men for å sjekke endring av kun tekststørrelse velger jeg Safari. I Vis-menyen velger jeg «Zoom kun tekst» og deretter «Zoom inn» fire ganger. Navigasjon og hovedinnhold er godt lesbart. Jeg finner likevel eksempler på tekst som overlapper og blir uleselig.

Skjermbilde som viser at tekst overlapper når den er forstørret 200 %.
Noe tekst overlapper med 200 % tekstforstørrelse.

Innholdet i seksjonen «Lær mer om kravet hos W3C» overlapper med 200 % tekstforstørrelse. Deler av teksten forsvinner. Dette tilfredsstiller ikke kravet.

1.4.5 Bilder av tekst

I sine løsningsforslag for web bruker Difi mange illustrasjoner med bilder av tekst. Noen er i en gråsone for hva som er akseptabelt, men jeg finner eksempler på bilder som enkelt kunne vært presentert med ren kode.

Skjermbilde fra Difi som viser to illustrasjoner som burde vært ren tekst.
Eksempel fra Difi som inneholder to bildefiler som heller kunne vært ren tekst.

Ettersom jeg selv her presenterer skjermbilder med ren tekst, skyter jeg meg selv i foten. Jeg velger likevel å bruke skjermbilder for å vise et identiske eksempler som Difi.

2.1.1 Tastatur

Jeg «tabber» sider og lenker. Jeg prøver skjemaer og starter filmer. Alt ved hjelp av tastaturet. Finner ingen feil i mine stikkprøver.

2.1.2 Ingen tastaturfelle

Finner ingen tastaturfeller i mine stikkprøver.

2.2.1 Justerbar hastighet

Jeg har ikke funnet noen tidsbegrensninger på sidene.

2.2.2 Pause, stopp, skjul

Jeg finner ingen eksempler på innhold som beveger seg uten at bruker setter det i gang.

2.3.1 Terskelverdi på maksimalt tre glimt

Jeg finner ingen eksempler på innhold som glimter. Difi bruker riktignok videoer, men de er rolige og uten hyppig blinking.

2.4.1 Hoppe over blokker

Dette er godt ivaretatt. Når jeg «tabber» meg gjennom navigasjonen vises lenken «Hopp til hovedinnhold». Difi har et eget løsningforslag for snarveier og hurtigkommandoer.

Skjermbilde fra difi.no som viser lenken Hopp til hovedinnhold for tastaturbrukere.
Lenken «Hopp til hovedinnhold» brukes av blant annet tastaturbrukere.

2.4.2 Sidetitler

Difi bruker nyttige og tydelige sidetitler. Har ikke funnet noe å utsette her.

2.4.3 Fokusrekkefølge

Fungerer bra. En liten kommentar er at jeg ville hatt fokus på lenken «Til toppen» før bunnteksten. Denne lenken er nå den siste lenken på alle sider. Her er jeg åpen for diskusjon.

2.4.4 Formål med lenke

De lenkene jeg har sett på har meningsfulle lenketekster. Ingenting å utsette.

2.4.5 Flere måter

Difi tilbyr både navigasjon og søk. De kunne i tillegg hatt sidekart, men det er ikke et krav å ha tre veier til Rom.

2.4.6 Overskrifter og ledetekster

Veldig bra. Difi har god kontroll på overskrifter og ledetekstene.

2.4.7 Synlig fokus

Alle lenker har synlig fokus. Tydeligheten varierer. Hovednavigasjonen endrer bakgrunnsfarge, og får veldig tydelig fokus. Lenkede overskrifter får kun nettleserens standardfokus som ikke er like tydelig. Ikonet av et forstørrelsesglasset i søkefeltet får en blassere farge ved fokus, og er dermed mindre tydelig. Difi er i henhold til kravet, men den visuelle fremstillingen av fokus kunne vært mer konsistent.

Skjermbilde fra Difi som viser at hovednavigasjonen får tydelig fokus med egen bakgrunnsfarge.
Lenken «Krav og regelverk» har tydelig fokus.

3.1.1 Språk på siden

Alle sider har angitt språkkoden nb. Det gjelder også sidene som er skrevet på nynorsk, for eksempel Kva seier forskrifta? Her skulle språkkoden vært nn slik Difi selv skriver i sitt løsningsforslag Språk i koden.

3.1.2 Språk på deler av innhold

Her synder de fleste, også Difi. På sin personvernerklæring skriver de om cookies. Dette er et engelsk ord som Difi ikke har markert som engelsk. Jeg skal innrømme at dette er flisespikkeri. Hensikten med kriteriet er at man skal markere språkendring på større deler enn enkle ord og begreper.

Dersom jeg gjør et søk etter sidekart kommer jeg til et søkeresultat uten treff. Her er alle løsningsforslagene skrevet på engelsk, og skal derfor markeres som engelsk. Det er det ikke. Det er selvfølgelig ikke meningen å presentere engelsk tekst her. Det er nok bare en feil eller forglemmelse.

Den engelske siden er markert som engelsk, men den inneholdet mye norsk, blant annet all navigasjon. Denne skulle vært markert som norsk.

Skjermbilde fra Difi som viser engelsk tekst når man gjør et søk uten treff.
Søkeresultatet har engelske løsningsforslag.

3.2.1 Fokus

Jeg har ikke funnet tilfeller der det skjer store endringer på en side når et element kommer i fokus.

3.2.2 Inndata

Jeg har heller ikke funnet tilfeller der endringer av skjemafelt medfører store endringer på en side.

3.2.3 Konsekvent navigering

Ingenting å utsette. Navigasjonen holder seg lik på tvers av sider.

3.3.1 Identifikasjon av feil

Felter i et skjema som fylles ut feil eller som ikke fylles ut, får feilmelding. Innskrivningsfeltene blir markert med rød kantlinje. Dette tilfredsstiller kriteriet. Jeg ser likevel litt forbedringspotensiale:

  • Feilmeldingene kan skrives og uten bruk av det unødvendig tunge ordet «obligatorisk». For eksempel «Feltet Navn kan ikke stå tomt.»
  • Feilmeldingene bør gjentas i nærhet av feltet som de gjelder.
  • Feilmeldingene bør lenkes til de respektive feltene.
  • Kontrasten på feilmeldingene er ikke god nok. Kun 4,4.
Skjermbilde fra Difis blogg som viser feilmeldinger når kommentarfeltet ikke er fyllt ut riktig.
Difi viser hvilke felt i skjemaet som feiler, og forklarer hvorfor.

3.3.2 Ledetekster eller instruksjoner

De få skjemaene jeg har funnet er ikke kompliserte, og krever et minimum av ledetekster og instruksjoner. Kriteriet er innfridd. Har likevel en kommentar. Påkrevde felter er markert med en rød (for de som kan se farger) stjerne. Stjernen har en tittel som sier «Dette feltet er obligatorisk.». Bra, men jeg savner bruk av aria-required. For å være ekstra tydelig ville jeg også skrevet i starten av skjemaet, «Felter som må fylles ut er merket med *». Selv en så velkjent konvensjon kan skape problemer for brukere med kognitive utfordringer.

3.3.3 Forslag ved feil

Jeg skal kommentere en artikkel, og skriver feil e-post. Feilmeldingen «E-postadressen du har oppgitt er ikke gyldig.» gir meg ikke en konkret løsning. Denne bør være tydeligere, for eksempel «E-posten er feil. Sjekk om den inneholder @ og punktum.».

Skjermbilde fra Difis blogg med feil e-post ved kommentering.
Feilmeldingen E-postadressen du har oppgitt er ikke gyldig gir ikke et konkret forslag til løsning.

Les gjerne min artikkel Feilmeldinger satt i system.

3.3.4 Forhindring av feil

Jeg har ikke funnet skjema som kan medføre juridiske forpliktelser.

4.1.1 Parsing

Jeg finner HTML-feil her og der, som jeg har nevnt tidligere. Ingen av feilene jeg har sett er alvorlige, og Difi innfrir derfor dette kriteriet.

4.1.2 Navn, rolle, verdi

Difi bruker standard HTML-elementer, og oppfyller derfor automatisk dette kriteriet.

Til slutt

Takk for at du leste hele saken. Har du innspill til mine vurdering setter jeg pris på å høre dem. Jeg er alltid åpen for å lære mer. Skriv en kommentar, eller finn meg på Twitter.

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?

GTM, et springbrett til innsikt

Har du ikke Google Tag Manager sier du? Få det på plass sier jeg.

Når jeg jobber med digitale løsninger liker jeg å designe med data. For tiden har jeg lagt min elsk på verktøyet Hotjar. For å installere en slik godbiter må du legge inn en kode i løsningen din. Det må gjøres av en IT-teknisk person. Med GTM på plass så slipper du det. Du må riktignok ha hjelp til å legge inn GTM, men når det er gjort åpner en ny verden seg.

Du har forhåpentligvis Google Analytics installert. Her klarer du å finne ut hvor mange som besøker deg, hvilke sider som er mest populære, og hvilke sider som har høy fluktfrekvens. Er du litt mer avansert vet du også konverteringsfrekvensen på kjerneoppgavene, og du har identifisert konkrete forbedringer som vil øke salget og minske frustrasjonen til dine kunder. Har du et standard oppsett av GA finnes det mange spørsmål du ikke får svar på. For eksempel hvor mange som spiller av filmene dine, hvor lenge filmene blir sett, eller hvor mange som bruker den elskede bildekarusellen som pryder forsiden din. For å få disse svarene trenger du få satt opp aktiviteter i GA. En teknisk jobb. IT må kontaktes. Kanskje har IT-avdelingen din laber Google-kompetanse? Med GTM på plass blir jobben enklere. Alt gjøres i Googles grensesnitt. Det kan òg riktignok være ganske teknisk, men du finner mange gode veivisere for å komme frem til mål.

Ble du interessert i Google Tag Manager nå, kan jeg anbefale iPULLRANK sin guide. De sier det så bra allerede i første setning:

In the world of digital marketing, if time is money, then data is pure gold.

De mest nerdete av dere vil kanskje legge merke til at Klokkeklart ikke har GTM. Bra observert.

Har du GTM? Hva bruker du det til?

Hva er flexbox?

Flexbox er et kraftig verktøy i CSS-verktøykassen. Det løser noen vanlige utfordringer med dagens float-baserte layouts, og åpner opp for nye muligheter.

Ikke en erstatning for ‘float’

Før jeg gravde meg ned i hva flexbox virkelig var, hadde jeg en oppfatning av at det var en erstatning for float. Etter å ha brukt det en stund, innser jeg at det er mer et nytt verktøy, enn et verktøy som erstatter et annet. Floats har fortsatt sin plass, men flexbox er et bedre verktøy for mange av jobbene floats tidligere har gjort.

Det betyr også at man kan ta et nettsted som allerede eksisterer og drysse flexbox der det måtte være hensiktsmessig.

Hvor god er støtten?

I følge caniuse.com har vi i Norge en støtte på 96,44 %. De resterende prosentene består av Internet Explorer 8 og 9. Du bør selv sjekke besøksstatistikken eller målgruppen (hvis du ikke har lansert enda) for å se hvor god støtten er.

Du bør også ta hensyn til prefikser og nettlesere som støtter den utdaterte anbefalingen. Verktøy som Sass/Compass, Autoprefixer og lignende kan hjelpe deg med dette.

Hva gjør flexbox bedre enn floats?

Flexbox fungerer på en helt annen måte enn floats. Først og fremst til å løse det som tradisjonelt sett har vært vanskelig å løse med floats, men i fremtiden vil vi se nye layouts og løsninger dukke opp på grunn av mulighetene flexbox gir oss.

Vanlige problemer man møter på når man jobber med HTML/CSS som flexbox løser:

Vertikalt sentrere et element

For eksempel hvis du ønsker å få tekst midt på et bilde både horisontalt og vertikalt.

Sentrert tekst, både horisontalt, vertikalt og over flere linjer
Illustrasjon av tekst som ligger sentrert både vertikalt og horisontalt over et fotografi.

 

Jevnt distribuere elementer horisontalt

Uten å måtte ta hensyn til hvor mange elementer det er. For eksempel i en horisontal navigasjonsmeny hvor du ønsker at elementene jevnt skal distribuere seg over hele navigasjonslinjen.

Lik avstand mellom menyelementene
Illustrasjon som viser jevn distribusjon av luften mellom elementene i en navigasjonsmeny.

Endre rekkefølgen på elementer i DOM-en

For eksempel hvis man på mobil ønsker en annen rekkefølge enn den man har i DOM-en.

Lage grids enklere

Her kan man enkelt distribuere bilder eller produkter jevnt, og enkelt ta hensyn til den responsive delen av det.

Det åpner også opp for nye muligheter layout-messig; både på desktop og på mobil.

Med hjelp av conditional classes kan du også bake inn en grasiøs fallback til de få prosentene som sitter på eldre nettlesere som IE8 og IE9.

Hvordan fungerer det?

I prinsippet har man to nye elementer i flexbox: Flexbox-kontaineren og flexbox-elementet. Man gjør et element til en flexbox-kontainer med display: flex; og da vil alle direkte barn av det kontainer-elementet automatisk bli flexbox-elementer.

<!– Hvis denne er satt til display: flex; … –>
<div class="kontainer">
  <!– … blir disse elementene rett under automatisk til flexbox-element –>
  <div>1</div>
  <div>2</div>
  <div>3</div>
</div>

See the Pen Flexbox-artikkel by Erling Hamso (@okse) on CodePen.

Flexbox-elementene vil som standard legge seg på en horisontal linje i flexbox-kontaineren. (Som følge av standard-verdien: flex-direction: row;.)

display: flex;

Fra før av kjenner du kanskje til display:-propertyen som tar verdier som block, inline, inline-block (og noen andre mer obskure verdier). For å gjøre en boks til en flexbox setter man display: til flex eller inline-flex. Utad vil flex-kontaineren oppføre seg som et block-element med flex, men som et inline-element med inline-flex. Akkurat som block og inline-block.

.kontainer {
  display: flex;
  /* Ikke glem prefixer og støtte for IE10 (gammel syntaks) */
}

/* Kun for å tydeliggjøre elementene */
.kontainer {
  padding: 16px;
  background: black;
  font-family: sans-serif;
}
.kontainer > * {
  padding: 8px;
  border: 5px solid #ff00f6;
  color: #ff00f6;
  font-size: 24px;
  margin: 5px
}

See the Pen Flexbox-artikkel by Erling Hamso (@okse) on CodePen.

Akser

Når et element er satt til display: flex; får man to akser å tenke på: Hovedaksen og kryssaksen. Hovedaksen går i den retningen du har satt flyten til. Hvis du ikke har definert en flytretning er standard flytretning row. Det betyr at elementene er «tredd på en snor» horisontalt over boksen. Hvis du endrer retning til column henger snoren fra toppen av boksen til bunnen. Startpunktet for boksene er venstre på row og toppen på column.

flex-direction: row; (row er standardverdien.)

See the Pen Flexbox-artikkel by Erling Hamso (@okse) on CodePen.

flex-direction: column; See the Pen Flexbox-artikkel by Erling Hamso (@okse) on CodePen.

Man kan distribuere, endre startpunkt, endre på rekkefølgen og mye annet på disse elementene som ligger på enten hovedaksen eller kryssaksen.

Flexbox inni flexbox

Da jeg begynte å lære meg flexbox, føltes konseptet med en flexbox inni en flexbox som en hack. Det viste seg å være feil, og man kan gjøre mange flere ting med å legge flexboxer inni hverandre. Merk: Et flexbox-element også kan være en flexbox-kontainer.

Hva mer er det?

Det er flust med ting du kan gjøre med flexbox, men intensjonen med denne artikkelen er ikke å forklare alt. Under har du lenker til ressurser som gjør en ypperlig jobb med å forklare nærmere hva flexbox er og hvordan du kan bruke det.

Er det noe spesifikt du lurer på kan du veldig gjerne legge igjen et spørsmål til meg i kommentarfeltet!

Lær deg Flexbox

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?

Vis eller skjul passord?

Hvorfor jeg ikke anbefaler Lyse å vise passord ved innlogging.

Denne artikkelen var først publisert på Medium.

Innlogging skaper frustrasjon. Mye og ofte. Det finnes mange tiltak for å gjøre innloggingsprosessen sømløs. Én av metodene er å gi brukeren mulighet til å se sitt passord i klartekst. Du har nok sett valget Vis passord, Vis/skjul, eller kanskje sett et lite ikon av et øyelokk. Dette valget er som regel skrudd av. Som bruker må du aktivt skru det på.

På lyse.no kan du hake av for å se ditt passord i klartekst.Kongen av skjemadesign, Luke Wroblewski, anbefaler å vise passordet i klartekst som standardvalg. Inspirert av denne anbefalingen satt jeg opp en A/B-test på lyse.no der halvparten av kundene se passordet, og resten fikk passordet maskert. Alle fikk mulighet til å skru av og på maskeringen. Jeg testet dette på over 8000 kunder ved hjelp av tjenesten Optimizely.

Konklusjonen var denne gang ikke i tråd med Lukes anbefaling. Nesten 10 % færre av dem som så passordet i klartekst logget inn. Anbefalingen til Lyse er derfor å beholde maskert passord inntil kundene har blitt mer modne for dette via andre tjenester.

De harde fakta

Min hypotese var at kundene ville få færre skrivefeil ved å hele tiden se passordet sitt. Jeg sjekket derfor antall feilmeldinger. Før testen skrev mellom 16 % (stor skjerm) og 18 % (mobil) av kundene feil e-post eller passord (loggene skiller dessverre ikke på dette). Under testen steg denne feilandelen til henholdsvis 18 og 27 %. Dette er en massiv økning, spesielt på mobil, og spesielt når man tenker på at det var kun 50 % av de besøkende som var utsatt for eksperimentet.

Det er godt mulig at testen burde vært satt opp annerledes, at det er faktorer her som jeg ikke har sett, og at andre innloggingstjenester vil få helt andre tall.

Har du testet noe lignende? Hvorfor tror du denne testen økte feilraten? Diskuter gjerne med meg på Twitter. Jeg heter @aeslettebo.