Skip to content

Roadmap

Jump to bottom
Wouter Meetsma edited this page Jun 3, 2026 · 48 revisions

RubricMaker — Feature Roadmap

Items 1–14, 16, and 19 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: Complete (PR #104)
Tier: Testing & Quality

Magic-link sign-in via the admin generate_link API (no email/inbucket required), cloud persistence, offline-queue-and-flush, and pending-queue checks are all covered in a dedicated supabase Playwright project (e2e/specs/14-supabase-sync.spec.ts).

What was built:

  • e2e/fixtures/supabase.fixture.ts — creates a fresh test user + school per test, signs in via magic link, tears down after
  • npm run e2e:supabase — runs the Supabase suite (--project=supabase --workers=1) against a local stack
  • CI job E2E — Supabase Integration runs after the standard offline suite; spins up supabase start, exports credentials, uploads separate artifacts
  • Five test scenarios: magic-link auth, cloud persistence after localStorage wipe, deletion sync, offline-queue flush on reconnect, queue empty while online

What to keep building (see CLAUDE.md):

  • Shared rubric flow — teacher A shares, teacher B sees it (not yet covered)
  • Grading-while-offline → sync on reconnect
  • Student portal sign-in via share code
  • Broader coverage of the reconnect-hydration path and multi-device data merging

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: Complete
Tier: Reach & Localisation

All five locale files (en, nl, fr, de, es) are fully in sync at 852 keys each. Spanish is registered in src/i18n.ts and exposed in the Settings language selector. CLAUDE.md documents that all five files must be updated together.

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. The API key field exists in Admin → Integrations and src/services/cambridgeApi.ts contains a working lookupWord() implementation, but the service is not yet imported or called by any feature.

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: Complete
Tier: UX

Print buttons added to StudentProfilePage, StatisticsPage, and ComparativeGrading. Centralized @media print block in src/index.css hides nav, sidebar, and interactive controls; forces white background; handles view-specific classes (.statistics-controls, .comparative-actions).

23. Full Themes — Font Families + Named Color Presets

Status: Planned
Tier: UX / Personalisation
Effort: 2–3 days

The app UI is visually tied to a single accent color and the Inter font. Full theme support lets schools and individual teachers express their identity and makes the app more accessible for neurodiverse students who prefer certain typefaces.

Phase 1 (in progress): Foundation already shipped:

  • AppSettings.uiFontFamily field + AppContext applies it as --font CSS variable with dynamic Google Fonts loading
  • 8 named accent-color preset swatches in Settings → General (Ocean, Forest, Indigo, Sunset, Rose, Slate, Teal, Gold)
  • UI font picker in Settings → General (Inter, Nunito, Source Sans 3, Lato, Roboto)

Phase 2 (planned): Full theme bundles:

  • Define 4–6 named themes (e.g. "Academy", "Nature", "Midnight", "Warm") — each theme sets accentColor, uiFontFamily, defaultFormat.fontFamily, defaultFormat.headerColor
  • Add a colorPreset?: string field to AppSettings to track the active preset name
  • Implement tonal accent-color scales (50–900 steps via color-mix() or LCH interpolation) so --accent-50 through --accent-900 are available for richer component styling in charts and rubric exports
  • Export font library for rubric DOCX/PDF: include decorative options: Playfair Display (elegant serif headings), Oswald (condensed bold), Bebas Neue (display caps), Special Elite (distressed typewriter), Courier Prime (clean terminal)
  • Rubric title "ASCII / terminal art" styling: monospace fonts + optional border decorations around rubric headings in DOCX export

What to build:

  • Theme definition file: src/data/themes.ts — array of { id, label, accent, font, headerColor, exportFont } objects
  • Theme picker in Settings → General (visual card swatches with preview)
  • Update src/context/AppContext.tsx to apply theme bundles atomically (single updateSettings call)
  • Extend src/utils/docxExport.ts and src/utils/pdfExport.ts to read settings.defaultFormat.fontFamily for decorative heading fonts
  • CSS custom properties audit: ensure --accent-{50..900} scale is wired consistently to charts, badges, and rubric cell highlights

Architecture impact: Low-medium — theme data file + Settings UI + CSS variable additions. No data model migration needed.

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