Skip to content

Landing Page

Canvas is the source of truth for this term’s assignments. This page may already show changes Canvas does not have yet.

TeamSpring3% of the spring grade

  • Landing PageSunday of week 7Rubric

One page per team, not per student.

Up to 48 hours late loses one rubric band on each criterion. After that it scores zero, unless you contacted the instructors before the deadline with a documented reason.

Your project needs a front door: the page a recruiter, a future user, or your project partner’s boss lands on and understands in thirty seconds what this is and why it matters. Building one gives every team member a link that belongs on a resume and in the Career and Individual Retrospective.

This is a team submission. One page, built together, crediting everyone. Individual portfolio pages are encouraged but are not this assignment.

Pick the format that fits your project:

  • A dedicated landing or product page (GitHub Pages, Vercel, Netlify, itch.io)
  • A polished repository README with structure, visuals, and a user-facing description
  • When what you produced is a result: a results page, preprint link, or published paper page, or a repository README that someone who didn’t build it can actually run. That means what the work shows, a figure or result table, and a worked example with the exact commands and the output to expect. For a result, the README usually is the front door, because the people who find your work arrive at the repository, and a README nobody can run is the research equivalent of a demo that crashes. Make Your Artifact Reproducible is the activity that gets you there.

Talk to your partner first: they may have an existing page to update rather than replace. Multi-year projects credit past contributors and may build on a previous team’s page.

AI use: AI may write copy and code for the page. Every claim about features, capabilities, and results must be accurate; a landing page that oversells what exists is graded as inaccurate, not ambitious.

Whatever the format, the page carries these four parts:

  1. Description and value proposition: one sentence saying what it is and who it is for; the problem it solves and why that matters; the “so what” that makes it notable. Written for the audience, not the grader.
  2. Highlights: 3 to 5 features, findings, or capabilities from the audience’s perspective, with at least one real screenshot, figure, or demo clip showing the project in action.
  3. How to try it: a clear call to action (Download, Play, Try it, View on GitHub, Read the paper) with brief prerequisites or platform notes.
  4. Credits and contact: all current team members, past contributors on multi-year projects, and a feedback channel (issues, email, or a form).

A public URL plus a full-page screenshot (the screenshot is the graded snapshot; the URL proves it’s live).

Rubric: 100 points across 4 criteria
CriterionRatings
Value proposition30 pointsOutcomes: SO3
  • Exceeds Expectations (30)One sentence says what the project is and for whom, the problem is stated in the user's terms, and no course vocabulary (capstone, team, partner, sprint, rubric) appears on the page.
  • Meets Expectations (24)A visitor can tell what the project is and who it is for, but no one sentence says both, the problem is stated in the team's terms rather than the user's, or course vocabulary appears on the page.
  • Does Not Meet Expectations (6)A visitor cannot tell what the project is or who it is for.
Highlights and access3 to 5 audience-perspective highlights, at least one real visual of the project in action, and a working call to action35 pointsOutcomes: SO2
  • Exceeds Expectations (35)Three to five highlights written from the audience's perspective, at least one real visual of the project actually running, and a call to action that says what it does and works.
  • Meets Expectations (28)Highlights are present but list features rather than what each does from the audience's perspective, the visual is a mockup or placeholder, or the call to action does not say what it does (Download, Play, Try it, View on GitHub, Read the paper).
  • Does Not Meet Expectations (7)No highlights, no visual of the project at all, or no way to access it.
Credits and contacteveryone credited, past contributors acknowledged where applicable, feedback channel present15 pointsOutcomes: SO4
  • Exceeds Expectations (15)Every team member credited, past contributors acknowledged where applicable, and a working feedback or contact channel.
  • Meets Expectations (12)Credits present but incomplete, or a contact channel is named without being usable.
  • Does Not Meet Expectations (3)Credits or contact missing.
Accessibility and nothing broken20 pointsOutcomes: SO3
  • Exceeds Expectations (20)No placeholder text; alt text on every meaningful image, 4.5:1 contrast on body text, descriptive link text (not "click here"), and no broken link, image, or embed.
  • Meets Expectations (16)No placeholder text, and the page fails one of these checks: alt text on every meaningful image, 4.5:1 contrast on body text, descriptive link text, no broken link, image, or embed.
  • Does Not Meet Expectations (4)Placeholder text (lorem ipsum, an empty section), or the page fails two or more of the checks in Meets.

For the accessibility and nothing broken criterion, the standard being graded is WCAG 2.2 level AA: text alternatives on meaningful images, 4.5:1 contrast on body text, and link text whose purpose is clear from the link and its surrounding text. Run Lighthouse or axe first, then do a manual pass, because automation covers only part of it: the accessibility guide has the coverage figures and the manual checks, and no tool will tell you that your alt text describes the wrong thing.

Designing for Accessibility for the accessibility-and-nothing-broken criterion, which is 20 of the 100 points here, and The Mom Test for the value proposition. Wire an Accessibility Audit Into CI automates the mechanical half of the accessibility check.

Browse Interaction Design and Accessibility and Working with Users when these run out.