Four study tools, one library.

Notes that outlive the app.

Study tools tend to keep your material inside an account and hand it back only as a proprietary export. Switch tools, or lose access, and a semester of typed-out cards has to be rebuilt from scratch. The material is the valuable part; the app around it is not.

So the constraint came first: every deck, quiz, and set of notes is a plain .txt file committed to the repository. It opens in any text editor, diffs cleanly, and is versioned for free. The programs are readers for those files rather than owners of them.

One format, four readers.

Every study file opens with the same four-line header — title, description, class, and semester — followed by a body whose line prefixes say which program the file is for:

• Q: and A: pairs make a flashcard deck
• Q: with lettered options, an asterisk on the correct one, and an Explain: line makes a quiz
• S: sections with N: notes beneath them make a fieldnote

The files are self-describing, and that is the design decision the rest follows from. The library reads each file's own header for its title, course, and term, and counts the body lines for its item count — so there is no separate index of metadata to keep in sync, and adding a file is a one-step operation.

The library lists its storage folder through the GitHub Contents API, with a committed manifest as a fallback when the API is unavailable; a GitHub Action regenerates that manifest whenever a file is pushed. Everything else runs in the browser — no backend, no accounts — and review progress lives in localStorage.

The four programs.

• Library — browses every study file in the repository, filtered by kind, subject, catalog, semester, and item count
• Flashcards — deck review that tracks hits and repetitions per card and shows each card's strength as a colour run
• Quiz — multiple choice with a per-question explanation and a scored verdict at the end
• Fieldnotes — sectioned reference notes for reading straight through before a session, exportable as Markdown

All four are built on the site's design system, so a program looks like the rest of the site rather than like an embedded app — the same palette, the same three typefaces, the same hairline borders. They also share a structural template: the same corner navigation in the same position, a settings page with export and import, and destructive actions kept behind a menu.

The motion budget is deliberately different here. The editorial pages of this site use a slow scroll reveal; the programs use none, because they are opened repeatedly to get something done and an entrance animation is only a delay.

In use, and what's missing.

The suite is in regular use for coursework, with files written for BIOENG 1071, BIOSC 1820, BIOSC 1250, and BIOSC 0350. Writing a deck now means writing a text file and committing it, which is fast enough that the notes actually get made.

What it doesn't do yet: there is no spaced repetition. Flashcards record hits and repetitions but nothing schedules the next review, so the data is there and the scheduling layer is not. Progress is per-browser, since localStorage doesn't sync between machines. And the library's file listing depends on an unauthenticated API rate limit, which is exactly why the manifest fallback exists.

Next: a scheduler built over the existing hit and repetition data, and progress export so a review history can move between devices.

Acknowledgments.

Design & development — Ty Zhang
Hosting — GitHub Pages
Live — huhudada.com/programs