likeperson.md

# Tverrgående workshopsammendrag

## Behovskartlegging – Likepersonsapp

**Norse Digital Products | NHF, Blindeforbundet, HLF, Barnekreftforeningen**
**Version 4.0.0**

Dette dokumentet oppsummerer fellestrekkene og de unike behovene på tvers av workshoppene med Norges Handikapforbund (NHF), Norges Blindeforbund og Hørselsforbundet (HLF). Barnekreftforeningen inngikk i forprosjektet og er ikke inkludert som egen workshopdeltaker her. Formålet er å gi teamet et prioriteringsgrunnlag for videre utvikling.

> **Note on reuse.** Parts of this document describe patterns (module toggles, area taxonomy, decoupled auth module, organization labels) that are specific to *this* platform's multi-tenant, multi-organization shape. Other products generated from a source doc via the same pipeline will not necessarily share that shape — a single-tenant SaaS, an internal tool, or a fixed-scope deliverable typically should **not** adopt module toggles or per-tenant label overrides. Each architectural pattern below is scoped with an applicability note; treat them as options justified by stated constraints, not defaults.

## 1. Felles behov – går igjen i alle tre organisasjoner

Følgende behov ble løftet frem – ofte ord for ord – i alle tre workshops. Dette er kjernen i hva appen MÅ løse.

### 1.1 Enkel aktivitetsregistrering (#1-prioritet hos alle)

Alle tre organisasjoner peker på dette som den aller viktigste funksjonen, og beskriver dagens situasjon som uholdbar. Fellesnevneren er at rapporteringen er så tungvint at det fører til massiv underrapportering – enten fordi folk ikke orker, eller fordi de ikke engang skjønner at det de gjør teller.

- **NHF:** Word-skjemaer sendes manuelt til regioner → manuell Excel-aggregering sentralt. Mål: registrering på under to klikk.
- **Blindeforbundet:** Digitalisere eksisterende Word-rapportskjema. Kortfattet rapport etter hjemmebesøk med avkrysning + fritekst + tale-til-tekst.
- **HLF:** En likeperson hadde 380 enkeltregistreringer på ett år. Standardverdier (dagens dato, 30 min) som kan overstyres. 60–70 % av registreringene er uten refusjon og skal være ekstremt enkle.

> **Designprinsipp:** Lavest mulig kognitiv belastning. Standardvalg, gjenkjennelig logikk, færrest mulig steg.

### 1.2 Universell utforming (WCAG 2.2 AA)

Alle tre organisasjoner har brukere med svært ulike forutsetninger – motoriske, kognitive og sensoriske. Appen SKAL oppfylle **WCAG 2.2 nivå AA** som minimumskrav for alle skjermer og interaksjoner.

- **WCAG 2.2 AA compliance** er et absolutt krav for MVP – ikke noe som fikses etterpå.
- **Skjermleser-støtte (VoiceOver/JAWS):** Alle interaktive elementer skal ha semantiske labels og ARIA-attributter. Særlig kritisk for Blindeforbundet, men relevant for alle.
- **Kognitiv tilgjengelighet:** NHF nevner spesifikt slagrammede. Enkel navigasjon, logisk flyt, ikke for mange valg. Tydelige feilmeldinger med forslag til løsning.
- **Kontrast og typografi:** Minimum 4.5:1 kontrast for tekst, 3:1 for store tekstelementer og UI-komponenter. Skalerbar skrift opp til 200%. Unngå tynne/kursive fonter.
- **Touch targets:** Minimum 24x24 CSS-piksler for alle interaktive elementer (WCAG 2.2 target size).
- **Tastaturnavigasjon:** Alle funksjoner tilgjengelige via tastatur. Synlig fokusindikator.
- Tilbakeknapp fremfor sidelengs-sveip. Vertikal scroll er normen.
- Varsling ved opplesning av sensitive felt (NHF).
- **Drag-and-drop alternativer:** Alle drag-baserte interaksjoner skal ha et ikke-drag alternativ (WCAG 2.2 dragging movements).

### 1.3 BankID / Vipps innlogging

Alle tre organisasjoner peker på BankID eller Vipps som foretrukket autentisering ved førstegangs innlogging, med biometrisk innlogging (Face ID / fingeravtrykk) etterpå. En viktig bieffekt: Vipps-innlogging kan returnere personnummer tilbake til medlemssystemene, som i dag mangler dette for mange brukere.

### 1.4 Sømløs Bufdir-rapportering

Alle tre organisasjoner mottar Bufdir-tilskudd og bruker mye tid på rapportering. Ønsket er det samme: trykk på én knapp og få ut det Bufdir trenger. Norse Digital Products tar initiativ til dialog med Bufdir på vegne av alle organisasjonene.

### 1.5 Inkrementell utrulling – parallelle systemer

Sterk enighet på tvers: Eksisterende løsninger må fungere parallelt til appen er godt etablert. Ingen av organisasjonene tåler et hard-cut. Appen skal introduseres som et til-bud, ikke et pålegg.

- **NHF:** «Ikke steng det gamle før folk er klare.»
- **HLF:** Rapportering kan ikke kuttes i påvente av appen – systemene må leve side om side.
- **Blindeforbundet:** Stegvis digitalisering etter bankenes modell for nettbankutrulling.

### 1.6 Testoppsett: TestFlight, 5–8 personer, én kontaktperson

Alle tre organisasjoner er enige om samme testmetode: iOS-distribusjon via TestFlight, 5–8 testpersoner med spenn i kjønn, alder og digitale ferdigheter, og én dedikert kontaktperson per organisasjon som filtrerer og samler tilbakemeldinger. Første testversjon er målsatt til våren.

## 2. Delte behov – nevnt av to av tre organisasjoner

Disse behovene er ikke universelle, men er sterke nok til å vurderes som del av kjerneprodukt.

### 2.1 Reiserefusjon og utleggsregistrering (HLF + Blindeforbundet)

Begge organisasjoner har behov for registrering av kilometergodtgjørelse, bompenger, parkering og kollektivt. Behovene er like, men HLF har mest detaljert krav:

- Faste valg for utleggstype – ikke fritekst – for å hindre feilkombinasjon (f.eks. både km og bussbillett).
- Kvitteringsbilde for utlegg over 100 kr (HLF).
- Automatisk godkjenning under 50 km / uten utlegg, manuell attestering ellers (HLF).
- Sjåfærhonorarer og taushetseerklæringer for sjåfører (Blindeforbundet).
- API-integrasjon mot regnskapssystem (Xledger for Blindeforbundet, Dynamics-portal for HLF).

### 2.2 Gamification og synliggjøring av innsats (NHF + HLF)

Begge organisasjoner er inspirert av Spotify Wrapped og ønsker en funksjon som viser likepersonens bidrag over tid – «Din likepersonsårek». Målet er å gi frivillige stolthet og motivasjon, og gjøre usynlig innsats synlig. Også nevnt: «Årets koordinator», statusbadges og halvårsoppsummeringer.

### 2.3 Pausefunksjon for likepersoner (NHF + HLF)

Likepersoner skal kunne sette seg på pause (midlertidig deaktivering) uten å melde seg ut. Koordinator må varsles. HLF kobler dette til sertifisering: ved utgått sertifikat forsvinner likepersonen fra lokallagets nettsider automatisk.

### 2.4 Koordinator kan rapportere på vegne av andre / bulkregistrering (NHF + HLF)

Ikke alle likepersoner vil eller kan bruke appen. Koordinatorer må ha mulighet til å registrere aktivitet på vegne av sine likepersoner, enten enkeltvis eller samlet for faste aktiviteter (f.eks. ukentlig trening med mange deltakere).

### 2.5 Tale-til-tekst i rapportskriving (Blindeforbundet + HLF)

Begge organisasjoner ønsker mulighet for å snakke inn rapporter fremfor å skrive. Blindeforbundet understreker at opptak under selve samtalen er uønsket – tale-til-tekst er for etterpå, ved rapportskriving.

## 3. Unike behov per organisasjon

### 3.1 Norges Blindeforbund – unike behov

- **Kryptert oppdragshåndtering:** Sende sensitive personopplysninger (navn, adresse, epikrise) til likepersoner med leveringsbekreftelse og lesebekreftelse. Statusoversikt over åpne oppdrag.
- Automatisk påminnelse etter 10 dager dersom kontakt ikke er opprettet.
- **Telling av oppdrag per RK:** Kontorhonorar utløses ved 3. oppdrag, høyere sats ved 15.
- **Formalisert rapportstruktur etter hjemmebesøk:** Helsetilstand, kursinteresse, hjelpemiddelsituasjon, «veien videre» – fungerer som bestilling til koordinatoren.
- Sterk motstand mot lydopptak under hjemmebesøk – sperrer for åpen samtale.
- **Geografisk kartvisning** av likepersoner for matching og oppdragstildeling (særlig store fylker).
- **Mentorordning (karriereverksted):** Eget notatverktøy, to-do-lister og deltakerlister for gruppeveiledning over to dager.
- Gradvis digitalisering av fullmakter og epikriser med manuelt fallback.

### 3.2 Norges Handikapforbund – unike behov

- **Kognitiv tilgjengelighet som topprioritering:** Spesielt slagrammede og personer med kognitive utfordringer blant brukerne.
- **Håndtering av medlemmer i flere lokallag (opptil 5):** Avklare tilhørighet og hindre dobbeltrapportering.
- **Duplikatvarsling:** Fange opp når samme aktivitet registreres av flere koordinatorer.
- **Dokumentvedlegg til aktiviteter:** Invitasjoner, Facebook-skjermbilder m.m. – viktig for Bufdir-etterprøving.
- Samisk språkstøtte vurdert på sikt (NHF har samisk tilknytning).
- **Bredest organisasjonsstruktur:** 12 landsforeninger, 9 regioner, 1 400 lokallag – aktivitetsfordeling mellom ledd må støttes.

### 3.3 Hørselsforbundet – unike behov

- **Detaljert refusjonsstyring** med faste valg som gjør feilkombinasjon teknisk umulig (f.eks. km + bussbillett kan ikke velges samtidig). Automatisk godkjenning under terskel.
- **Kursadministrasjon og sertifisering:** Påmelding til kurs i appen, automatisk påminnelse ved utløp, digitale sertifikater. Det fysiske kortet er et «adelsmerke» og skal leve parallelt.
- **Koordinering med eget portalprosjekt:** HLF redesigner «min side» på Dynamics-plattformen. Appen og portalen må ikke overlappe eller motarbeide hverandre.
- **Oppfølging av likepersoner:** 40 % var ikke fornøyd med oppfølgingen i spørreundersøkelse. Scenariobaserte push-meldinger og kalendersynkronisering.
- **Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel).

## 4. Behovsoversikt – prioriteringsmatrise

> **How to read this matrix.** It is a workshop snapshot of divergent stakeholder needs — the input that motivated the module-toggle architecture below. It is **not** a development spec and should not drive per-organization code branches. Authoritative per-org scope lives in the module toggle registry (see *Module Toggles per Organization*). The Prioritet and Fase columns are indicative only; the current roadmap lives in sections 5 and 7 and will drift as priorities shift.

| Behov / Funksjon | Barnekreft | NHF | Blindeforbundet | HLF | Prioritet | Fase |
|-|-|-|-|-|-|-|
| Enkel aktivitetsregistrering | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
| Universell utforming / tilgjengelighet | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 (2 Blind.) |
| BankID / Vipps innlogging | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 |
| Bufdir-rapportering (automatisert) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 3 |
| Parallelle systemer i overgang | ✓ | ✓ | ✓ | ✓ | MUST HAVE | - |
| TestFlight-oppsett (iOS) / Apptester (Android), én kontaktperson | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
| Reiserefusjon / utleggsregistrering | – | – | ✓ | ✓ | SHOULD HAVE | 2 |
| Gamification / Spotify Wrapped | ✓ | ✓ | – | ✓ | NICE TO HAVE | 4 |
| Pausefunksjon for likepersoner | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 |
| Bulkregistrering / proxy-rapportering | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 |
| Tale-til-tekst | – | – | ✓ | ✓ | SHOULD HAVE | 2 |
| Kryptert informasjon | ✓ | ✓ | ✓ | ✓ | MUST | 1 |
| Formalisert rapportstruktur | ✓ | – | ✓ | – | NICE (Blindeforbundet) | 4 |
| Kursadministrasjon / sertifisering | ✓ | – | – | ✓ | SHOULD (HLF) | 4 |
| Koordinering med ekstern portal | – | – | – | ✓ | MUST (HLF) | 3 |
| Dokumentvedlegg til aktiviteter | – | ✓ | – | – | NICE TO HAVE | 3 |
| Admingrensesnitt for org (Admin Panel – Next.js) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 |
| Snakkekort | ✓ | ✓ | ✓ | ✓ | NICE | 3 |
| Eksterne lenker til ressurser | ✓ | ✓ | ✓ | ✓ | NICE | 2 |
| Pårørende database | ✓ | – | – | – | NEED | 1 |
| Basic search (contact and notater) | ✓ | ✓ | ✓ | ✓ | MUST | 1 |
| Notater | ✓ | ✓ | ✓ | ✓ | NICE | 2 |

### Product Landscape — Meander Platform

Meander is the platform. It ships as four distinct products, each serving different users and purposes. The three user-facing products share the same PostgreSQL database and the same authentication module.

**Product 1: Meander Mobile App** (Flutter)
- Purpose: Day-to-day operational tool for peer mentors and coordinators
- Users: Peer Mentors (Likepersoner), Coordinators
- Core capabilities:
  - Activity registration (quick logging, wizards, bulk/proxy)
  - Contact and peer mentor management
  - Travel expense registration
  - Personal statistics and impact summaries
  - Push notifications and assignment tracking
  - Speech-to-text input, document attachments
  - Gamification (wrapped summaries, badges)
- Tech: Flutter, Riverpod (no codegen), Drift (offline), WCAG 2.2 AA

**Product 2: Admin Web Portal** (Next.js)
- Purpose: Organization management, reporting, and oversight
- Users: Organization Admins, Coordinators, Global Admins
- Core capabilities:
  - User management (invite, deactivate, role assignment)
  - Organization settings and terminology/labels configuration
  - Bufdir report generation and one-click export
  - Activity oversight, approval workflows, and corrections
  - Reimbursement approval and expense oversight
  - Coordinator and organization-level dashboards and KPIs
  - Multi-organization hierarchy management
  - Course and certification administration
- Tech: Next.js on Vercel, server-side rendering, same auth system

**Product 3: Authentication Module**
- Purpose: Issue and validate credentials for every Meander product. Treated as its own product — not a feature of any single product — because it must be decouplable and movable into its own service or repository at any time without forcing changes on consumers.
- Users: Every other Meander product that needs to know who a user is: Mobile App, Admin Web Portal, and any future product, partner, or integration.
- Core capabilities:
  - Email/password sign-in for MVP; BankID and Vipps in Phase 2
  - Short-lived access tokens plus rotating refresh tokens
  - Session revocation (sign-out, forced expiry, admin-initiated)
  - Per-tenant isolation of signing material
  - A clean extension point for attaching product-specific claims (role, organization memberships) without the auth module knowing the product's schema
- Boundaries:
  - Owns only identity and session state. No product data, no authorization logic, no role semantics.
  - Authorization (who can do what within a product, tenant scoping, audit of domain actions) is the consuming product's responsibility.
  - Exposes a stable contract (sign-in, sign-out, refresh, identity lookup) so consumers do not depend on its internals.
- Portability requirement: the module must be extractable into a standalone service or repository later without API changes for consumers. This rules out reaching into product tables, coupling to product frameworks, or leaking product concepts into tokens beyond a generic claims bag.

**Product 4: Product Sales Website** (Next.js or static)
- Purpose: Commercial website to sell Meander to other organizations
- Users: Prospective organizations, buyers, decision-makers
- Core capabilities:
  - Product listing and feature showcase
  - Potential benefit calculator (ROI for organizations)
  - Demo booking flow
  - Privacy, Terms & Conditions, Data Processing Agreement, and SLA pages
  - Generate leads and drive sales conversions
- Tech: Next.js or static site, public-facing, no auth required

### Module Toggles per Organization

> **Applicability.** This pattern applies to multi-tenant products whose tenants have materially divergent needs (the Meander case: four organizations with partly overlapping feature sets). Single-tenant products, or products where every tenant uses the same feature set, do **not** need module toggles — the added config surface is overhead without benefit. When adopting this pattern from a source doc into a new product, first confirm the tenancy and divergence actually justify it.

Not every organization needs every capability. The needs matrix shows features that are must-have for one organization and irrelevant for another (e.g. encrypted assignments for Blindeforbundet, course administration for HLF, document attachments for NHF). Rather than branching the product per organization, the platform treats each functional area as an independently toggleable module.

**Design intent:**

- **Module = Area.** The canonical areas defined in the area taxonomy (section 8) are the unit of toggling. Each area ID (e.g. `expense-reimbursement`, `encrypted-assignments`, `certification-training`) is a module that can be enabled or disabled per tenant. This keeps the registry generic — no hand-maintained feature flag list parallel to the area taxonomy.
- **Admin surface owns the switch.** Whichever product serves as the administrative surface (here, the Admin Web Portal) exposes the toggles under Organization Management → Feature Toggles. The enabled set is persisted as tenant configuration.
- **Backend is the source of truth.** The API exposes the enabled module set for the current user's tenant as part of the session/bootstrap response. Every endpoint that belongs to a module checks the tenant's enabled set before executing — clients cannot bypass a disabled module by calling the API directly.
- **Clients load generically.** Clients (mobile, web, partner integrations) do not hardcode which tabs, entry points, or screens exist. At startup each client reads the enabled module set and renders only the navigation, surfaces, and flows belonging to enabled modules. Disabling a module hides its UI entirely; re-enabling restores it without a client release.
- **Always-on core.** A small set of modules is non-toggleable because the product is meaningless without them. For this platform: `authentication-access-control`, `home-navigation`, `accessibility`, `help-support`, `profile-management`. Other products reusing this pattern should define their own always-on set based on what is universally required.
- **Dependencies between modules** are declared in the registry, not inferred. If module A requires module B, enabling A implicitly enables B; the admin UI makes this visible rather than failing silently at runtime.
- **Area toggle vs config flag.** Toggle a whole area when the full workflow (UI, API, admin tooling) appears or disappears together. Use a config flag inside an area when only one dimension varies (e.g. speech-to-text on `activity-registration`, receipt-required threshold inside `expense-reimbursement`). Prefer the lighter option; promote a config flag to its own area only when a second tenant actually diverges.
- **No per-tenant code paths.** Tenant-specific behavior lives in (a) the enabled module set, (b) a terminology/labels system for display strings, and (c) per-module configuration values. New tenants onboard by picking modules and labels, never by shipping code.

This keeps the codebase single-tenant in shape while supporting multiple organizations with materially different needs, and leaves room for new tenants without a rewrite.

### Core Roles & Access Boundaries

Each organization has its own roles and users. Norse (the platform owner) manages global admins separately.

**4 defined user roles:**

- **Peer Mentor (Likeperson):** Creates and tracks activities and follow-ups. Mobile app only. Cannot access admin portal. Beginner-level digital skills assumed.
- **Coordinator:** Oversees peer mentors within their local association, dispatches assignments, approves expenses, registers on behalf of others. Mobile app + admin portal.
- **Organization Administrator (Org Admin):** Manages one organization's users, roles, reports, and statistics. Primarily admin portal. Can access mobile app.
- **Global Administrator:** Norse Digital Products staff. Cross-organization system management and support. Admin portal only. No default access to org user data/content. Critical principle: tenant separation — each org's data is isolated; global admins manage the system, not the org's operational data.

### Core Operational Flow

1. Peer mentor performs activity or event
2. Activity is registered and tracked in Meander Mobile App
3. Coordinator oversees follow-up, quality, and approval
4. Org Admin gets overview in Admin Web Portal
5. Structured data supports Bufdir reporting and analytics

### Shared Backend

- **Next.js application on Vercel** serving the REST API (`/api/v1/...`) and the admin portal (`/admin/...`)
- **Standardized REST API** consumed by the mobile app (Flutter) and the admin portal (SSR)
- **PostgreSQL database** (standard, managed) — no vendor-specific extensions, pure SQL with migrations
- **Authentication:** Handled by the Authentication Module (Product 3), treated as a decoupled product so it can be moved into its own service or repository later without forcing changes on consumers. Issues short-lived access tokens plus rotating refresh tokens; sessions survive silently across token expiry and end cleanly when the refresh chain is broken. Email/password for MVP; BankID/Vipps in Phase 2. Biometric session unlock (Face ID / fingerprint) after first login. Mobile stores tokens in the platform secure store; admin portal uses HTTP-only cookies. Global admins authenticate separately (no org context). Authorization — roles, organization scoping, tenant isolation — is the consuming product's responsibility, never the auth module's.

### Mobile App Architecture

**Auth & Access**
- **No organization selection screen** — organization context is determined by the user's account (set during onboarding/invitation by admin). Users do NOT choose their organization at login.
- Email/password login
- BankID / Vipps login (Phase 2)
- Biometric session authentication (Face ID / fingerprint)
- Role-based access control — Peer Mentor and Coordinator roles
- No-access screen for Global Admin (redirected to admin portal)

**Navigation**
- Bottom nav with 5 tabs: Home, Contacts, Add (modal launcher for Activity and Event wizards), Work, Notifications
- Settings accessible from hamburger menu

**Screens**
- Role-specific home content (peer mentor vs coordinator variants)
- Contacts list with role-specific views
- Contact detail, edit, and peer mentor profile screens
- Activity wizard (multi-step: contact → date → time → duration → summary)
- Event wizard (multi-step: title → date → time → duration → location → summary)
- Settings and preferences
- Notification inbox

**Core/Shared**
- REST API client (`ApiHttpClient`) with JWT bearer, auto-refresh on 401, 15s timeout, and a typed `ApiException` hierarchy
- Offline-first persistence (Drift + SQLCipher encrypted local DB, mutation outbox, sync queue with retry/backoff, ID mapping for offline-created entities, conflict resolver)
- Optimistic mutations with automatic rollback on failure (contact edits and paginated list updates)
- Design token system (colors, typography, spacing, radii, sizing) — WCAG 2.2 AA compliant
- Reusable widgets: AppButton, AppTextField, bottom nav, page header, role switch, custom fields table
- Organization labels system — per-org terminology overrides fetched from backend and cached offline (currently: `contacts`, `my_contacts`, `peer_mentors`; extensible to singular forms and role terms such as `peer_mentor`, `coordinator`, `contact`)
- Module registry — the app's navigation, home surfaces, and entry points are assembled at runtime from the enabled module set returned by the backend. Each area from section 8 registers its nav item, home widgets, and deep links against its area ID; disabled modules are simply not mounted. No compile-time switching per organization.

## 5. Anbefalt prioriteringsrekkefølge for teamet

### Fase 1 – MVP (alle organisasjoner, vår)

**Meander Mobile App (MVP scope):**
- Aktivitetsregistrering med lavest mulig antall klikk og standardverdier
- WCAG 2.2 AA compliance fra dag én
- E-post/passord innlogging (BankID/Vipps i fase 2)
- Enkel statistikkvisning per likeperson og per koordinator
- Kontaktliste og likepersonsoversikt
- 2 brukerroller i mobilapp: Peer Mentor, Koordinator

**Admin Web Portal (MVP scope):**
- Brukeradministrasjon (invitere, deaktivere, rolletildeling)
- Organisasjonsinnstillinger og terminologikonfigurasjon
- Aktivitetsoversikt og grunnleggende statistikk
- 2 brukerroller i admin: Organisasjonsadministrator, Global Administrator

**Shared Backend (MVP scope):**
- REST API (Next.js på Vercel) med PostgreSQL database
- JWT-basert autentisering
- Flerorganisasjonsstøtte (multi-tenancy)

**Product Sales Website (MVP scope):**
- Landingsside med produktbeskrivelse og fordeler
- Kontaktskjema / demo-booking
- Privacy policy og vilkår

### Fase 2 – Kjerneprodukt

- Bufdir-rapportering automatisert / eksport med ett klikk
- Reiserefusjonshåndtering (faste valg, terskelbasert godkjenning)
- Kryptert oppdragsutsendelse med statussporing (Blindeforbundet-kritisk)
- Pausefunksjon og bulkregistrering for koordinatorer
- Tale-til-tekst i rapportskriving

### Fase 3 – Vekst og engasjement

- Gamification / «Ditt likepersonsår»
- Kursadministrasjon og sertifisering (HLF)
- Dokumentvedlegg til aktiviteter
- Integrasjoner: Cornerstone, Consio, Dynamics, Xledger
- Mentorordning og karriereverksted (Blindeforbundet)

## 6. Fellesåpne punkter

- Norse Digital Products initierer dialog med Bufdir om forenklet rapporteringsformat på vegne av alle fire organisasjoner.
- Alle organisasjoner sender over eksisterende skjemaer (Word, Excel, print screens) som grunnlag for digitalisering.
- Testgrupper (5–8 pers.) og kontaktpersoner defineres av hver organisasjon.
- Barnekreftforeningen: Avklare behov som skiller seg fra de tre workshoporganisasjonene basert på forprosjektmaterialet.
- Vipps login-kostnad (350–750 kr/mnd) fordeles mellom organisasjonene – avtal modell.

## 7. Neste aksjonspunkter

### Mobiliseringsfase - Fase 0 frem til 13. mars

- Strategisk: Playing to win → Value prop (Alle)
- Oppdatere pengecase (Daniel & Lasse)
  - Mulige partnerskap utover sertifiseringer: Feks Bufdir, Motimate, andre fordeler.
- Kontakte Bufdir (Daniel)
- Panorama
- Få opp nettside (Aleksander)
- Oversikt over hva vi har allerede utviklet (Marius og Aleksander)
- Plan for pilotering/testing (Marius, Aleksander og Gellert)
  - Featureoversikt
  - Raskt ut og iterere basert på læring
- Hvordan vi kan oppdatere organisasjon (Aleksander og Gellert)

### Fase 1 MLP

- Scope to be decided
- Hva har vi allerede
- Hva må på plass
- Enkel admin

### Fase 2

- Bufdirrapportering
- Reiserefusjon
- Pause

### Fase 3

- Signering
- Snakkekort/toolbox
- Lenker til kurs
- Digitalt likepersonsbevis
- Validere value prop

### Fase 4

- Gamification
- Wrapped
- Spill
- Stikk motsatt av likepersonlogg
- Fordelskalkulator

---

## 8. Vocabulary — Canonical Area & Feature Structure

> **AUTHORITATIVE**: This section defines the official area names, feature groupings, and terminology for the Meander platform. The blueprint MUST use these exact area names and feature groupings. Do not invent new areas, merge areas, or move features between areas.
>
> **Dual role.** In this platform the area taxonomy also doubles as the module toggle registry — each Area ID is the unit that admins enable or disable per organization. Products reusing this pattern should preserve that 1:1 relationship (one area = one toggleable module). Products that don't need module toggles still benefit from the taxonomy as a stable vocabulary, but the toggle semantics become optional.

### Mobile App — Areas

| Area ID | Area Name | Features |
|-|-|-|
| authentication-access-control | Authentication & Access Control | Email & Password Login, BankID Authentication, Vipps Authentication, Biometric Login (Face ID/Fingerprint), Role-Based Access Control |
| profile-management | Profile Management | Profile Data & Settings, Profile Switching, Share Profile, Authentication Methods (Passkeys) |
| activity-registration | Activity Registration | Simple Activity Logging, Activity Registration Wizard, Calendar Sync, Speech-to-Text Input |
| proxy-bulk-registration | Proxy & Bulk Registration | Coordinator Proxy Reporting, Bulk Registration |
| event-management | Event Management | Event Creation, Event Listing, Event Sign-up |
| expense-reimbursement | Expense & Reimbursement | Travel Expense Registration, Receipt Photo Upload, Expense Types & Requirements, Confidentiality Declarations |
| contacts | Contacts | Contact List & Search, Contact Detail & Edit, Caregiver & Next-of-Kin |
| notes | Notes | Notes List, Note Editor |
| statistics | Statistics | Personal Activity Statistics, Coordinator Team Reports |
| bufdir-reporting | Bufdir Reporting | Bufdir Report Generation, Bufdir Export, Accounting System Integration |
| encrypted-assignments | Encrypted Data Assignments | Encrypted Assignment Dispatch, Assignment Threshold Tracking |
| notifications | Notifications | Push Notifications, Email/SMS Notifications, Notification Scenarios, Notification Settings |
| referral-program | Referral Program | Invite Link & QR Sharing, Recruitment Tracking |
| certification-training | Certification & Training | Course Registration, Digital Peer Mentor Certificate, Career Workshops |
| achievements-gamification | Achievements & Gamification | Annual Summary (Wrapped), Achievement Badges, Advantage Calculator |
| conversation-tools | Conversation Tools | Talking Cards Toolbox |
| accessibility | Accessibility | WCAG 2.2 AA Compliance, Sensitive Field Readout Warning, Sami Language Support |
| home-navigation | Home & Navigation | Role-Specific Home Dashboard, App Settings & Preferences, External Resource Links |
| help-support | Help & Support | Contact Us, Privacy Policy, Accessibility Statement, FAQ |
| offline-sync | Offline & Sync | Offline Data Support, Background Sync |

### Admin Portal — Areas

| Area ID | Area Name | Features |
|-|-|-|
| admin-dashboard | Admin Dashboard | Dashboard KPIs, Activity Feed |
| admin-user-management | User Management | User CRUD, Role Assignment, Bulk Actions |
| admin-activity-oversight | Activity Oversight | Activity Review & Approval, Activity Flagging |
| admin-expense-approval | Expense Approval | Expense Approval Queue, Auto-Approval Rules, Reimbursement Overview |
| admin-reporting | Reporting & Export | Team Reports, Bufdir Export, Custom Reports |
| admin-organization | Organization Management | Organization Settings, Custom Terminology, Feature Toggles, Multi-Organization Hierarchy, Member Associations |
| admin-integrations | Integrations | External Portal Integration, Accounting API |
| admin-security | Security & Audit | Security Dashboard, Audit Log, Session Management |

### Sales Website — Areas

| Area ID | Area Name | Features |
|-|-|-|
| sales-product | Product Showcase | Product Landing Page, Feature Overview |
| sales-calculator | Benefit Calculator | Impact Calculator, Cost Comparison |
| sales-demo | Demo Booking | Booking Form, Booking Confirmation |
| sales-legal | Legal Documents | Privacy Policy, Terms of Service, DPA, Cookie Policy |

### Terminology

| Term | Definition | Norwegian |
|-|-|-|
| Peer Mentor | Volunteer who provides support to contacts | Likeperson |
| Coordinator | Staff member who manages peer mentors | Koordinator |
| Organization Admin | Administrator of a single organization | Organisasjonsadministrator |
| Global Admin | Administrator across all organizations | Global administrator |
| Contact | Person receiving support from a peer mentor | Kontakt (overrideable per org via the Organization Labels system, e.g. `Familie`, `Bruker`) |
| Activity | A logged interaction (home visit, phone call, meeting, etc.) | Aktivitet |
| Assignment | Encrypted sensitive data dispatch to a peer mentor | Oppdrag |
| Reimbursement | Expense claim for travel or other costs | Refusjon / Utlegg |
| Bufdir | Norwegian government agency funding the program | Bufdir |
| Area | High-level functional grouping in the platform | Omrade |
| Feature | Specific capability within an area | Funksjon |

# Tverrgående workshopsammendrag ## Behovskartlegging – Likepersonsapp **Norse Digital Products | NHF, Blindeforbundet, HLF, Barnekreftforeningen** **Version 4.0.0** Dette dokumentet oppsummerer fellestrekkene og de unike behovene på tvers av workshoppene med Norges Handikapforbund (NHF), Norges Blindeforbund og Hørselsforbundet (HLF). Barnekreftforeningen inngikk i forprosjektet og er ikke inkludert som egen workshopdeltaker her. Formålet er å gi teamet et prioriteringsgrunnlag for videre utvikling. > **Note on reuse.** Parts of this document describe patterns (module toggles, area taxonomy, decoupled auth module, organization labels) that are specific to *this* platform's multi-tenant, multi-organization shape. Other products generated from a source doc via the same pipeline will not necessarily share that shape — a single-tenant SaaS, an internal tool, or a fixed-scope deliverable typically should **not** adopt module toggles or per-tenant label overrides. Each architectural pattern below is scoped with an applicability note; treat them as options justified by stated constraints, not defaults. ## 1. Felles behov – går igjen i alle tre organisasjoner Følgende behov ble løftet frem – ofte ord for ord – i alle tre workshops. Dette er kjernen i hva appen MÅ løse. ### 1.1 Enkel aktivitetsregistrering (#1-prioritet hos alle) Alle tre organisasjoner peker på dette som den aller viktigste funksjonen, og beskriver dagens situasjon som uholdbar. Fellesnevneren er at rapporteringen er så tungvint at det fører til massiv underrapportering – enten fordi folk ikke orker, eller fordi de ikke engang skjønner at det de gjør teller. - **NHF:** Word-skjemaer sendes manuelt til regioner → manuell Excel-aggregering sentralt. Mål: registrering på under to klikk. - **Blindeforbundet:** Digitalisere eksisterende Word-rapportskjema. Kortfattet rapport etter hjemmebesøk med avkrysning + fritekst + tale-til-tekst. - **HLF:** En likeperson hadde 380 enkeltregistreringer på ett år. Standardverdier (dagens dato, 30 min) som kan overstyres. 60–70 % av registreringene er uten refusjon og skal være ekstremt enkle. > **Designprinsipp:** Lavest mulig kognitiv belastning. Standardvalg, gjenkjennelig logikk, færrest mulig steg. ### 1.2 Universell utforming (WCAG 2.2 AA) Alle tre organisasjoner har brukere med svært ulike forutsetninger – motoriske, kognitive og sensoriske. Appen SKAL oppfylle **WCAG 2.2 nivå AA** som minimumskrav for alle skjermer og interaksjoner. - **WCAG 2.2 AA compliance** er et absolutt krav for MVP – ikke noe som fikses etterpå. - **Skjermleser-støtte (VoiceOver/JAWS):** Alle interaktive elementer skal ha semantiske labels og ARIA-attributter. Særlig kritisk for Blindeforbundet, men relevant for alle. - **Kognitiv tilgjengelighet:** NHF nevner spesifikt slagrammede. Enkel navigasjon, logisk flyt, ikke for mange valg. Tydelige feilmeldinger med forslag til løsning. - **Kontrast og typografi:** Minimum 4.5:1 kontrast for tekst, 3:1 for store tekstelementer og UI-komponenter. Skalerbar skrift opp til 200%. Unngå tynne/kursive fonter. - **Touch targets:** Minimum 24x24 CSS-piksler for alle interaktive elementer (WCAG 2.2 target size). - **Tastaturnavigasjon:** Alle funksjoner tilgjengelige via tastatur. Synlig fokusindikator. - Tilbakeknapp fremfor sidelengs-sveip. Vertikal scroll er normen. - Varsling ved opplesning av sensitive felt (NHF). - **Drag-and-drop alternativer:** Alle drag-baserte interaksjoner skal ha et ikke-drag alternativ (WCAG 2.2 dragging movements). ### 1.3 BankID / Vipps innlogging Alle tre organisasjoner peker på BankID eller Vipps som foretrukket autentisering ved førstegangs innlogging, med biometrisk innlogging (Face ID / fingeravtrykk) etterpå. En viktig bieffekt: Vipps-innlogging kan returnere personnummer tilbake til medlemssystemene, som i dag mangler dette for mange brukere. ### 1.4 Sømløs Bufdir-rapportering Alle tre organisasjoner mottar Bufdir-tilskudd og bruker mye tid på rapportering. Ønsket er det samme: trykk på én knapp og få ut det Bufdir trenger. Norse Digital Products tar initiativ til dialog med Bufdir på vegne av alle organisasjonene. ### 1.5 Inkrementell utrulling – parallelle systemer Sterk enighet på tvers: Eksisterende løsninger må fungere parallelt til appen er godt etablert. Ingen av organisasjonene tåler et hard-cut. Appen skal introduseres som et til-bud, ikke et pålegg. - **NHF:** «Ikke steng det gamle før folk er klare.» - **HLF:** Rapportering kan ikke kuttes i påvente av appen – systemene må leve side om side. - **Blindeforbundet:** Stegvis digitalisering etter bankenes modell for nettbankutrulling. ### 1.6 Testoppsett: TestFlight, 5–8 personer, én kontaktperson Alle tre organisasjoner er enige om samme testmetode: iOS-distribusjon via TestFlight, 5–8 testpersoner med spenn i kjønn, alder og digitale ferdigheter, og én dedikert kontaktperson per organisasjon som filtrerer og samler tilbakemeldinger. Første testversjon er målsatt til våren. ## 2. Delte behov – nevnt av to av tre organisasjoner Disse behovene er ikke universelle, men er sterke nok til å vurderes som del av kjerneprodukt. ### 2.1 Reiserefusjon og utleggsregistrering (HLF + Blindeforbundet) Begge organisasjoner har behov for registrering av kilometergodtgjørelse, bompenger, parkering og kollektivt. Behovene er like, men HLF har mest detaljert krav: - Faste valg for utleggstype – ikke fritekst – for å hindre feilkombinasjon (f.eks. både km og bussbillett). - Kvitteringsbilde for utlegg over 100 kr (HLF). - Automatisk godkjenning under 50 km / uten utlegg, manuell attestering ellers (HLF). - Sjåfærhonorarer og taushetseerklæringer for sjåfører (Blindeforbundet). - API-integrasjon mot regnskapssystem (Xledger for Blindeforbundet, Dynamics-portal for HLF). ### 2.2 Gamification og synliggjøring av innsats (NHF + HLF) Begge organisasjoner er inspirert av Spotify Wrapped og ønsker en funksjon som viser likepersonens bidrag over tid – «Din likepersonsårek». Målet er å gi frivillige stolthet og motivasjon, og gjøre usynlig innsats synlig. Også nevnt: «Årets koordinator», statusbadges og halvårsoppsummeringer. ### 2.3 Pausefunksjon for likepersoner (NHF + HLF) Likepersoner skal kunne sette seg på pause (midlertidig deaktivering) uten å melde seg ut. Koordinator må varsles. HLF kobler dette til sertifisering: ved utgått sertifikat forsvinner likepersonen fra lokallagets nettsider automatisk. ### 2.4 Koordinator kan rapportere på vegne av andre / bulkregistrering (NHF + HLF) Ikke alle likepersoner vil eller kan bruke appen. Koordinatorer må ha mulighet til å registrere aktivitet på vegne av sine likepersoner, enten enkeltvis eller samlet for faste aktiviteter (f.eks. ukentlig trening med mange deltakere). ### 2.5 Tale-til-tekst i rapportskriving (Blindeforbundet + HLF) Begge organisasjoner ønsker mulighet for å snakke inn rapporter fremfor å skrive. Blindeforbundet understreker at opptak under selve samtalen er uønsket – tale-til-tekst er for etterpå, ved rapportskriving. ## 3. Unike behov per organisasjon ### 3.1 Norges Blindeforbund – unike behov - **Kryptert oppdragshåndtering:** Sende sensitive personopplysninger (navn, adresse, epikrise) til likepersoner med leveringsbekreftelse og lesebekreftelse. Statusoversikt over åpne oppdrag. - Automatisk påminnelse etter 10 dager dersom kontakt ikke er opprettet. - **Telling av oppdrag per RK:** Kontorhonorar utløses ved 3. oppdrag, høyere sats ved 15. - **Formalisert rapportstruktur etter hjemmebesøk:** Helsetilstand, kursinteresse, hjelpemiddelsituasjon, «veien videre» – fungerer som bestilling til koordinatoren. - Sterk motstand mot lydopptak under hjemmebesøk – sperrer for åpen samtale. - **Geografisk kartvisning** av likepersoner for matching og oppdragstildeling (særlig store fylker). - **Mentorordning (karriereverksted):** Eget notatverktøy, to-do-lister og deltakerlister for gruppeveiledning over to dager. - Gradvis digitalisering av fullmakter og epikriser med manuelt fallback. ### 3.2 Norges Handikapforbund – unike behov - **Kognitiv tilgjengelighet som topprioritering:** Spesielt slagrammede og personer med kognitive utfordringer blant brukerne. - **Håndtering av medlemmer i flere lokallag (opptil 5):** Avklare tilhørighet og hindre dobbeltrapportering. - **Duplikatvarsling:** Fange opp når samme aktivitet registreres av flere koordinatorer. - **Dokumentvedlegg til aktiviteter:** Invitasjoner, Facebook-skjermbilder m.m. – viktig for Bufdir-etterprøving. - Samisk språkstøtte vurdert på sikt (NHF har samisk tilknytning). - **Bredest organisasjonsstruktur:** 12 landsforeninger, 9 regioner, 1 400 lokallag – aktivitetsfordeling mellom ledd må støttes. ### 3.3 Hørselsforbundet – unike behov - **Detaljert refusjonsstyring** med faste valg som gjør feilkombinasjon teknisk umulig (f.eks. km + bussbillett kan ikke velges samtidig). Automatisk godkjenning under terskel. - **Kursadministrasjon og sertifisering:** Påmelding til kurs i appen, automatisk påminnelse ved utløp, digitale sertifikater. Det fysiske kortet er et «adelsmerke» og skal leve parallelt. - **Koordinering med eget portalprosjekt:** HLF redesigner «min side» på Dynamics-plattformen. Appen og portalen må ikke overlappe eller motarbeide hverandre. - **Oppfølging av likepersoner:** 40 % var ikke fornøyd med oppfølgingen i spørreundersøkelse. Scenariobaserte push-meldinger og kalendersynkronisering. - **Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel). ## 4. Behovsoversikt – prioriteringsmatrise > **How to read this matrix.** It is a workshop snapshot of divergent stakeholder needs — the input that motivated the module-toggle architecture below. It is **not** a development spec and should not drive per-organization code branches. Authoritative per-org scope lives in the module toggle registry (see *Module Toggles per Organization*). The Prioritet and Fase columns are indicative only; the current roadmap lives in sections 5 and 7 and will drift as priorities shift. | Behov / Funksjon | Barnekreft | NHF | Blindeforbundet | HLF | Prioritet | Fase | |-|-|-|-|-|-|-| | Enkel aktivitetsregistrering | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Universell utforming / tilgjengelighet | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 (2 Blind.) | | BankID / Vipps innlogging | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 2 | | Bufdir-rapportering (automatisert) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 3 | | Parallelle systemer i overgang | ✓ | ✓ | ✓ | ✓ | MUST HAVE | - | | TestFlight-oppsett (iOS) / Apptester (Android), én kontaktperson | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Reiserefusjon / utleggsregistrering | – | – | ✓ | ✓ | SHOULD HAVE | 2 | | Gamification / Spotify Wrapped | ✓ | ✓ | – | ✓ | NICE TO HAVE | 4 | | Pausefunksjon for likepersoner | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 | | Bulkregistrering / proxy-rapportering | ✓ | ✓ | – | ✓ | SHOULD HAVE | 2 | | Tale-til-tekst | – | – | ✓ | ✓ | SHOULD HAVE | 2 | | Kryptert informasjon | ✓ | ✓ | ✓ | ✓ | MUST | 1 | | Formalisert rapportstruktur | ✓ | – | ✓ | – | NICE (Blindeforbundet) | 4 | | Kursadministrasjon / sertifisering | ✓ | – | – | ✓ | SHOULD (HLF) | 4 | | Koordinering med ekstern portal | – | – | – | ✓ | MUST (HLF) | 3 | | Dokumentvedlegg til aktiviteter | – | ✓ | – | – | NICE TO HAVE | 3 | | Admingrensesnitt for org (Admin Panel – Next.js) | ✓ | ✓ | ✓ | ✓ | MUST HAVE | 1 | | Snakkekort | ✓ | ✓ | ✓ | ✓ | NICE | 3 | | Eksterne lenker til ressurser | ✓ | ✓ | ✓ | ✓ | NICE | 2 | | Pårørende database | ✓ | – | – | – | NEED | 1 | | Basic search (contact and notater) | ✓ | ✓ | ✓ | ✓ | MUST | 1 | | Notater | ✓ | ✓ | ✓ | ✓ | NICE | 2 | ### Product Landscape — Meander Platform Meander is the platform. It ships as four distinct products, each serving different users and purposes. The three user-facing products share the same PostgreSQL database and the same authentication module. **Product 1: Meander Mobile App** (Flutter) - Purpose: Day-to-day operational tool for peer mentors and coordinators - Users: Peer Mentors (Likepersoner), Coordinators - Core capabilities: - Activity registration (quick logging, wizards, bulk/proxy) - Contact and peer mentor management - Travel expense registration - Personal statistics and impact summaries - Push notifications and assignment tracking - Speech-to-text input, document attachments - Gamification (wrapped summaries, badges) - Tech: Flutter, Riverpod (no codegen), Drift (offline), WCAG 2.2 AA **Product 2: Admin Web Portal** (Next.js) - Purpose: Organization management, reporting, and oversight - Users: Organization Admins, Coordinators, Global Admins - Core capabilities: - User management (invite, deactivate, role assignment) - Organization settings and terminology/labels configuration - Bufdir report generation and one-click export - Activity oversight, approval workflows, and corrections - Reimbursement approval and expense oversight - Coordinator and organization-level dashboards and KPIs - Multi-organization hierarchy management - Course and certification administration - Tech: Next.js on Vercel, server-side rendering, same auth system **Product 3: Authentication Module** - Purpose: Issue and validate credentials for every Meander product. Treated as its own product — not a feature of any single product — because it must be decouplable and movable into its own service or repository at any time without forcing changes on consumers. - Users: Every other Meander product that needs to know who a user is: Mobile App, Admin Web Portal, and any future product, partner, or integration. - Core capabilities: - Email/password sign-in for MVP; BankID and Vipps in Phase 2 - Short-lived access tokens plus rotating refresh tokens - Session revocation (sign-out, forced expiry, admin-initiated) - Per-tenant isolation of signing material - A clean extension point for attaching product-specific claims (role, organization memberships) without the auth module knowing the product's schema - Boundaries: - Owns only identity and session state. No product data, no authorization logic, no role semantics. - Authorization (who can do what within a product, tenant scoping, audit of domain actions) is the consuming product's responsibility. - Exposes a stable contract (sign-in, sign-out, refresh, identity lookup) so consumers do not depend on its internals. - Portability requirement: the module must be extractable into a standalone service or repository later without API changes for consumers. This rules out reaching into product tables, coupling to product frameworks, or leaking product concepts into tokens beyond a generic claims bag. **Product 4: Product Sales Website** (Next.js or static) - Purpose: Commercial website to sell Meander to other organizations - Users: Prospective organizations, buyers, decision-makers - Core capabilities: - Product listing and feature showcase - Potential benefit calculator (ROI for organizations) - Demo booking flow - Privacy, Terms & Conditions, Data Processing Agreement, and SLA pages - Generate leads and drive sales conversions - Tech: Next.js or static site, public-facing, no auth required ### Module Toggles per Organization > **Applicability.** This pattern applies to multi-tenant products whose tenants have materially divergent needs (the Meander case: four organizations with partly overlapping feature sets). Single-tenant products, or products where every tenant uses the same feature set, do **not** need module toggles — the added config surface is overhead without benefit. When adopting this pattern from a source doc into a new product, first confirm the tenancy and divergence actually justify it. Not every organization needs every capability. The needs matrix shows features that are must-have for one organization and irrelevant for another (e.g. encrypted assignments for Blindeforbundet, course administration for HLF, document attachments for NHF). Rather than branching the product per organization, the platform treats each functional area as an independently toggleable module. **Design intent:** - **Module = Area.** The canonical areas defined in the area taxonomy (section 8) are the unit of toggling. Each area ID (e.g. `expense-reimbursement`, `encrypted-assignments`, `certification-training`) is a module that can be enabled or disabled per tenant. This keeps the registry generic — no hand-maintained feature flag list parallel to the area taxonomy. - **Admin surface owns the switch.** Whichever product serves as the administrative surface (here, the Admin Web Portal) exposes the toggles under Organization Management → Feature Toggles. The enabled set is persisted as tenant configuration. - **Backend is the source of truth.** The API exposes the enabled module set for the current user's tenant as part of the session/bootstrap response. Every endpoint that belongs to a module checks the tenant's enabled set before executing — clients cannot bypass a disabled module by calling the API directly. - **Clients load generically.** Clients (mobile, web, partner integrations) do not hardcode which tabs, entry points, or screens exist. At startup each client reads the enabled module set and renders only the navigation, surfaces, and flows belonging to enabled modules. Disabling a module hides its UI entirely; re-enabling restores it without a client release. - **Always-on core.** A small set of modules is non-toggleable because the product is meaningless without them. For this platform: `authentication-access-control`, `home-navigation`, `accessibility`, `help-support`, `profile-management`. Other products reusing this pattern should define their own always-on set based on what is universally required. - **Dependencies between modules** are declared in the registry, not inferred. If module A requires module B, enabling A implicitly enables B; the admin UI makes this visible rather than failing silently at runtime. - **Area toggle vs config flag.** Toggle a whole area when the full workflow (UI, API, admin tooling) appears or disappears together. Use a config flag inside an area when only one dimension varies (e.g. speech-to-text on `activity-registration`, receipt-required threshold inside `expense-reimbursement`). Prefer the lighter option; promote a config flag to its own area only when a second tenant actually diverges. - **No per-tenant code paths.** Tenant-specific behavior lives in (a) the enabled module set, (b) a terminology/labels system for display strings, and (c) per-module configuration values. New tenants onboard by picking modules and labels, never by shipping code. This keeps the codebase single-tenant in shape while supporting multiple organizations with materially different needs, and leaves room for new tenants without a rewrite. ### Core Roles & Access Boundaries Each organization has its own roles and users. Norse (the platform owner) manages global admins separately. **4 defined user roles:** - **Peer Mentor (Likeperson):** Creates and tracks activities and follow-ups. Mobile app only. Cannot access admin portal. Beginner-level digital skills assumed. - **Coordinator:** Oversees peer mentors within their local association, dispatches assignments, approves expenses, registers on behalf of others. Mobile app + admin portal. - **Organization Administrator (Org Admin):** Manages one organization's users, roles, reports, and statistics. Primarily admin portal. Can access mobile app. - **Global Administrator:** Norse Digital Products staff. Cross-organization system management and support. Admin portal only. No default access to org user data/content. Critical principle: tenant separation — each org's data is isolated; global admins manage the system, not the org's operational data. ### Core Operational Flow 1. Peer mentor performs activity or event 2. Activity is registered and tracked in Meander Mobile App 3. Coordinator oversees follow-up, quality, and approval 4. Org Admin gets overview in Admin Web Portal 5. Structured data supports Bufdir reporting and analytics ### Shared Backend - **Next.js application on Vercel** serving the REST API (`/api/v1/...`) and the admin portal (`/admin/...`) - **Standardized REST API** consumed by the mobile app (Flutter) and the admin portal (SSR) - **PostgreSQL database** (standard, managed) — no vendor-specific extensions, pure SQL with migrations - **Authentication:** Handled by the Authentication Module (Product 3), treated as a decoupled product so it can be moved into its own service or repository later without forcing changes on consumers. Issues short-lived access tokens plus rotating refresh tokens; sessions survive silently across token expiry and end cleanly when the refresh chain is broken. Email/password for MVP; BankID/Vipps in Phase 2. Biometric session unlock (Face ID / fingerprint) after first login. Mobile stores tokens in the platform secure store; admin portal uses HTTP-only cookies. Global admins authenticate separately (no org context). Authorization — roles, organization scoping, tenant isolation — is the consuming product's responsibility, never the auth module's. ### Mobile App Architecture **Auth & Access** - **No organization selection screen** — organization context is determined by the user's account (set during onboarding/invitation by admin). Users do NOT choose their organization at login. - Email/password login - BankID / Vipps login (Phase 2) - Biometric session authentication (Face ID / fingerprint) - Role-based access control — Peer Mentor and Coordinator roles - No-access screen for Global Admin (redirected to admin portal) **Navigation** - Bottom nav with 5 tabs: Home, Contacts, Add (modal launcher for Activity and Event wizards), Work, Notifications - Settings accessible from hamburger menu **Screens** - Role-specific home content (peer mentor vs coordinator variants) - Contacts list with role-specific views - Contact detail, edit, and peer mentor profile screens - Activity wizard (multi-step: contact → date → time → duration → summary) - Event wizard (multi-step: title → date → time → duration → location → summary) - Settings and preferences - Notification inbox **Core/Shared** - REST API client (`ApiHttpClient`) with JWT bearer, auto-refresh on 401, 15s timeout, and a typed `ApiException` hierarchy - Offline-first persistence (Drift + SQLCipher encrypted local DB, mutation outbox, sync queue with retry/backoff, ID mapping for offline-created entities, conflict resolver) - Optimistic mutations with automatic rollback on failure (contact edits and paginated list updates) - Design token system (colors, typography, spacing, radii, sizing) — WCAG 2.2 AA compliant - Reusable widgets: AppButton, AppTextField, bottom nav, page header, role switch, custom fields table - Organization labels system — per-org terminology overrides fetched from backend and cached offline (currently: `contacts`, `my_contacts`, `peer_mentors`; extensible to singular forms and role terms such as `peer_mentor`, `coordinator`, `contact`) - Module registry — the app's navigation, home surfaces, and entry points are assembled at runtime from the enabled module set returned by the backend. Each area from section 8 registers its nav item, home widgets, and deep links against its area ID; disabled modules are simply not mounted. No compile-time switching per organization. ## 5. Anbefalt prioriteringsrekkefølge for teamet ### Fase 1 – MVP (alle organisasjoner, vår) **Meander Mobile App (MVP scope):** - Aktivitetsregistrering med lavest mulig antall klikk og standardverdier - WCAG 2.2 AA compliance fra dag én - E-post/passord innlogging (BankID/Vipps i fase 2) - Enkel statistikkvisning per likeperson og per koordinator - Kontaktliste og likepersonsoversikt - 2 brukerroller i mobilapp: Peer Mentor, Koordinator **Admin Web Portal (MVP scope):** - Brukeradministrasjon (invitere, deaktivere, rolletildeling) - Organisasjonsinnstillinger og terminologikonfigurasjon - Aktivitetsoversikt og grunnleggende statistikk - 2 brukerroller i admin: Organisasjonsadministrator, Global Administrator **Shared Backend (MVP scope):** - REST API (Next.js på Vercel) med PostgreSQL database - JWT-basert autentisering - Flerorganisasjonsstøtte (multi-tenancy) **Product Sales Website (MVP scope):** - Landingsside med produktbeskrivelse og fordeler - Kontaktskjema / demo-booking - Privacy policy og vilkår ### Fase 2 – Kjerneprodukt - Bufdir-rapportering automatisert / eksport med ett klikk - Reiserefusjonshåndtering (faste valg, terskelbasert godkjenning) - Kryptert oppdragsutsendelse med statussporing (Blindeforbundet-kritisk) - Pausefunksjon og bulkregistrering for koordinatorer - Tale-til-tekst i rapportskriving ### Fase 3 – Vekst og engasjement - Gamification / «Ditt likepersonsår» - Kursadministrasjon og sertifisering (HLF) - Dokumentvedlegg til aktiviteter - Integrasjoner: Cornerstone, Consio, Dynamics, Xledger - Mentorordning og karriereverksted (Blindeforbundet) ## 6. Fellesåpne punkter - Norse Digital Products initierer dialog med Bufdir om forenklet rapporteringsformat på vegne av alle fire organisasjoner. - Alle organisasjoner sender over eksisterende skjemaer (Word, Excel, print screens) som grunnlag for digitalisering. - Testgrupper (5–8 pers.) og kontaktpersoner defineres av hver organisasjon. - Barnekreftforeningen: Avklare behov som skiller seg fra de tre workshoporganisasjonene basert på forprosjektmaterialet. - Vipps login-kostnad (350–750 kr/mnd) fordeles mellom organisasjonene – avtal modell. ## 7. Neste aksjonspunkter ### Mobiliseringsfase - Fase 0 frem til 13. mars - Strategisk: Playing to win → Value prop (Alle) - Oppdatere pengecase (Daniel & Lasse) - Mulige partnerskap utover sertifiseringer: Feks Bufdir, Motimate, andre fordeler. - Kontakte Bufdir (Daniel) - Panorama - Få opp nettside (Aleksander) - Oversikt over hva vi har allerede utviklet (Marius og Aleksander) - Plan for pilotering/testing (Marius, Aleksander og Gellert) - Featureoversikt - Raskt ut og iterere basert på læring - Hvordan vi kan oppdatere organisasjon (Aleksander og Gellert) ### Fase 1 MLP - Scope to be decided - Hva har vi allerede - Hva må på plass - Enkel admin ### Fase 2 - Bufdirrapportering - Reiserefusjon - Pause ### Fase 3 - Signering - Snakkekort/toolbox - Lenker til kurs - Digitalt likepersonsbevis - Validere value prop ### Fase 4 - Gamification - Wrapped - Spill - Stikk motsatt av likepersonlogg - Fordelskalkulator --- ## 8. Vocabulary — Canonical Area & Feature Structure > **AUTHORITATIVE**: This section defines the official area names, feature groupings, and terminology for the Meander platform. The blueprint MUST use these exact area names and feature groupings. Do not invent new areas, merge areas, or move features between areas. > > **Dual role.** In this platform the area taxonomy also doubles as the module toggle registry — each Area ID is the unit that admins enable or disable per organization. Products reusing this pattern should preserve that 1:1 relationship (one area = one toggleable module). Products that don't need module toggles still benefit from the taxonomy as a stable vocabulary, but the toggle semantics become optional. ### Mobile App — Areas | Area ID | Area Name | Features | |-|-|-| | authentication-access-control | Authentication & Access Control | Email & Password Login, BankID Authentication, Vipps Authentication, Biometric Login (Face ID/Fingerprint), Role-Based Access Control | | profile-management | Profile Management | Profile Data & Settings, Profile Switching, Share Profile, Authentication Methods (Passkeys) | | activity-registration | Activity Registration | Simple Activity Logging, Activity Registration Wizard, Calendar Sync, Speech-to-Text Input | | proxy-bulk-registration | Proxy & Bulk Registration | Coordinator Proxy Reporting, Bulk Registration | | event-management | Event Management | Event Creation, Event Listing, Event Sign-up | | expense-reimbursement | Expense & Reimbursement | Travel Expense Registration, Receipt Photo Upload, Expense Types & Requirements, Confidentiality Declarations | | contacts | Contacts | Contact List & Search, Contact Detail & Edit, Caregiver & Next-of-Kin | | notes | Notes | Notes List, Note Editor | | statistics | Statistics | Personal Activity Statistics, Coordinator Team Reports | | bufdir-reporting | Bufdir Reporting | Bufdir Report Generation, Bufdir Export, Accounting System Integration | | encrypted-assignments | Encrypted Data Assignments | Encrypted Assignment Dispatch, Assignment Threshold Tracking | | notifications | Notifications | Push Notifications, Email/SMS Notifications, Notification Scenarios, Notification Settings | | referral-program | Referral Program | Invite Link & QR Sharing, Recruitment Tracking | | certification-training | Certification & Training | Course Registration, Digital Peer Mentor Certificate, Career Workshops | | achievements-gamification | Achievements & Gamification | Annual Summary (Wrapped), Achievement Badges, Advantage Calculator | | conversation-tools | Conversation Tools | Talking Cards Toolbox | | accessibility | Accessibility | WCAG 2.2 AA Compliance, Sensitive Field Readout Warning, Sami Language Support | | home-navigation | Home & Navigation | Role-Specific Home Dashboard, App Settings & Preferences, External Resource Links | | help-support | Help & Support | Contact Us, Privacy Policy, Accessibility Statement, FAQ | | offline-sync | Offline & Sync | Offline Data Support, Background Sync | ### Admin Portal — Areas | Area ID | Area Name | Features | |-|-|-| | admin-dashboard | Admin Dashboard | Dashboard KPIs, Activity Feed | | admin-user-management | User Management | User CRUD, Role Assignment, Bulk Actions | | admin-activity-oversight | Activity Oversight | Activity Review & Approval, Activity Flagging | | admin-expense-approval | Expense Approval | Expense Approval Queue, Auto-Approval Rules, Reimbursement Overview | | admin-reporting | Reporting & Export | Team Reports, Bufdir Export, Custom Reports | | admin-organization | Organization Management | Organization Settings, Custom Terminology, Feature Toggles, Multi-Organization Hierarchy, Member Associations | | admin-integrations | Integrations | External Portal Integration, Accounting API | | admin-security | Security & Audit | Security Dashboard, Audit Log, Session Management | ### Sales Website — Areas | Area ID | Area Name | Features | |-|-|-| | sales-product | Product Showcase | Product Landing Page, Feature Overview | | sales-calculator | Benefit Calculator | Impact Calculator, Cost Comparison | | sales-demo | Demo Booking | Booking Form, Booking Confirmation | | sales-legal | Legal Documents | Privacy Policy, Terms of Service, DPA, Cookie Policy | ### Terminology | Term | Definition | Norwegian | |-|-|-| | Peer Mentor | Volunteer who provides support to contacts | Likeperson | | Coordinator | Staff member who manages peer mentors | Koordinator | | Organization Admin | Administrator of a single organization | Organisasjonsadministrator | | Global Admin | Administrator across all organizations | Global administrator | | Contact | Person receiving support from a peer mentor | Kontakt (overrideable per org via the Organization Labels system, e.g. `Familie`, `Bruker`) | | Activity | A logged interaction (home visit, phone call, meeting, etc.) | Aktivitet | | Assignment | Encrypted sensitive data dispatch to a peer mentor | Oppdrag | | Reimbursement | Expense claim for travel or other costs | Refusjon / Utlegg | | Bufdir | Norwegian government agency funding the program | Bufdir | | Area | High-level functional grouping in the platform | Omrade | | Feature | Specific capability within an area | Funksjon |