Skip to content

Roadmap

Jump to bottom
Wouter Meetsma edited this page Jun 2, 2026 · 49 revisions

RubricMaker — Feature Roadmap

Items 1–13 are complete. This file tracks the remaining work.

Tier 4 — Testing & Quality

13. Playwright End-to-End Smoke Tests ✅

Status: Complete (PRs #93, #94)

Core smoke tests covering the offline teacher workflow are live. playwright.config.ts and e2e/ are in the repository.

14. Playwright E2E — Supabase Integration Coverage

Status: Planned
Tier: Testing & Quality
Effort: 3–5 days

The base smoke suite covers the offline path. The Supabase sync layer — auth, shared rubrics, cross-device data — has zero automated coverage. A silent bug there breaks cloud users without any test catching it.

What to build:

  • Use a local Supabase stack (npm run db:start) as the integration target; store credentials in .env.test
  • Cover the highest-risk sync paths:
    1. Sign in via email OTP → data loads from Supabase (not localStorage)
    2. Create a rubric while online → it appears in Supabase and persists after localStorage clear
    3. Shared rubric — teacher A shares, teacher B sees it
    4. Go offline → grade a student → come back online → grade syncs to Supabase
  • Use Playwright route() to mock Supabase REST/Realtime for fast unit-level sync tests
  • Add a npm run e2e:supabase script separate from the offline suite

Architecture impact: Test-only — no changes to app code.

Tier 5 — Architecture

15. Supabase-First Architecture (localStorage as Offline Cache)

Status: Planned
Tier: Architecture
Effort: 8–12 days

Currently localStorage is the source of truth and Supabase is a write-through cache. This causes Supabase data to lag behind, making cross-device access unreliable. Flipping the model — Supabase primary, localStorage offline cache — makes cloud sync reliable and opens the door to real-time collaboration between colleagues.

Scope:

  • Audit the read path in src/store/storage.ts and src/context/AppContext.tsx
  • AppContext hydrates from Supabase on load (when configured); localStorage is populated as a cache
  • Offline detection via navigator.onLine + reconnect events; queue writes and flush on reconnect
  • Conflict resolution: last-write-wins on updated_at timestamp (simplest safe default)
  • Auth-gated: the Supabase-first path only activates when VITE_SUPABASE_URL is set; full offline-only mode is unchanged for users without Supabase

Architecture impact: High — core data layer (storage.ts, AppContext, StorageSync). Requires a migration path for existing localStorage-only users and thorough E2E coverage before ship (see item 14).

Tier 6 — Reach & Localisation

16. Spanish (ES) i18n + FR/DE Completion

Status: Planned
Tier: Reach & Localisation
Effort: 1 day (technical) + translation review per language

EN and NL are complete. FR and DE are ~93% complete — both are missing the admin and onboarding namespace keys. Spanish opens a large new teacher market.

What to build:

  • Complete the two missing namespace keys in src/locales/fr.json and src/locales/de.json
  • Add src/locales/es.json (copy of en.json with values translated to Spanish)
  • Register es in src/i18n.ts
  • Add Spanish to the language selector in src/pages/SettingsPage.tsx
  • Update Internationalisation.md (wiki) to list ES as supported
  • Update CLAUDE.md to note all five locale files must be updated together: en, nl, fr, de, es

Architecture impact: Minimal — locale files + i18n registration only.

Tier 7 — Content & Templates

17. IB (International Baccalaureate) Rubric Templates

Status: Planned
Tier: Content & Templates
Effort: 1–2 days

IB is used in 5,000+ schools globally. MYP Language Acquisition has 4 criteria × 8 performance levels (0–8), a clean fit for the existing rubric model. DP Language A Literature and Language B criteria can also be pre-built.

What to build:

  • IB MYP Language Acquisition criteria as a built-in rubric template (JSON in src/data/)
  • IB DP Language A: Literature criteria
  • IB DP Language B criteria
  • Surface these in the template picker in the rubric builder

Architecture impact: Minimal — static data files + template picker extension.
Research: IB criteria are publicly documented; no API needed.

Tier 8 — EFL Core

18. Cambridge English Framework Integration

Status: Planned
Tier: EFL Core
Effort: 2–3 days (static) or 5–7 days (live API)

Cambridge levels (KET/PET/FCE/CAE/CPE mapping to A2–C2) are the dominant assessment framework for EFL teachers. A Cambridge API key field already exists in AdminPage settings but is not yet wired to any functionality.

What to build:

  • Investigate Cambridge Assessment API availability and terms; if accessible, integrate via a new src/services/cambridgeApi.ts modelled on src/services/standardsApi.ts
  • If a live API requires a partnership agreement, ship as static CEFR-mapped Cambridge descriptor data (aligned to the existing CEFR infrastructure)
  • Surface Cambridge exam labels (e.g., "B2 First") alongside CEFR levels in the grading and analytics views

Architecture impact: Medium — new service module; CEFR level mapping already exists.

Tier 9 — UX

19. Print CSS — Remaining Views

Status: Planned
Tier: UX
Effort: 1–2 days

EssaySlipSheet, RubricBuilder, and GradeStudent already have window.print() support. The following views still need it: StudentProfilePage, StatisticsPage, ComparativeGrading. There is also no centralized @media print stylesheet — rules are scattered per component.

What to build:

  • Centralized @media print rules in src/index.css: hide navigation, sidebar, action buttons; force white background
  • Add print buttons + view-specific print CSS to StudentProfilePage, StatisticsPage, ComparativeGrading

Architecture impact: Low — CSS additions only.

20. Student Portfolio View

Status: Planned
Tier: UX / Features
Effort: 3–4 days

All underlying data exists (grades, CEFR sessions, essays, feedback history) but is spread across separate pages. A portfolio view aggregates a student's full year into a single scrollable report — useful for parent-teacher conferences, student self-reflection, and end-of-year reporting.

What to build:

  • New route /students/:id/portfolio (or a tab on StudentProfilePage)
  • Chronological timeline: rubric grades → essays submitted → CEFR assessments → speaking sessions
  • Print/export to PDF from the portfolio view
  • No new data fetching; purely a UI aggregation of existing AppContext state

Architecture impact: Low — new page on existing data model.

Tier 10 — Compliance

21. Accessibility (WCAG 2.1 AA Audit + Priority Fixes)

Status: Planned
Tier: Compliance
Effort: 3–5 days

WCAG 2.1 AA compliance is required by EU law (EN 301 549) for software used in schools. The app is currently untested for accessibility. Key risk areas: icon-only buttons without aria labels, keyboard navigation in the grading interface, color contrast of CSS custom properties in light and dark mode.

What to build:

  • Run axe-core or Lighthouse accessibility audit; document the top 10 violations
  • Fix: add aria labels to all icon-only buttons (lucide-react icons)
  • Fix: ensure the rubric level selector in GradeStudent is keyboard-navigable (arrow keys, Enter)
  • Fix: verify color contrast ratios for --accent, --text, --bg-elevated in both themes
  • Add axe-core to the Vitest/Playwright suite so regressions are caught automatically

Architecture impact: Low — HTML attributes and CSS only.

Tier 11 — Integrations (Community Contribution)

22. Magister / SOMtoday Roster Import

Status: Planned (Community Contribution)
Tier: Integrations
Effort: 4–6 days per platform

Magister and SOMtoday are the dominant student information systems (SIS) in Dutch schools. Auto-importing class rosters would eliminate the largest manual onboarding step for NL teachers. Full integration documentation is in /docs/MAGISTER_INTEGRATION.md.

What to build:

  • src/services/magisterApi.ts — Magister REST + OAuth flow
  • src/services/somtodayApi.ts — SOMtoday OpenID Connect flow
  • OAuth token exchange must go through a Supabase edge function (client secret cannot be exposed in the SPA)
  • Student data model already exists; the import maps to existing types

Architecture impact: Medium — new service files; edge function for token exchange.
Note: This item is open for community contribution. Core team will review and merge a well-tested PR.

Clone this wiki locally