Screen Designs

This section contains screen specifications for the Registration Portal Phase 2. Screens are organized by scope (Common, Membership-specific, Event-specific) and include wireframes, field specifications, and behavior notes.

1. Screen Inventory

Screen Scope Phase Purpose

Identity Selection

Common

Phase 2

OIDC sign-in or anonymous access choice

Registration Overview (Membership)

Membership

Existing + Phase 2

Membership period, member status, person selection

Registration Overview (Event)

Event

Phase 2

Event details, participant status, cancellation

Link Person - Search

Common

Existing + Phase 2

Search by ID number or DOB

Link Person - Results

Common

Phase 2

Masked search results display

Link Person - Create

Common

Existing

New person creation form

Registration Questions

Common

Existing + Phase 2

ProcessDefinition-driven questions

Payment Selection

Common

Phase 2

Online vs manual payment choice

Manual Payment - QR Handoff

Common

Phase 2

QR code display for staff capture

Online Payment - Redirect

Common

Existing

Gateway redirect (minimal UI)

Confirmation

Common

Existing

Success message and summary

Event Cancellation

Event

Phase 2

Cancel with refund calculation

2. Common Screens

2.1. SCR-001: Identity Selection

Purpose: Allow users to authenticate via OIDC or continue anonymously.

When Displayed: Entry point for Event Registration when OIDC is configured.

Not Displayed: Membership Registration (uses hash-based access).

Prototype: View Interactive Prototype

2.1.1. Wireframe

@startuml
salt
{
  <b>Welcome to Event Registration
  ==
  .
  How would you like to continue?
  .
  { [Sign in with Google] }
  .
  or
  .
  { [Continue without signing in] }
  .
  .
  <i>Sign in to access your saved profile and
  <i>linked persons from previous registrations.
}
@enduml

2.1.2. Elements

Element Type Behavior Required

Title

Heading

"Welcome to Event Registration"

Yes

OIDC Button

Button

Redirect to configured identity provider

When OIDC configured

Anonymous Button

Button

Create anonymous session, proceed to Registration Overview

Yes

Help Text

Paragraph

Explains benefit of signing in

Yes

2.1.3. Behavior Notes

  • OIDC provider name displayed dynamically (e.g., "Sign in with Google")

  • Multiple OIDC providers may be configured (show multiple buttons)

  • Anonymous option always available

  • On successful OIDC auth, redirect to Registration Overview with profile loaded

  • On failed auth, show error message with retry option

2.2. SCR-002: Link Person - Search

Purpose: Search for existing persons by ID number or date of birth.

When Displayed: User clicks "Add Person" or "Add Family Member" from Registration Overview.

2.2.1. Wireframe

@startuml
salt
{
  <b>Find a Person
  ==
  .
  Search by:
  .
  (X) SA ID Number
  ( ) Date of Birth
  .
  ID Number:
  [ 8503150123089         ]
  .
  { [Cancel] | [Search] }
}
@enduml

2.2.2. Alternate: DOB Search

@startuml
salt
{
  <b>Find a Person
  ==
  .
  Search by:
  .
  ( ) SA ID Number
  (X) Date of Birth
  .
  Date of Birth:
  [ 1985 ] / [ 03 ] / [ 15 ]
  .
  { [Cancel] | [Search] }
}
@enduml

2.2.3. Elements

Element Type Behavior Required

Search Type

Radio buttons

Toggle between ID Number and DOB search

Yes

ID Number Field

Text input

13-digit SA ID validation

When ID selected

DOB Fields

Date picker / dropdowns

Year → Month → Day selection

When DOB selected

Cancel Button

Button

Return to Registration Overview

Yes

Search Button

Button

Execute search, show results or create form

Yes

2.2.4. Validation Rules

  • ID Number: Must be exactly 13 digits, valid Luhn checksum

  • DOB: Valid date, not in future, reasonable age range

2.3. SCR-003: Link Person - Results (DOB Search)

Purpose: Display masked search results for DOB-based searches.

When Displayed: After DOB search returns matches.

2.3.1. Wireframe

@startuml
salt
{
  <b>Search Results
  ==
  .
  Found 3 people born on 1985-03-15:
  .
  {T
    | Name | Gender | Action
    + M*** J******* | Male | [Select]
    + M****** S**** | Male | [Select]
    + M******* R****** | Female | [Select]
  }
  .
  Not the right person?
  { [Create New Person] }
  .
  { [← Back to Search] }
}
@enduml

2.3.2. Elements

Element Type Behavior Required

Results Count

Text

"Found X people born on [date]"

Yes

Results Table

Table

Masked name, gender, select action

Yes

Masked Name

Text

First letter visible, rest masked (e.g., "M* J*")

Yes

Gender

Text

Full gender displayed

Yes

Select Button

Button

Navigate to confirmation/linking

Per row

Create New Button

Button

Navigate to Create Person form

Yes

Back Button

Button

Return to search form

Yes

2.3.3. Masking Rules

  • First Name: Show first letter, mask remainder with asterisks

  • Last Name: Show first letter, mask remainder with asterisks

  • Gender: Display fully (Male, Female, Other)

  • No other fields displayed (email, phone, ID hidden)

2.4. SCR-004: Link Person - Create

Purpose: Create a new person when no match found.

When Displayed: After search returns no results, or user chooses "Create New Person".

2.4.1. Wireframe

@startuml
salt
{
  <b>Create New Person
  ==
  .
  Identity (from search - locked):
  ID Number: [ 8503150123089 ] (locked)
  Date of Birth: [ 1985-03-15 ] (locked)
  Gender: [ Male ] (locked)
  .
  Personal Details:
  First Name*: [ John                ]
  Last Name*: [ Smith               ]
  Email: [ [email protected]    ]
  Contact Number: [ 0821234567        ]
  .
  { [Cancel] | [Save] }
}
@enduml

2.4.2. Elements

Element Type Behavior Required

ID Number

Text (locked)

Pre-populated from search, not editable

When ID search

Date of Birth

Text (locked)

Pre-populated from search, not editable

Yes

Gender

Text (locked)

Auto-derived from ID or selected

Yes

First Name

Text input

User enters first name

Yes

Last Name

Text input

User enters last name

Yes

Email

Email input

Optional contact email

No

Contact Number

Tel input

Optional phone number

No

Cancel Button

Button

Return to search

Yes

Save Button

Button

Create person, link to profile, return to overview

Yes

2.5. SCR-005: Registration Questions

Purpose: Display ProcessDefinition-driven questions for all selected persons.

When Displayed: After person selection, during registration workflow.

2.5.1. Wireframe - Text Question

@startuml
salt
{
  <b>Emergency Contact Number
  ==
  .
  Please provide an emergency contact number for each person:
  .
  Sarah Smith:
  [ 0821234567          ]
  .
  Billy Smith:
  [ 0821234567          ]
  .
  Emma Smith:
  [ 0821234567          ]
  .
  { [← Back] | [Next →] }
}
@enduml

2.5.2. Wireframe - Checkbox Question

@startuml
salt
{
  <b>Medical Conditions
  ==
  .
  Does anyone have any medical conditions we should be aware of?
  .
  [ ] Sarah Smith
  [X] Billy Smith
  [ ] Emma Smith
  .
  { [← Back] | [Next →] }
}
@enduml

2.5.3. Wireframe - Communication Preferences (Multi-Select)

@startuml
salt
{
  <b>Communication Preferences
  ==
  .
  How would you like to receive updates and notifications?
  .
  Sarah Smith:
  [X] Email  [ ] SMS  [X] WhatsApp
  .
  Billy Smith:
  [X] Email  [ ] SMS  [ ] WhatsApp
  .
  Emma Smith:
  [X] Email  [ ] SMS  [ ] WhatsApp
  .
  <i>Select at least one option per person.
  .
  { [← Back] | [Next →] }
}
@enduml

2.5.4. Wireframe - Terms & Conditions

@startuml
salt
{
  <b>Terms and Conditions
  ==
  .
  Please read and accept the terms and conditions:
  .
  [Terms and conditions text displayed here...]
  .
  [X] I accept for all members
  .
  [X] Sarah Smith - I accept the terms and conditions
  [X] Billy Smith - I accept the terms and conditions
  [X] Emma Smith - I accept the terms and conditions
  .
  { [← Back] | [Next →] }
}
@enduml

2.5.5. Question Types Supported

Type UI Component Behavior

TXT

Text input per person

Free text entry

NUM

Number input per person

Numeric validation

DRP

Dropdown per person

Select from options

BCB

Checkbox per person

Yes/No binary

ITC

Master checkbox + individual

Terms acceptance

ONE

Radio buttons (single select)

Exactly one person selected

RDO

Radio per person

Select option per person

SEL

Checkbox group per person

Multi-select (e.g., comms preference)

2.6. SCR-006: Payment Selection

Purpose: Allow user to choose between online and manual payment.

When Displayed: After completing registration questions, when manual payment is enabled.

Prototypes:

2.6.1. Wireframe

@startuml
salt
{
  <b>Payment
  ==
  .
  Registration Summary:
  .
  Sarah Smith (Adult): R 500.00
  Billy Smith (Junior): R 300.00
  Emma Smith (Junior): R 200.00
  --------------------------------
  Total: R 1,000.00
  .
  How would you like to pay?
  .
  { [Pay Online] }
  .
  { [Pay at Registration Desk] }
  .
  { [← Back] }
}
@enduml

2.6.2. Elements

Element Type Behavior Required

Summary Table

List

Itemized participants and amounts

Yes

Total

Text (bold)

Sum of all registration fees

Yes

Pay Online Button

Button

Redirect to WooCommerce gateway

Yes

Pay at Desk Button

Button

Navigate to QR code screen

When enabled

Back Button

Button

Return to last question

Yes

2.7. SCR-007: Manual Payment - QR Handoff

Purpose: Display QR code for staff to capture payment.

When Displayed: After user selects "Pay at Registration Desk".

Prototype: View Interactive Prototype

2.7.1. Wireframe

@startuml
salt
{
  <b>Pay at Registration Desk
  ==
  .
  Present this code to the staff member:
  .
  +------------------+
  |                  |
  |   [QR CODE]      |
  |                  |
  +------------------+
  .
  Reference: <b>REF-2024-8A3F
  Amount: <b>R 1,000.00
  .
  <i>The staff member will scan this code
  <i>to process your payment.
  .
  This page will update automatically
  when payment is confirmed.
  .
  { [Cancel Registration] }
}
@enduml

2.7.2. Elements

Element Type Behavior Required

QR Code

Image

Encodes reference number

Yes

Reference Number

Text (bold)

Unique payment reference

Yes

Amount

Text (bold)

Total to be paid

Yes

Help Text

Paragraph

Instructions for user

Yes

Auto-Update Note

Text

Explains automatic confirmation

Yes

Cancel Button

Button

Cancel registration, return to overview

Yes

2.7.3. Behavior Notes

  • Page polls backend for payment status (WebSocket or polling)

  • On payment confirmation, automatically navigate to Confirmation screen

  • Timeout after configured period (e.g., 30 minutes)

  • On timeout, show expiry message with options

2.8. SCR-008: Confirmation

Purpose: Display successful registration confirmation.

When Displayed: After successful online or manual payment.

2.8.1. Wireframe - Membership

@startuml
salt
{
  <b>Registration Complete!
  ==
  .
  ✓ Payment Successful
  .
  Membership Numbers:
  .
  Sarah Smith: M2024-1523
  Billy Smith: M2024-1524
  Emma Smith: M2024-1525
  .
  Amount Paid: R 1,000.00
  Reference: ORD-892-2024
  .
  A confirmation email has been sent to
  [email protected]
  .
  { [Return to Home] }
}
@enduml

2.8.2. Wireframe - Event

@startuml
salt
{
  <b>Registration Complete!
  ==
  .
  ✓ Payment Successful
  .
  Registered Participants:
  .
  Billy Smith - Bib: B1523 - 10km Run
  .
  Amount Paid: R 350.00
  Reference: ORD-893-2024
  .
  Race Pack Collection:
  March 14, 2024, 10:00-18:00
  Centurion Mall
  .
  A confirmation email has been sent to
  [email protected]
  .
  { [Return to Home] }
}
@enduml

3. Membership-Specific Screens

3.1. SCR-101: Registration Overview (Membership)

Purpose: Display membership period details, member status, and person selection.

When Displayed: Entry point for Membership Registration after hash validation.

Prototype: View Interactive Prototype

3.1.1. Wireframe

@startuml
salt
{
  <b>2024 Running Club Membership
  ==
  .
  Registration Period: Jan 1 - Dec 31, 2024
  .
  Select Family Members:
  .
  {T
    | ☐ | Name | Date of Birth | Status | Actions
    + ☐ | Sarah Smith | 1985-03-15 | Available | [Edit]
    + ☐ | Billy Smith | 2010-11-03 | Available | [Edit]
    + ☐ | Emma Smith | 2013-07-20 | Registered | -
  }
  .
  { [+ Add Family Member] }
  .
  Selected: 0 | Total: R 0.00
  .
  { [Continue →] }
}
@enduml

3.1.2. Elements

Element Type Behavior Required

Membership Title

Heading

Membership type and period name

Yes

Registration Period

Text

Open/close dates

Yes

Person Table

Table

Checkbox, name, DOB, status, actions

Yes

Status Column

Badge

Available, Registered, Pending Payment

Yes

Edit Action

Button

Navigate to edit person (if permitted)

When editable

Add Person Button

Button

Navigate to Link Person search

Yes

Selection Summary

Text

Count and calculated total

Yes

Continue Button

Button

Proceed to Registration Details (questions)

Yes

3.1.3. Status Badges

Status Meaning Selectable?

Available

Can be registered

Yes

Registered

Already has active membership

No

Pending Payment

Registration awaiting payment

No

4. Event-Specific Screens

4.1. SCR-201: Registration Overview (Event)

Purpose: Display event details, participant status, and actions including cancellation.

When Displayed: Entry point for Event Registration.

Prototype: View Interactive Prototype

4.1.1. Wireframe

@startuml
salt
{
  <b>10km Fun Run - March 15, 2024
  ==
  .
  Location: Centurion, Gauteng
  Entry Fee: R 350.00 per participant
  Registration Closes: March 10, 2024
  .
  Your Participants:
  .
  {T
    | ☐ | Name | Status | Bib | Actions
    + ☐ | Sarah Smith | Available | - | [Edit]
    + - | Billy Smith | Registered | B1523 | [Cancel]
    + ☐ | Emma Smith | Available | - | [Edit]
  }
  .
  { [+ Add Person] }
  .
  Selected: 0 | Total: R 0.00
  .
  { [Register Selected →] }
}
@enduml

4.1.2. Elements

Element Type Behavior Required

Event Title

Heading

Event name and date

Yes

Event Details

Text

Location, fee, close date

Yes

Participant Table

Table

Checkbox, name, status, bib, actions

Yes

Bib Number

Text

Assigned bib for registered participants

When registered

Cancel Action

Button

Navigate to cancellation flow

When registered by current user

Add Person Button

Button

Navigate to Link Person search

Yes

Selection Summary

Text

Count and calculated total

Yes

Register Button

Button

Proceed to Registration Details

Yes

4.2. SCR-202: Event Cancellation

Purpose: Display cancellation details and refund calculation.

When Displayed: User clicks "Cancel" for a registered participant.

4.2.1. Wireframe - With Refund

@startuml
salt
{
  <b>Cancel Registration
  ==
  .
  Participant: Billy Smith
  Event: 10km Fun Run - March 15, 2024
  Original Amount: R 350.00
  .
  Refund Calculation:
  .
  Cancellation: 14 days before event
  Refund Policy: 90% refund (10% admin fee)
  .
  <b>Refund Amount: R 315.00
  .
  The refund will be processed to your
  original payment method within
  5-7 business days.
  .
  { [Go Back] | [Confirm Cancellation] }
}
@enduml

4.2.2. Wireframe - No Refund

@startuml
salt
{
  <b>Cancel Registration
  ==
  .
  Participant: John Smith
  Event: 10km Fun Run - March 15, 2024
  Original Amount: R 350.00
  .
  Refund Calculation:
  .
  Cancellation: 3 days before event
  Refund Policy: No refund within 7 days
  .
  <b>Refund Amount: R 0.00
  .
  ⚠ WARNING: Cancellations within 7 days
  of the event are not eligible for refunds.
  .
  { [Go Back] | [Confirm Cancellation] }
}
@enduml

4.2.3. Elements

Element Type Behavior Required

Participant Name

Text

Person being cancelled

Yes

Event Details

Text

Event name and date

Yes

Original Amount

Text

Amount originally paid

Yes

Days Until Event

Text

Calculated from current date

Yes

Refund Policy

Text

Applicable rule

Yes

Refund Amount

Text (bold)

Calculated refund

Yes

Warning

Alert

Shown when no refund

When <7 days

Go Back Button

Button

Return to Event Overview

Yes

Confirm Button

Button

Process cancellation

Yes

4.2.4. Refund Rules

Timing Refund

≥7 days before event

90% (10% admin fee retained)

<7 days before event

0% (no refund)

4.3. SCR-203: Cancellation Confirmation

Purpose: Confirm successful cancellation.

When Displayed: After user confirms cancellation.

4.3.1. Wireframe

@startuml
salt
{
  <b>Registration Cancelled
  ==
  .
  ✓ Cancellation Successful
  .
  Billy Smith's registration for
  10km Fun Run has been cancelled.
  .
  Refund: R 315.00 will be processed
  to your original payment method
  within 5-7 business days.
  .
  { [Return to Event] }
}
@enduml

5. Responsive Design Requirements

5.1. Breakpoints

Breakpoint Width Layout Changes

Mobile

< 576px

Single column, stacked elements

Tablet

576px - 992px

Two columns where appropriate

Desktop

> 992px

Full multi-column layouts

5.2. Mobile Considerations

  • QR code must be large enough to scan easily

  • Tables convert to card layouts on mobile

  • Touch-friendly button sizes (minimum 44px)

  • Form inputs full-width on mobile

6. Accessibility Requirements

  • WCAG 2.1 AA Compliance required

  • Keyboard Navigation - All actions accessible via keyboard

  • Screen Reader Support - Proper ARIA labels and landmarks

  • Color Contrast - Minimum 4.5:1 for normal text

  • Focus Indicators - Visible focus states on all interactive elements

  • Error Messages - Associated with form fields, announced to screen readers

7. Interactive UI Prototypes

The following interactive HTML prototypes demonstrate the visual design and interaction patterns for Phase 2 screens.

Screen Description Prototype

Identity Selection

SCR-001: OIDC sign-in or anonymous access choice

View

Landing Page

Generic landing page with events and membership panels

View

Registration Overview (Membership)

SCR-101: Membership period, member status, person selection

View

Registration Overview (Event)

SCR-201: Event details, participant status, registration

View

Payment Selection (Membership)

SCR-006: Order summary and payment method choice

View

Payment Selection (Event)

SCR-006: Event order summary with individual line items

View

Manual Payment - QR Handoff

SCR-007: QR code display for staff capture

View
These prototypes are interactive HTML files with JavaScript for demonstration purposes. Click through the flows to experience the intended user journey.

8. Related Documentation