Regler for skjema, validering, formattering og feilmeldinger

[dagtj]

I team PM Betaling har vi utarbeidet noen regler for innhold og koding av skjema. Disse bygger på tidligere dokumentasjon vi har funnet på Sparebank1, ELMER3, UU-krav og diskusjoner i teamet og "best pratice" vi har kommet over.

Reglene er beskrevet på en side som er bygget i Axure - de fleste med eksempler:

https://59n7ky.axshare.com/validering_av_skjema.html

Vi trenger bistand til å identifisere konsekvenser og endringsbehov i FFE og få implementert disse.

[ivarni]

Hm, flere av de kravene strider mot ting vi har fått beskjed om å gjøre i våre applikasjoner, så kanskje det burde en runde gjennom design og ux rådet først for forankring der?

[ivarni]

Ellers en veldig fin ting som jeg tror hadde vært bra å få inn i designguiden på en eller annen måte 👍

EDIT: Sorry, feil knapp der. Litt usikker på hvorfor jeg har lov til å close issues i utgangspunktet men det var ikke meningen å trykke på den knappen.

[dagtj]

Det har vært gjennom IxD-forum, ja. Og ytterligere revidert deretter. Nå er det sjelden det blir 100% enighet der, men dette er det beste vi klarer å komme fram til nå. Og fortsetter gjerne diskusjonen videre her. Kanskje vi skal holde igjen på de mest omdiskuterte forslagene. Kan du være konkret, @ivarni?

[ivarni]

Helt greit for meg at det kommer krav som er annerledes enn de vi har fra før, jeg vil bare sikre at det er enighet om det på tvers før vi eventuelt bruker tid på å endre store deler av skjema-koden vår :)

Dersom det ikke er innlysende av andre grunner skal obligatoriske elementer merkes "(valgfri)"

Her antar jeg at ikke-obligatoriske elementer skal merkes "(valgfri)" men denne var helt ny for oss.

Validering og feilmelding til bruker bør gjøres så tidlig som mulig, f.eks. når et felt forlates

Her ble det tidligere bestemt at vi ikke skulle starte med "live" validering før brukeren har forsøkt å submit'e formen, men etter første gang submit så ville alle felter valideres fortløpende. Dette blant annet fordi feilmeldingene våre skyver andre elementer nedover siden og at det kan oppleves som veldig forstyrrende når det skjer mens brukeren fyller ut skjema. Antagelsen er vel da at det i de aller fleste tilfeller ikke er valideringsfeil og at vi da heller kan vente slik at flertallet ikke opplever dette.

Det skal være plass til en linje feilmelding uten å måtte flytte på elementene, ved flere linjer skyves øvrig skjema nedover

Dette henger nok veldig sammen med punktet over :)

Når bruker begynner å endre et skjemaelement skal kontekstuell feilmelding fjernes og stil endres

Her har vi tidligere vist feilmeldingen helt til feltet har en gyldig verdi i stedet for å fjerne den med en gang

Dersom skjemaet er langt eller over flere trinn skal valideringsfeil etter submit også vises som en melding øverst under H1. Meldingen skal ikke fjernes eller endres mens skjemaet deretter rettes.

Dette syns jeg bare er merkelig, vi skal altså fjerne feilene fra det enkelte feltet med en gang det endres men beholde det i oversikten til det submittes igjen?

Beløp o.l. skal skrives i høyrejustert tekstfelt

Nytt for oss og noe jeg ikke er heeelt overbevist om at designerne våre har tatt hensyn til. Antar det ikke gjelder steder som dette så man bør kanskje legge til noe om at for inline-inputs er det andre regler?

Som sagt, jeg er veldig positiv til å få på plass felles kjøreregler for dette men vil bare forsikre meg om at alle er med på laget før vi eventuelt bruker ganske mye ressurser på å endre applikasjonene våre. Spesielt punkt 5, 6 og 7 høres veldig dyrt ut slik vi har lagt opp ting.

[dagtj]

Takk for at du får i gang en god diskusjon! Jeg velger å kommentere dine kommentarer enkeltvis. Den første om "valgfri" var en ren skrivefeil, har rettet det nå. Dette punktet tok jeg faktisk med da det ble kommentert av flere andre designere at slik var praksis. Men det er nok ulik praksis rundt omkring på huset! Det er uansett en god regel i alle skjema at brukeren skjønner hvilke felter som MÅ fylles ut. Hvordan ville du ellers løst dette, eller hva er alternativ praksis?

[ivarni]

Vi løser det med å vise valideringsfeil dersom kunden utelater et påkrevd felt :)

[dagtj]

Ang. "live" validering: Det vil nok være en skjønnsmessig vurdering, og valgfritt i hvert enkelt tilfelle om det er best med umiddelbar validering eller etter submit. Vi har situasjoner med avhengigheter hvor Kontonummer f.eks. avgjør om du skal fylle ut KID eller melding, da må vi validere Kontonummer straks. Når du sier "tidligere bestemt" - er det formulert noe sted? Høres radikalt ut andre veien for meg, at det ikke gis åpning for kontekstuell validering før etter første submit. Ellers uheldig at det ikke i utgangspunktet er plass til feilmeldinger på minimum 1 linje, derfor tok vi med et punkt på det. Ellers "hopper" skjemaet veldig vertikalt slik FFE nå er implementert.

[ivarni]

Det ligger sikkert i en Jira-sak et sted men da skal vi tilbake i tid til før FFE i det hele tatt fantes og det vet jeg ikke om jeg orker å grave fram. Vi har i hvert fall jobbet med den forutsetningen i litt over 3 år nå.

[dagtj]

Vel, da jeg er direkte uenig med deg at det ikke er innlysende hva som er påkrevd eller ikke, før du begynner å fylle ut skjema, før du trykker Submit og oppdager hva som var påkrevd. Viser også til ELMER3 pkt. 3.6.

[ivarni]

Det er ikke min mening jeg sitter og ytrer her, det er de føringene vi har fått fra UX/Design i teamet vårt tidligere. Det er derfor jeg opprinnelig spurte om dette var forankret hele veien opp for da er det merkelig at det er såpass stor forskjell på føringer som er gitt nedover :)

Personlig syns jeg det er greit å få beskjed så tidlig som mulig når jeg gjør noe feil.

[dagtj]

"tidligere vist feilmeldingen helt til feltet har en gyldig verdi": Vi legger til grunn at validering ikke skal meldes til bruker under utfylling, men tidligst ved å forlate et felt eller på submit. Dersom jeg begynner å rette et felt kan vi altså ikke vite om det har blitt riktig eller ei. Så her blir det en avveining mellom å minne brukeren om at "her var det feil" på den ene siden, og "nå ble det kanskje riktig" på den andre. Når noe er endret i et input-felt er det i alle fall 100% sikkert at innholdet som ga feil i stad ikke er er 100% til stede lenger. Feilmeldingen som fortsatt står der kan også skape usikkerhet - "jamen, jeg har jo skrevet 11 tall på kontonummer nå?" Kanskje vi tar feil, men dette kan bare brukertest og annen analyse avdekke.

[dagtj]

Ang. forholdet mellom oppsummerende feilmelding med linkeliste til feilene, og kontekstmeldinger som forsvinner når du begynner å rette på dem: Det henger delvis sammen med prinsippet jeg nettopp kommenterte, at det er skånsomt for brukerne å fjerne allerede utdatert feilmelding når de er i gang med å rette et felt. Vi har sett eksempel på at feilmeldingen i toppen oppdateres fortløpende ettersom skjemaet rettes - et og et kulepunkt forsvinner. For det første tror vi ikke det er mange som vil få med seg dette. For det andre kan vi ikke vite om feilen er rettet før et nytt submit. For de tredje tenker vi at det er greit å se den statiske feilmeldingen i toppen, som en huskelapp på hva som var feil sist, samtidig som vi har "trukket tilbake" de konkrete og kontekstuelle feilmeldingene i skjemaet. Alt er nå forsøkt rettet, prøv igjen!

[dagtj]

Vi har ikke tatt med noe om inline-input, da vi så langt ikke har slikt på nettbank betaling. Men enig i ditt eksempel fra Forsikring, her er det mest fornuftig at at ALLE felt er midtstilt, da det skal flyte best mulig med tekst eller innhold for og bak.

[hdaljord]

Retningslinjene på formatering av inputfelt tar lite hensyn til om det er flere ulike typer felt i samme skjema. Jeg kan se for meg at skjemaene blir ganske rotete om noen felt (beløp/tall) skal være høyrejustert, mens andre felt (tekst/dato) skal være venstrejustert. Har dere tenkt på dette?

[dagtj]

Jeg forstår faktisk ikke helt hva du mener her, hvordan det kan være et problem at et skjema består av ulike elementer som oppfører seg ulikt. Se vedlagte eksempel.

[hdaljord]

I eksempelet ditt kan øynene lese nedover helt til du kommer til kroner-feltet hvor man plutselig må hoppe til høyre for å se innholdet. Her er det bare ett felt som skiller seg ut, men i lengre skjemaer kan det bli mye mer hopping og færre linjer å følge med øynene, og muligens fremstå som mer rotete og mer slitsomt å lese/følge.

[dagtj]

Enig at vi skal tilstrebe god leseflyt i skjema. Men det er få felt vi anbefaler å høyrejustere. Kroner-feltet her har også automatisk formattering innebygd. I det du legger 4 til 123 legger vi til mellomrom lengst til venstre - 1 234. Denne formatteringen vil føles mer naturlig i et høyrejustert felt. Det skaper også mer orden når kroner og øre står samlet. Når dette skjemaet er tomt vil du lese ledetekstene nedover til du kommer til Kroner og trykket i feltet under (som er helt tomt). Du har ikke noe forhold til at det er høyrejustert før du begynner å taste tall. Jeg tror ikke det vil oppleves rotete at de da kommer til høyre, tett på øre 00. Dessuten krever skjemaet i utgangpunktet mye veksling mellom venstre og høyre side, krysset i toppen, chevron for Fra konto, Øre og knapp for Forfallsdato. Men alt dette er synsing, dersom vi vil avklare det nærmere må vi teste begge varianter med blikksporing.

[hdaljord]

Jeg reagerte mest på at det stod "skal" hvis dette skal være retningslinjer som skal gjelde overalt. Det er forskjell på skjemaer og det betyr også at det kan være forskjell på hvordan dette bør være.

Det vil også være mer naturlig at de er høyrejustert slik som i eksempelet de stedene der du har et påfølgende felt for øre, men det er ikke overalt vi har med felt for øre. For eksempel har vi i forsikring BM tatt bort alt av ører.

[dagtj]

Det er ikke opptil meg å vurdere graden av pålegg her, men Sparebank1 bør opptre mest mulig konsistent langs alle akser. Vi har spilt inn et forslag som de ansvarlige får ta videre som de vil. Har fjernet ordet "skal" for å gjøre dette mindre kontroversielt. Det vil også være nyttige å samle flere eksempler på tvers for å se om reglene lar seg anvende ulik kontekst og bruk, slik du sier.

[dagtj]

Har lagt på et passord på AxShare siden sist, fornavnet til aller øverste direktør i SB1. Du vet ikke, sier du? Vel, da lærte du noe nytt: turid

[dagtj]

Har lagt til to regler til på AxShare.

[selbekk]

Hva er status på dette issuet? Skal vi legge det inn i designsystemet vil det kreve endel arbeid på komponentene våre, i tillegg til en informasjonsjobb ut mot teamene.

Her burde nok @kwltrs eller @antidecaf på banen med litt meninger :)

[antidecaf]

@selbekk Dette har vært tema på DS-forum i det siste og ligger for øyeblikket i hendene til UX, som skal samle interessenter og utarbeide forslag til retningslinjer. :)