Status: under development. The calendar beta is tracked in issue #81. The design below distinguishes the initial beta from later attendance features; it should not be read as a list of already available capabilities.
Why a calendar?#
A Plan captures the courses a student intends to study, while teaching groups and their events give those courses actual times. A useful calendar brings those events together in a weekly view, making it easier to notice overlaps, inspect alternatives, and decide what to do next.
The first version should be valuable without asking students to resolve every conflict or maintain a detailed attendance model. Students should be able to open their active Plan, see its teaching events, navigate weeks, and hide irrelevant options.
Relationship to assemblies#
Assemblies are proposed configurations generated from selected LEGO blocks. They may include unavoidable conflicts and may eventually influence both active calendar courses and default study groups. Their generation and ranking are separate from calendar state.
The calendar is independently editable. Assembling or saving a candidate must not change it. A future Apply to calendar action should preview and reconcile changes against existing course activity, study-group preferences, and attendance overrides before user confirmation. This integration is not part of the initial read-only calendar beta.
An overlap can remain visible even after an assembly is applied. Hiding an event is not the same as choosing to attend another event. Weekly overrides and partial attendance belong to calendar intent, not to the assembly algorithm. Earlier documentation called some conflict choices Decision Slots; that is no longer a mandatory separate workflow.
Data and responsibility boundaries#
| Concern | Source or owner | Design rule |
|---|---|---|
| Active Plan membership | Authenticated user/Plan state | The beta projects course instances in the active Plan; future calendar-active course selection may be narrower after explicit application. |
| Teaching groups and occurrences | SISU data through sisu-wrapper | Preserve institutional times, identifiers, cancellation state, and notices; do not mutate upstream facts. |
| Calendar projection and layout | Frontend domain logic | Derive a locally queryable weekly view; week navigation should not require a backend round trip. |
| Display visibility | User/Plan-scoped preference | Hiding an item does not express attendance, registration, or group equivalence. |
| Recurring attendance and exceptions | Future user/Plan-scoped intent | Keep recurring preferences distinct from individual-week overrides. |
| Runtime persistence | Authenticated backend | Server is authoritative for saved preferences; failed writes must be visible and recoverable. |
Issue #89 established the need to preserve source event series IDs, expanded occurrence times, statuses, and location metadata. Individual occurrences may lack a stable upstream ID, so derived occurrence keys and their behavior under rescheduling need explicit handling in the projection and persisted preferences (#90).
A time-compatible alternative teaching group is not necessarily an academically equivalent or registration-eligible substitute. The interface must not imply that a student’s calendar selection changes official SISU registration.
Calendar beta: a useful weekly view#
The first milestone (#81) focuses on a practical calendar with minimal setup:
- Project active-Plan events. Build a deterministic representation of fixed-time occurrences, source references, and diagnostics for missing or changed upstream data (#90).
- Display a responsive week. Show event times, course and group information, location when available, and accessible details. Dense overlaps should remain legible rather than collapsing into narrow columns (#91).
- Control visibility. Show or hide groups and specific occurrences without changing source data or claiming an attendance decision (#92).
- Persist preferences. Save user/Plan-scoped visibility preferences; handle failed requests, stale references, sign-out, and account switching explicitly (#93).
- Present flexible exam windows. Distinguish a fixed exam from an availability period, which must not occupy every hour as if it were a booked sitting (#100).
- Test the actual journeys. Cover navigation, overlapping events, empty states, identity changes, and errors with deterministic Playwright fixtures (#94).
Start with a calendar that answers “What could I attend this week?” before asking users to answer “What exactly will I attend?” for every occurrence.
After beta: expressing attendance intent#
These features make the connection to Decision Slots stronger, but are post-beta, not prerequisites for rendering the calendar:
- Recurring group preferences (#101): what the student ordinarily intends to attend, independently of visibility and LEGO blocks.
- Weekly alternatives (#102): replace, add, or skip a particular occurrence without changing the recurring default.
- Interval-aware conflict decisions (#103): detect overlaps among selected attendance intervals, including cases with more than two simultaneous events. Unresolved conflicts stay visible.
- Partial attendance (#104): represent an intended portion of an occurrence without modifying the institutional event.
- Planned e-exam sitting (#105): let the student place an intended sitting inside an availability window, clearly marked as planned, not externally booked.
Attendance decisions remain scoped to occurrences or recurring preferences and never silently rewrite an assembly.
Constraints and open questions#
- Caching and offline use: Previously obtained teaching data should support local projection and navigation where available. This does not imply complete offline editing or synchronization; the backend remains authoritative for persisted user intentions.
- Temporal identity: Rescheduled or cancelled occurrences need stable-enough matching, diagnostics, and explicit stale-reference behavior rather than silently applying old choices to new times.
- Accessibility: Hover previews may improve exploration, but keyboard and touch users need equivalent controls.
- Conflict meaning: A visible overlap is not necessarily an intended-attendance conflict. Likewise, a flexible availability window is not a confirmed appointment.
- Usability: Validate the mental model with student scenarios before making advanced attendance controls part of the default experience (#106).
Related documentation#
- Assemblies — Candidate generation and explicit calendar application.
- Legacy Decision Slots — Earlier conflict-handling proposal.
- Plans — Course selection and the planning context.
- Study-event and Location Contract — Source event metadata and temporal semantics.
- Course Data Architecture — Published catalogue and on-demand SISU data boundaries.