🏠 Overview › ✅ Implementation Tasks ›✅ epic-membership-recruitment-peer-mentor-ui-task-010

Build contact details collection form on onboarding screen

epic-membership-recruitment-peer-mentor-ui-task-010 — Implement a contact details form on NewMemberOnboardingScreen collecting the new member's name, phone number, and email address. Apply form validation using Flutter form validators. Fields must have WCAG 2.2 AA compliant labels, error messages, and 48dp minimum touch targets.

high priority medium complexity frontend pending frontend specialist Tier 2

Acceptance Criteria

Form contains three fields: full name (text), phone number (tel), and email address (email); all are required
Full name: minimum 2 characters, no leading/trailing whitespace after trim, accepts Norwegian characters (æ, ø, å)
Phone number: validated as a Norwegian mobile number (8 digits, optional +47 prefix); uses numeric keyboard input type
Email address: validated against RFC 5322 simplified pattern; uses email keyboard input type with auto-correct disabled
Each field has a visible label (not placeholder-only) that persists when the field has focus or content
Validation error messages appear inline below the relevant field on form submission attempt or on field blur; messages are in Norwegian (nb_NO)
All interactive form elements (fields, submit button) have a minimum touch target of 48×48dp
Focus order follows reading order (name → phone → email → submit) and is navigable via keyboard/switch access
Form retains field values across screen rebuilds caused by keyboard appearance/disappearance
Submit button is disabled while any field is empty (real-time reactive state)

Technical Requirements

frameworks
Flutter
Riverpod
data models
contact
performance requirements
Validation runs synchronously on each field change — no perceptible lag (<16ms per frame)
Form state does not trigger full-screen rebuilds; use form-scoped state management
security requirements
Phone number and email values must not be logged in debug or release builds
Auto-fill attributes set appropriately (name, tel, email) to leverage OS secure autofill, not insecure clipboard inspection
Form data held only in ephemeral Riverpod state until submitted — not persisted to local storage
ui components
AppTextField (existing reusable widget)
AppButton (existing reusable widget)
ContactDetailsForm
NewMemberOnboardingScreen

Execution Context

Execution Tier
Tier 2

Tier 2 - 518 tasks

Can start after Tier 1 completes

Implementation Notes

Use Flutter's built-in Form + GlobalKey for validation orchestration. Extend the existing AppTextField reusable widget rather than creating a new one — add label and error message props if not already present. Norwegian phone regex: r'^(\+47)?[49]\d{7}$'. Email regex: r'^[\w.+-]+@[\w-]+\.[\w.]+$'.

Use Riverpod's StateNotifierProvider or a FormNotifier to hold form values reactively and drive the submit button enabled state. Wrap fields in a Column inside SingleChildScrollView to prevent overflow when the keyboard is open. Ensure InputDecoration.floatingLabelBehavior is set to FloatingLabelBehavior.always so labels are always visible. Set textInputAction to TextInputAction.next on name and phone fields, and TextInputAction.done on the email field.

Testing Requirements

Widget tests for each validation rule: empty submission, invalid phone formats, invalid email formats, Norwegian characters in name, and all-valid submission. Test that the submit button is disabled with empty fields and enabled with valid inputs. Test keyboard type per field using widget finder assertions. Accessibility test: verify Semantics label is set on each field and that error messages have role='alert' equivalent (using Semantics(liveRegion: true)).

Test form state retention when simulating keyboard open/close via MediaQuery override.

Component
New Member Onboarding Screen
ui medium
Dependencies (1)
On NewMemberOnboardingScreen, display the organisation's logo, brand colors sourced from the design token system, and a Norwegian-language welcome message. The welcome copy must be localised (nb_NO) and reference the referring peer mentor's organisation name dynamically. epic-membership-recruitment-peer-mentor-ui-task-009
Epic Risks (3)
medium impact medium prob technical

QR codes rendered at the minimum 200×200 size may fail to scan under typical indoor lighting conditions on older or lower-resolution phone cameras, causing recruitment moments to fail when a peer mentor shows the screen to a prospective member.

Mitigation & Contingency

Mitigation: Set the default QR render size to 260×260 logical pixels (not the 200px minimum) and apply a high-contrast white module background. Test scan reliability on at minimum three physical devices (budget Android, mid-range Android, iPhone SE) before marking the screen as done.

Contingency: If scan reliability remains an issue, add a 'Enlarge QR' full-screen mode triggered by tapping the code, and ensure the text referral URL with copy-to-clipboard is always visible as a fallback sharing method.

high impact medium prob integration

The onboarding screen submits attribution and then hands off to an external membership registration URL (HLF's Dynamics portal or similar). If the external URL is unavailable, changes its format, or requires authentication the new member does not have, the conversion funnel is broken at its final step.

Mitigation & Contingency

Mitigation: Confirm the external registration URL and its expected query parameters with HLF's portal team before implementing the handoff. Record the pending_signup attribution event before launching the URL so data is not lost if the external site fails. Display a fallback message with contact information if the URL launch fails.

Contingency: If the external membership URL is not available at feature launch, implement a temporary form that collects name and email and stores a pending_member record in Supabase, allowing coordinators to manually complete registration while the integration is finalised.

low impact medium prob integration

Embedding the RecruitmentStatsWidget on the peer mentor home screen may conflict with existing layout components (activity summary, badge shelf), causing overflow or requiring a redesign of the home screen that is outside this epic's scope.

Mitigation & Contingency

Mitigation: Design the widget as a horizontally constrained card with a maximum height of 96dp so it can be inserted into any vertical list without overflow. Coordinate with the home screen's existing layout owners before starting the embedding task.

Contingency: If home screen embedding creates unacceptable layout conflicts, defer embedding to a separate home-screen redesign task and make the widget accessible only via the dedicated ReferralCodeScreen for the initial release.

Quick Links
All Tasks Execution Plan