Hunt #1: X-Ray Vision — Chat Log
How a movie clip, a metaphor, and 9 stops became TNT’s first scavenger hunt. The design conversation from concept to deliverable.
This is a design log, not an app log. It documents the conversation between TTG (the teacher) and Copilot about how to build Hunt #1 — the reasoning behind each stop, the problems that were caught before the hunt went live, and the decisions that shaped the final version.
Reading a design log teaches you something an app log cannot: that the most important work happens before a line of code is written. The questions “Why this? Why not that? What could go wrong?” are the curriculum.
I thought of a hunt involving the movie clip about x-ray vision and entry #030 in askCopilot. My list of suggested stops:
- Starting with TNT index: find the Man of Steel clip page
- On movie_clips: find a heading about imagination — Google it (Einstein)
- Use the search bar — find the Clark Kent tile
- Find the URL of manOfSteelXray.html
- Clark's complaint to his mom
- Her response
- Follow hyperlinks on that page to find my x-ray vision
- In Entry #030 — ways to 'see behind the scenes'
- Back on movie_clips — what tag is the heading about intelligence? Does it have an id?
This is a strong concept for Hunt #1. The thematic spine — x-ray vision metaphor → XRAY framework → students actually using x-ray vision — is the best possible hook for an orientation. Four things need addressing before building.
The heading on movie_clips.html reads "Intelligence: Imagination > Knowledge" — a TNT paraphrase, not the exact Einstein quote. Googling the heading text exactly may produce mixed results. Students without search experience may get frustrated.
Fix: Provide the search term explicitly: "imagination more important than knowledge quote". The concept still works; the scaffolding removes the friction.
The original phrasing gave students the filename (manOfSteelXray.html) then asked for the URL. If you already have the filename, finding the URL is trivial.
Fix: Don't give the filename. Make the tile discovery (Clark Kent search) the navigation event, and Stop 4 asks students to read the URL from the address bar after navigating there. The address bar observation is itself a useful habit.
"Are there ways described to see behind the scenes?" is essentially asking for a summary. Open-ended comprehension questions are hard to grade and hard for first-week students to answer.
Fix: Make it specific: "What is the four-letter acronym for the web detective framework, and what does each letter stand for?" This requires reading the entry carefully without being vague.
"What tag is used for the heading?" requires right-click → Inspect or Ctrl+U View Source. First-week novices don't know either of these exist.
Fix: Include explicit step-by-step instructions: (1) Right-click the heading, (2) choose Inspect, (3) look at the highlighted line. This is exactly the right moment to introduce DevTools for the first time — it's motivated by the x-ray vision metaphor and immediately rewarding.
Yes, we need to assume that novices have no prior CS training or experience with TNT or DevTools. I see this first hunt as an orientation. Let's use the right-click. Also, within that folder, I will want a chatlog that shows our teamwork / collaboration on this project.
Two options for first DevTools contact: Ctrl+U (View Source — opens entire file as text) or right-click → Inspect (opens DevTools anchored to the specific element).
Right-click Inspect wins here for two reasons: (1) it delivers targeted information — the exact element the student is looking at, highlighted — rather than a wall of raw text they must search; (2) it directly enacts the x-ray vision metaphor. The student right-clicks the heading, and DevTools reveals the skeleton beneath it. That sequence is what Clark Kent learns to do in the supply closet: focus on one thing at a time. Ctrl+U would flood the student with the entire source — exactly the overwhelm Martha's framework is designed to prevent.
The original concept asked only for the tag and the id. The full highlighted DevTools line is:
<h2 id="movieGridHeading" class="section-title glow-heading">
The class attribute is worth asking about: section-title and glow-heading are the CSS rules that make the heading look the way it does. Asking for the class names plants a seed: these names connect the HTML element to the stylesheet. That's the A layer of XRAY — Appearance rules. The question doesn't explain this yet; it just puts the vocabulary in students' hands for when it comes up in the next hunt.
The original concept was implicitly one difficulty level. The three-tier structure was applied:
- Bronze (1–6): Pure reading and navigation. No technical tools. Anyone can complete this with patience and a working internet connection.
- Silver (7–8): Following hyperlinks across pages and reading complex analytical content. Requires focus and willingness to engage with a long entry.
- Gold (9): First actual DevTools use. Step-by-step scaffolded. Designed to be achievable with the instructions provided, even with zero prior experience.
The plan document suggested index.html as the first hunt target. This hunt uses index.html as a starting point but then moves through four pages. This is actually better for an orientation hunt:
- Students learn the site's navbar architecture as a side effect of navigating
- Students learn that URLs map to file system paths (Stop 4)
- Students learn that pages cross-link to each other (Stop 7)
- The x-ray vision metaphor motivates all four of these naturally — they're not learning "web structure," they're following Clark Kent's trail
Every stop in this hunt connects to the same idea: x-ray vision. Students find the clip (meet the metaphor), watch Clark get overwhelmed (understand the problem), read about the XRAY framework (learn the solution), and finally right-click Inspect (use the solution). A hunt without a thematic spine is a random collection of questions. A hunt with one is a story. Stories are memorable. Questions are not.
Stop 9 provides step-by-step instructions for right-click → Inspect. The instructions are explicit because the tool is unfamiliar, not because the concept is hard. The answer to "what tag is this?" is one glance once DevTools is open. The barrier isn't the knowledge; it's the activation. Scaffolding the tool removes the barrier without removing the learning. Future hunts can shorten the scaffolding as students become familiar with the panel.
Stop 4 originally gave students the filename before asking for the URL. Self-answering questions don't test knowledge — they test copying. The fix (remove the filename, ask for what the address bar says after navigation) took five seconds to implement but changed the stop from trivial to genuinely observational. Every question on a hunt should require something from the student that isn't already in the question itself.
Post-Launch Catalog Page Styling
The cards featuring the Hunts have the same background color as the page. I think a subtle difference could be good: not a stark white but something that makes the page less bland. What do you recommend?
The problem is .hunt-card uses var(--adv-parchment) (#f8f4ec) — the same value as the body background. Recommendation: #fdf9f2 — a warm ivory that sits noticeably lighter on the luminance scale without going cold or stark. It stays in the same warm-cream family so it reads as intentional rather than accidental, and it gives the cards enough lift to read as contained elements against the page.
The catalog page background and the .hunt-card background were both #f8f4ec (parchment). Cards need enough visual separation from the page to read as distinct contained elements; without it the layout looks flat.
| Option | Value | Why not? |
|---|---|---|
| Stark white | #ffffff | Too cold; breaks the warm parchment palette |
| Same as page | #f8f4ec | Cards disappear; original problem |
| Warm ivory | #fdf9f2 | — chosen: lighter, warmer, stays in the cream family |
Change applied in adventures.css — one value, propagates to all current and future hunt cards automatically.
Post-Launch 2 Open Key Button & The Themed Login Question
I got the keys to work! What if we had a subtle button to ‘Open Key’ on the worksheet that linked to a generic page where we can put in our credentials to see the key? Seems like a convenient option. We could build a thematic page that is nicer than the ugly login I saw earlier. Is this sound?
The button is a great idea. The themed login page hits a hard technical wall.
The browser login dialog you saw is HTTP Basic Authentication — it is rendered entirely by the browser, not by the web server or any HTML on the page. There is no CSS you can write, no page you can serve, no JavaScript you can run that changes what that dialog looks like. The browser owns it. That is by design: a login dialog that the page itself could style would be a phishing vector. Knowing this saves you from building something for hours and wondering why it never changes.
Built: a subtle “Open Answer Key” button at the bottom of the worksheet, below a “Teacher Reference” label. It links directly to the key URL. Clicking it on the live server triggers the browser’s Basic Auth dialog, credentials are entered once per browser session, and the key opens. The button is hidden on print (print-hide class) so it never appears on student copies.
Not built: a custom login page. This would require switching from HTTP Basic Auth (.htaccess) to form-based auth (a PHP login form, session management, CSRF tokens, session expiry). That is a significant engineering change that adds complexity without meaningful benefit for a single-teacher use case. The browser dialog is ugly but it works, it is secure, and the browser caches the credentials for the session so you only see it once per visit.
Future option: if TNT ever needs multiple teachers with different access levels, or a student-facing quiz that reveals partial answers on submission, form-based PHP auth becomes worth the complexity. Until then, Basic Auth + a direct URL bookmark is the right tool.
The browser login dialog is a browser chrome element — it lives outside the web page, the same way your browser’s address bar and tabs do. Web pages run in a sandbox; they cannot reach outside that sandbox to modify native browser UI. This is one of the oldest security boundaries in the web platform.
The AuthName directive in .htaccess controls the one piece of text that appears inside the dialog — the realm name (“TNT Adventures — Teacher Access Only”). That is the extent of customization available. Everything else — layout, colors, fonts, logo, button labels — is locked.