Støtte read-only skjema-komponenter

[sjur-gr]

Vi ønsker å vurdere skjema-komponenter som er read-only. Har du innspill til hvordan vi kan støtte read-only på en god og brukervennlig måte?

[JorgenMaristuen]

Hva er read-only?

Readonly-attributtet spesifiserer at et inputfelt i et skjema er skrivebeskyttet. Et skrivebeskyttet felt kan ikke endres. Til forskjell fra et disabled/deakivert felt, kan en bruker tabbe til det, markere det og kopiere teksten fra det. Verdiene i readonly-felter inkluderes også når et skjema sendes inn.

Kartlegging av behov i NAV

Etter å ha snakket litt med teamene, ser vi at det finnes to forskjellige behov:

1. Enkel visning

Typisk brukt ved totrinnskontroll hos saksbehandlere. Lignende løsninger brukes også i oppsummering av søknadsløp på eksterne flater. Her er poenget å gjøre enkelt å lese/skanne innholdet uten unødvendig støy. Derfor fjernes vanligvis all grafisk styling og tomme datafelter, og det som vises er label og tekst/verdi. Avhengig av type input-felt vises verdiene som ren tekst, kommaseparerte verdier, eller kulepunkter.

Eksempel på redigeringsmodus og lesemodus

Redigeringsmodus:

Lesemodus:

På disse sidene/skjemaene er det ikke en blanding av redigerbare og read-only felter. Men i noen tilfeller kan det være mulighet for å åpne redigeringsmodus for et felt ved å klikke på et ikon e.l.:

Eksempel på lesemodus med redigeringsmulighet

Lesemodus med redigeringsmulighet:

Redigeringsmodus åpnet:

Noen ganger er det behov for å fjerne og omstrukturere skjemainnholdet for lesemodus, og da er spørsmålet om dette fortsatt er det samme skjemaet, eller en nye side med annen visning av dataene:

Eksempel på omstrukturert innhold

Redigeringsmodus:

Lesemodus:

2. Nedtonet komponent-styling

I skjemaer som inneholder både felter som er redigerbare og felter som er skrivebeskyttet, kan det være et poeng å vise hva slags type input-felter som er skrivebeskyttet og hva slags valg som er mulige. Eksempelvis kan det være et skjema hvor det av tekniske årsaker ikke er mulig å redigere alle felter, men der dette vil bli mulig i fremtiden.

Eksempel team Valp

Eksempel fra team Valp (ønsker konteksten ved at det fortsatt ser ut som input-felter med tanke på at vi på sikt skal fjerne read-only.)

Eksempel Foreldrepenger

Hvordan kan Aksel gjøre det enklere?

Vi ser et ganske utbredt behov for "enkel visning" til oppsummeringer og totrinnskontroll. Fra noen har vi fått ønsker om egne props fra designsystemet. Andre styrer visningen i en wrapper for hver form-komponent som håndterer knytningen mellom react-hook-form og komponenten fra ds-react. Dersom det er behov for å fjerne eller omstrukturere mer av innholdet i en komponent, kan det bli teknisk vanskelig å lage dette som en prop. Et fleksibelt alternativ kan være en summary list komponent slik som gov.uk bruker.

Det andre behovet, "nedtonet komponent-styling", er det som det gir mest mening å ha som prop, siden vi her beholder det grunnleggende utseendet til hver komponent. Dette tenker vi da å lage som en egen state i Figma og kode, på linje med active, hover og disabled.

Skisse:

[gunnjohansen2]

Når det er klart, kunne dere lagt ut en lenke til skisser i Figma? 😊

[JorgenMaristuen]

Ja, det skal vi gjøre! 😃

[JorgenMaristuen]

Her kan dere teste ut komponenter med read-only: Hjelp oss med Read-only i Figma
@gunnjohansen2