UI Wireframes and User Flows

Neemias

1. Purpose

This document defines low-fidelity screen structure and user flows before implementation. It ensures complete coverage for role behavior, offline and online state transitions, accessibility, and feedback placement.

2. Screen Map

+----------------+
| Login          |
+----------------+
        |
        v
+----------------+
| Dashboard      |----> Attendance
| Role-based Nav |----> Students
| Sync Indicator |----> Reports
+----------------+----> Settings
        |
        v
+----------------+
| Session Expired|
| Re-auth Modal  |
+----------------+

3. Global Layout Rules

• Top app bar includes connectivity and sync status on all screens.
• Primary action area remains reachable on mobile with one-hand interaction.
• Focus order is linear and predictable for keyboard users.
• All user-visible state changes trigger visual and optional auditory feedback.

4. Primary Flows

4.1 Login and Session

Start -> Login Form -> Authenticate -> Dashboard
                      -> Failed Login -> Error Feedback

Key UI elements:

• Username input with label.
• Password input with label and visibility toggle.
• Submit button.
• Error region announced to screen readers.

4.2 Attendance Marking Flow

Dashboard -> Search Student -> Student Card with Photo -> Mark Present or Mark Absent
          -> Confirm Action -> Success Feedback -> Queue or Sync

Wireframe:

+------------------------------------------------+
| Neemias                     Online  Synced|
+------------------------------------------------+
| Search: [______________________________]        |
|                                                |
| +--------------------------------------------+ |
| | [Photo]  Joao Silva   ID: 12345            | |
| | Last: Present 10:30                         | |
| +--------------------------------------------+ |
|                                                |
| [Mark Present]  [Mark Absent]                 |
+------------------------------------------------+

Behavior notes:

• Photo appears immediately on matching result.
• Confirmation dialog required before commit.
• Success feedback appears with text and status icon.

4.3 Student Creation Flow

Dashboard -> Students -> Add Student -> Fill Form -> Confirm -> Success

Student list behavior:

• Students are ordered alphabetically by display name.
• Selecting a student opens a profile/details view.

Wireframe:

+-----------------------------------------------+
| Add Student                                   |
+-----------------------------------------------+
| Name *                                        |
| [___________________________________________] |
|                                               |
| Photo *                                       |
| [Upload] [Preview]                            |
|                                               |
| [Cancel]                          [Confirm]   |
+-----------------------------------------------+

4.3.1 Student Profile / Details View

Students -> Student Profile -> View Details -> Close

Wireframe:

+-----------------------------------------------+
| Student Profile                               |
+-----------------------------------------------+
| [Photo]  Ana Oliveira                         |
| ID: 12348                                     |
|                                               |
| Last attendance: Present 10:30                |
|                                               |
| [Close]                                       |
+-----------------------------------------------+

Expected behavior:

• The profile view is used to demonstrate how a student record is presented to stakeholders.
• It surfaces identity data, photo, and recent attendance state.
• If attendance history is unavailable, the view shows an explicit empty state.

4.4 Admin Deletion Flow with Justification

Students -> Student Details -> Delete -> Justification Required -> Confirm -> Archived

Wireframe:

+-----------------------------------------------+
| Delete Student                                |
+-----------------------------------------------+
| Student: Joao Silva                           |
|                                               |
| Justification (required, 10 to 500 chars)     |
| [___________________________________________] |
| [___________________________________________] |
|                                               |
| Warning: Historical record is retained.       |
|                                               |
| [Cancel]                           [Delete]   |
+-----------------------------------------------+

Expected behavior:

• Non-admin users cannot access delete action.
• Empty or short justification blocks submission.
• Successful delete moves student to archived state, keeps history visible.

4.5 Offline and Sync Flow

Online -> Offline Detected -> Local Queue Mode -> Reconnect -> Sync Attempt -> Result

Wireframe status area:

+------------------------------------------------+
| Status: Offline                                |
| Changes saved locally. Pending: 3              |
| [View Queue]                                   |
+------------------------------------------------+

Expected behavior:

• Offline indicator stays persistent in app bar.
• Actions remain available for essential attendance workflow.
• Sync success or failure state is explicit and dismissible.

4.6 Session Expiry and Re-authentication Flow

Offline work -> Session expires -> User attempts protected submit -> Re-auth required
             -> Login modal -> Success -> Submit queued actions

Wireframe modal:

+-----------------------------------------------+
| Session Expired                               |
+-----------------------------------------------+
| Your offline changes are safe.                |
| Re-authenticate to submit protected actions.  |
|                                               |
| Username                                      |
| [________________________]                    |
| Password                                      |
| [________________________]                    |
|                                               |
| [Cancel]                         [Sign In]    |
+-----------------------------------------------+

5. Role-Based Navigation

• ROLL_CALLER: Attendance, Search.
• REPORT_USER: Reports, Search.
• DATA_ENTRY: Students add, Search.
• ADMIN_USER: Full navigation including delete and settings.
• ADMIN_USER: Full navigation including delete, settings, and user management tab.

Unauthorized action pattern:

• Disable unavailable controls in menu and action areas.
• Provide clear denial message when direct route access is attempted.

6. Accessibility Notes

• Every control has visible label and semantic role.
• Focus indicator is always visible.
• No color-only status communication; pair color with icon and text.
• Error messages are associated with form fields.
• Keyboard support covers all flows, including dialogs.
• Screen-reader announcements for success and failure events.

7. Localization Notes

• Brazilian Portuguese is default for all labels and messages.
• All text comes from locale resources, not inline strings.
• Date and time display follow locale formatting.

8. State Indicator Placement

• Connectivity state: top-right app bar.
• Sync state and pending count: top app bar and status panel.
• Success and error feedback: toast region below app bar plus optional audio cue.
• Critical blockers such as session expiry: modal centered with focus trap.

9. Implementation Handoff Checklist

• Every required flow has a screen and transition.
• Every state has visible feedback.
• Every protected action has role and auth gate behavior.
• Every destructive action includes double-check and justification when required.
• Every key flow has keyboard and screen-reader path coverage.

10. User Management Flow (Admin only)

Settings -> Users -> List users -> (Create | Edit | Reset password | Deactivate)

Expected behavior:

• User list shows display name, username, role, and status.
• Create validates unique username and required password policy.
• Edit updates display name and role.
• Password reset updates hash only and records redacted audit payload.
• Deactivation requires confirmation and applies guard errors for self-deactivation and last active admin.
• Deactivated users are visually distinct and blocked from login.