MEDIUM story-email-password-login-peer-mentor-008 2 pts
2
Story Points
Medium
Priority
Email and Password Login
Feature

User Story

As a Peer Mentor (Likeperson)
I want the app to check that my email address is in a valid format before sending my login request
So that So that I get immediate feedback if I have made a typo in my email, rather than waiting for a server round-trip to tell me something is wrong

Audience Summaries

Client-side email validation directly reduces operational costs by eliminating avoidable server requests caused by malformed input. For peer mentors operating in rural Norway — where network connectivity is often unreliable — this improvement is not cosmetic: it meaningfully reduces data consumption and perceived latency during authentication. Fewer failed requests translate into lower API call volume, reducing infrastructure costs at scale. Faster, inline feedback shortens the error-correction loop, improving user satisfaction and reducing login abandonment.

This story supports the platform's commitment to accessibility and usability for a diverse user base, including those with limited digital literacy, reinforcing trust and adoption across participating organisations.

This is a medium-priority story with self-contained scope: all logic runs client-side with no new backend dependencies. Effort is low to moderate — primarily UI form logic and field-level error state management. The five acceptance criteria are clear and testable: empty email, invalid email format, empty password, successful validation triggering a network call, and error clearance on correction. QA must confirm that validation fires on submit (not keystroke), that network requests are fully blocked when validation fails, and that loading indicators appear correctly on success.

No cross-team dependencies are anticipated, though alignment with the design system on error message styles should be confirmed early to avoid rework.

Implementation requires a submit-time validation handler on the login form that checks the email field against a standard RFC-compliant regex pattern and verifies the password field is non-empty before any authentication API call is dispatched. Field-level error messages must be rendered inline, adjacent to the relevant input, using the existing error component pattern. The loading state on the submit button must only activate after all client-side checks pass. Edge cases include: empty string vs.

whitespace-only input for both fields, email patterns with valid structure but unusual TLDs, and correct error clearance when the user re-submits after correction. No changes to backend auth endpoints are required. Unit tests should cover all five acceptance criteria scenarios.

Acceptance Criteria

  • Given the email field contains 'notanemail', When the user taps the sign-in button, Then inline validation displays 'Please enter a valid email address' adjacent to the email field and no network request is made
  • Given the email field is completely empty, When the user taps sign in, Then the error 'Email address is required' is shown for the email field
  • Given the password field is empty, When the user taps sign in, Then the error 'Password is required' is shown for the password field
  • Given all client-side validation passes, When the user taps sign in, Then the network authentication request is initiated and a loading indicator is shown on the button
  • Given an inline validation error is shown, When the user corrects the field and taps sign in again, Then the field error clears and the request proceeds if all fields are now valid

Business Value

Client-side validation reduces failed server requests, lowers API costs, and provides a measurably faster error-correction cycle for the user. For peer mentors in areas with poor connectivity — common in rural Norway where peer support work often takes place — avoiding unnecessary network round-trips for avoidable input errors improves perceived performance and reduces data usage.

Dependencies