Landing Page
Canvas is the source of truth for this term’s assignments. This page may already show changes Canvas does not have yet.
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.
What You Produce
Section titled “What You Produce”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.
Required Content
Section titled “Required Content”Whatever the format, the page carries these four parts:
- 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.
- 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.
- 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.
- Credits and contact: all current team members, past contributors on multi-year projects, and a feedback channel (issues, email, or a form).
What You Submit
Section titled “What You Submit”A public URL plus a full-page screenshot (the screenshot is the graded snapshot; the URL proves it’s live).
Rubric
Section titled “Rubric”| Criterion | Ratings |
|---|---|
| Value proposition30 points | |
| Highlights and access3 to 5 audience-perspective highlights, at least one real visual of the project in action, and a working call to action35 points | |
| Credits and contacteveryone credited, past contributors acknowledged where applicable, feedback channel present15 points | |
| Accessibility and nothing broken20 points |
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.
Activities That Prepare This
Section titled “Activities That Prepare This”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.