Skip to content

Claims & Requirements

This project uses a claims system (a form of specifications grading). Each claim is a feature that your team demonstrates in person; it is marked approved or not yet. Approved claims count toward your grade bundle.

In addition, your final application must meet a set of Requirements that apply to the whole application. Requirements are not claims: they are checked once, at the end, and each unmet requirement is a penalty.

Summary

Type Worth When Needed for
Basic required Mon Nov 2 – Fri Dec 11 all 10 for any passing grade
Intermediate 1 credit each Once basic done, until Fri Dec 11 B: 4; A: 8; A+: 12 credits
Stretch 2 credits each (after 4 Intermediate) Once basic done, until Fri Dec 11 B: 4; A: 8; A+: 12 credits
Requirements −5% each if unmet Code freeze, Mon Dec 14, 11:59 PM —

The rules:

  1. Weekly claim limits: 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). Every demo counts toward the limit, whether or not the claim is approved. Unused claims do not carry over to the next week.
  2. Basic claims can be made any time from Mon Nov 2 until Fri Dec 11. You need all ten for any passing grade.
  3. Basic claims first: You can start making Intermediate and Stretch claims as soon as B1–B9 are approved. The API claim (B10) is the one exception: make it whenever it’s ready (we’ll cover fetch() in class later). You may (and should!) work on Advanced features earlier—you just can’t claim them yet.
  4. Credits: Each Intermediate claim is worth 1 credit; each Stretch claim is worth 2 credits. Stretch credits count only once your team has at least 4 approved Intermediate claims.
  5. Claims only count once: You can only earn credit for a claim the first time it is approved. Additionally, going past 12 credits does not raise your grade further.
  6. Claims close when final exams begin. The last day for claims is Fri Dec 11. No claims can be made during Thanksgiving break or final exam week—during finals, you demo your finished app in your presentation.

You Cannot Save It All for the End

Week of Basic Intermediate/Stretch
Nov 02 up to 5 none (B1–B9 take at least 2 weeks)
Nov 09 up to 5 up to 3, once B1–B9 are approved
Nov 16 up to 5 up to 3, once B1–B9 are approved
Nov 23 Thanksgiving break Thanksgiving break
Nov 30 up to 5 up to 3, once B1–B9 are approved
Dec 07 up to 5 up to 3; last claims Fri Dec 11
Dec 14 Final exams: present and demo your app Final exams: present and demo your app

Plan ahead

The 10 Basic claims need at least two weeks of claims, and every week you wait to finish B1–B9 costs you 3 Intermediate/Stretch slots. Teams that finish B1–B9 by Fri Nov 13 have 9 Intermediate/Stretch slots; teams that wait until December have at most 6.

Making Claims

Claims are demonstrated in person, either during in-class work sessions or in office hours. Make a claim when the feature is fully implemented, tested, committed, and deployed.

To make a claim:

  1. Add the claim to the Claims table in your README.md, with the name of the team member(s) who led it, before you demo it.
  2. Demonstrate the feature using your deployed application (not localhost).
  3. Be ready to show and explain the code. Your instructor may ask the lead team member(s) to explain your approach, walk through the code, or explain how they would teach someone else to build it. If your team can’t, the claim is rejected and cannot be demonstrated again until the following week. See AI Use and Code Ownership.

If a claim is not approved, you’ll get feedback on what’s missing. Fix it and try again! A retry counts toward that week’s limit, so test thoroughly before you demo.

Pace yourselves

An A (90%) requires 8 credits: for example, 4 Intermediate + 2 Stretch claims (6 claims), or 8 Intermediate claims.

One way to get there:

  • Weeks of Nov 2 and Nov 9: Basic claims B1–B9, while you start building Intermediate/Stretch features.
  • Weeks of Nov 16, Nov 30, and Dec 7: 2 Intermediate/Stretch claims each (leaving room for retries), plus B10 once your API works.

An A+ (100%) requires 12 credits: for example, 4 Intermediate + 4 Stretch claims (8 claims).

That is meant for the top teams: it requires finishing B1–B9 early and claiming in all three weeks, with almost no failed demos.

Basic Claims

These claims represent a minimum viable application. All ten are needed for any passing grade; B1–B9 are needed before Intermediate/Stretch claims.

The CRUD claims (B4–B7) refer to your app’s user data: the information the user creates and manages (Ex: recipes, trips, workouts).

  • B1. Views & Navigation

    • The app has at least 3 distinct pages/views with different purposes, including a home/landing view.
    • A navigation menu appears on every view, and all of its links work.

  • B2. App Layout

    • Pages use CSS Grid and/or Flexbox to arrange content like a modern web app (Ex: a header with navigation, content in cards, columns, or panels)—not just one long column of default HTML.
    • The layout adapts for a mobile-sized screen (Ex: using media queries).

  • B3. Visual Styling

    • The app has a custom look: a color palette, fonts, and spacing that are not browser defaults.
    • Buttons, form fields, and other UI elements are styled consistently, and the app resembles your design sketch.
    • It doesn’t need to be a work of art, but it should look like a real app.

  • B4. Create

    • The user can add a new item to their data using a form with labeled inputs.
    • The new item appears on the page immediately.

  • B5. Read

    • The user’s data is displayed in a list, table, or cards that are generated by JavaScript from the data.
    • When there is no data yet, a helpful “empty” message is shown instead of a blank area.

  • B6. Update

    • The user can edit an existing item, and the change appears on the page immediately.

  • B7. Delete

    • The user can remove an existing item, and it disappears from the page immediately.

  • B8. Persistence

    • All user data is saved in localStorage and restored when the page is reloaded or the browser is reopened.
    • Creating, updating, and deleting items (B4, B6, B7) all persist.

  • B9. Form Validation

    • Invalid input is prevented, with a specific, visible error message next to the field that explains how to fix it.
    • Uses HTML validation attributes and/or the Constraint Validation API, not just alert().

  • B10. Third-Party API

    • The app uses fetch() to request data from a third-party API, based on the user’s input (Ex: a search term, a selected category, a saved city).
    • The results are displayed on the page (by creating/updating DOM elements) without a full page reload.
    • The API is credited in the app (Ex: in the footer or an About view).
    • This claim does not need to be approved before you start Intermediate/Stretch claims.

Advanced Claims

Intermediate and Stretch claims (together, “Advanced” claims) can be made as soon as B1–B9 are approved, until Fri Dec 11. They let you extend your application in the directions that fit it best. Intermediate claims are worth 1 credit and Stretch claims are worth 2 credits; Stretch credits count only once you have at least 4 approved Intermediate claims.

You do not need to complete all of these, just enough to earn the credits you want.

Intermediate Claims (1 credit each)

  • I1. Export & Import

    • The user can click a button to download all of their data as a JSON file.
    • The user can choose a previously exported file, and the app replaces (or merges) its data with the file’s contents. The imported data is displayed and persists after reload.

  • I2. Loading & Error States

    • A visible loading indicator appears while API requests are in progress.
    • When a request fails (Ex: go offline in DevTools) or returns no results, a helpful message is shown instead of a broken page.

  • I3. Search, Filter & Sort

    • The user can narrow down and reorder their data (Ex: search box or category filter, plus a sort by date/name/rating).

  • I4. Alternate Layouts

    • The user can toggle between 2+ distinct layouts for the same data (Ex: list vs. grid vs. compact) without reloading.

  • I5. Pagination

    • Large data sets (user data or API results) are shown in pages, or with a “load more” button.

  • I6. Persistent Preferences

    • The user can change at least two settings (Ex: light/dark theme, units, default view) that are saved in localStorage and restored on reload.

  • I7. Dashboard / Summary

    • A view shows information computed from the user’s data (Ex: totals, averages, counts per category, upcoming items).

  • I8. Second API

    • The app fetches and displays data from a second, different third-party API (not just another endpoint of the first).

  • I9. Auto-Refreshing Data

    • Some displayed data updates automatically on a timer or event, without user action (Ex: a clock, countdown, or live feed).

  • I10. Transitions & Animation

    • CSS transitions or animations give meaningful feedback (Ex: items sliding in/out, expanding panels)—more than just a hover color change.
    • Motion is reduced or removed when the user has enabled prefers-reduced-motion.

  • I11. Image/File Input

    • The user can choose a file from their device (Ex: a photo) and the app previews or reads it. (Importing exported data for I1 does not count.)

  • I12. Keyboard Shortcuts

    • At least three key combinations trigger app functions, and the shortcuts are listed somewhere in the app.

  • I13. Help & Tips

    • The app includes a help view or contextual tips (Ex: tooltips, “?” buttons) that explain how to use its main features.

  • I14. Print Styles

    • Printing a view (Ex: a list or a single item) produces a clean layout with no navigation, buttons, or wasted space.

  • I15. Browser APIs

    • The app meaningfully uses a browser API not covered elsewhere (Ex: Clipboard, Notifications, Web Share, Speech), including handling the case where the user denies permission.
    • (Geolocation does not count here; it is claimed as S8.)

  • I16. Modules & Classes

    • JavaScript is organized into at least three ES modules (import/export), and the user data is modeled with at least one class.

  • I17. Shareable URLs

    • Part of the app’s state (Ex: the current search, filter, or selected item) is stored in the URL’s query string or hash.
    • Copying the URL into a new tab restores the same state.

  • I18. Interactive States

    • All interactive elements (buttons, links, form fields, clickable cards) have custom styles for :hover, :focus-visible, :active, and :disabled (where applicable), consistent across the whole app.
    • The focus style is clearly visible on every background, and states don’t rely on color alone (Ex: also an outline, underline, or shadow).

Stretch Claims (2 credits each)

Stretch credits count only after your team has at least 4 approved Intermediate claims.

  • S1. Data Visualization

    • The app displays the user’s data or API data as a chart, graph, or map (canvas, SVG, or a library like Chart.js) that updates when the data changes.

  • S2. Drag and Drop

    • The user can drag items to reorder or move them (Ex: between lists), and the new order/location persists.

  • S3. Single-Page App Routing

    • The app is a single-page application: all views are rendered by JavaScript from one HTML page, and each view has its own URL (Ex: #/recipes/42).
    • The browser’s back/forward buttons work, and pasting a URL into a new tab opens the same view.
    • (A team that earns S3 cannot also earn I17 for the same URLs.)

  • S4. Installable PWA

    • The app has a web app manifest and a service worker, can be installed, and still loads (with its saved data) while offline.

  • S5. Internationalization

    • The user can switch between 2+ languages, and all interface text changes accordingly.

  • S6. Accessible Custom Component

    • Build an interactive component yourself (Ex: tabs, a pop-up dialog, an accordion, or an autocomplete dropdown) that works for keyboard and screen reader users.
    • It follows the W3C pattern for that component: the right ARIA roles/states and the expected keyboard controls (Ex: arrow keys switch tabs, Escape closes a dialog).
    • Status messages (Ex: “Item deleted”) are announced to screen reader users using an ARIA live region.

  • S7. Touch Gestures

    • Swipe, long-press, or pinch gestures trigger specific actions on a touch device (Ex: swipe to delete), with an equivalent non-gesture way to do the same thing.

  • S8. Geolocation

    • The app uses the user’s location (with permission) to change what it shows (Ex: nearby results, local weather, distance to saved places).
    • The app still works, with a sensible fallback, if the user denies permission.
    • (A team that earns S8 cannot also count Geolocation as the Browser API for I15.)

  • S9. Guided Tour

    • A first-time user is walked step by step through the main features with an overlay that highlights each part of the interface.
    • The tour can be skipped, is remembered once finished, and can be replayed later.

  • S10. Image Upload & Gallery

    • The user can attach images from their device to their items, see previews, and view them in a gallery.
    • The images are still there after a reload. (I11 does not also count for the same feature.)

  • S11. Canvas Graphics

    • The app uses the HTML5 <canvas> element for interactive graphics that respond to the user (Ex: drawing, image editing, a game, an animated visualization).
    • Charts drawn by a library do not count here (see S1).

  • S12. IndexedDB or OPFS Storage

    • The app stores user data (Ex: large records or files such as images) in IndexedDB or the Origin Private File System instead of only localStorage, and restores it after a reload.

  • S13. Your Own Idea

    • A feature that is genuinely novel for your app and not covered by other claims.
    • You must get written approval from your instructor (with an agreed-upon description, as either an Intermediate or a Stretch claim) before Thanksgiving break.
    Ideas
    • Immersive & 3D: WebXR augmented/virtual reality (Ex: with A-Frame), or interactive 3D graphics (Ex: with Three.js).
    • Camera, audio & AI: scanning barcodes/QR codes with the camera, sound or music with the Web Audio API, or on-device machine learning (Ex: TensorFlow.js) to classify images or suggest tags—no API key required.
    • Engineering challenges: reusable Web Components (custom HTML elements), Web Workers for heavy processing, or generating real files (Ex: PDF reports, .ics calendar events).

Requirements

Requirements apply to the whole application at the end of the project, so they are not claims. They are checked on your deployed app at the code freeze (Mon Dec 14, 11:59 PM). Each requirement that is not met deducts 5% from your project grade.

Don’t wait until the end! Your instructor will do a requirements check-in (feedback only, no deduction) in mid-November, so you know where you stand.

  • R1. Vanilla

    • No frontend frameworks (Ex: React, Vue, Svelte, Angular). Client-side libraries (Ex: Chart.js) are allowed if loaded from a CDN or included in the repo, and credited in the README.

  • R2. Deployed

    • The final version of the app works at a public URL (Ex: GitHub Pages), without anything installed locally.
    • The deployed version matches the code-freeze commit.

  • R3. No Console Errors

    • Using the app’s features does not produce errors in the DevTools console (and no leftover debugging output).

  • R4. Consistent Design

    • All views share the same header/navigation/footer structure and a cohesive custom style (colors, fonts, spacing), not browser defaults.

  • R5. Valid, Semantic HTML

    • Every page passes the W3C HTML validator with no errors.
    • Pages use semantic elements (header, nav, main, footer, etc.) rather than generic divs where appropriate.

  • R6. Responsive

    • Every view is usable from 320px to 1440px wide, with no horizontal scrolling, and the layout adapts (Ex: the navigation and content rearrange on small screens).

  • R7. Accessible

    • Every view has zero errors and zero contrast errors in WAVE.
    • Everything can be done with the keyboard alone, with a visible focus indicator.

  • R8. README

    • README.md describes the app, links to the deployed URL, lists the team members, credits the API(s), libraries, and media used, and includes the Claims table (claim, team member who led it, date approved).