Retningslinje
Dekoratøren
Oversikt over hvilke funksjoner som ligger i dekoratøren, hvilke fordeler den gir og hvordan teamene kan ta den i bruk.
Hva er dekoratøren?
Kort oppsummert er dekoratøren toppen og bunnen av nav.no, dvs logoen, menyen, innloggingsknappen, søkefunksjonen og alle lenkene i det blå feltet i bunnen av siden.
Målet med dekoratøren er å gi brukeren en helhetlig opplevelse på nav.no. Nav.no består av mange individuelle applikasjoner og tjenester som eies av mange forskjellige team. For innbyggerne er det derimot viktig at nav.no oppleves som én side hvor det er lett å kjenne seg igjen, enten man skal finne informasjon om AAP, sende inn meldekort eller søke om svangerskapspenger.
Vi har en egen Slack-kanal for dekoratøren. Den finner du på #dekoratøren_på_navno. Her poster vi nyheter om endringer og oppdateringer som gjøres. I tillegg fungerer den som en support-kanal for alle som har spørsmål eller trenger hjelp.
Hvorfor er det en fordel for team å bruke dekoratøren?
Når team bruker dekoratøren slipper de å vedlikeholde ting som søk, menyer og innlogging – det får de automatisk. Dessuten inneholder dekoratøren også en rekke hjelpefunksjoner som gjør at teamene slipper å lage alt dette selv. Eksempler på slike funksjoner er utloggingsvarsel, samtykkebanner («cookie-banner»), analyse og språkvelger.
Hvordan ta i bruk dekoratøren
Team som vil ta i bruk dekoratøren, kan besøke https://github.com/navikt/nav-dekoratoren og finne teknisk dokumentasjon og forklaring på hvordan de kommer i gang. Denne artikkelen fokuserer på den overordnede intensjonen med dekoratøren og hvordan den hjelper med å skape ett enhetlig nav.no.
Slik er dekoratøren bygget
Rent teknisk er dekoratøren en egen applikasjon. Det kan du se hvis du besøker www.nav.no/dekoratoren. Når teamene bruker dekoratøren, hentes alle delene som JavaScript-kode, html og stilsett fra denne applikasjonen. Det betyr at alle team alltid vil ha en oppdatert versjon av dekoratøren. Hver gang vi i Team nav.no gjør en endring, legger til en ny funksjon eller oppdaterer lenker, vil disse oppdateringen vises i alle applikasjoner som bruker dekoratøren uten at teamene trenger å gjøre noe selv.
Grønn dekoratør
Dagens dekoratør er bygget for å sende minst mulig kode. Den er bygget med webcomponents, helt vanlig javascript og annen standardisert webteknologi. Det sparer mange kilobyte pr visning, og dekoratøren logget 97M sidevisninger i 2024, så disse reduksjonene merkes godt! Derfor skryter vi litt av at dekoratøren er ganske så grønn!
Håndtering av samtykke («cookie-banner»)
Den nye ekomloven krever at Nav henter inn samtykke fra brukeren før vi kan bruke cookies og lignende teknologi til analyse og logging i forbindelse med innsiktsarbeid. Loven omfatter alle måter å lagre data på i brukerens nettleser (cookies, localstorage, sessionstorage etc.), men for enkelhets skyld bruker vi begrepet “cookie” i denne artikkelen.
Team nav.no har laget et felles cookie-banner som vises i alle applikasjoner som bruker dekoratøren. På denne måten kan vi sentralisere og organisere samtykkene, slik at team enkelt kan sjekke hvilke samtykker brukeren har gitt, og være sikker på at lagring og lesing kun skjer i samsvar med brukerens samtykke.
- I cookie-banneret kan brukeren velge å si «Ja» eller «Nei» til bruk av valgfrie informasjonskapsler. Det er viktig at disse valgene oppleves likeverdige, og at det er like lett å si nei som å si ja.
- Brukeren kan også klikke en lenke i banneret for å lese mer om hvilke data Nav lagrer. Dette er en del av kravet om «informert samtykke».
- I bunnen av dekoratøren og på siden med informasjon om cookies («cookie-erklæringen»), finnes mekanismer hvor brukeren kan endre samtykket sitt. Da vises cookie-banneret på nytt slik at brukere kan gjøre et nytt valg.
- Lagrede cookies som ikke er «strengt nødvendige» slettes når cookie-banneret vises første gang og når det vises på nytt etter 90 dager.
- Brukeren regnes som å ikke ha gitt sitt samtykke hvis
- banneret vises og bruker ikke har tatt et valg
- bruker har klikket «Nei»
- Dekoratøren laster ikke inn scripts for Amplitude, Hotjar eller liknende før bruker har gitt aktivt samtykke.
Dekoratøren har en tillattliste med alle navn/nøkler på cookies som det er lov å lagre. Vi tilbyr funksjoner som sjekker om en cookie er tillatt å skrive før den settes. Da sjekkes det om
- navnet på cookien er kjent og ligger i tillattlisten
- hvis cookien er definert som frivillig, sjekkes om brukeren har gitt sitt samtykke til frivillige cookies.
Du finner mer informasjon om dette i dokumentasjonen for nav-dekoratoren-moduler.
Cookie-banneret vises automatisk i alle applikasjoner som bruker dekoratøren. Teamene trenger ikke å gjøre noe aktivt selv for å “slå på” cookie-banner. Derimot finnes det hjelpefunksjoner som teamene kan bruke for å være sikre på å etterleve kravene. Disse funksjonene ligger i nav-dekoratoren-moduler som er en hjelpepakke som team bruker for å sette inn dekoratøren i applikasjonene sine.
Eksempler på slike funksjoner er:
setNavCookie: Denne sjekker om en cookie finnes i tillatt-listen og om det er lov å lagre den i henhold til brukers eventuelle samtykke.isStorageKeyAllowed: Sjekker om en cookie er tillatt å lagre. Kan for eksempel brukes dersom teamet må håndtere spesielt dersom bruker ikke har gitt samtykke.getCurrentConsent: Gir informasjon om om hvilket samtykke brukeren har gitt. Nyttig dersom teamet for eksempel har egne måter å lagre cookies eller annet på og vil sjekke om bruker har gitt samtykke til for eksempel analyse.
Dekoratøren stopper ikke lagring av cookies med mindre teamet bruker hjelpefunksjonene i nav-dekoratoren-moduler som i eksemplene ovenfor! Derfor er det viktig at teamene sjekker hvilket samtykke brukeren har gitt. Hvis ikke kan teamet risikere at bruker ikke har gitt samtykke, men at frivillige cookies (f.eks. Amplitude) lagres allikevel. Det er et brudd på krav om etterlevelse.
Det er viktig å understreke at funksjonaliteten i dekoratøren er ment å være til hjelp for teamene. De funksjonene som leveres via dekoratøren, Amplitude, Hotjar og andre måleverktøy, har dekoratøren ansvaret for å stoppe dersom brukeren ikke har gitt samtykke.
Utover dette er det teamene som er ansvarlig for etterlevelse. Hvert enkelt team er ansvarlige for å gjøre egne vurderinger av om cookiene de bruker er nødvendige eller frivillige, og for å dokumentere etterlevelse av kravene i loven. Team som har egne cookies må melde inn disse til #cookiebanner. Det er både for å legge de til i tillattlisten, men også fordi alt som lagres på brukerens maskin skal informeres om i cookie-erklæringen.
Hvis dere er usikre, be om råd og bistand i #cookiebanner.
Team nav.no og jurister i blant annet Team ResearchOPS har jobbet mye med detaljene rundt utforming av cookie-banneret og krav til hvordan den skal oppføre seg.
I denne omgang har vi etablert 2 kategorier: «strengt nødvendige» og «frivillige».
- Strengt nødvendige cookies som kan vi lagre uten å be om samtykke fra brukeren. Det kan være cookies som sikrer drift, stabilitet, monitorering, innlogging, lastbalansering etc.
- Frivillige cookies dreier seg i hovedsak om logging og analyse. Det er disse som brukeren faktisk gir et aktivt samtykke til.
Det er altså ikke noe som heter å «samtykke til kun nødvendige» – disse krever nemlig ikke noe samtykke.
Hvilke cookies vurderes som strengt nødvendige?
Det ble stilt spørsmål ved hva som kan defineres som «strengt nødvendig». Bruk av mellomlagring av skjemaer er eksempel på noe vi har diskutert. Sammen med juristene har vi vurdert at mellomlagring som gjøres i session, dvs. slettes når brukeren lukker websiden, kan aksepteres som «strengt nødvendig». Det er teamene selv som er ansvarlige for etterlevelse av lovkravene, og som må vurdere hva de definerer som "strengt nødvendig" med hensyn til lagring av cookies.
Hvilke typer teknologi omfattes av loven?
Ekomloven er ganske vag i beskrivelsen, men intensjonen med lovendringen er at Norge skal nærme seg EU-direktivet for håndtering av cookies. Derfor har vi også sett til eksisterende tolkninger av EUs ekomdirektiv (ePrivacy Directiv) for å vurdere hva som er omfattet av loven og ikke. Blant annet gjelder loven alle måter å tilegne seg informasjon fra nettleseren, enten de defineres som "strengt nødvendig" eller ikke. Det gjelder også identifisering av nettleseren gjennom såkalt fingerprinting. Det er for eksempel årsaken til at bruk av Umami fortsatt krever samtykke selv om den ikke lagrer noe i brukerens nettleser.
Verktøy for webstatistikk og spørreundersøkelser
Dekoratøren tilbyr Umami og Amplitude for logging og innsikt i tillegg til Hotjar og Task Analytics for undersøkelser. Disse scriptene lastes inn automatisk i dekoratøren (forutsatt brukers samtykke) slik at de er klar til bruk i teamenes applikasjoner.
Umami er verktøyet som skal ta over for Amplitude som skal avvikles mot slutten av 2025. Umami fungerer i store trekk på samme måte som Amplitude, men dataene lagres i Nav sine egne løsninger. Dermed unngår vi overføring til tredjeland og sikrer at vi er i henhold til EUs personverndirektiv. Umami håndterer loggingen, mens selve analysen kan gjøres i Metabase.
For å gjøre overgangen fra Amplitude til Umami så enkel som mulig for teamene finnes det hjelpefunksjoner i nav-dekoratoren og nav-dekoratoren-moduler som kan benyttes. Her er navngivingen endret fra Amplitude til Analytics, utover det fungerer de likt som tilsvarende metoder for Amplitude. Analytics-metodene logger til både Amplitude og Umami, og kommer til å gjøre det til Amplitude fases ut. Dermed kan team som allerede bruker Amplitude via dekoratøren få en sømløs overgang til Umami.
For team som ikke bruker Amplitude via dekoratøren, men i stedet har laget sin egen integrasjon ber vi teamet kontakte #researchops.
For team som vil bruke dette finnes teknisk dokumentasjon i nav-dekoratoren, men her er et eksempel på hvordan disse brukes:
import { getAmplitudeInstance} from '@navikt/nav-dekoratoren-moduler'const logger = getAmplitudeInstance('my-app-origin')logger("skjema åpnet", { skjemaId: 1234, skjemanavn: "mitt-skjemanavn",});
Merk: Amplitude avvikles mot slutten av dette året (2025). Etter dette er det Umami og Metabase som kan brukes til analyse og innsikt.
Undersøkelser for Hotjar og Task Analytics settes opp på egne måter utenfor dekoratøren. Dekoratøren brukes kun for å hente inn og sette i gang undersøkelsene, slik at team ikke trenger å gjøre dette i sin egen kode.
For team som trenger hjelp, kontakt #team-navno på Slack.
Innlogging
Dekoratøren har ikke egen mekanisme for innlogging. Innloggingsknappen som ligger i headeren sender brukeren til login.nav.no, hvor ID-porten håndterer hele prosessen. Deretter sendes brukeren tilbake til den opprinnelige siden eller applikasjonen vedkommende var på. Dekoratøren sjekker hva slags innloggingsstatus brukeren har for å kunne vise navnet til brukeren i topp av siden, og for å kunne vise en egen innlogget meny.
Hvis team ønsker å sjekke innloggingsstatus eller finne token for kall mot andre tjenester, må de gjøre dette via felles innloggingstjenester. Dekoratøren tilbyr ikke noe API for dette. Informasjon om felles innloggingstjenester finner på nais.io.
Utloggingsvarsel
En innlogging varer i 60 minutter før den må fornyes (såkalt «token refresh»). 5 minutter i forkant vil brukeren få et utloggingsvarsel, som gir mulighet til enten å fornye innloggingen med nye 60 minutter eller logge ut umiddelbart.
Denne funksjonen er slått på som standard i dekoratøren, men team som bruker dekoratøren kan velge å slå den av.
En total innlogging varer i 6 timer (såkalt «session»). Denne kan ikke fornyes. Brukere som har vært logget inn lenge ved å stadig fornye innloggingen sin, vil til slutt måtte logge ut og logge inn på nytt.
Språk
Språk i dekoratøren
Dekoratøren støtter bokmål og engelsk i det visuelle grensesnittet, det vil si topp, bunn, søkefelt, meny, utloggingsvarsel, cookie-banner etc. Det finnes også delvis støtte på samisk.
Hvis du har en side hvor selve innholdet (f.eks. artikkelteksten) er oversatt til polsk, så vil språket i dekoratøren-grensesnittet vises på engelsk, mens innholdet vises på polsk.
Språkvelger
Dersom du har innhold på flere språk, tilbyr dekoratøren en språkvelger. Dette er en nedtrekksmeny som lar brukeren skifte språk på én side til et av de andre språkene som teamet har gjort tilgjengelig. Teamet kan selv angi hvilke språk som er tilgjengelige for en gitt side ved å sende inn språkene som innstilling til dekoratøren. Teknisk dokumentasjon om språk finnes her.
Språkvelgeren støtter en rekke språk og målformer: bokmål, nynorsk, samisk, engelsk, polsk, ukrainsk og russisk.
Søk
Dekoratøren tilbyr søk direkte fra menyen. I tillegg kan brukeren velge å åpne søkeresultat på en egen side, som også tilbyr avanserte søkefiltere.
Søket inkluderer innhold på alle sider i Enonic XP (redaktørplattformen på nav.no). I tillegg er det mulig å legge inn ekstra treff for team som ønsker at søk på spesielle nøkkelord skal lede brukeren til deres egen applikasjon. Ta kontakt med #team-navno for hjelp med dette.
Prioriteringer i søk
Søket bruker Opensearch. Denne analyserer innhold og nøkkelord og rangerer søkeresultatene avhengig av hvilke ord brukeren har skrevet inn. I hovedsak er prioriteringene hensiktsmessige, men i enkelte tilfeller kan man oppleve at treff som burde komme øverst vil havne lenger ned på listen.
Søk og personvern
Vi vet at noen brukere misforstår meningen med søket og skriver lange setninger, oppgir personinformasjon osv. For å unngå at slik informasjon lagres, filtrerer vi vekk innhold som for eksempel kan likne på fødselsnummer, telefonnummer etc. I tillegg har vi satt en begrensning på 100 tegn i søkefeltet.
Meny
Menyen i topp og bunn hentes fra Enonic XP. Dersom du har spørsmål eller ønsker å endre lenker i menyen, ta kontakt med #team-navno.
Brødsmulesti
For sider som ligger under flere andre nivåer i strukturen, kan det være til hjelp å legge inn en brødsmulesti. Brødsmulesti fungerer som et veikart for brukeren til nettstedets hierarki, og er nyttig i noen tilfeller. En brødsmulesti kan hjelpe brukeren å
- se hvor de er i sidestrukturen (spesielt når de kommer inn på nav.no via et organisk søk)
- navigere tilbake i strukturen
- gå direkte til et nivå lenger opp i strukturen
Brødsmulesti er et sekundært navigasjonselement, og skal ikke erstatte hovednavigasjonen på siden. Vi bruker ikke brødsmulesti
- hvis strukturen har mindre enn tre nivåer
- ved lineær navigasjon gjennom stegene i et skjema eller en prosess
Dekoratøren har innebygde komponenter for å vise brødsmulesti. Dette sikrer at den blir lik ut på tvers av applikasjoner på nav.no, i de tilfellene hvor den skal vises. For å bruke brødsmulestien via dekoratøren, sender applikasjonen inn data om struktur, sidetitler og url, og så bygges brødsmulestien automatisk.
Mer teknisk informasjon om brødsmulesti finnes i dokumentasjonen til dekoratøren.
Brødsmulestien blir plassert til venstre på siden, under menyen og hovednavigasjonen, men over sidetittelen. Alle leddene i brødsmulestien vil være klikkbare lenker, bortsett fra siden brukeren står på, som er vanlig tekst. Brødsmulestien er også testet med hensyn til universell utforming (WCAG) og fungerer med både skjermleser og tastaturnavigasjon.
Om brødsmulesti på de åpne sidene på nav.no
Chatbot Frida
Chatboten er skjult som standard, og vises dersom det finnes en pågående chat med veileder. Det er også mulig å slå chatbot helt av. Husk at dersom chatbot slås helt av, så vil den ikke vises på den aktuelle siden eller applikasjonen, selv om brukeren har en pågående samtale.
Medvirkende
