Coding kit · Grades 9–12

Build a webpage with real game data

Students learn how HTML, CSS, JavaScript and APIs work together by retrieving real data from Wild Willows and using it to build their own interactive webpage.

Grades 9–12 60–120 minutes No installation No student accounts HTML · CSS · JS · APIs · JSON Real live API

You do not need to know JavaScript to teach this

Every chapter is worked through on the page itself, so nothing depends on you writing code at the board. Each example runs when a student presses Run, so a mistake shows up in the same minute they made it rather than at the end. The editor explains errors in plain English instead of showing a stack trace, and the troubleshooting table below covers what actually goes wrong in a room of thirty.

The honest version: you will be asked questions you cannot answer. “Let's find out” is a good answer, and looking it up together in front of them is the most accurate thing you can model about this job.

For students The Lesson Ten chapters, every sample editable and live. This is what you put on the projector and what they work through. For students The Code Builder Three files and a preview, for the build challenge and for anyone who finishes early.

What students can do by the end

The looping objective is the one that separates this from a typical intro lesson. Most stop at displaying a single value; chapter 8 is where students stop copying and start asking their own questions of the data.

Standards this supports

Every code below was checked against the published standard, and each row says which chapter actually does it.

Read this first if you are matching a district curriculum map. CSTA published a full revision in July 2026, and it renumbered everything: the 3A and 3B levels are gone, replaced by a single HS band for grades 9–12. Most curriculum maps in use today still cite the 2017 codes, so both are below — 2026 first, with its 2017 predecessor beside it. CSTA publishes an official crosswalk between the two.

CSTA 2026 — the codes this lesson meets

High school band, grades 9–12. “Was” gives the closest 2017 code, per CSTA’s crosswalk.

CodeWasWhat it asks forWhere the lesson does it
HS‑PRO‑PD‑13 3B‑AP‑16 Use documentation, libraries and APIs as part of building a program. Chapters 4 and 5, and the closest thing here to a bullseye — the standard names APIs outright. Chapter 4 makes a real request over your school’s own network and reports its status, timing and size; chapter 5 is fetch(). The field reference is the documentation half.
HS‑PRO‑VD‑16 3A‑AP‑14 Write a program that uses appropriate data structures to store, reach and manipulate data. Chapters 6 and 8. Chapter 6 is reading values out of nested objects and arrays by path; chapter 8 is .filter(), .map() and .sort() over about 150 animal records, with .reduce() marked as a stretch.
HS‑PRO‑RD‑17 — new in 2026 Analyze how a piece of code works, including what its parameters, return values and data structures are doing. The debugging material, which had no home in the 2017 standards at all. The broken version with three planted bugs is a reading-and-diagnosis exercise, not a writing one; the editor’s error panel names the line and explains the problem in English; and chapter 1 opens on how to read code you did not write.
HS‑ALG‑PS‑02 3A‑AP‑15, ‑17, ‑18 Refine an algorithm’s design using control structures and procedural abstraction. Chapters 7 and 8. if / else, comparisons, truthiness and the empty-state guard; then chaining methods together in chapter 8 and asking which order is readable. Three separate 2017 codes collapse into this one.
HS‑PRO‑PD‑12 3B‑AP‑14 Build a modular program, using procedures, external libraries or objects so it can be reused and read. Chapter 10, in the Code Builder. Three files — index.html, styles.css, main.js — is the separation of concerns argument made concrete, and students have to keep all three consistent for anything to render.
HS‑PRO‑TR‑20 3A‑AP‑21, ‑19 Refine what you built based on testing, user feedback and responsible design values. The Run loop, all lesson. Nothing runs until a student says so, and the error panel turns a failure into the next edit inside the same minute. The Creative band of the assessment below asks for a page that communicates something rather than only displaying it, which is where the design values land.

The 2017 code with no 2026 successor

If your curriculum map is still on the 2017 standards, this one is worth claiming, because it is the best single match in that version for the part of the lesson that most reliably works — and CSTA dropped it.

CodeWhat it asks forWhere the lesson does it
3A‑CS‑03 Write down systematic troubleshooting strategies that other people can use to find and fix errors. The whole debugging spine: the error panel, the three planted bugs, and the troubleshooting table on this page. CSTA retired the standalone Troubleshooting sub-concept in 2026 and mapped this code to nothing; under the new standards the nearest home is HS‑PRO‑RD‑17 above.

What this lesson does not cover

Codes that look like they should fit and do not. Listed because a mapping is only useful if it can be trusted where it does claim something.

Standards text. The descriptions above are written for this page in plain language — they are not CSTA’s official wording. CSTA does not publish per-code links, so read the full text in the 2026 standards viewer or the 2017 interactive browser. Citations: Computer Science Teachers Association. (2026). 2026 CSTA PK–12 Computer Science Standards. And: Computer Science Teachers Association (2017). CSTA K–12 Computer Science Standards, Revised 2017. Both are published under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license.

Vocabulary

One line each. Copy this onto the board, or print the page.

HTMLStructure. What is on the page.
CSSAppearance. What it looks like.
JavaScriptBehavior. What it does.
APIA way for programs to communicate.
EndpointA specific address where an API provides something.
RequestAsking an API for something.
ResponseWhat the API sends back.
JSONA structured text format commonly used to send data.
fetch()The JavaScript function that makes a web request.
StringText. Always in quotes.
NumberA value you can do arithmetic with. No quotes.
Booleantrue or false.
ArrayAn ordered list of things.
ObjectA thing with named parts.
null / undefinedNothing on purpose / nothing found.
ConditionA question with a yes-or-no answer.
if / elseDo one thing when a condition is true, another when it is not.
===Asks whether two things are exactly the same. One = sets, three === ask.
LoopDoing something once for each item in a list.
.map()Make a new list by changing each item.
.filter()Make a shorter list by keeping only some items.

Before the Lesson

  1. Work through the student lesson once yourself. Half an hour, and it is the single best preparation. You will find the two or three places your class will slow down.
  2. Check the network can reach wildwillows.app. Do this a week ahead, not the morning of. A filtered domain is the most common way this lesson fails, it looks like broken code to a student, and it needs an IT ticket rather than a fix you can make in the room.
  3. Optional: show five minutes of the game. Students who have seen the meadow understand what biome: "meadow" means, and the data stops being abstract.
  4. Pick a flow. Three are below. Sixty to a hundred and twenty minutes means different things in different schools.

There is nothing to install, no software to request, no accounts to create in advance, and no class codes to hand out.

Three ways to run it

One period, 60 minutes

10 minWhat is a webpage? Show a page and ask what controls the words, the colors, and what happens on click. Let them guess before naming HTML, CSS and JavaScript.
10 minWhat is an API? Get to the real endpoint fast. Then press the button in chapter 4 on the projector and show the actual response.
30 minGuided coding, chapters 1 to 9, trimmed. See what to cut below.
10 minBuild challenge in the Code Builder. A taster rather than a project.

Two periods

Day 1Chapters 1 to 6: the three languages, the DOM, what an API is, fetching it, and reading values out of the response. Finish in the Code Builder with challenges 1 and 2.
Day 2Chapters 7 to 10: decisions, looping, rendering to the page, and their own build.

Three periods

Day 1The web stack. Chapters 1 to 3, ending with JavaScript changing the page.
Day 2The API and its data. Chapters 4 to 6: the request, the response, the types in it, and reaching into them.
Day 3Decisions, looping, rendering and build. Chapters 7 to 10.

What to cut when time is short

You can make this call mid-lesson. The three things that carry chapter 9, which is where the payoff is, are if / else, .map() and .filter(). Keep those.

Keep
  • if / else, chapter 7
  • .filter() and .map(), chapter 8
  • Chapter 9, putting the data on the page
  • The empty-state guard, chapter 7. Without it a filter that matches nothing renders a blank page and every student assumes they broke it.

Those are marked as optional in the student page's own interface too, so skipping them does not read to a student as falling behind.

Two openers that work

What is a webpage?

Put any page on the projector. Ask three questions and let them guess before you name anything: what decides the words, what decides the colors, and what happens when I click this. You will get to structure, appearance and behavior on your own, in their words, which is a better start than three definitions.

What is an API?

Do not define it first. Open chapter 4 on the projector and press See the real API response. The page reports the status, the time and the size of the request it just made over your school’s own network, then shows the data that came back. Ask what they think happened before you name any of it.

The definition afterwards fits in a line: one program asked another program, on a different computer, for something, and got it back as text. The rest of the lesson is reading that text.

Assessment

Deliberately not quiz-heavy. Three bands you can grade as completion, as points, or as a project.

Understanding
  • Can explain what HTML, CSS and JavaScript each do
  • Can explain what an API is, and what a request and a response are
Technical
  • Successfully retrieves the API data
  • Displays at least one value from it on the page
  • Uses if / else to handle a case the data might not cover
  • Modifies HTML, CSS and JavaScript
Creative
  • Builds a page that communicates something about the Wild Willows data, rather than only displaying it

Grade the understanding column hardest. A student who used the worked example and can explain what the code does has learned more than one who wrote messier code unaided and cannot.

Troubleshooting

Six things that actually go wrong, and what to do about each. None of them needs you to read the student's code.

What they seeWhat it meansWhat to do
“Failed to fetch” The network blocked the request. This is the big one. Open wildwillows.app/GameData in a tab. If that fails too, it is the school filter and it needs IT. Nothing in the code will fix it.
The preview is blank Usually an error before anything was drawn. Look at the panel under the editor. It names the line and explains the problem. If the panel is empty, the code has not run yet: press Run.
“is not defined” A name that does not exist. Almost always a typo or a capital letter. Compare the spelling in the two places it appears. animal and Animal are different names.
“Cannot read properties of null” querySelector found nothing, so there is nothing to change. Check the id in the HTML matches the one in the JavaScript, including the #.
Yesterday's work is gone Different machine, guest mode, or the browser cleared its storage. Work saves in that browser, not to an account. Have them press Download at the end of each period; that file reopens with Open.
The preview will not update The code has an error, or it is still waiting on the debounce. Press Run. If it still does not change, read the error panel: a page that will not update is nearly always a page that threw.

Answer key

The finished chapter 10 challenge, all three files. Open it in the Code Builder to run it, or read it here.

index.html
<h1 id="title">Meadow Apex Predators</h1>
<ul id="animal-list"></ul>
styles.css
body { font-family: system-ui, sans-serif; padding: 1rem; color: #3b4232; }
h1   { color: #6b3fa0; }
li   { margin-bottom: .3rem; }
main.js
async function loadGameData() {
  const response = await fetch("https://wildwillows.app/GameData");
  const data = await response.json();

  const matches = data.animals
    .filter(animal => animal.trophic === "apex-predator")
    .sort((a, b) => a.name.localeCompare(b.name));

  const list = document.querySelector("#animal-list");

  if (matches.length === 0) {
    list.innerHTML = "<li>No animals matched.</li>";
  } else {
    list.innerHTML = matches.map(animal => `<li>${animal.name}</li>`).join("");
  }
}

loadGameData();

Seventeen apex predators, alphabetical. Challenge 5 in chapter 10 is exactly this, and the count is how a student checks their own answer.

A broken version, for a warm-up or a substitute

Three planted bugs. Give students the file and ask them to find them using the error panel. It is a good sub-plan and a better test of understanding than writing it from scratch.

async function loadGameData() {
  const response = fetch("https://wildwillows.app/GameData");   // bug 1
  const data = await response.json();

  const matches = data.animal                                     // bug 2
    .filter(animal => animal.trophic === "apex-predator");

  document.querySelector("#animals-list").innerHTML =             // bug 3
    matches.map(animal => `<li>${animal.name}</li>`).join("");
}

loadGameData();
The three bugs

1. A missing await before fetch. response.json is not a function on a Promise, and that is what the panel will say.

2. data.animal should be data.animals. The panel reports that you cannot call .filter on undefined.

3. The selector says #animals-list and the HTML says animal-list. The panel reports that the element is not on the page.

What this collects

Anonymous counts and nothing else: which chapters were reached, which errors the editor explained, roughly how long a session in the builder ran, and whether the network let the data through. No accounts, no cookies used for tracking, no third-party analytics.

Student code never leaves the browser. It is saved in that browser's own storage so it is still there next period, and it is sent nowhere: not when they run it, not when it produces an error, and not in the usage counts. The only way their work leaves the machine is if they press Download.

Because nothing identifies a student, a class or a school, there is no student record to request, correct or delete. The privacy policy has a section addressed to schools and districts.

This describes this kit — the lesson, the builder and the API docs. The game is a separate program and reports more than these pages do, including the caretaker name typed on the save; if you also run the science kit, its own section covers that.

Ready to teach it?

Open the lesson on the projector and work through chapter 1 with the class. If you run it and something confuses students or runs long, tell me — that is the kind of thing these pages get rewritten for.