App Settings & Preferences
Feature Detail
Description
App Settings and Preferences provides a centralized screen accessible from the hamburger menu for configuring notification preferences, accessibility options, and personal app behavior. User preferences persist locally via Drift and sync to the backend so settings survive reinstalls. Organization-specific terminology overrides are reflected in labels, and accessibility settings such as font scaling feed into the design token system to maintain WCAG 2.2 AA compliance at any user-configured scale.
Sources & reasoning
Settings and preferences are explicitly listed as a distinct screen in Mobile App Architecture; the hamburger menu navigation confirms placement. The unconditional WCAG 2.2 AA mandate, font-scaling requirement, and organization labels system all depend on a user-configurable preferences surface. Fase 1 MVP scope covers core mobile functionality; blueprint assigns MVP by ordinal.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
The platform serves users with diverse motor, cognitive, and sensory impairments across all four organizations; user-configurable preferences allow individuals to tailor the app beyond device-level accessibility settings alone. This directly supports the unconditional WCAG 2.2 AA mandate. Persisting preferences to the backend prevents repeated reconfiguration across devices, reducing friction for coordinators. The settings screen is the natural surface for organization terminology display, ensuring the labels system delivers correct terminology throughout the app without additional navigation.
Preferences must be stored in a Drift table and flushed via the mutation outbox so they survive offline periods and sync transparently. The Preferences Service should expose a Riverpod provider consumed by the design token system and the organization labels provider, triggering reactive UI updates on change. Each module registers its configurable options via a settings registry analogous to the module registry pattern, avoiding tight coupling to the core settings screen. Font scaling must be tested at 200 percent per WCAG 2.2 AA. All controls require keyboard navigation with visible focus indicators.
Components (47)
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.