diff --git a/apps/www/app/content/patterns/en/button-placement-and-order.mdx b/apps/www/app/content/patterns/en/button-placement-and-order.mdx index 39d0bcbbf3..087eec6294 100644 --- a/apps/www/app/content/patterns/en/button-placement-and-order.mdx +++ b/apps/www/app/content/patterns/en/button-placement-and-order.mdx @@ -1,7 +1,7 @@ --- title: Button placement and order sidebar_title: Button placement -category: Upcoming +category: Upcoming patterns description: How can we create a more predictable and inclusive experience by standardizing button placement and order? partners: Digdir, Nav, Skatteetaten ++ search_terms: placement, order diff --git a/apps/www/app/content/patterns/en/consent-banner.mdx b/apps/www/app/content/patterns/en/consent-banner.mdx new file mode 100644 index 0000000000..51b5229dca --- /dev/null +++ b/apps/www/app/content/patterns/en/consent-banner.mdx @@ -0,0 +1,29 @@ +--- +title: Consent banner +sidebar_title: Consent banner +category: Upcoming patterns +description: How can we ensure a holistic and accessible approach to managing consent for cookies and tracking technologies? +partners: Digdir, Nav, Skatteetaten ++ +search_terms: consent banner, cookie banner, cookies, consent, privacy +date: 2026-02-16 +order: 75 +--- + +A consent banner should give users genuine control over their own data. At the same time, it must be clear, understandable and accessible to everyone. Today, this is handled differently across public services, both in terms of language, design, equal presentation of choices and technical implementation. + +A shared pattern for consent banners can contribute to: + +- A more consistent and recognisable user experience +- Equal presentation of choices, without manipulative design +- Improved accessibility and inclusive design +- Clearer distinction between necessary and optional technologies +- A shared understanding of recommended interaction and behaviour + + +**Work in progress** \ +A cross-agency working group is developing common guidelines and recommendations for this topic during spring 2026. We greatly appreciate input from anyone with relevant experience, insights or results from user testing. You are welcome to contribute in the related [GitHub discussion thread](https://github.com/digdir/designsystemet/discussions/1671). + + diff --git a/apps/www/app/content/patterns/en/date-and-time.mdx b/apps/www/app/content/patterns/en/date-and-time.mdx new file mode 100644 index 0000000000..31f88c6845 --- /dev/null +++ b/apps/www/app/content/patterns/en/date-and-time.mdx @@ -0,0 +1,106 @@ +--- +title: Ask users for date and time +sidebar_title: Date and time +category: Ask users for... +description: Asking users for date and time is often solved in a more complicated way than necessary. In many situations, standard input fields are both faster to use and easier to understand than custom-built date pickers. +partners: Digdir, Brønnøysundregistrene +date: 2026-02-18 +order: 10 +--- + +How you ask users for date and time should be based on the information you actually need. Some dates are easy to remember, such as a date of birth, while others must be read from documents or cards. In some situations, an approximate date is sufficient, or a date relative to today. In other cases, users need to choose a date or time from a predefined set of options. + +Avoid making the task more complicated than necessary. Custom-built date pickers often result in lower accessibility and more friction than simple text fields. They can be difficult to use with a keyboard, provide poor support for screen readers, and require unnecessary navigation when the user already knows the date. + +## Known dates + +When asking for known dates, such as a date of birth or wedding date, simple text fields work well. Users already know the answer and often prefer to type it directly instead of navigating a calendar. + +Consider splitting the date into separate fields for day, month and year. This makes it easier to enter the date correctly and provides better support for assistive technologies. + + + +When asking users for a date as it appears on a bank card, passport or other document, the fields should match the format shown in the document. This makes it easier to transfer the date correctly and reduces the risk of errors. + +## Date from a predefined set of options + +If you know that users need to choose a date or time from a limited set of options, for example available appointments in the coming week, it may be more efficient to present these as ready-made choices. + +When the number of options is very limited, such as a few dates or times, [`Radio`](/en/components/docs/radio/overview) can be a good choice. It allows users to quickly select an option without having to type anything. + + + +### Let users narrow down the options + +When the number of options increases, a [`Select`](/en/components/docs/select/overview) can be useful to narrow down the list. Users can choose preferred weeks, days or time ranges, and then see the available options based on that selection. + +Note: The example below is not connected to an actual data source. It illustrates how users can narrow down the options before seeing the available appointments. + + + +You should only show options that have available appointments, and avoid disabling weeks without availability, as this may create confusion. Explain in advance that only weeks with available times are shown, so users understand why some weeks are not available to select. + +## Specific date in the near future or past + +In some cases, when users need to choose a specific date close to today, visual support can be helpful. An [`Input`](/en/components/docs/input/overview) with `type="date"` allows users to either enter the date directly or use the browser’s built-in date picker. This often provides a good balance between flexibility and support. + +Support varies between browsers and devices in terms of functionality, appearance and interaction, but the solution is often more accessible and robust than custom-built alternatives. + + + +## Start and end date + +When users need to provide a period, the start date and end date should be clearly shown together. Use two separate fields and make it clear which date is which. + +Place the fields in a logical order and validate that the end date is not earlier than the start date. If the dates depend on each other, error messages should explain what is wrong and how the user can correct it. + + + +## Time – start and end + +When users need to provide a time interval, such as opening hours or the duration of a meeting, an [`Input`](/en/components/docs/input/overview) with `type="time"` can be used. It allows users to enter the time directly, while the browser provides additional support. + +Use separate fields for start and end time, and display them clearly together. + + + +## Approximate date + +If users only need to provide month and year, they should be able to do exactly that. This is particularly relevant when the event took place a long time ago and users may not know the exact date. + +For example, you can allow users to enter an approximate date in a free text field, or provide separate fields for month and year only, as shown in the example below. + + + +## Date relative to another date + +In some situations, it is more natural to ask for dates relative to another date, for example when setting up a reminder. In these cases, it may be better to use a [`Select`](/en/components/docs/select/overview) to offer options such as “tomorrow”, “in 3 days” or “1 day before”. If the day of the week is important for the task, it should also be clearly displayed. + + + +## Summary + +Start with the need and choose the solution that allows users to complete the task as quickly as possible. Standard text fields are often more accessible and faster to use than advanced date pickers. + +- Show ready-made options when the alternatives are limited +- Let users type when the answer is known +- Only ask for as precise a date and time as the situation requires +- Use built-in browser support rather than custom-built solutions + +## Sources and relevant information + +- [Who needs a JavaScript date picker? (dbushell.com)](https://pikaday.dbushell.com/) +- [Maybe You Don’t Need a Date Picker (adrianroselli.com)](https://adrianroselli.com/2019/07/maybe-you-dont-need-a-date-picker.html) +- [Ask users for dates (gov.uk)](https://design-system.service.gov.uk/patterns/dates/) + + diff --git a/apps/www/app/content/patterns/en/date-and-time.stories.tsx b/apps/www/app/content/patterns/en/date-and-time.stories.tsx new file mode 100644 index 0000000000..82c86e12b0 --- /dev/null +++ b/apps/www/app/content/patterns/en/date-and-time.stories.tsx @@ -0,0 +1,321 @@ +import { + Field, + Fieldset, + Label, + Link, + Radio, + Select, + Textfield, +} from '@digdir/designsystemet-react'; + +export const KnownDatesEN = () => { + return ( +
+ When were you born? + For example 24 7 1987 + +
+ + + +
+
+ ); +}; + +export const NearFuturePastEN = () => { + return ( + + ); +}; + +export const StartEndDateEN = () => { + return ( +
+ + How long will you be away? + + Enter start and end date +
+ + +
+
+ ); +}; + +export const StartEndTimeEN = () => { + return ( +
+ + How long does the school day last? + + Enter start and end time +
+ + +
+
+ ); +}; + +export const ApproximateDateEN = () => { + return ( +
+ + When did the event occur? + + + Enter an approximate date. We cannot process cases more than 20 years + back. + +
+ + + + + + + + +
+
+ ); +}; + +export const RelativeDateEN = () => { + return ( + + + + + ); +}; + +export const PredefinedOptions1EN = () => { + return ( +
+ When would you like an appointment? + + Choose from the next five available appointments, or select a later + time. + + + + + + + + + + Find available appointments further ahead + +
+ ); +}; + +export const PredefinedOptions2EN = () => { + return ( +
+ + When would you like an appointment? + + + If some weeks are not available, it means there are no free appointments + that week. If you prefer Tuesdays, you can choose a weekday instead of a + week. You will then see all available appointments on Tuesdays going + forward. + + +
+ + + + + + + + + + + + + + +
+ +
+ Select one of the available times + + + + + + +
+
+ ); +}; diff --git a/apps/www/app/content/patterns/en/errors.mdx b/apps/www/app/content/patterns/en/errors.mdx index 82516e7d07..07b05bcc6a 100644 --- a/apps/www/app/content/patterns/en/errors.mdx +++ b/apps/www/app/content/patterns/en/errors.mdx @@ -1,7 +1,7 @@ --- title: User-triggered error messages sidebar_title: Error messages -category: Completed +category: Basic patterns description: How to tell users that something has been filled in incorrectly or is missing in a form. partners: Digdir, Nav, Skatteetaten ++ search_terms: validation diff --git a/apps/www/app/content/patterns/en/external-links.mdx b/apps/www/app/content/patterns/en/external-links.mdx index 77a3d77b5d..3a9b4e1bb5 100644 --- a/apps/www/app/content/patterns/en/external-links.mdx +++ b/apps/www/app/content/patterns/en/external-links.mdx @@ -1,7 +1,7 @@ --- title: Labeling Links description: How should we label links, and which language and design principles should we follow? -category: Completed +category: Basic patterns partners: Digdir, Nav, Skatteetaten ++ search_terms: linktext, target, navigation, url date: 2025-05-12 diff --git a/apps/www/app/content/patterns/en/representation.mdx b/apps/www/app/content/patterns/en/representation.mdx index 1ec20d4dec..b49b256382 100644 --- a/apps/www/app/content/patterns/en/representation.mdx +++ b/apps/www/app/content/patterns/en/representation.mdx @@ -1,7 +1,7 @@ --- title: Sign-in and representation sidebar_title: Representation -category: Upcoming +category: Upcoming patterns description: How do we handle switching between actors across services? partners: Digdir, Nav, Skatteetaten ++ date: 2025-12-03 diff --git a/apps/www/app/content/patterns/en/required-and-optional-fields.mdx b/apps/www/app/content/patterns/en/required-and-optional-fields.mdx index 99057ce79a..89a35d5ed7 100644 --- a/apps/www/app/content/patterns/en/required-and-optional-fields.mdx +++ b/apps/www/app/content/patterns/en/required-and-optional-fields.mdx @@ -1,7 +1,7 @@ --- title: Required and optional form fields sidebar_title: Required fields -category: Completed +category: Basic patterns description: To help users understand which fields must be completed, required fields must be clearly and consistently labelled. partners: Digdir, Nav, Skatteetaten ++ date: 2026-02-02 diff --git a/apps/www/app/content/patterns/en/systemnotifications.mdx b/apps/www/app/content/patterns/en/systemnotifications.mdx index 38c462b7e6..5c4970198b 100644 --- a/apps/www/app/content/patterns/en/systemnotifications.mdx +++ b/apps/www/app/content/patterns/en/systemnotifications.mdx @@ -1,7 +1,7 @@ --- title: System notifications sidebar_title: System notifications -category: Completed +category: Basic patterns description: How to help users understand situations in the service that are not caused by their own actions. partners: Digdir, Nav, Skatteetaten ++ search_terms: alert, modal diff --git a/apps/www/app/content/patterns/en_index.mdx b/apps/www/app/content/patterns/en_index.mdx index e38adde6b2..c47bf2a84e 100644 --- a/apps/www/app/content/patterns/en_index.mdx +++ b/apps/www/app/content/patterns/en_index.mdx @@ -1,5 +1,3 @@ -## Common patterns - If we can establish common patterns, it becomes easier for a user who has done something in one place to recognize and understand how to do it elsewhere. This way, we can help include more people digitally. It is also one of the measures in the "[Action Plan for Increased Inclusion in a Digital Society, measure 26](https://www.regjeringen.no/no/dokumenter/handlingsplan-for-auka-inkludering-i-eit-digitalt-samfunn/id2984233/)", which states that we should work towards more similar interaction patterns across services. Common patterns can, for example, contribute to: @@ -10,36 +8,14 @@ Common patterns can, for example, contribute to: In the report "[Digital throughout life with better user experience](https://www.digdir.no/sammenhengende-tjenester/digital-hele-livet-med-bedre-brukeropplevelse/4405)", several [concrete usability problems](https://github.com/digdir/innsiktsbibliotek/issues/3) have been identified that can be improved if we collaborate on establishing similar patterns across public services. We can collaborate on patterns even if we don't use the same technical components or design elements. -Illustration with arrows pointing in the same direction - -## Cross-agency collaboration - -To establish common patterns across services, the design system teams from **Digdir, Nav, Norwegian Tax Administration, Brønnøysund Register Centre, and Oslo Municipality**, among others, have formed a cross-agency working group to develop common guidelines for interaction patterns. +To establish shared patterns across organisations, we have created a cross-agency pattern collaboration. You can read more about this in the [Collaboration model](/en/intro/collaboration#3-tverretatlig-mønster-samarbeid). -We gather insights from our own organizations, review them, identify differences, and arrive at a common approach through regular work meetings. - -The patterns established through this collaboration are published as articles: - -- [Required and optional form fields](required-and-optional-fields) -- [User-triggered error messages](errors) -- [System notifications](systemnotifications) +We gather insights from our respective organisations, review them together, identify differences, and agree on a shared approach through regular working sessions. Anyone can influence the work through open discussions in [Slack](https://www.designsystemet.no/slack) and [GitHub](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). If you would like to be more closely involved, there is also room for additional participants in the working groups. [Get in touch by email](mailto:designsystem@digdir.no). ## Planned patterns -The patterns that need to be addressed across agencies are documented in [this overview on Github](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). The main group for pattern collaboration prioritizes which patterns to work on and initiates working groups. If you have suggestions for other patterns, you are welcome to [create a new discussion thread](https://github.com/digdir/designsystemet/discussions/new?category=samarbeid-m%C3%B8nster-for-innbyggertjenester). We also appreciate all insights shared in the various topic threads for each pattern. - -## Join the collaboration +Patterns that require cross-agency collaboration are documented in [this GitHub overview](https://github.com/digdir/designsystemet/discussions/categories/patterns-for-public-services?discussions_q=is%3Aopen+category%3A%22Patterns+for+public+services%22+sort%3Atop). -Anyone who wishes can influence the work through open discussions on [Slack](https://www.designsystemet.no/slack) and [Github](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). If you want to be more closely involved in the collaboration, we also have room for more participants in the working groups. [Contact us (email)](mailto:designsystem@digdir.no)! +The main group for the pattern collaboration prioritises which patterns to work on and initiates working groups as needed. If you have suggestions for additional patterns, you are welcome to [start a new discussion thread](https://github.com/digdir/designsystemet/discussions/new?category=samarbeid-m%C3%B8nster-for-innbyggertjenester). -Logos of Digdir, Oslo Municipality, Nav, Norwegian Tax Administration, Brønnøysund Register Centre +We also appreciate any insights shared in the topic threads for each pattern. \ No newline at end of file diff --git a/apps/www/app/content/patterns/no/button-placement-and-order.mdx b/apps/www/app/content/patterns/no/button-placement-and-order.mdx index 08d6652f89..5d782d2d23 100644 --- a/apps/www/app/content/patterns/no/button-placement-and-order.mdx +++ b/apps/www/app/content/patterns/no/button-placement-and-order.mdx @@ -1,7 +1,7 @@ --- title: Plassering og rekkefølge på knapper sidebar_title: Plassering av knapper -category: Kommende +category: Kommende mønstre description: Hvordan kan vi skape en mer forutsigbar og inkluderende opplevelse ved å standardisere plassering og rekkefølge på knapper? partners: Digdir, Nav, Skatteetaten ++ search_terms: button, knapperekkefølge, knappplassering @@ -17,7 +17,7 @@ Ulik plassering og rekkefølge på knapper, særlig navigasjonsknapper, kan skap variant="tinted" > **Arbeid pågår** \ -En tverretatlig arbeidsgruppe arbeider høsten 2025 med å utvikle felles retningslinjer og anbefalinger for dette temaet. Vi setter stor pris på innspill fra alle som har erfaringer, innsikt eller resultater fra brukertester. Bidra gjerne i den tilhørende [diskusjontråden på github.com](https://github.com/digdir/designsystemet/discussions/1671). +En tverretatlig arbeidsgruppe arbeider med å utvikle felles retningslinjer og anbefalinger for dette temaet. Vi setter stor pris på innspill fra alle som har erfaringer, innsikt eller resultater fra brukertester. Bidra gjerne i den tilhørende [diskusjontråden på github.com](https://github.com/digdir/designsystemet/discussions/1671). diff --git a/apps/www/app/content/patterns/no/consent-banner.mdx b/apps/www/app/content/patterns/no/consent-banner.mdx new file mode 100644 index 0000000000..f3f75371d5 --- /dev/null +++ b/apps/www/app/content/patterns/no/consent-banner.mdx @@ -0,0 +1,29 @@ +--- +title: Samtykkebanner +sidebar_title: Samtykkebanner +category: Kommende mønstre +description: Hvordan kan vi sikre helhetlig og tilgjengelig håndtering av samtykke til informasjonskapsler og sporingsteknologi? +partners: Digdir, Nav, Skatteetaten ++ +search_terms: consent banner, cookie banner, cookies, samtykke, personvern +date: 2026-02-16 +order: 75 +--- + +Et samtykkebanner skal gi brukeren reell kontroll over egne data. Samtidig skal det være tydelig, forståelig og tilgjengelig for alle. I dag løses dette ulikt på tvers av offentlige tjenester, både når det gjelder språk, utforming, likeverdige valg og teknisk implementering. + +Et felles mønster for samtykkebanner kan bidra til: + +- Mer konsekvent og gjenkjennelig brukeropplevelse +- Likeverdig presentasjon av valg, uten manipulerende design +- Bedre tilgjengelighet og universell utforming +- Tydeligere avgrensning mellom nødvendige og valgfrie teknologier +- Felles forståelse av anbefalt interaksjon og oppførsel + + +**Arbeid pågår** \ +En tverretatlig arbeidsgruppe arbeider våren 2026 med å utvikle felles retningslinjer og anbefalinger for dette temaet. Vi setter stor pris på innspill fra alle som har erfaringer, innsikt eller resultater fra brukertester. Bidra gjerne i den tilhørende [diskusjontråden på github.com](https://github.com/digdir/designsystemet/discussions/1671). + + diff --git a/apps/www/app/content/patterns/no/date-and-time.mdx b/apps/www/app/content/patterns/no/date-and-time.mdx new file mode 100644 index 0000000000..bca3a7bef9 --- /dev/null +++ b/apps/www/app/content/patterns/no/date-and-time.mdx @@ -0,0 +1,99 @@ +--- +title: Spør brukerne om dato og klokkeslett +sidebar_title: Dato og klokkeslett +category: Spør brukerne om... +description: Å spørre brukerne om dato og klokkeslett blir ofte løst mer komplisert enn nødvendig. I mange situasjoner er vanlige input-felt både raskere å bruke og lettere å forstå enn egenbygde datovelgere. +partners: Digdir, Brønnøysundregistrene +date: 2026-02-18 +order: 10 +--- + +Hvordan du ber brukerne om dato og klokkeslett, bør ta utgangspunkt i hvilken informasjon du faktisk trenger. Noen datoer er enkle å huske, som fødselsdato, mens andre må leses fra dokumenter eller kort. I noen situasjoner holder det med en omtrentlig dato, eller et tidspunkt i forhold til i dag. Andre ganger skal brukerne velge en dato eller et tidspunkt fra et forhåndsdefinert utvalg. + +Unngå å gjøre oppgaven mer komplisert enn nødvendig. Egenbygde datovelgere gir ofte lavere tilgjengelighet og mer friksjon enn enkle tekstfelt. De kan være vanskelige å bruke med tastatur, gi dårlig støtte for skjermleser og kreve unødvendig navigering når brukerne allerede kjenner datoen. + +## Kjente datoer + +Når du spør om kjente datoer, som fødselsdato eller bryllupsdato, fungerer enkle tekstfelt godt. Brukerne vet allerede svaret og ønsker ofte å skrive det direkte, uten å måtte navigere i en kalender. + +Del gjerne datoen opp i separate felt for dag, måned og år. Det gjør det enklere å skrive inn datoen korrekt og gir bedre støtte for hjelpemidler. + + + +Når du ber brukerne om en dato slik den står i et bankkort, pass eller annet dokument, bør feltene samsvare med formatet i dokumentet. Det gjør det enklere å overføre datoen korrekt og reduserer risikoen for feil. + +## Dato fra et forhåndsdefinert utvalg + +Hvis du vet at brukerne skal velge en dato eller et tidspunkt fra et begrenset utvalg, for eksempel ledige timer den kommende uken, kan det være mer effektivt å tilby disse som ferdige valg. + +Når utvalget er svært begrenset, for eksempel noen få datoer eller tidspunkter, kan [`Radio`](/no/components/docs/radio/overview) være et godt valg. Det gjør det raskt og enkelt å velge et alternativ uten å måtte skrive noe selv. + + + +### La brukerne begrense utvalget +Når antall valg øker, kan en [`Select`](/no/components/docs/select/overview) være nyttig for å begrense utvalget. Da kan brukerne velge blant foretrukne uker, dager eller klokkeslett, og deretter se de tilgjengelige alternativene for det valget. NB: Eksempelet under er ikke fungerende, da det ikke er koblet til et faktisk utvalg av datoer eller klokkeslett, men illustrerer hvordan du kan la brukerne begrense utvalget før de ser de tilgjengelige alternativene. + + + +Du bør kun vise valg som har ledige timer, og unngå å for eksempel deaktivere uker som ikke har ledige timer, da det kan skape forvirring. Forklar i forkant at det kun er uker med ledige tidspunkt som vises, slik at brukerne forstår hvorfor noen uker ikke er tilgjengelige å velge. + +## Konkret dato i nær fremtid eller fortid + +I noen tilfeller når brukerne skal velge en konkret dato tett opp mot dagens dato kan det være nyttig med visuell støtte. En [`Input`](/no/components/docs/input/overview) med `type="date"` lar brukerne enten skrive datoen direkte eller bruke nettleserens innebygde datovelger. Dette gir ofte en god balanse mellom fleksibilitet og støtte. Støtten varierer mellom nettlesere og enheter, både når det gjelder funksjonalitet, utseende og interaksjon, men løsningen er ofte mer tilgjengelig og robust enn egenbygde alternativer. + + + +## Start- og sluttdato + +Når brukerne skal oppgi en periode, bør startdato og sluttdato vises tydelig sammen. Bruk to separate felt, og gjør det klart hvilken dato som er hvilken. + +Plasser feltene i logisk rekkefølge, og valider at sluttdato ikke er før startdato. Hvis datoene avhenger av hverandre, bør feilmeldinger forklare hva som er galt og hvordan brukerne kan rette det. + + + +## Klokkeslett – start og slutt + +Når brukerne skal oppgi et tidsintervall, som åpningstid eller varighet på et møte, kan en [`Input`](/no/components/docs/input/overview) med `type="time"` brukes. Det lar brukerne skrive klokkeslettet direkte, samtidig som nettleseren tilbyr støtte. + +Bruk separate felt for start- og sluttid, og vis dem tydelig sammen. + + + +## Omtrentlig tidspunkt +Hvis brukerne bare trenger å oppgi måned og år, bør det være mulig å gjøre nettopp det. Dette er særlig relevant når hendelsen ligger langt tilbake i tid, og brukerne ikke nødvendigvis vet nøyaktig tidspunkt. + +For eksempel kan du la brukerne oppgi omtrentlig tid i et fritekstfelt, eller tilby egne felt for kun måned og år slik som i eksempelet under. + + + +## Dato relativt til en annen dato + +I noen situasjoner er det mer naturlig å spørre om tidspunkter relativt til en annen dato, for eksempel når brukerne setter opp en påminnelse. Da kan det være bedre å bruke en [`Select`](/no/components/docs/select/overview) for å gi brukerne valg om «i morgen», «om 3 dager» eller «1 dag før». Hvis ukedag er viktig for oppgaven, bør denne vises tydelig i tillegg. + + + +## Oppsummering + +Start med behovet, og velg den løsningen som lar brukerne løse oppgaven raskest mulig. Ofte er vanlige tekstfelt mer tilgjengelige og raskere å bruke enn avanserte datovelgere. + +- Vis ferdige valg når alternativene er begrensede +- La brukerne skrive når svaret er kjent +- Spør bare om så presis dato og tid som situasjonen krever +- Bruk innebygd nettleserstøtte fremfor egenbygde løsninger + +## Kilder og relevant informasjon +- [Who needs a JavaScript date picker? (dbushell.com)](https://pikaday.dbushell.com/) +- [Maybe You Don’t Need a Date Picker (adrianroselli.com)](https://adrianroselli.com/2019/07/maybe-you-dont-need-a-date-picker.html) +- [Ask users for dates (gov.uk)](https://design-system.service.gov.uk/patterns/dates/) + + diff --git a/apps/www/app/content/patterns/no/date-and-time.stories.tsx b/apps/www/app/content/patterns/no/date-and-time.stories.tsx new file mode 100644 index 0000000000..fc006af099 --- /dev/null +++ b/apps/www/app/content/patterns/no/date-and-time.stories.tsx @@ -0,0 +1,317 @@ +import { + Field, + Fieldset, + Label, + Link, + Radio, + Select, + Textfield, +} from '@digdir/designsystemet-react'; + +export const KnownDates = () => { + return ( +
+ Når ble du født? + For eksempel 24 7 1987 + +
+ + + +
+
+ ); +}; + +export const NearFuturePast = () => { + return ( + + ); +}; + +export const StartEndDate = () => { + return ( +
+ + Hvor lenge skal du være borte? + + Oppgi start- og sluttdato +
+ + +
+
+ ); +}; + +export const StartEndTime = () => { + return ( +
+ + Hvor lenge varer skoledagen? + + Oppgi start- og sluttid +
+ + +
+
+ ); +}; + +export const ApproximateDate = () => { + return ( +
+ Når skjedde hendelsen? + + Oppgi omtrentlig tidspunkt. Vi kan ikke behandle saker lengre enn 20 år + tilbake i tid. + +
+ + + + + + + + +
+
+ ); +}; + +export const RelativeDate = () => { + return ( + + + + + ); +}; + +export const PredefinedOptions1 = () => { + return ( +
+ Når vil du ha time? + + Velg blant de neste fem ledige timene vi har, eller velg et senere + tidspunkt. + + + + + + + + + + + + + + Finn ledige timer lengre frem i tid + +
+ ); +}; + +export const PredefinedOptions2 = () => { + return ( +
+ Når vil du ha time? + + Dersom noen uker ikke er tilgjengelige å velge, betyr det at det ikke + finnes ledige tidspunkt i den uken. Foretrekker du tirsdager, kan du + velge en bestemt ukedag i stedet for uke. Da vises alle ledige tidspunkt + på tirsdager fremover. + + +
+ + + + + + + + + + + + + + +
+ +
+ Velg et av de ledige tidspunktene + + + + + + + + + + +
+
+ ); +}; diff --git a/apps/www/app/content/patterns/no/errors.mdx b/apps/www/app/content/patterns/no/errors.mdx index 99fb1f621e..7c775f4122 100644 --- a/apps/www/app/content/patterns/no/errors.mdx +++ b/apps/www/app/content/patterns/no/errors.mdx @@ -1,7 +1,7 @@ --- title: Brukerutløste feilmeldinger sidebar_title: Feilmeldinger -category: Ferdig +category: Grunnleggende mønstre description: Slik forteller du brukeren at noe er fylt ut feil eller mangler i et skjema. partners: Digdir, Nav, Skatteetaten ++ search_terms: validation, validering, feil diff --git a/apps/www/app/content/patterns/no/external-links.mdx b/apps/www/app/content/patterns/no/external-links.mdx index dbcd49d16a..04f462f9e4 100644 --- a/apps/www/app/content/patterns/no/external-links.mdx +++ b/apps/www/app/content/patterns/no/external-links.mdx @@ -1,7 +1,7 @@ --- title: Merking av lenker description: Hvordan merke lenker og hvilke språk- og designprinsipper bør vi følge? -category: Ferdig +category: Grunnleggende mønstre partners: Digdir, Nav, Skatteetaten ++ search_terms: url, lenketekst, ekstern date: 2025-05-12 diff --git a/apps/www/app/content/patterns/no/representation.mdx b/apps/www/app/content/patterns/no/representation.mdx index fbdfc14ea0..3eac60f6bf 100644 --- a/apps/www/app/content/patterns/no/representation.mdx +++ b/apps/www/app/content/patterns/no/representation.mdx @@ -1,7 +1,7 @@ --- title: Innlogging og representasjon sidebar_title: Representasjon -category: Kommende +category: Kommende mønstre description: Hvordan håndterer vi aktørbytte på tvers av tjenester? partners: Digdir, Nav, Skatteetaten ++ date: 2025-12-03 diff --git a/apps/www/app/content/patterns/no/required-and-optional-fields.mdx b/apps/www/app/content/patterns/no/required-and-optional-fields.mdx index 92aa4dac71..fc7e72a23d 100644 --- a/apps/www/app/content/patterns/no/required-and-optional-fields.mdx +++ b/apps/www/app/content/patterns/no/required-and-optional-fields.mdx @@ -1,7 +1,7 @@ --- title: Obligatoriske og valgfrie skjemafelt sidebar_title: Obligatoriske felt -category: Ferdig +category: Grunnleggende mønstre description: For at brukerne skal forstå hvilke felter som må fylles ut, må obligatoriske felt merkes tydelig og konsekvent. partners: Digdir, Nav, Skatteetaten ++ search_terms: required, optional, påkrevd, valgfritt diff --git a/apps/www/app/content/patterns/no/systemnotifications.mdx b/apps/www/app/content/patterns/no/systemnotifications.mdx index f2a082516c..912ba841a0 100644 --- a/apps/www/app/content/patterns/no/systemnotifications.mdx +++ b/apps/www/app/content/patterns/no/systemnotifications.mdx @@ -1,7 +1,7 @@ --- title: Systemvarsler sidebar_title: Systemvarsler -category: Ferdig +category: Grunnleggende mønstre description: Slik hjelper du brukerne å forstå situasjoner i tjenesten som ikke skyldes deres egne handlinger. partners: Digdir, Nav, Skatteetaten ++ search_terms: alert, modal, systemvarsel, systemmelding diff --git a/apps/www/app/content/patterns/no_index.mdx b/apps/www/app/content/patterns/no_index.mdx index 049d5527f8..bdf1ef95bb 100644 --- a/apps/www/app/content/patterns/no_index.mdx +++ b/apps/www/app/content/patterns/no_index.mdx @@ -1,5 +1,3 @@ -## Felles mønstre - Klarer vi å etablere felles mønstre blir det lettere for en bruker som har gjort noe et sted å kjenne igjen og forstå hvordan det skal gjøres et annet sted. På den måten kan vi bidra til å inkludere flere digitalt. Det er også et av tiltakene i "[Handlingsplanen for Økt inkludering i et digitalt samfunn, tiltak 26](https://www.regjeringen.no/no/dokumenter/handlingsplan-for-auka-inkludering-i-eit-digitalt-samfunn/id2984233/)" ,der det står at vi skal jobbe for mer like interaksjonsmønstre på tvers. Felles mønstre kan for eksempel bidra til at: @@ -10,36 +8,11 @@ Felles mønstre kan for eksempel bidra til at: I rapporten "[Digital hele livet med bedre brukeropplevelse](https://www.digdir.no/sammenhengende-tjenester/digital-hele-livet-med-bedre-brukeropplevelse/4405)" er det funnet flere [konkrete problemer med brukskvalitet](https://github.com/digdir/innsiktsbibliotek/issues/3) som kan forbedres dersom vi samarbeider om å etablere like mønstre på tvers av offentlige tjenester. Vi kan samarbeide om mønstre selv om vi ikke bruker de samme tekniske komponentene eller designelementene. -Illustrasjon med piler som går i samme retning - -## Tverretatlig samarbeid - -For å etablere felles mønstre på tvers har designsystem-teamene til **Digdir, Nav, Skattetaten, Brønnøysundregistrene og Oslo kommune** med flere, gått sammen om en tverretatlig arbeidsgruppe for å utarbeide felles retningslinjer for interaksjonsmønstre. - -Vi samler innsikt fra egne organisasjoner, gjennomgår dette, identifiserer ulikheter og lander på en felles tilnærming gjennom jevnlige arbeidsmøter. +For å etablere felles mønstre på tvers har vi etablert et mønster-samarbeid med flere virksomheter, les mer om dette i [Samarbeidsmodell](/no/intro/collaboration#3-tverretatlig-mønster-samarbeid). -Mønstrene som er landet i fellesskap er publisert som artikler: +Vi samler innsikt fra egne organisasjoner, gjennomgår dette, identifiserer ulikheter og lander på en felles tilnærming gjennom jevnlige arbeidsmøter. Alle som ønsker kan påvirke arbeidet gjennom åpne diskusjoner i [Slack](https://www.designsystemet.no/slack) og [Github](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). Ønsker du å være tettere på samarbeidet har vi også plass til flere i arbeidsgruppene. [Ta kontakt (epost)](mailto:designsystem@digdir.no)! -- [Obligatoriske og valgfrie skjemafelt](required-and-optional-fields) -- [Brukerutløste feilmeldinger](errors) -- [Systemvarsler](systemnotifications) ## Planlagte mønstre -Mønstrene det er behov for å jobbe med på tvers dokumenteres i [denne oversikten på Github](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). Det er hovedgruppen for mønster-samarbeidet som prioriterer hvilke mønstre som skal jobbes med og igangsetter arbeidsgrupper. Har du forslag til andre mønstre, er du velkommen til å [opprette en ny diskusjonstråd](https://github.com/digdir/designsystemet/discussions/new?category=samarbeid-m%C3%B8nster-for-innbyggertjenester). Vi setter også pris på alt av innsikt som deles i de ulike tema-trådene per mønster. - -## Bli med på samarbeidet - -Alle som ønsker kan påvirke arbeidet gjennom åpne diskusjoner i [Slack](https://www.designsystemet.no/slack) og [Github](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). Ønsker du å være tettere på samarbeidet har vi også plass til flere i arbeidsgruppene. [Ta kontakt (epost)](mailto:designsystem@digdir.no)! - -Logoene til Digdir, Oslo kommune, Nav, Skatteetaten, Brønnøysundregistrene +Mønstrene det er behov for å jobbe med på tvers dokumenteres i [denne oversikten på Github](https://github.com/digdir/designsystemet/discussions/categories/patterns-for-public-services?discussions_q=is%3Aopen+category%3A%22Patterns+for+public+services%22+sort%3Atop). Det er hovedgruppen for mønster-samarbeidet som prioriterer hvilke mønstre som skal jobbes med og igangsetter arbeidsgrupper. Har du forslag til andre mønstre, er du velkommen til å [opprette en ny diskusjonstråd](https://github.com/digdir/designsystemet/discussions/new?category=samarbeid-m%C3%B8nster-for-innbyggertjenester). Vi setter også pris på alt av innsikt som deles i de ulike tema-trådene per mønster. \ No newline at end of file diff --git a/apps/www/app/layouts/patterns/layout.tsx b/apps/www/app/layouts/patterns/layout.tsx index addb4bbc3e..caa2b0ea17 100644 --- a/apps/www/app/layouts/patterns/layout.tsx +++ b/apps/www/app/layouts/patterns/layout.tsx @@ -38,15 +38,15 @@ export const loader = async ({ params: { lang } }: Route.LoaderArgs) => { } = {}; if (lang === 'no') { - cats.Ferdig = []; - cats['Under arbeid'] = []; - cats.Kommende = []; + cats['Grunnleggende mønstre'] = []; + cats['Spør brukerne om...'] = []; + cats['Kommende mønstre'] = []; } if (lang === 'en') { - cats.Completed = []; - cats['Under construction'] = []; - cats.Coming = []; + cats['Basic patterns'] = []; + cats['Ask users for...'] = []; + cats['Upcoming patterns'] = []; } /* Map over files with mdx parser to get title */ diff --git a/apps/www/public/img/date-and-time/example1.webp b/apps/www/public/img/date-and-time/example1.webp new file mode 100644 index 0000000000..e201c0004b Binary files /dev/null and b/apps/www/public/img/date-and-time/example1.webp differ diff --git a/apps/www/public/img/date-and-time/example10.webp b/apps/www/public/img/date-and-time/example10.webp new file mode 100644 index 0000000000..5d41d97456 Binary files /dev/null and b/apps/www/public/img/date-and-time/example10.webp differ diff --git a/apps/www/public/img/date-and-time/example11.webp b/apps/www/public/img/date-and-time/example11.webp new file mode 100644 index 0000000000..68f9f6f048 Binary files /dev/null and b/apps/www/public/img/date-and-time/example11.webp differ diff --git a/apps/www/public/img/date-and-time/example2.webp b/apps/www/public/img/date-and-time/example2.webp new file mode 100644 index 0000000000..710dcf2d78 Binary files /dev/null and b/apps/www/public/img/date-and-time/example2.webp differ diff --git a/apps/www/public/img/date-and-time/example3.webp b/apps/www/public/img/date-and-time/example3.webp new file mode 100644 index 0000000000..39de835ed0 Binary files /dev/null and b/apps/www/public/img/date-and-time/example3.webp differ diff --git a/apps/www/public/img/date-and-time/example4.webp b/apps/www/public/img/date-and-time/example4.webp new file mode 100644 index 0000000000..68fe697ab2 Binary files /dev/null and b/apps/www/public/img/date-and-time/example4.webp differ diff --git a/apps/www/public/img/date-and-time/example5.png b/apps/www/public/img/date-and-time/example5.png new file mode 100644 index 0000000000..185c66cc4e Binary files /dev/null and b/apps/www/public/img/date-and-time/example5.png differ diff --git a/apps/www/public/img/date-and-time/example6.png b/apps/www/public/img/date-and-time/example6.png new file mode 100644 index 0000000000..6ee35e013c Binary files /dev/null and b/apps/www/public/img/date-and-time/example6.png differ diff --git a/apps/www/public/img/date-and-time/example7.webp b/apps/www/public/img/date-and-time/example7.webp new file mode 100644 index 0000000000..2f2b875f75 Binary files /dev/null and b/apps/www/public/img/date-and-time/example7.webp differ diff --git a/apps/www/public/img/date-and-time/example8.webp b/apps/www/public/img/date-and-time/example8.webp new file mode 100644 index 0000000000..97f2b779aa Binary files /dev/null and b/apps/www/public/img/date-and-time/example8.webp differ diff --git a/apps/www/public/img/date-and-time/example9.webp b/apps/www/public/img/date-and-time/example9.webp new file mode 100644 index 0000000000..4c37714c4f Binary files /dev/null and b/apps/www/public/img/date-and-time/example9.webp differ