One unfinished task
A fictional student needs a three-step plan for a short work block. The app helps divide time; it does not promise better grades or personalized tutoring.
Topic 8 · Web Basics and App Design
Use it. Explain it.
Then design your own.
Start with a working web app. Learn what the browser does, connect a prompt to visible behavior, and turn one small idea into a design another person can check.
01 · Use and explainTuesday 10/27 · after the team talks
02 · Design and critiqueNext design studio · date to be confirmed
03 · Build and testTopic 9 · using your design evidence
This is the proposed class route. It keeps the separate 12-screen fundamentals lesson and the original 20-screen, two-meeting design lesson available.
Use this guide to choose the next block. Linked lesson screens open in a separate tab. Return here between blocks. The original deck’s Next button and displayed timings still follow its full two-meeting sequence; they do not follow this selected route.
Paper, a typed outline, and the course mockup support the same design questions. A live build, video, AI account, paid tool, or model upgrade is not required. This guide creates no extra submission.
From team talks to web fundamentals.
The talks finish Topic 6. Then use all 12 fundamentals screens in order. The goal is to explain how a web app works before asking Claude Code to change one.
- 0–2121 minutes
Three team talks
Each team has 5 minutes to present and 2 minutes for questions: 3 × (5 + 2) = 21 minutes.
- 21–243 minutes
Transition and settle
Open the fundamentals lesson, make the controls readable, and get ready to inspect the Study Sprint example.
- 24–6844 minutes
Complete Web Application Fundamentals
Use the example, predict and check its result, compare two controlled changes, and explain what you would ask Claude Code to change. Start at Screen 1 and follow the lesson’s own Next button through Screen 12.
- 68–8012 minutes
Protected buffer
Use this time for access needs, questions, unfinished reflection, or a slower demonstration. There is no new required task in this block.
Make the first version specific.
Carry forward the same user, input, rule, and result. Work in the existing App Design Packet, on paper, or in an equivalent typed outline. Keep your route and evidence together.
- 0–88 minutes
Choose a seed and cut the scope
Use the complete Study Sprint seed below, or your own equally small seed. No Topic 7 artifact is a prerequisite. Name one user, one task, one primary action, and one feature you will leave out.
Keep: your scope sentence, authorized input, boundary, and removed feature.
- 8–2012 minutes
Map the parts and sketch three states
Recall HTML, CSS, JavaScript, and the browser. Sketch or label the initial screen, missing-input screen, and result screen. In both wireframe rounds, specify a next action and preserve valid choices when something is missing.
Keep: a four-part responsibility map and labeled states, including error recovery.
- 20–266 minutes
Decide whether the app needs AI
For Study Sprint, a transparent rule is enough: 2 minutes to prepare, the chosen duration minus 5 to work, and 3 to reflect. Write the exact mapping and the human check. Claude Code may help author the app; that does not mean the finished app needs a model call.
Keep: the AI-fit decision, exact rule, and what a person must verify.
- 26–348 minutes
Build the contract from a worked example
A contract tells a builder what the page must do and tells a reviewer what to check. Start with the same Study Sprint app. Suggest one part’s answer, reveal its worked example, and point to the matching control, state, or test. Pause after parts 3 and 6 before continuing.
- User + task
- Authorized input
- Primary action
- Exact rule
- Visible result
- Error + recovery
- Access needs
- Boundary
- Three success tests
Parts 1–3 name the task; 4–6 explain the behavior; 7–9 set access, boundaries, and checks. After the example, adapt one part to your seed before drafting the rest.
- 34–4410 minutes
Repair a prompt in two rounds
With a partner, replace one vague adjective with an observable behavior. Then add missing-input recovery, keyboard access, and the valid choice that must remain. Working alone? Write both the reviewer’s finding and the designer’s repair.
- 44–5410 minutes
Adapt the example and write three tests
Use the worked contract as a model for your chosen seed. Draft parts 1–3, then 4–6, then 7–9; point to the same wireframe throughout. State each test’s input, action, and exact expected result before running or walking through it. Paper or a typed state walkthrough is sufficient.
For Study Sprint, test a normal 25-minute result, recovery from blank/space-only input without losing the chosen duration, and a 45-minute result after revision. Use the exact values in the seed below.
- 54–628 minutes
Critique, defend, and revise
Ask a reviewer to locate the user task, primary action, states, boundary, and tests without guessing. Record one specific finding, its consequence, and your revision. A solo review uses the same questions.
- 62–686 minutes
Check the packet and prepare the handoff
Use the packet check below. Include the build-flow transfer note and route/assistance disclosure. Mark any unfinished field; a complete packet is not promised by the end of class.
- 68–8012 minutes
Protected buffer
Continue unfinished evidence, ask a question, or use an accessible alternative. No additional required activity is scheduled here.
Finish allowance stays the same. The packet’s existing workload guide allows 35–50 focused minutes to finish after in-class drafting. Keep that allowance for unfinished work. The LMS supplies the exact submission deadline and policies; this proposed route does not change them.
Study Sprint: six decisions already on the table.
A fictional student wants to plan one focused work block. Use this seed directly, or replace it with your own one-screen idea that supplies the same six decisions.
A fictional task and a duration
Use a task such as Review chapter notes and choose 15, 25, or 45 minutes. The primary action is Build my plan.
Three steps with an exact rule
2 prepare + (duration − 5) work + 3 reflect
Show the task, chosen duration, three labeled steps, and a way to revise or start over. For 25 minutes, the result is 2 / 20 / 3; for 45, it is 2 / 40 / 3.
One screen, no private records
No accounts, backend, API keys, model calls, or real personal/student data. No calendar integration or public deployment is required. The draft is a design, not a production service.
Inspect the result and recovery
Check that the steps sum to the selected duration. Try blank and spaces-only task input: show a specific message, return attention to the task field, create no plan, and preserve the selected duration. Correct the task and try again.
Can someone use the three states?
Can a reviewer find what to enter, what to press, where the result appears, and how to recover? Use the wireframe or a paper walkthrough to find one unclear label or missing action.
Keep the design and its checks together.
What the packet preserves
- One user/task, authorized input, a removed feature, and the boundary.
- HTML/CSS/JavaScript/browser responsibilities and initial, missing-input, and result states.
- A labeled wireframe or text outline, recovery action, AI-fit decision, exact rule, and human check.
- The nine-part contract, one critique finding and revision, and three tests with exact expected results.
Transfer and disclosure still matter
Course-summary transfer route: specify before building → inspect behavior against the contract → revise the smallest difference and retest. Explain what you can decide before a build and what requires observing behavior.
Disclosure: name the route/source/tool, the decision it affected, an accepted/rejected/revised suggestion, your checks, a remaining limitation, and the final human decision.
Use the existing maximum-four-page packet or its accepted equivalent. Paper/text, the course mockup, and an instructor-approved optional client-only probe can provide the same evidence and earn the same credit. No code or video is required. Submit through the LMS before Topic 9, following its exact deadline and format instructions.
Topic 9 handoff: input → click/event → transparent rule → visible result → missing-input behavior → three manual tests.
See a real edit before your first build. Topic 9 opens with a teacher-led Claude Code edit and browser check: add a 30-minute choice, inspect the changed source, and test for 2 / 25 / 3 while preserving existing choices and missing-input recovery. Predict and record what is actually observed. If the live edit cannot finish, the teacher identifies the prepared reference as a fallback. This stays outside the 10/27 fundamentals session and adds no Topic 8 submission or student account requirement.
Full lessons and reference material.
- Web Application FundamentalsSeparate 12-screen lesson · 44 minutes · use and explain the working example.
- Original design lessonAll 20 screens and the full two-meeting sequence remain available. Its Next button follows that original sequence.
- App Design PacketThe existing submission, evidence requirements, accepted alternatives, and finish allowance.
- Topic 8 hubTopic resources and the course’s assignment information.