FOLLOW-UP PROMPT — Phase 1 Form Enhancement: Simulated Processing on Submit

Context

The main build is done (or in progress) from the master prompt. This prompt addresses a specific gap: when the user hits “Start My Application →” in Phase 1, the transition to Phase 2 currently feels instant and hollow. We need a 5–8 second simulated processing sequence between Phase 1 submission and Phase 2 start that makes the lead feel like something real just happened with their information.

What to Build

When the user submits the Phase 1 form (name, email, phone), do NOT immediately jump to Phase 2. Instead:

Step 1: Form Validation Microinteraction (0–0.5s)

Each field gets a small ✓ checkmark that appears sequentially (name → email → phone), 150ms apart
The checkmarks are --status-success green, small (12px), appear to the right of each input
The button text changes from “Start My Application →” to a state with a spinner
The button becomes non-interactive (pointer-events: none, slight opacity reduction to 0.8)

Step 2: The Verification Strip (0.5s–6s)

The form area smoothly compresses upward (or the content below it expands) to reveal a processing strip — a narrow, full-width horizontal band below the form that shows a sequence of verification steps.

This strip has a monospace font (JetBrains Mono or the mono font from the design system) and displays steps one at a time, each replacing the previous:

SEQUENCE (show each for ~1.2 seconds, crossfade between them):

1. "Securing connection..."
   └─ A subtle progress bar fills from left to right during this step (thin, 2px, --accent color)

2. "Validating contact information..."
   └─ Show the phone number partially masked: +971 ●●● ●●48
   └─ Small text appears: "Format verified"

3. "Checking against existing applications..."
   └─ Small text appears: "No duplicate found"

4. "Initializing application workspace..."
   └─ Small text appears: "Ref: FC-2026-[5 random digits]"
   └─ This reference number should persist and appear again in Phase 3

5. "Ready."
   └─ This one stays for 0.6s, then the transition to Phase 2 begins

Visual treatment of the strip:

Background: --bg-surface or slightly darker than the page
Top border: 1px --border-subtle
Text color: --text-secondary for the main line, --text-muted for the sub-lines
The active step text has --text-primary color
Left-aligned, with a small pulsing dot (●) indicator before the text during processing, which becomes a static checkmark (✓) when that step completes
Each step fades in (opacity 0→1, translateY 4px→0, 200ms) and the previous step fades to --text-muted and slides up slightly before being replaced
The 2px progress bar at the top of the strip fills across ALL steps (not per-step) — so it’s at ~20% after step 1, ~40% after step 2, etc., reaching 100% at “Ready.”

Step 3: Transition to Phase 2 (6s–6.8s)

The entire Phase 1 content (hero, form, strip) fades out and slides up (opacity 1→0, translateY 0→-20px, 400ms)
Phase 2 Step 1 fades in from below (opacity 0→1, translateY 20px→0, 400ms, 200ms delay after Phase 1 exit)
At the top of Phase 2, show a small persistent header bar with:
- FirstChapter logo (small, ~24px height)
- The user’s name: “Hi, [First Name]”
- The reference number from step 4: “Ref: FC-2026-XXXXX”
- This bar stays fixed during all of Phase 2 and Phase 3

Bonus: Phase 2 Step Transitions

While you’re at it — each step transition within Phase 2 (when user selects an option and moves to the next question) should also have a micro-processing feel:

When user selects an option → the selected card gets a brief --accent border flash (100ms)
300ms pause (the card appears “locked in”)
A small text appears below the selection grid: “Got it.” in --text-secondary, fades in over 200ms
500ms pause
Then the current step exits (fade + slide up) and the next step enters (fade + slide in from below)
Total transition time per step: ~1 second. Fast enough to not annoy, slow enough to feel deliberate.

Each Phase 2 step should also show a step indicator — not a traditional progress bar, but a simple text counter in the top-right of the content area:

01 / 05

Monospace, --text-muted color, small size (13px). Updates with each step.

Technical Notes

The reference number generated in Phase 1 (step 4 of the strip) must be stored in React state and passed through to Phase 3 where it appears in the final summary card. Use a simple useRef or top-level state variable — do NOT regenerate it.
The progress bar in the verification strip should use a CSS transition on width, not a JS animation loop. Set transition: width 1.2s linear and update the width via state on each step change.
The persistent header bar in Phase 2/3 should be position: sticky; top: 0 with backdrop-filter: blur(12px) and a semi-transparent --bg-primary background (rgba equivalent with 0.85 alpha).
All delays should use setTimeout wrapped in useEffect cleanup to prevent memory leaks if the user somehow navigates away.
The phone number masking in step 2: take the last 2 digits of the entered phone, mask everything else with ● — this creates a “we actually validated your real number” feel without exposing the full number back.

What This Achieves

Right now the form submit → next screen jump feels like a client-side form wizard. After this enhancement, it feels like submitting an application to a real system that:

Validates their identity
Checks for duplicates
Opens a case file
Assigns a reference number

This is the difference between “I filled out a web form” and “I started an application.” That perception gap is exactly what FirstChapter needs Shams executives to feel when they see this demo.

Constraints (same as master prompt)

No bounce/spring animations
No Lottie or SVG animation libraries
All transitions via CSS transition or animation with @keyframes
Monospace font for all processing text
No emoji in the processing strip — use ● and ✓ characters only
Mobile: the strip stacks naturally, text sizes stay the same, progress bar spans full width

esafwan/Shams.md

Select an option

No results found