pulse

/projects/ulbra-student-dashboard

← All projects

Student Dashboard

A screen on a wall that tells students where to be.

Head of Technology — design & implementation · Apr 2026 – Current

.NET 10React 19PostgreSQLMicrosoft FabricODBCDocker Swarm
Private

Overview

A schedule display installed in the university’s first building, the medical school, where it shows students the day’s classes. One system with two faces: an unattended fullscreen kiosk, and a sign-in-protected admin where staff manage the content it rotates. Academic data comes from the university’s analytics lakehouse.

What I did

I built it end to end — the API, the lakehouse integration, both front ends and the deployment.

  • The lakehouse connection that supplies the schedule.
  • The kiosk display, its rotation and its day/night themes.
  • The content admin and its scheduled playlist.
  • Deployment onto the internal cluster.

The problem

Students arriving at the building had no way to see the day’s schedule without looking it up on a phone, and the university had no way to put anything in front of them at the moment they walked in. A printed sheet answers the first problem badly and the second not at all.

What it does

  • A fullscreen kiosk sized for the physical panel it runs on, not for a browser window.
  • Rotates between schedule pages and campus content on a fixed cadence.
  • Switches between a day and a night theme by the clock, so it is readable in both.
  • Staff schedule content with start and end dates; it appears and expires on its own.

Engineering decisions

  • Polling, not a live connection

    The display asks the server for fresh data on a short interval rather than holding a socket open. A socket is the better answer when a human is watching and latency matters; this is a screen on a wall with nobody in front of it. Polling recovers from a dropped network by itself, and nobody has to walk to the building to restart it.

  • The analytics lakehouse as the source

    The schedule is read from the university’s analytics platform rather than from the academic system directly. It is the copy that is already shaped for reading, already has access controls the display can be granted narrowly, and — crucially — cannot be affected by a screen in a lobby querying it all day.

  • One system, two audiences

    The kiosk has no login and no interaction; the admin has both. Splitting them into two deployments was the obvious move and was rejected: they share the content model entirely, and two services would mean two places to change when the shape of a slide changes. The boundary is a route and an auth check, not a process.