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          |
                        +----------------+
                                |
                +---------------+---------------+
                |               |               |
        +----------------+ +----------------+ +----------------+
        | Onboarding      | | Event Register  | | Dashboard      |
        | (invite link)   | | (public)        | | Role-based Nav |
        +----------------+ +----------------+ +----------------+
                                                        |
        +-------+-------+--------+----------+---------+---------+----------+
        |       |       |        |          |         |         |          |
   Attendance Students Classes Reports Settings Import/  Events    Capacity
                                        |          Export  (admin)   (live)
                                   +----+----+                      
                                   |         |                      
                               Users    Roles/Nuclei

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:

+-----------------------------------------------+
| Perfil do estudante                           |
+-----------------------------------------------+
| [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 Student Onboarding Flow (invite link)

Invite Link -> Multi-step Form -> OTP Verification -> Complete
  Step 1: Basic Info (name, birth date, photo)
  Step 2: Contact (phone, address)
  Step 3: Health (allergies, special needs)
  Step 4: Sociodemographic Profile
  Step 5: LGPD Consent
  Step 6: OTP Verification

Expected behavior:

• Each step validates independently before advancing.
• Progress indicator shows current step.
• OTP sent to registered phone; expires after 5 minutes.
• On completion, student is created and linked to the inviter's organization.

4.7 Public Event Registration Flow

Event Link -> Registration Form -> Confirm -> Success

Wireframe:

+-----------------------------------------------+
| Inscrição para o Evento                       |
+-----------------------------------------------+
| Nome do Aluno                                 |
| [___________________________________________] |
|                                               |
| Responsável                                   |
| [___________________________________________] |
|                                               |
| Telefone                                      |
| [___________________________________________] |
|                                               |
| [Cancelar]                       [Inscrever]  |
+-----------------------------------------------+

Expected behavior:

• Accessible via public URL without authentication.
• Validates required fields before submission.
• Confirms registration with success message.
• Admin can view all registrations at /events/:eventId/registrations.

4.8 Classes and Sessions Flow

Dashboard -> Classes -> Class List -> Class Detail -> Slots & Sessions

Class list behavior:

• Shows all active classes with age range (e.g., Berçário: 0-2 anos).
• Selecting a class opens detail with weekly slots and session history.

Wireframe:

+-----------------------------------------------+
| Turmas                                        |
+-----------------------------------------------+
| [Berçário]        0-2 anos                    |
| [Maternal Infantil] 2-3 anos                  |
| [Jardim de Infância] 3-4 anos                 |
| ...                                           |
|                                               |
| [+ Nova Turma]                                |
+-----------------------------------------------+

ClassSlot model:

• Weekly recurring slot with day of week and time.
• Each slot generates ClassSession instances for attendance tracking.
• Sessions can be created ad-hoc or from recurring slots.

4.9 Import/Export Flow

Dashboard -> Import/Export -> Tab: Export | Import | Templates

Wireframe:

+-----------------------------------------------+
| Importar / Exportar                           |
+-----------------------------------------------+
| [Exportar] [Importar] [Templates]             |
+-----------------------------------------------+
|                                               |
| Exportar:                                     |
| Entidade: [Alunos v]  Formato: [Excel v]     |
| [Exportar]                                    |
|                                               |
| Importar:                                     |
| Arquivo: [Selecionar...]                      |
| [Validar] [Importar]                          |
|                                               |
| Templates:                                    |
| Baixar template para preenchimento manual.    |
| [Baixar Template de Alunos]                   |
| [Baixar Template de Turmas]                   |
+-----------------------------------------------+

Expected behavior:

• Export generates .xlsx file with current data.
• Import validates file structure before committing.
• Templates provide correct column headers for manual data entry.
• Errors during import are reported per-row with actionable messages.

4.10 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

• CHAMADOR: Attendance, Search.
• RELATORIOS: Reports, Search.
• CADASTRO: Students add, Classes, Nuclei, Search.
• RESPONSAVEL: View own students.
• VOLUNTARIO: Limited student browse, session view.
• COORDENACAO_KIDS: Reports (consolidated), Student browse (full).
• ADMINISTRATIVO_KIDS: Reports (consolidated), Student browse (full).
• ADMIN: Full navigation including delete, settings, user management, and role management.

Unauthorized action pattern:

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

Dynamic roles:

• Custom roles can be created by ADMIN via Settings > Roles.
• Each custom role selects from the 25 available permissions.
• System roles cannot be deleted; custom roles with assigned users are blocked from deletion.

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.
• Plugin routes and i18n entries are registered and tested.
• Public routes (onboarding, event registration) work without authentication.

10. User Management Flow (Admin only)

Settings -> Usuários -> Listar usuários -> (Criar | Editar | Resetar senha | Desativar)

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.