Home / Schedule / Mini Project 2: Interactive Web Tool

Mini Project 2: Interactive Web Tool

Released: Monday, 6/15. Proposal due: Sunday, 6/21. Final due: Friday, 6/26.

The Challenge

Build a JavaScript tool that runs entirely on GitHub Pages. It keeps track of some state and turns it into useful output: the user does something, your JavaScript updates the data behind the page, and the page recalculates and redraws itself. The point is logic and state, not a button that just changes a color.

This is a static, front-end-only project. Nothing runs on a server, and nothing has to stay secret. No calls out to the internet either; everything happens in the browser, from the user's own input. (Calling a real API and hiding an API key is MP3, where a static site no longer works and you move to a serverless platform like Vercel.)

Write the JavaScript yourself: vanilla JavaScript only, no frameworks or libraries (no React, Vue, or jQuery, and nothing loaded from a CDN). The point of MP2 is to write the logic so you understand it.

Start Here: Create Your Project Repo

Your first step, before any planning or code, is to create a new, separate public GitHub repo for this project. Do not put it inside your oim3690 repo or your username.github.io repo. Everything for this project lives here, and you will deploy it from this repo with GitHub Pages, so your live URL becomes username.github.io/repo-name. Name the repo in lowercase with hyphens, after what the tool does (for example, tip-calculator). Once it exists, link to it from your oim3690 repo README; once it is deployed, add the live URL there too.

Build Something Real

Build something you actually want to exist: a small tool that fixes a real annoyance in your week, or one you have wished existed. The strongest projects come from your own itch, not from a list. If it is for someone else, name a real person who would use it. A real user is the best way to get the size right: if nobody would open it twice, it is probably too thin.

Then aim for the right scope. The examples below are patterns to adapt to your own idea, not a menu to pick from. Three tiers:

Too small (do not stop here)

  • A bare to-do list: add, check, delete, and nothing else
  • A plain countdown or stopwatch
  • A one-formula calculator (tip, BMI) with a single input and a single output

These are warm-ups. We build things like this together in class. On their own they do not show enough logic for MP2.

Good MP2 scope (aim here)

  • A budget tracker that categorizes expenses and shows running totals and a breakdown
  • A Pomodoro timer that logs finished sessions and shows today's count or your streak
  • A flashcard app that tracks which cards you missed and reshuffles those to the front
  • A grade calculator with weighted categories that tells you the score you still need
  • A quiz that scores you, remembers the ones you got wrong, and lets you retry just those

Ambitious (if you want to push)

  • Any of the above, plus localStorage so the data survives a refresh
  • Multiple views, filtering or sorting, undo, export to the clipboard or a file
  • A small game with rules, scoring, and a win or lose state

The thing that separates "good" from "too small": your tool remembers something and works out a new answer from it, instead of only reacting to the last click.

Requirements (Base)

  • Semantic HTML structure
  • CSS styling that looks intentional (it does not need to be fancy)
  • State you hold in JavaScript (an array, an object, a running number) that more than one interaction reads or changes
  • Derived output: the page shows something computed from that state (a total, a count, a filtered list, a score), not just the raw input echoed back
  • At least 3 types of user interaction (for example: button click, form submit, keyboard input, dropdown, checkbox)
  • Dynamic DOM updates in response, not alert() boxes
  • A way to reset or start over without refreshing the page
  • Static and self-contained: no server, no external API, and no frameworks or libraries (vanilla JavaScript only, nothing loaded from a CDN). It must run on GitHub Pages as plain files.
  • Deployed on GitHub Pages

Extensions

Push further if you want:

  • localStorage to save data between sessions (tasks persist after closing the tab)
  • Keyboard shortcuts
  • Dark mode or a theme toggle
  • Animations or transitions on state changes
  • Export data (copy to clipboard, download as a file)
  • Multiple views or pages
  • Undo and redo
  • Mobile-optimized touch interactions

Iteration Plan

Milestone 0: Proposal and PRD (required)

Goal: Define what you are building, and who it is for, before writing code.

Commit a PROPOSAL.md with:

  • What I'm building: (one sentence)
  • Who it's for / why: name a real person or yourself; what problem does it solve?
  • The state it tracks: what data does the tool need to remember?
  • Core features: (3-5 things it will do)
  • What I don't know yet: which JavaScript concepts will you need to figure out?

Then turn it into a PRD. This step is required for MP2. Paste your proposal into AI: "Here is my project proposal. Act as a product manager. Interview me one question at a time to turn this into a detailed PRD." Answer the questions, then ask it to write the PRD.md. Read the whole thing and make sure it is what you actually want. When you build, point AI at it: "Read PRD.md and implement the first feature." This is the same harness you used for MP1.

Iteration 1: Structure and First Interaction

Goal: Build the HTML/CSS skeleton and get one interaction working.

Tasks:

  • Plan your state first. Write down the data your tool tracks before you write code.
  • Create the HTML layout for your tool
  • Add basic CSS styling
  • Write JavaScript for your first interaction (for example, a button that adds an item, a form that calculates something)
  • Get it deployed on GitHub Pages

Write about this in your weekly log: What HTML structure did you choose? What was your first piece of JavaScript? If AI generated it, what did you have to understand to make it work with your HTML?

Iteration 2: Core Functionality

Goal: Make the tool actually useful.

Tasks:

  • Add the remaining interactions (all 3+ types)
  • Handle user input properly (what happens with empty input? invalid data?)
  • Make the derived output update clearly every time the state changes
  • Test all the features by actually using the tool yourself

Write about this in your weekly log: What was the hardest interaction to implement? What JavaScript concepts did you use (variables, functions, arrays, conditionals, DOM methods)? What bugs did you find and fix?

Iteration 3: Polish and Test

Goal: Polish it enough that a classmate could use it without your help.

Tasks:

  • Improve the visual design (spacing, colors, feedback on user actions)
  • Add the reset/clear functionality
  • Test edge cases (rapid clicking, long text, empty state)
  • Get feedback from a classmate: can they use it without your help?
  • Fix what confused them

Write about this in your weekly log: What feedback did you get? What edge cases did you handle? What would you add with more time?

Submission

  • Create a new, separate public GitHub repo for this project (do NOT put it inside your oim3690 repo or your username.github.io repo)
  • Deploy on GitHub Pages (your live URL will be username.github.io/repo-name)
  • On Canvas, submit your repo URL. Then make the live site easy to find: on the repo page open About (the gear at the top right) and check "Use your GitHub Pages website" so your live link shows on the repo.
  • In your oim3690 repo README, link the project both ways: the repo (the code) and the live site (the running tool). They are two different things, and you should know which is which.
  • Include in the project repo:
    • PROPOSAL.md with all sections
    • PRD.md generated with AI
    • README.md with what the tool does, how to use it, the live link, and what you learned
  • Weekly log entries covering your project work

This project is reviewed as part of your checkpoints.

Tips

  • Plan your state first. Before writing code, ask: what data does my tool need to track? (items in a list, current score, timer value, etc.) Write those variables first.
  • Start with one interaction. Get one thing working end-to-end before adding more.
  • Use console.log liberally. When your logic doesn't work, log your variables to see what's happening.
  • Separate concerns. Keep logic in functions, DOM updates in separate functions. Don't put everything in one giant event listener.
  • When asking AI for help, be specific: "Write a function that adds a new to-do item to the DOM" is better than "Build me a to-do app."

Due Friday, 6/26

Last updated: Saturday, 6/13/2026