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.
Post-Launch 3 Student Profile in the Back-Bar & Print Header
In the adventuresHome and sHuntHome, we show the novice their login information. I believe that should be on each scavenger hunt page too. What is your recommendation for inclusion here? Also, we should allow for the anomaly where a novice might have navigated to the page without the login info.
Two placements were considered. The bottom student-bar (used on adventureHome.html) is visible at the end of the page, below all content. On a nine-stop worksheet that means the student’s “logged in as” confirmation is off-screen throughout the entire session. The back-bar at the top (used on sHuntHome.html) is always visible above the hero when the page loads.
The back-bar wins here for three reasons: (1) it is visible immediately without scrolling; (2) it already carries the navigation links (← Scavenger Hunts, Adventures Home), so the profile slot joins existing chrome rather than adding a new UI element; (3) the worksheet is read-only in terms of profile management — students edit their profile on adventureHome.html, not on a task page.
The print-only student header had blank lines for Name and Period/Class. Adding id attributes to those spans lets the profile script write the student’s saved data into the print view. The Date field is deliberately left blank — it is correct at print time, not at load time.
A student who sets up their profile at adventureHome.html gets a worksheet that already has their name on it when they print. The teacher receives correctly-identified work without the student hand-writing their name twice.
A student can navigate directly to the hunt URL without visiting adventureHome.html first. The tntAdventureProfile key may not exist. This is not an error state; the hunt is fully functional either way. The graceful degradation:
- Profile exists → back-bar right side shows name and period; print header is pre-filled.
- No profile → back-bar right side shows a soft amber “→ Set up your profile first” link pointing to
adventureHome.html; print header retains blank lines for manual entry. No modal, no block, no friction — a nudge, not a gate.
| File | What Changed |
|---|---|
sh-xray-2026-08-01.html | Back-bar added (← Scavenger Hunts • Adventures Home • profile display); .back-bar CSS added and excluded from print media query; print header Name and Period spans given IDs; profile IIFE added at bottom |
sh-xray-2026-08-01-chatlog.html | Post-Launch 3 documented |
Post-Launch 4 Print Button & Answer Summary Modal
Why not augment the post-hunt instructions with a ‘Print’ button as well as a feature (I envision a modal) where a press of a button condenses the novice’s response to their Name, Period and Date, the name of the hunt, and just the questions and their answers — that can be copied and pasted elsewhere. This way they can have a full record or just the summary (easier for the teacher to collect and grade). What name do you suggest for that consolidation button?
Five candidates evaluated:
| Candidate | Why not chosen |
|---|---|
| Copy My Answers | Imperative — implies one specific action; doesn’t describe what the student receives. |
| Summary Sheet | Suggests a static document; this is dynamically built from live inputs. |
| Quick Submit | Assumes a submission destination. The button prepares text; the student chooses where it goes. |
| Export Answers | “Export” is technical vocabulary that novices may not recognize as an everyday action. |
| Answer Summary | — chosen. Noun phrase: describes the output, not the action. Submission-method neutral — works for Google Forms, email, LMS, or any other tool. |
Alternative: a button that silently copies to the clipboard without showing anything. The modal wins for three reasons:
- Students see exactly what they’re sending before they send it. Unanswered questions appear as
(no answer), making gaps obvious. - Teachers can calibrate expectations: “your summary should show nine stops with answers.” The preview makes that checkable before submission.
- The textarea is editable before copying, allowing minor corrections without redoing the whole form.
The summary is generated as plain text, not HTML or JSON. Plain text pastes cleanly into Google Forms, email, Canvas, Schoology, and any other submission tool. The format: a header block (student name, period, date, hunt title) followed by stop-by-stop Q&A pairs. Stops with unanswered questions still include (no answer) placeholders so the teacher can see what was attempted, not just what was completed.
The Clipboard API (navigator.clipboard.writeText()) handles copying with a document.execCommand('copy') fallback for older browsers. A “Copied!” label briefly replaces the button text to confirm the action.
| File | What Changed |
|---|---|
sh-xray-2026-08-01.html | Print button added to submission section; “Answer Summary” button added; Bootstrap modal added before footer; summary-generation IIFE added; lastUpdate updated to 08/07/2026 |
sh-xray-2026-08-01-chatlog.html | Post-Launch 4 documented |
Post-Launch 5 Validation Fix — Missing </main>
Two W3C validation errors appeared after Post-Launch 4:
- “Unclosed element main” at the line where
<main>opens — the element was never closed. - “End tag for body seen, but there were unclosed elements” at
</body>— a direct cascade of the first error.
Root cause: </main> was never written when the chatlog was originally created. The log-container <div> closed correctly before the footer, but <main> was never closed. Every subsequent editing session (Post-Launch 1 through 4) inserted content inside the unclosed element, faithfully preserving the structural error each time.
</main> Added Before the Footer CommentOne line: </main> inserted between the log-container’s closing </div> and the <!-- FOOTER --> comment. The bug was latent since Session 1 and survived four post-launch sessions undetected.
Why browsers hid it: All browsers implement HTML error recovery that silently auto-closes unclosed block elements before the end of the document. The page rendered and behaved correctly in every browser — the structural error was invisible at runtime. The validator reports against the specification; the browser reports against what it can render. Running the validator after structural edits (not just content additions) is the only reliable way to catch these silent omissions.
| File | What Changed |
|---|---|
sh-xray-2026-08-01-chatlog.html | </main> added before the FOOTER comment; Post-Launch 5 documented |