Skip to content

Project

Your Final Project for CS 343 is to collaborate with your teammates to build a Dynamic Application Prototype (DAP 👊).

Project Overview

Teams of students will create a useful frontend web application that:

  • Is Vanilla

    Is written in vanilla HTML/CSS/JS, doesn’t use any frameworks like React/Svelte/Vue.

    You are permitted to use existing client-side libraries (Ex: Chart.js, Grid.js).

  • Is deployed Publicly

    Does not require any packages to be installed locally.

  • Has Responsive Design

    Looks good on both desktop and mobile.

  • Meets A11y Guidelines

    Passes audit for WCAG 2.1 AA.

  • Manages User Data

    Lets users create, read, update, and delete (CRUD) their own data.

  • Persists Data

    Uses localStorage for data persistence.

  • Looks Polished

    Has a consistent, custom visual design across every page.

  • Integrates with a “3P” API

    Better Together…

    Your app will make requests to existing third-party (“3P”) services on the web to provide functionality that might not be possible in a client-side-only app.

    A collective list of free APIs

Milestones

Milestone What Due
Teams Form a team of 3 and tell your instructor Thu Oct 22
Pitch & Sketch Pitch your idea in class; submit an annotated design sketch Tue Oct 27 (in class)
Basic Claims Demonstrate all 10 Basic claims (a working, minimal app) Nov 2 – Fri Dec 11
Advanced Claims Demonstrate Intermediate and Stretch claims for a higher grade Once B1–B9 are approved, until Fri Dec 11
Requirements Final code freeze; whole-app requirements are checked Mon Dec 14, 11:59 PM
Presentation 10–12 minute team presentation Final exam time

Pitch & Sketch

In this short, one-week milestone, your team will come up with an idea, choose a third-party API, and design the layout of your application. You will pitch the idea to your instructor in class and turn in an annotated design sketch.

See the Pitch & Sketch page for details.

Basic Claims

You will build a minimal (but complete!) working application. Your team must demonstrate all ten Basic claims by Fri Dec 11. Nine of them use skills you already have (HTML, CSS layout, JavaScript, forms, and localStorage); the tenth (B10) is your third-party API, which you can claim once we’ve covered fetch().

Advanced Claims

As soon as Basic claims B1–B9 are approved, you may demonstrate Advanced claims (Intermediate and Stretch) to raise your grade. You can (and should) start building these features earlier. You choose which ones (and how many) based on your app and the grade you want.

Presentation

During your section’s Final Exam Time, your team will give a 10–12 minute presentation of your finished project.

See the Presentation page for details.

Grading

The project uses specifications grading. Nothing is graded on a sliding scale: each item is either met or not yet.

Bundles

Your grade is the highest column in which you meet every row. Each column supersedes the one to its left, meaning you cannot earn a higher grade without meeting all the requirements of the lower columns.

D C B A A+ (100%)
Basic claims all 10 all 10 all 10 all 10 all 10
Pitch & Sketch — complete complete complete complete
Presentation — you present 3 of 5 criteria 4 of 5 criteria 4 of 5 criteria
Advanced credits — — 4 intermediate 8 total 12 total

Advanced credits: each Intermediate claim is worth 1 credit and each Stretch claim is worth 2 credits. Stretch credits count only after you have at least 4 Intermediate claims.

For example, an A could be 4 Intermediate + 2 Stretch claims, or 8 Intermediate claims. An A+ takes 4 more credits on top of that (Ex: 2 more Stretch claims or 4 more Intermediate claims).

Every row, no exceptions

To earn a grade, you must meet every row in that column. Missing even one row means you do not earn that grade—you get the next column down where you meet every row.

For example, a team with 12 credits and a complete Pitch & Sketch, but only 3 of 5 presentation criteria, earns a B (not an A or A+).

Your project grade is recorded as a percentage, which counts toward your course grade using the syllabus scale (90 and above is an A, 80 is a B, 70 is a C, and 60 is a D):

Bundle A+ A B C D F
Project grade (%) 100 90 80 70 60 0

Making Claims (and Limits)

Claims are demonstrated in person during class times or scheduled office hours.

Limits apply:

  • Each week, each team may demonstrate at most 5 Basic claims and at most 3 Intermediate/Stretch claims (none in the first week, since B1–B9 can’t all be approved by then).
  • Basic claims can be made any time from Nov 2 until Fri Dec 11.
  • Intermediate/Stretch claims can be made as soon as Basic claims B1–B9 are approved, until Fri Dec 11.
    • Thus, to get an A or higher, you must plan your claims carefully: aim to have B1–B9 approved by Fri Nov 13, so you can use every week for Intermediate/Stretch claims.
  • To get an A+ (100%), you will need to max out on claims virtually every week.

See the Claims page for more details and a week-by-week breakdown.

Penalties

Penalties are not part of the bundles; they are deducted from your project grade afterward.

  • Unmet requirements: each requirement your final app does not meet deducts 5% (Ex: an A bundle with one unmet requirement is recorded as 85%).
  • Late Pitch & Sketch: a late Pitch & Sketch still counts as complete (so you can still earn a C or higher), but it deducts 5%.
  • No late Intermediate/Stretch claims are accepted; they must be demonstrated before the final deadline.

AI Use and Code Ownership

Using AI is optional. No team is required to use it, but you are expected to try it and learn AI skills. If you do use AI tools, use them only as a pair programmer, to assist with writing pieces of code, but not as a replacement for implementing entire features. This course is about learning the fundamentals of client-side web development yourself; AI-centric software development is a different course. Practice the habits from the AI Time callouts in the labs and preps. See AI Tools for our recommended setup (GitHub Copilot with free student access).

Good uses of AI

  • Explaining an error message, a concept, or unfamiliar code
  • Suggesting why your code isn’t working
  • Answering “how do I…” questions about a specific, small task
  • Reviewing code you wrote and suggesting improvements
  • Generating sample/test data

Not acceptable

  • “Vibe coding” a feature, page, or large piece of the app from a prompt
  • Pasting in code that nobody on the team understands
  • Letting AI make design and architecture decisions for you
  • Using AI to write your explanations of your own code

You Must Own Your Code

Every feature and every line of code in your project must be owned by your team. When you make a claim, the team member who led it may be asked to:

  • explain your team’s approach and why you chose it,
  • walk through the code in a code review, or
  • teach someone else how to build the same feature.

If your team cannot do this, the claim is rejected, and you may not demonstrate it again until the following week. (The rejected demo also counts toward that week’s claim limit.)

Don’t waste your instructor’s time

Egregious or repeated ownership failures will be treated as evidence that AI is being used irresponsibly. In that case, your instructor may limit your team’s claims; for example, by lowering your weekly limit or requiring a full code review before any further claims are accepted.

Teams

Teams consist of 3 students (with one team ±1 depending on class size). After forming your team, you should:

  1. Make your team known to your professor by the means they have indicated (e.g. in Canvas, or otherwise).
  2. Do all your work for all parts of this project in the repository the professor specifies (e.g. one your instructor created for you).
  3. Agree on how you will communicate (group chat, etc.) and when you will meet each week.

“I did all the work on my own private repository”, or “I don’t know how to use Git” (you’ll learn it) are not valid excuses and will result in your team not receiving credit for the work.

What if I want to work individually?

Part of the learning objective of this course is to work effectively in a team. You may not work individually on this project unless discussed and approved by your instructor (and you better have a very good reason). If you are granted permission to work individually, you will still be expected to complete all the requirements as a three-person team would.

Individual Grades and Peer Evaluation

By default, every team member receives the team’s grade. At the end of the project, each student will privately evaluate their teammates’ contributions. If there is a significant imbalance in workload, individual grades may be adjusted up or down from the team grade.

A (non-graded) peer evaluation check-in will also happen in mid-November, so that problems can be addressed early. If you are concerned about your team’s dynamics at any point, talk to your instructor sooner rather than later. Failure to do so may result in your entire team struggling or receiving a lower grade.

Every member should lead claims

Divide the work by feature, not by file (e.g., not “one person does all the CSS”). The team member who led a claim may be asked to explain the code for any claim.

Acknowledgements

Section Contents