Teacher Dashboard

The classroom problem

Every teaching day starts with the same two questions: what’s on for each class today, and exactly what needs to be printed before the bell rings. A hosted dashboard answers those questions fine — right up until the school’s wifi drops, or the login session expires, or the network the whole building depends on has a bad morning. None of that is hypothetical in a school building; it’s Tuesday. A tool that can’t answer “what’s scheduled today” without a network connection isn’t a convenience feature away from being reliable, it’s built on the wrong foundation.

There’s a second problem underneath the first: how many copies to print isn’t the same question for every class. A worksheet that goes out one per student needs a different count for a 24-student section than an 18-student one, and a handout meant for the whole room once needs neither. Getting that number right by hand every morning, for every class, every day, is exactly the kind of small repeated arithmetic a computer should be doing and a teacher shouldn’t have to.

The design decision

Offline-first is the design decision, not a constraint bolted on afterward. A working version of this tool already exists — built as a Python script that generates one self-contained HTML file, opened directly from disk, no server, no login, no network call of any kind. This portfolio project is the second half of that decision: a public, data-free engine that generates the same kind of dashboard for anyone, without ever seeing a single real class, student, or school.

That’s the strongest engineering signal in this project, so it’s worth naming directly: the configurator that generates the dashboard holds no data at all. No account, no server-side storage, no analytics — a teacher’s actual schedule, class names, and links exist only in their browser’s memory while they fill in the form, and then in the file they download. There was no other way to build a shareable version of a tool built on one real teacher’s real roster without either exposing that data or building something that no longer resembles the real tool. Making the generator itself data-free was the only design that let both exist.

How it works

The engine is a single form: classes and the days they meet, a list of units with dates, links, and what needs printing, and a set of shortcut links to the tools a teacher actually uses daily. Filling it in and clicking generate produces one .html file — inline styles, inline script, the teacher’s config baked in as a small embedded data block. That file is the dashboard from then on: opened from disk, every school morning, wifi or no wifi.

Two details make it usable past the first day rather than just a one-time generator. The teacher can export their filled-in config as JSON and re-import it later to keep editing — a semester’s worth of units doesn’t have to be re-entered from scratch. And a button copies a ready-to-paste prompt, built live from the config’s own schema, so a teacher can hand their in-progress unit list to their own AI assistant, ask it to draft the rest, and paste the JSON straight back in. The engine never calls an AI itself — that would mean a network call, and network calls are exactly what this tool exists to not need.

What I’d do next

The real, privately-run version of this dashboard already tracks something adjacent to the next real problem: which assignments have been posted to Google Classroom and which have made it into the gradebook of record, shown as a simple queue with each item’s status. That’s a hand-checked snapshot today, not a live pipeline — and the natural next step is making it one, with a fetch → stage → approve → push shape: pull new Classroom activity, stage it for review, require a human approval before anything writes back to a grade of record, then push. The interesting part of that roadmap isn’t the automation, it’s the approval gate — a grading system has no undo, so the design question is entirely about where a human has to look before something becomes permanent. That’s designed, in the sense that the real tool’s current manual snapshot step already stands in for it; none of the automated version exists yet, and it shouldn’t be described as more built than that.