Profile Data & Settings
Feature Detail
Description
Profile Data & Settings provides each user a dedicated screen to view and update their personal information within the Meander Mobile App, including name, contact details, notification preferences, and account configuration. The screen surfaces settings relevant to the user's active role and organization while enforcing WCAG 2.2 AA requirements on every interactive element. It forms the foundational identity layer that downstream features-activity registration, assignment dispatch, and statistics-rely on to associate records with the correct person and organization context.
Sources & reasoning
The blueprint marks Profile Data & Settings as MVP with a Profile Screen UI component and Profile Service. The Fase 1 MVP scope in the source doc names two mobile role profiles and an always-on profile-management area, confirming MVP release. Profile data is the identity anchor for activity registration, assignment dispatch, and reimbursement-all core MVP workflows. WCAG requirement applies from day one.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
A clear, accessible profile screen is the anchor for user trust and data integrity across the platform. Peer mentors and coordinators must keep contact details current so that assignments are dispatched correctly, reimbursements reach the right account, and coordinators can reach their team. Without accurate profile data, user-organization role records become unreliable and Bufdir reports contain errors that jeopardize funding. The screen also surfaces app-level preferences-notification channel, language-that directly affect engagement and WCAG compliance for users with varied digital skills, including the cognitively impaired users NHF specifically flagged.
Implemented as a Flutter screen backed by a Riverpod provider that fetches the user record from the REST API and caches it in Drift (SQLCipher) for offline access. Profile edits use optimistic mutations with automatic rollback on API failure, consistent with the mobile offline-first architecture. All form fields must satisfy WCAG 2.2 AA touch-target (24×24 px minimum) and 4.5:1 contrast requirements. The screen reads organization-specific terminology overrides from the cached labels store so field labels reflect per-org vocabulary. Sensitive fields trigger the Sensitive Field Warning Widget when screen-reader focus lands on them, satisfying the Blindeforbundet/NHF accessibility requirement.
Components (43)
Shared Components
These components are reused across multiple features
Service Layer (11)
Data Layer (23)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.