04 — Information Architecture (Homework Module)

• 1. Zone: authenticated app → Homework destination
• 2. Route table (module-owned; extends 00-shared/05 §4)
• 3. Screen hierarchy
• 4. Modal hierarchy (module, per 00-shared/05 §5)
• 5. Screen relationships
• 6. Quick actions / FAB / context menus
• 7. Information needs per screen (content model)
• 8. Accessibility of IA

Where Homework screens live in the shell (00-shared/05 §2: /homework destination, roles teacher, student, parent-read). Routes mirror the API exactly: homework.controller.ts exposes POST /homework, GET /homework/class/:classId, GET /homework/:id, PATCH /homework/:id, DELETE /homework/:id, POST /homework/:id/submit, GET /homework/:id/submissions, PATCH /homework/:id/submissions/:submissionId/grade.

1. Zone: authenticated app → Homework destination

AppShell (/homework branch)
 └─ /homework                          HomeworkList (role-filtered)
     ├─ /homework/new                  Create/Edit form (teacher/admin)
     ├─ /homework/:id                  Homework detail
     │   ├─ submissions tab (teacher/admin)  → grading sheet
     │   └─ grade feedback (student/parent)  → submission detail
     └─ /homework/:id/edit             Edit form (teacher/admin; PATCH)

• Phone: push navigation; Tablet/desktop (≥ 840 dp): master-detail — list left, detail right (00-shared/04 §6).

2. Route table (module-owned; extends 00-shared/05 §4)

Deep link: studylyon://homework/:id (00-shared/05 §4).

3. Screen hierarchy

flowchart TD
    HW[/homework/ list/] --> NEW[/homework/new create/]
    HW --> D[/homework/:id detail/]
    D --> E[/homework/:id/edit/]
    D --> SUB[/homework/:id/submit/]
    D --> SL[/homework/:id/submissions teacher/]
    SL --> GS[/submissions/:submissionId grade sheet/]
    D --> FD[/grade feedback student/]

• List is the hub: creation, detail, and (teacher) submissions all branch from it.
• Detail is role-shaped: student sees Submit + grade feedback; teacher sees Edit/Delete menu + Submissions; parent sees read-only (planned).

4. Modal hierarchy (module, per 00-shared/05 §5)

1. Snackbar/toast — "Homework assigned", "Submitted", "Graded", "Copied" (attachment).
2. Bottom sheet — attachment preview picker, grade summary quick-view.
3. Dialog — delete confirm, regrade confirm ("overwrites existing grade"), submit confirm when late (client-computed flag).
4. Full-screen page — create/edit form (> 3 fields → page), grading sheet (list-like, full screen for batch work).
5. Loader — inline spinners / skeletons; never full-screen dual column.

5. Screen relationships

• List → detail → edit returns → detail refreshes (Refresh).
• Detail → submissions → grade sheet returns → submission row shows new grade.
• Student detail → submit success → detail shows "Submitted" state (server doc is the single source of truth).
• Any homework state change on server (graded elsewhere) → next screen open re-fetches; WS (planned) topic for homework not in 00-shared/07 §8 list — use notification.new + pull-to-refresh.

6. Quick actions / FAB / context menus

• FAB on list: "New homework" (teacher/admin only; one FAB per screen, 00-shared/05 §7).
• Context menu on homework row: Edit, Delete (teacher/admin). On submission row (teacher): Open, Grade.
• Swipe (phone): row actions Edit/Delete (≤ 2, 00-shared/08 §1).
• Keyboard (desktop): N new homework on list; Esc closes sheets/dialogs.

7. Information needs per screen (content model)

8. Accessibility of IA

• One headlineMedium per screen; list rows read title, subject, due; grade rows read student, status, marks.
• Focus order: list → filter → FAB; forms in field order (08_Form_Specifications.md).