Building TNT Adventures

“Home” describes what the file does; “Index” describes how it was historically generated. In the early web, index.html was auto-generated by Apache directory listings — a convention that survived long after most sites stopped using directory listings. In a deliberately designed site, every file should have a name that communicates its role to the developer who opens the project in an editor six months from now.

Rule: If you can read the filename and immediately know what the page does without opening it, the name is correct. adventureHome.html passes that test. index.html does not.

The naming hierarchy for the Adventures section now has three distinct patterns, each self-describing:

• adventureHome.html — the section landing page
• sHuntHome.html — the scavenger hunt catalog (camelCase: activity type + role)
• sh-xray-2026-08-01.html — individual hunts (kebab-case: type prefix + topic + date)

When index.html is removed from a directory, any browser that navigates to the bare directory URL (/adventures/) gets a 404. Keeping a redirect shim in place — two-line HTML with <meta http-equiv="refresh"> plus a JS fallback — costs nothing and eliminates all compatibility risk.

The canonical name is the new one (adventureHome.html). The old file exists only to serve any traffic that arrives via the directory URL or an outdated bookmark. It is not linked from anywhere in the project going forward.

The three-section <details> format from swingAlphabetSPARK.html maps directly onto the Stooges page:

• Episode overview (open) — We Want Our Mummy (1939), a .mission-quote dialogue block, and the persistence theme
• The Adventures connection — the Curly–student parallel, with Hunt #1 stops 1 and 9 as concrete evidence
• Fun Facts — Stooges adventure-genre history with amber border (matching swingAlphabet)

The .content-card was updated to #111827 and the clip frame border changed from green to amber — consistent with swingAlphabet and other clip pages. Adventures green stays in the hero gradient; the shared dark card palette is now uniform across the clip collection.

Two placements were considered: in the content area (between hero and activity cards) or inside the hero itself. The hero wins: the blurb is visible on load alongside the title, setting tone before anything else is read.

The blurb renders at 88% size and 62% opacity — subordinate to the title and subtitle, but immediately readable. The “Meet them →” link uses amber so it reads as the one actionable element in the hero without competing with the main headings.

“Meet them” implies the Stooges are characters you can go and encounter — not a footnote about the background image. The arrow makes it a direction, not a label.

The profile is stored under tntAdventureProfile as a JSON object: { firstName, lastName, period }. Date is deliberately excluded — it belongs to individual activity submissions, not the identity record. When a hunt page needs to record a response, it reads the profile from localStorage and appends the submission date at that moment.

Three behaviors driven by the presence or absence of the stored key:
No profile → modal opens immediately, non-dismissable (static backdrop, no Escape, no close button) until form is completed.
Profile exists → modal skipped; student bar renders at page bottom showing name, period, and Edit / Reset links.
Edit clicked → modal opens in edit mode with pre-filled values and a visible close button (fully dismissable).

The same <div class="modal"> serves onboarding and editing, but with different Bootstrap options. On first visit: backdrop: 'static', keyboard: false. On edit: backdrop: true, keyboard: true with the close button made visible.

Options are passed programmatically as the second argument to new bootstrap.Modal(el, options) rather than set as data-bs-* HTML attributes, because the behavior must differ between the two modes. One element, two instantiation contexts, correct behavior in both cases.

The student bar sits at the bottom of <main>, between the content section and the footer — visible to a student looking for it, unobtrusive for one who is not. It is a status indicator, not a call to action.

The Reset link invokes confirm() before clearing the profile. A student who clicks Reset accidentally should not lose their saved data without a second deliberate action.

The student bar now has two layers: the normal status row (id="studentBarMain") and a hidden confirmation row (id="resetConfirm"). When Reset is clicked, the confirmation row slides into view below the status line with two styled buttons: Yes, clear it (red) and Cancel (grey). Cancel hides the confirmation row. Yes, clear it performs the actual reset.

No overlay, no browser dependency, no thread blocking — and the visual language (red for destructive, grey for safe) communicates the intent without any words beyond the label.

openModal() now calls bootstrap.Modal.getInstance(el) before creating a new instance. If a stale instance exists, prev.dispose() is called first. Only then is new bootstrap.Modal(el, options) called, with a clean element.

Rule: Always call getInstance() before new Modal() on a shared DOM element. Stale instances are the most common source of unexpected Bootstrap modal behavior, and they are invisible — no console error, just wrong behavior.

When openModal(false) is called (first-visit or post-reset mode), the three form fields are now explicitly cleared and any is-invalid classes from a previous attempt are removed. Without this, old values and red validation highlights from a prior session persist in the form after a reset — which is confusing precisely because the user just cleared their profile and expects a blank slate.

The immediate initProfile() call is replaced with a two-branch check. If document.readyState === 'complete', all resources are already loaded and initProfile() runs immediately. Otherwise, it is registered as a window.load listener, which fires only after every stylesheet, script, and image is fully applied.

The readyState guard is necessary because the script sits at the bottom of <body>: by the time the browser parses it, load may have already fired. Registering a listener for an event that has already fired does nothing — the guard prevents that silent failure.

The pageshow event fires for both normal loads and BFCache restorations. When event.persisted === true, the page was served from cache. A listener for this event calls initProfile() again, correctly rendering either the student status bar (if a profile is saved) or the welcome modal (if not).

pageshow is the only event that fires in both load and cache-restore contexts. DOMContentLoaded and window.load do not fire on BFCache restoration — this is by design, for performance. Any page that initializes UI from stored state must listen for pageshow to behave correctly after back/forward navigation.

One template for all five Adventures pages. Path values vary by directory depth; the structure is identical:

• Icon 1: TNT dynamite icon → site home (index.html)
• Icon 2: Validate icon → W3C validator (dynamic URL via validateLink JS pattern)
• Text: All rights reserved. • © 2015–[year] TechNoviceTools (TNT) • Last updated: [date]

Why no Bootstrap icon? Bootstrap is a framework dependency, not a content partner. Dependency credit belongs in page comments or chatlog tech notes, not in student-facing footer chrome.

A metaphor earns its place in a curriculum when it illuminates the actual concept, not just illustrates it. The Danger Room metaphor does pedagogical work: it explains why DevTools is safe to experiment in (reset on refresh), who is responsible for what they learn (Xavier required discipline), and what power looks like without training (Jean Grey, uncontrolled).

The classroom discussion prompts in the third collapsible panel of the clip page all derive from this: power and responsibility, the Danger Room principle, training vs. raw talent, the choice Xavier made. These are not decorative questions — they are the same questions a software ethics curriculum asks. The metaphor bridges entertainment to content in a way a plain DevTools tutorial cannot.

The Danger Room/Field Mission split reflects a real technical distinction that is also a real pedagogical progression. Every novice should master the Danger Room first: experiment freely, break things deliberately, reset on refresh. Only after that foundation is solid does the “this is not a simulation” warning on the Field Mission page make sense — and carry appropriate weight.

The warning on fieldMissionOverrides.html opens with a deliberately bold callout: “This is not a simulation.” That sentence means nothing to a student who has never experienced the Danger Room’s consequence-free refresh. It means everything to one who has.

“Field Mission” wins on three criteria: it stays inside the X-Men universe, it describes exactly what the activity is (a structured mission beyond the training room), and it sets up a natural escalation ladder (Danger Room → Field Mission → ?) without requiring franchise knowledge to understand the progression.

Cerebro requires knowing that Cerebro amplifies telepathy to global range — useful for teachers who know the lore, confusing for students who don’t. “Field Mission” is self-explanatory to anyone who has seen any action film. Self-explanatory names win in educational contexts because cognitive load belongs to the content, not the label.

The Field Mission guide is explicitly designed to receive screenshot support. Each placeholder is a styled dashed zone (role="img" for accessibility, with a descriptive aria-label) that shows exactly what screenshot will go there: “DevTools Sources panel, Overrides tab selected, showing the folder path and checked Enable Local Overrides checkbox.” When the screenshot is ready, replace the placeholder content with an <img> tag — the zone handles it.

The Danger Room guide has no screenshot zones because the operations it describes (Elements panel, Styles pane, Console) are visually simpler and more familiar from general DevTools exposure. The Field Mission guide covers the Sources panel, which students are much less likely to have encountered, making visual support proportionally more valuable.

The Adventures landing page originally held three activity cards at col-md-4 (one row of three on medium+ screens). Adding Danger Room Training and Field Missions as the fourth and fifth cards required a grid change. All five cards now use col-sm-6 col-md-3: two columns on mobile, four per row on medium+ screens with a fifth wrapping cleanly.

Card status: Scavenger Hunts (live), Danger Room Training (live), Field Missions (coming — field manual linked from card), Fix the Bug (coming), DevTools Challenges (coming). Two of five are live. The ordering places both live activity types first, making the page feel active rather than aspirational.

This chatlog (adventuresChatlog.html) covers the Adventures infrastructure: naming, file structure, student identity, footer consistency, and the curriculum arc that introduced DevTools training. It is the founding document for the Adventures section.

Each activity type that develops beyond its initial card will earn its own chatlog and potentially its own cover page. Precedent already exists: the Scavenger Hunt section has sh-xray-2026-08-01-chatlog.html for Hunt #1. The Danger Room and Field Mission will follow the same pattern as they develop individual named missions (Alpha, Beta, Gamma, Delta).

The split makes logs useful at the right granularity: this file for anyone asking “how was Adventures built and why does it exist?” — individual activity logs for anyone asking “why did this specific mission work the way it does?”