Follow the Leader — S.P.A.R.K. Chat Log
Building a free-form trail-documentation tool, the TRAIL presentation framework, and a student-facing guide that bridges novice guided tours to the full SPARK CODES curriculum.
This page chronicles the creation of the Follow the Leader app from initial concept to delivered files. The S.P.A.R.K. banners frame each development phase. The decision boxes document key design choices. The critique box examines what made the prompt effective.
Notice how this differs from the Code Word Collector chatlog: the domain is different (documenting a journey vs. collecting vocabulary), but the build pattern is the same — localStorage persistence, auto-grow rows, print + export output, and a separate companion document.
I’m envisioning another app, followTheLeader.html, that captures a novice’s challenge or quest to find something within TNT. They are to ‘blaze a trail’ and then lead the class to the treasure. It’s not scripted like a scavenger hunt — it’s more free-form. There will be no over-programming, but it may require finding information, particular pages, or using ‘x-ray vision.’ It could last 3–10 minutes. I’d like a form with a starting place, a final destination, and the path taken (breadcrumbs!). Like the Code Word Collector they can print or send it to the clipboard. They are leading their peers, so they need to be coached on presenting. We have a SPARK speeches page already — those principles apply, but this activity is simpler and deserves a shorter thematic acronym. Can you create a chatlog and a short guide page like gettingStarted they can use to begin giving more technical guided explanations?
This prompt does five things well. First, it names the contrast: “not scripted like a scavenger hunt — more free-form.” That single distinction defines the entire design direction. Second, it provides the Code Word Collector as an architectural model, giving Copilot both a structural template and a visual precedent to build from. Third, it explicitly scopes the complexity: “no over-programming” prevents feature creep. Fourth, it identifies the output destination (breadcrumbs → presentation) which determines the form structure. Fifth, it references the existing SPARK CODES speech framework and asks not to replicate it but to complement it with something shorter and more focused.
The request for a “shorter thematic acronym” is the most interesting constraint. It acknowledges that a 3–10 minute guided tour needs different preparation than a 15–30 minute formal speech, and asks for the framework to reflect that difference. The word “thematic” means the acronym should connect to the trail/exploration metaphor — not just five arbitrary words that happen to spell something.
The scavenger hunt has a known answer: the teacher knows the destination before the student sets out, and the worksheet tests whether the student found it. Every stop is pre-scripted.
The Follow the Leader activity inverts this: the student’s path is not pre-determined. A teacher might say “find something that surprises you about the XRAY framework” — there is no single correct answer. The student’s trail is the output; there is no separate answer key. This distinction changes everything about the form design.
The scavenger hunt worksheet has fixed stops with specific answer fields. The Follow the Leader form has open breadcrumb rows and two open-ended discovery fields (Treasure, Surprise). There is no correct number of stops. There is no teacher-verified answer to check against. The form captures a journey, not test responses.
The SPARK CODES framework (from gettingStarted.html) has 10 principles designed for 15–30 minute formal project presentations. Applying all 10 to a 3–10 minute guided tour is disproportionate — it is like using a commercial pilot’s preflight checklist to ride a bicycle.
A 5-letter acronym was chosen to match the scope difference: roughly half the principles for roughly half the time. The word TRAIL was chosen because it is literally thematic — the activity is about blazing a trail. Every letter maps to an action that is specifically relevant to a guided tour (not a speech):
- T — Tell the destination first (tours start with the destination, speeches start with why)
- R — Remember your audience is starting cold (you know the path; they don’t)
- A — Announce each turn (narrate the breadcrumbs — this is specific to trail-following)
- I — Invite participation (a question makes a report into a conversation)
- L — Land on the treasure last (close on the discovery, not the steps)
The Code Word Collector uses a single table structure: everything the student captures goes in table rows. The Follow the Leader form has three distinct structural layers, each serving a different purpose:
- Quest card (challenge + start + destination) — metadata about the mission; these are identifiers, not findings. They go at the top because they contextualize everything below.
- Breadcrumbs table (location + finding) — the sequential path log. Same DOM-API row-building pattern as the Code Word Collector, same auto-grow sentinel. Starts with 6 rows, grows by 3.
- Discovery section (treasure + surprise) — conclusions, not stops. The Treasure is the answer to the quest; the Surprise is what the student didn’t expect. Both belong structurally below the trail because they summarize it, not extend it.
A student actively filling in their trail during class is in documentation mode. A student preparing to present is in rehearsal mode. These are different cognitive states that don’t overlap well in the same interface.
The main app is for capturing. The guide page is for preparing. Putting the TRAIL framework inside the main app would interrupt the trail documentation flow and create visual clutter during both phases. Separating them also means a student can print the guide independently, have it on a second tab, or read it before class without opening the trail form at all.
The guide page explicitly positions TRAIL as a starting point, not a permanent ceiling. The final section of the guide links directly to the SPARK CODES gettingStarted page with the framing: “TRAIL is the on-ramp. SPARK CODES is the highway.”
This creates a deliberate curriculum progression: a student who gives their first guided tour with TRAIL will find that four of the five principles (lead with the destination, remember the audience, structure the narrative, invite questions) already appear in evolved form inside SPARK CODES. TRAIL builds the vocabulary and the habit; SPARK CODES deepens it.
Build completed across five new files:
Created: followTheLeader.html (main app — form + modal)
Created: styles/followTheLeaderStyles.css (screen + @media print)
Created: scripts/followTheLeaderScripts.js (localStorage IIFE, DOM rows)
Created: followTheLeaderGuide.html (TRAIL presentation framework)
Created: followTheLeaderChatlog.html (this document)
Folder: FollowTheLeaderSPARK/
Hero image: followTheLeader.jpg (provided by TTG)
Storage key: ftl_v1
Initial rows: 6 | Grows by: 3 per Add / auto-grow trigger
Form IDs: ftlName, ftlPeriod, ftlDate,
ftlQuest, ftlStart, ftlDest,
ftlTreasure, ftlSurprise
Table: ftlTableBody (DOM-built rows; inputs[0]=location, inputs[1]=finding)
Export Summary modal: #ftlSummaryModal (purple #7c3aed — matches CWC pattern)
Print CSS: hides nav, footer, log-bar, hero, actions, tip
shows .ftl-print-header (forest-green branded print top)
preserves forest-green thead with print-color-adjust: exact
The Follow the Leader form serves two roles simultaneously: it captures the trail during exploration, and it becomes the student’s notes when presenting. A form designed only for submission produces a clean printout but a useless cue sheet. The breadcrumbs table rows are short and scannable by design — a student can glance at “Stop 3: manOfSteelXray.html — found teal callout box” while talking to the class. The form is also the script.
The SPARK CODES framework has 10 principles because a 15–30 minute formal presentation with Q&A requires 10 things to go right. A 3–10 minute guided tour requires 5. Scaling a framework down to match a shorter activity is not dumbing it down — it is correct engineering. A student who is overwhelmed by 10 principles before their first guided tour will perform worse than one who has 5 clear things to remember. TRAIL is intentionally minimal. The curriculum progression from TRAIL to SPARK CODES is the skill-building arc.
The paradox of a free-form exploration is that it produces very little that is presentable unless the student is capturing as they go. The breadcrumbs table enforces structure on an unscripted activity without constraining the activity itself. A student can visit any page, follow any link, use DevTools or not — the table just asks them to record where they went and what they found. The structure is in the form; the freedom is in the trail. This is the correct boundary between scaffolding and constraint.
A novice student noticed that Follow the Leader is listed as a JavaScript app but “looks like a form.” This session documents the decision to create aboutFollowTheLeader.html as a standalone teaching page, the reasoning behind that placement choice (rather than embedding the content here in the chatlog), and a defense of each structural and pedagogical decision made inside the page itself.
You are a master CS teacher and a competent web developer. A novice, new to the ‘Follow the Leader’ app notices that it’s classified as a ‘JavaScript’ app but there’s nothing about it that looks ‘code-y.’ Can you write up an explanation of how JavaScript was used in the app (and why) and use this as a teaching moment to introduce JavaScript programming to a ‘newbie’? I’m thinking we could do this in a file: aboutFollowTheLeader.html (or, if you think it is best put in the chatlog, we can put it there. I’m interested in where you think it best lands).
The prompt does three things particularly well. First, it names the persona precisely: “a novice who notices it’s classified as a JavaScript app.” That single framing tells us the reader’s starting point (they can see the category label but can’t connect it to experience) and the gap to close (showing the invisible machinery). Second, it explicitly invites a placement recommendation — “I’m interested in where you think it best lands” — which is itself a teaching move: it asks the developer to reason about information architecture before writing a single line. Third, it frames the exercise as a “teaching moment,” which scopes the tone: not a technical reference document, not marketing copy, but genuine pedagogy aimed at someone who is confused, not unintelligent.
The one thing the prompt does not specify is the depth of JavaScript knowledge to assume. The word “newbie” implies no prior experience, but it could mean anything from “knows what a browser is” to “has seen HTML before.” In practice, the content was aimed at the more conservative assumption: someone who has used a web browser but has never looked at source code.
The chatlog is a developer’s build diary. Its implicit audience is someone curious about how the app was built: what design choices were made, what prompted them, and what can be learned from the process. That audience is comfortable with technical vocabulary and process narrative.
The about page’s audience is completely different: a novice who is confused about a category label. Those two audiences have different questions (“what was the SPARK process?” vs. “what is JavaScript actually doing here?”), different prior knowledge, and different reading contexts (a student who opened the chatlog to understand the development history vs. a student who clicked “Under the Hood” because they were puzzled).
Embedding the teaching content here would create three problems: (1) novices who never open the chatlog would never find it; (2) the educational content would interrupt the developer narrative with a sudden audience shift; (3) the page could not be linked from other entry points (the JS Apps grid, future resource pages) without linking to a chatlog that contains unrelated development content.
A standalone page solves all three. It can be linked from the log bar of the main app, discovered independently, linked from elsewhere, and read without developer-diary context. It also follows the existing companion-page pattern already established by the TRAIL Guide.
A novice who doesn’t understand what role JavaScript plays in the browser cannot appreciate any specific feature. The HTML/CSS/JS pillar structure is the canonical mental model that every CS teacher uses at the very first introduction. It was placed first, not buried mid-page, because understanding the category (JavaScript = behaviour) is prerequisite to understanding the instance (this specific behaviour). If you show the code before you show the frame, the code has no meaning.
Analogies are the fastest route from the abstract to the concrete for a reader who has no schema to attach new information to. The school analogy was chosen because every student has an embodied, intuitive understanding of schools: they know what a building is (structure), what decoration does (appearance), and what staff do (make things function). All three mappings hold cleanly — HTML structures, CSS decorates, JavaScript staffs the place. The analogy also directly answers the original confusion: without JavaScript, “the building exists and looks nice, but nothing actually happens.” That sentence is the insight the novice needs, stated in terms they already own.
Counterfactual framing is a powerful teaching technique: describing what is absent makes what is present legible. The callout addresses the student’s original confusion head-on — “it looks like just a form” — by confirming that yes, without JavaScript it would be just a form: static, forgetful, inert. This inverts the student’s perception. They thought the form was the app. The callout reframes: the form is just HTML. The app is JavaScript.
The app uses JavaScript for more than five things: debouncing, date formatting, the validate-link footer logic, modal population, and others. All of these were catalogued during development. Five were chosen for the teaching page because they represent five genuinely distinct conceptual categories — DOM manipulation, events, persistence, conditional logic, and string/API work — rather than five arbitrary instances of the same concept.
Starting with too many concepts overwhelms a novice and produces the same surface-level confusion the page is trying to cure. Five concepts that are truly different give the student five real tools to carry forward. Debouncing was moved to a bonus tip rather than a sixth job because it is a refinement of concepts already covered (events + timing) rather than a new conceptual category. It rewards the curious reader without taxing the novice who is already at capacity.
Abstract code examples teach syntax in isolation. Code from the actual running app teaches the connection between symbol and behavior. When a student reads the buildRow snippet and then opens DevTools to confirm that the <tbody> is empty in the source HTML, the snippet transforms from an illustration into an explanation. That moment of verification is the pedagogical goal.
Each snippet was trimmed to the minimum that demonstrates the concept — not a full function listing, but the three to six lines that carry the idea. This keeps cognitive load low while keeping the connection to real code intact. Syntax colouring (keywords, strings, comments, methods) was added manually via spans because a novice benefits from visual differentiation of code roles even before they can name those roles.
Vocabulary presented before examples is memorization without meaning. Vocabulary presented after examples is recognition with meaning. The glossary is positioned at the end of the five job cards, not the beginning, so every term arrives with a worked example already in the student’s head. The glossary then re-encounters the same terms in condensed form, which is a second exposure that reinforces retention. It also gives the student something to save, screenshot, or return to — a reference card extracted from the narrative.
Reading about code is passive. The experiments convert the page from a reading exercise into a doing exercise. Each of the five was chosen to be achievable in under 30 seconds with no setup: F12, type a command, observe. The sequence escalates intentionally:
- 1–2: Observe (watch localStorage update; read the raw JSON string)
- 3: Read (find and read the source of a function you now understand)
- 4: Write (type JavaScript in the console and watch the DOM change)
- 5: Verify (confirm the empty HTML tbody; see the JS-built rows)
The page could have ended with the DevTools experiments. It closes instead with an explicit reframe: these five concepts are not kindergarten warm-ups to be discarded when things get serious. They are the core vocabulary of professional front-end development. This matters for a novice audience because beginners often carry the assumption that “real programming” is something different from what they just learned — that the simple version is not the real version. Naming that assumption and correcting it directly is not motivational filler. It is accurate. DOM manipulation, event listeners, localStorage, conditional logic, and the Clipboard API are used by working developers daily.
TNT regularly motivates activities with a short, memorable movie clip. This session documents the creation of movie_clips/followTheLeaderClip.html — “Following the Leader” from Disney’s Peter Pan (1953) — its card in the movie grid, its cross-link from the Follow the Leader app, and the reasoning behind the content and structure decisions.
As is common at TNT, I like to motivate an activity with a fun, (goofy) movie clip that sticks in a novice’s head (I’m so evil). I have attached the files about followTheLeader and you can see its content and purpose. I have attached a markdown file about the specs of making a movie clip for TNT along with an example: spockPIclip. Let’s create a movie clip page, followTheLeaderClip.html and link it to movie_clips using the icon we used on the js_apps page. Here is the code for the movie clip to include. You also have the artwork we used for the app that we can use in the hero background.
The clip: [YouTube embed — ID: 0DJpuaOpydo — “Following the Leader” from Peter Pan, Disney 1953, DisneyMusicVEVO]
Let’s write this prompt up (and critique it) in the followTheLeader chatlog.
This prompt does six things well. First, it provides both a specification document AND a named example page (spockPIclip.html) as context. The movie clip spec itself says: “If you attach one or more existing movie clip pages alongside the spec, treat them as the style authority. The spec defines the rules; the examples demonstrate how those rules look in practice. When they differ, the examples win.” Attaching the example is not redundant — it is the most important part of the context bundle.
Second, the prompt references the icon and hero background by implication rather than by file path: “the icon we used on the js_apps page” and “the artwork we used for the app.” This is efficient shorthand that works because js_apps.html and followTheLeader.html are both attached as context. The developer reads both files to retrieve the exact paths rather than the teacher having to look them up manually.
Third, the prompt states the pedagogical intent explicitly — “a fun, goofy movie clip that sticks in a novice’s head” — which scopes the tone of the page. A clip page for a horror film requires different prose than one for a children’s earworm. The intent statement changes what gets written in the introductory paragraphs.
Fourth, the prompt provides the embed code directly. This is the most irreplaceable piece of information in any clip-page request: without the YouTube ID, nothing can be built. Embedding the raw <iframe> snippet (even knowing the spec will strip the frameborder and width/height attributes per its own validation rules) is the right move — it gives the exact ID and any si tracking parameter.
Fifth, the final line — “Let’s write this prompt up (and critique it) in the followTheLeader chatlog” — closes the loop. Every session in this chatlog was requested; none appeared spontaneously. Treating the chatlog as a deliberate artifact of the build process, not an afterthought, is a habit this prompt models explicitly.
One gap: the prompt does not specify the card description text for the movie_clips.html grid. This had to be inferred from the clip’s content and the FTL activity’s description. In practice, the inferred text is appropriate — but a very specific card teaser (e.g. one quoting the song or naming the Lost Boys) would require the teacher to supply it.
The movie clip spec defaults to var(--tnt-amber) as the accent color and says to override “only when the film has a strong thematic color that justifies it.” Three reasons justify the forest-green override here: (1) Peter Pan’s costume is green — it is the film’s dominant hero color; (2) Neverland is a jungle island; (3) the forest green exactly matches the Follow the Leader app palette, creating visual continuity between the clip page and the companion tool. A student who opens both pages consecutively will register that they belong to the same ecosystem.
The clip page spec says to use a still or promotional image specific to the film if available, or fall back to ../images/movieCrowd.jpg. Neither option is ideal here: TNT does not hold a Disney promotional still, and the generic cinema interior would create no connection to the FTL activity. The Follow the Leader app hero image (followTheLeader.jpg) is thematically appropriate — forest setting, trail imagery — and makes the clip page feel like it belongs to the same curriculum unit as the app. The spec’s hero-background rule describes an ideal; the guiding principle is fitness for purpose.
The spec template provides three <details> sections: overview, CS connection, and optional fun facts/discussion prompts. The fun facts section was omitted because the CS connection section already serves the discussion function. A dedicated discussion-prompts block would repeat the TRAIL framework, which is already documented in full in followTheLeaderGuide.html. Adding a third section here would create redundant content at a lower quality than the guide page already provides. The clip page links directly to the guide; students who want depth can follow that link.
The clip page links to the Follow the Leader app via a companion callout in Section 2. The Follow the Leader app’s intro panel was also updated to link back to the clip page. The spec’s guidance is explicit: if the target file is attached as context, both links should be written in a single pass.
The return link in the app is phrased “Why this activity exists →” rather than “Watch the clip.” This framing is more likely to be clicked by a student who has already opened the trail form, because it promises context rather than entertainment. A student who is mid-task will not want to watch a video; a student who wants to understand the pedagogical framing of what they are doing will.
The teacher describes this strategy as “evil” in the prompt, and the word is worth examining. What makes an ear-worm pedagogically useful is exactly what makes it annoying: it is hard to forget. “Following the leader, the leader, the leader” does not fade. A student who hears it in class will hum it during the trail-documentation activity and, more importantly, will hear it again internally when they stand up to present. “I am Peter Pan right now. My classmates are the Lost Boys.” That association costs nothing after the initial 90-second clip. It guides behavior for the rest of the activity.
This is a legitimate pedagogical technique with a long history — mnemonics, jingles, and song-based learning exploit procedural memory to carry declarative content. The “evil” the teacher is describing is the benevolent kind: engineering a memory hook that students cannot opt out of, in service of content they genuinely need to retain.
I think our discussion about where the ‘about’ page for followTheLeader is good information in our chatlog (decisions about placement) but moreover, you made decisions about what to put into the about page. I’d like you to defend your reasoning on its content (I am pleased with it by the way). I’d like to include this current prompt, and the one you used to make the about page in the chatlog, again, for instructional purposes.
This prompt models a teaching behavior that students should learn to apply to their own work: asking for a rationale. “I am pleased with it” establishes that the critique is not remediation — it is reflection. The distinction matters. When you ask for a defense of a decision that worked, you are practicing the kind of retrospective analysis that separates a craftsperson (who produces a result) from a practitioner (who understands why the result works and can reproduce the reasoning in a new context).
Including both prompts in the chatlog, as requested, also demonstrates a second principle: the chatlog is not only a record of code decisions. It is a record of design thinking. The most instructionally valuable entries in any SPARK chatlog are the ones where reasoning is made explicit — not just “we chose X” but “we chose X over Y because…” Students reading this log later are not just learning what was built. They are learning how to think about what to build next.
The Follow the Leader ecosystem is ready for upload. This session documents the news entry (#047) announcing the full app suite to TNT’s audience, the resource card added to the “TNT’s Own Resources” section of resources.html, and the reasoning behind both. It is likely the final entry in this log before the files go live.
We are close to uploading this app into live TNT. We need an entry in the news page about it. Be sure to look at the entry on ‘To Err is Human’ to see the protocol I like about files linked at the bottom of a news entry. I have supplied all the followTheLeader-related files so you can see what should be summarized in the article. The novice should notice there’s an opportunity in this venue to learn more about JavaScript programming, which doesn’t happen in many app scenarios.
In my view, since this is a resource novices can use, I think it should have an entry card in the ‘TNT’s Own Resources’ area on the resources page. Let’s include this prompt in the chatlog for followTheLeader. It may be the last one as we prepare to upload all of this live.
This prompt does five things worth naming. First, it names the gate condition explicitly: “we are close to uploading.” That phrase triggers a specific type of task — pre-launch documentation — rather than a feature addition or a design decision. Naming the phase avoids a mismatch between what the teacher expects and what gets delivered.
Second, it references a named example for format compliance: “look at the entry on ‘To Err is Human’ to see the protocol I like.” The specification is by example rather than by rule, which is exactly the right technique when the rule is visual and hard to describe in words. Attaching example pages as context (as this prompt does for all the FTL files) is itself the SPARK method applied to the news entry problem.
Third, the teacher issues an editorial priority: “the novice should notice there’s an opportunity in this venue to learn more about JavaScript programming, which doesn’t happen in many app scenarios.” This is a content weighting instruction. The news entry could describe the trail form in detail, the TRAIL framework in detail, the movie clip, or the chatlog. The instruction says lead with the JavaScript education angle — that’s what is rare, and rarity is what makes something news.
Fourth, the resources.html request is framed as a judgment: “in my view, since this is a resource novices can use.” The teacher is not asserting an objective fact; they are applying a categorization criterion — usefulness to novices as a standalone resource — and inviting agreement with the reasoning rather than just issuing an order. That framing models the kind of thinking the chatlog is trying to teach.
Fifth, “it may be the last one as we prepare to upload all of this live” names the end state. This is not a commitment, but it is a useful signal: the design phase is substantially complete, and what follows should be deployment hygiene, not new features. Every project benefits from someone saying out loud that the building phase is winding down.
The news entry could have foregrounded the trail form, the TRAIL framework, the Peter Pan clip, or the chatlog. The teacher’s instruction was clear: lead with the JavaScript education opportunity. Three reasons make this correct. First, it is genuinely unusual — most TNT apps are used, not explained; a companion page that walks a novice through five distinct JS concepts, with real code and hands-on experiments, is a differentiator. Second, it is the highest-value entry point for the audience most likely to land on the news page without context: a student or parent skimming headlines who wonders what makes this app interesting. “It teaches you how it works” is a hook; “it has six rows that grow automatically” is not. Third, the JavaScript primer (aboutFollowTheLeader.html) is the piece most likely to be shared or referenced independently, which makes it worth emphasizing in the announcement that introduces the whole ecosystem.
The JS Apps grid is for apps that students run. The Resources page — specifically “TNT’s Own Resources” — is for tools that students consult. The distinction matters. Code Word Collector already lives in both places. Follow the Leader qualifies for the Resources section because it has two use modes: a student opens it during an activity (app mode), and a student opens it to understand what JavaScript actually does (reference mode). The “Under the Hood” companion makes the second mode possible. Without that companion, Follow the Leader would be just an app. With it, it is also a reference.
The resource card description links directly to aboutFollowTheLeader.html alongside the main app link, making the JavaScript primer discoverable from the Resources page even for a student who isn’t planning to run the trail form.
Session 4 build complete. Pre-launch file inventory for the Follow the Leader ecosystem:
news.html — entry #047 added (Aug 2026, newest first) resources.html — Follow the Leader card added to TNT’s Own Resources followTheLeaderChatlog.html — Session 4 added (this entry) followTheLeader.html — lastUpdate 08/08/2026, movie clip cross-link live Follow the Leader ecosystem — all files ready for upload: FollowTheLeaderSPARK/followTheLeader.html FollowTheLeaderSPARK/styles/followTheLeaderStyles.css FollowTheLeaderSPARK/scripts/followTheLeaderScripts.js FollowTheLeaderSPARK/followTheLeaderGuide.html FollowTheLeaderSPARK/followTheLeaderChatlog.html FollowTheLeaderSPARK/aboutFollowTheLeader.html movie_clips/followTheLeaderClip.html Sessions: 4 | Design decisions documented: 20 Links to this ecosystem from: js_apps.html (figure card) movie_clips.html (grid card) resources.html (TNT’s Own Resources card) news.html (entry #047)
The teacher’s phrase “it may be the last one as we prepare to upload all of this live” is worth preserving in the log because it demonstrates something students rarely see modeled: naming completion. Programming projects do not end; they reach a state where the current version is good enough to ship and further changes would require new justification. Saying “we are near the end of the design phase” is not a commitment to stop — it is an explicit acknowledgment of where the project stands, which is the first condition for deciding rationally whether to continue. Students who learn to name completion states will write better software, run better meetings, and submit better assignments than those who continue indefinitely because no one said stop.
The original Follow the Leader resource card description included a hyperlink inside the description paragraph: <a href="FollowTheLeaderSPARK/aboutFollowTheLeader.html">JavaScript primer</a>. The entire card is itself an <a> element. HTML does not permit nesting one <a> inside another. The W3C validator flags this as an error; browsers handle it unpredictably by splitting the outer link in ways that vary by browser engine.
The fix is a single-word adjustment: remove the inner hyperlink and keep the text “JavaScript primer” as plain text within the description. The card’s href already navigates to the trail form; a student who wants the primer can find it from there. This is the correct pattern for all TNT resource cards — descriptions are plain prose, not navigation. Compare every other card in the “TNT’s Own Resources” section: none of them embed links inside their descriptions. The temptation to link deeply from within a card is understandable, but the HTML validity rule — no block-level clickable region may contain another clickable region — is the deciding constraint. Pre-upload validation catches exactly this class of error before it reaches a live audience.
A gap discovered during upload: Follow the Leader was never added to explore.html. This session documents the fix (adding the app to the Utilities and S.P.A.R.K. categories), the reasoning behind each classification, and the broader lesson every novice deploying an app should internalize: working from a checklist is not bureaucracy — it is engineering.
I thought I was finished with the followTheLeader chatlog but in uploading the related files, I realized I forgot to ‘wire up’ the followTheLeader app in the explore page. Let’s add this there (I see it as a SPARK app (obviously) and as a ‘Utilities’ app (much like Code Word Collector.)) Please comment on these classifications and let’s add the app to explore, remembering that only the chatlog gets mentioned in the offcanvas callouts for SPARK apps; just the app itself is in callouts in other classification areas.
Use this as a reminder to novices that they ought to have some sort of ‘checklist’ before they ‘call it a day’ on an app and its inclusion into an ecosystem.
This prompt models something students rarely see: the honest admission of an oversight followed by a constructive response. “I thought I was finished” is not a failure statement — it is the exact cognitive state that precedes every gap discovered during deployment. Naming it out loud, without deflection, is the first condition for converting a mistake into a lesson.
The phrase “in uploading the related files, I realized” identifies the mechanism: the deployment process itself performed the audit. This is not uncommon. Trying to actually transfer files forces a review of what exists, what links where, and what's missing — an audit that development-mode browsing rarely triggers. The lesson is not that the teacher was careless. It is that some gaps are only visible from the deployment vantage point.
The classification reasoning (“I see it as a SPARK app (obviously) and as a Utilities app”) is offered with appropriate confidence levels. “Obviously” for S.P.A.R.K. acknowledges that the criterion is unambiguous. The hedging on Utilities (“much like Code Word Collector”) is correct — the comparison does more reasoning work than asserting the category from scratch. Inviting commentary on those classifications is itself a good pedagogical move: it asks for principled agreement or principled disagreement, not just compliance.
The final sentence — “Use this as a reminder to novices” — converts a personal oversight into curriculum. That transformation is the mark of an experienced teacher. Every problem a student will encounter was first encountered by the teacher. Sharing the encounter is the transfer.
The S.P.A.R.K. category in explore.html is not simply for “apps built with AI assistance.” Every 2026 app was built with some AI assistance. The defining criterion is documentation: an app belongs in S.P.A.R.K. when it has a chatlog that chronicles the design process — the prompts, the decisions, the reasoning that would otherwise be invisible.
Follow the Leader has the most extensively documented chatlog in the 2026 ecosystem by that criterion: five sessions, 24 design decisions, covering app architecture, the TRAIL framework, a JavaScript primer for novices, a movie clip integration, a news entry, a resource card, a validation bug, and now the pre-upload checklist. The chatlog is not a byproduct of building the app — it is a curriculum artifact produced alongside it. That is the S.P.A.R.K. category’s purpose.
The teacher’s comparison to Code Word Collector is precise. Both apps are classroom capture tools: one captures vocabulary, the other captures a trail. Both use localStorage, auto-grow tables, print output, and clipboard export. Both serve the student during an activity and produce a deliverable the teacher can assess. The architectural pattern is the same because the problem type is the same: “help me record something structured while I am in motion.”
The explore.html Utilities description reads: “Handy gadgets that solve surprisingly specific problems with satisfying elegance.” Follow the Leader solves a specific problem — “how do I document an unscripted exploration so I can present it coherently?” — with a form architecture (quest card + breadcrumbs table + discovery section) that is both simple and exactly sized for its purpose. It is not a game, not a simulation, not a text manipulator. It is a tool. Utilities is correct.
The gap that surfaced here — explore.html was not wired — is the kind that a checklist catches and memory does not. Every TNT app in the 2026 ecosystem touches a set of shared pages when it ships. A complete deployment checklist for a TNT JS app looks like this:
- Language index page (js_apps.html, processing_apps.html, php_apps.html) — figure card with icon and caption
- movie_clips.html — grid card, if a companion movie clip exists
- news.html — news entry describing the launch
- resources.html — resource card in “TNT’s Own Resources,” if the app is a student reference tool
- explore.html — (a) featured link in the category card, AND (b) full entry in the offcanvas — for every category the app belongs to ← the one that was missed
- Companion cross-links — bidirectional links between all companion files (app ↔ guide ↔ chatlog ↔ movie clip ↔ resources card)
- W3C validation — all new files pass the HTML and CSS validators
- Live test — after uploading, open every linked page on the live server (not localhost) and confirm no 404s, no broken images, no missing scripts
The explore.html item is the most easily overlooked because it requires two separate operations per category: updating the category card’s featured list AND updating the offcanvas app list. A developer who remembers to add the card but forgets the offcanvas (or vice versa) has done half the job. A checklist item written as “explore.html — card AND offcanvas” closes that gap. The antidote to “I thought I was finished” is not better memory. It is a checklist that doesn’t allow “finished” until each item is checked.
Session 5 build complete. explore.html wired:
explore.html changes: Utilities card — Follow the Leader added (3rd featured item, at cap) Utilities offcanvas — Follow the Leader added S.P.A.R.K. offcanvas — Follow the Leader + Chat Log added lastUpdate — 07/31/2026 → 08/08/2026 FollowTheLeaderChatlog.html — Session 5 added Final ecosystem wiring from explore.html: Categories: Utilities (card + offcanvas), S.P.A.R.K. (offcanvas) Total sessions: 5 | Total design decisions documented: 24 Full wiring across the TNT ecosystem: js_apps.html (figure card) ✓ movie_clips.html (grid card) ✓ news.html (entry #047) ✓ resources.html (TNT Own Resources card) ✓ explore.html (Utilities + S.P.A.R.K.) ✓ ← added this session followTheLeader.html (all companion cross-links) ✓
A student identified two factual errors in movie_clips/followTheLeaderClip.html. Both were AI attribution errors produced by confident pattern completion rather than verified fact lookup. This session documents what was wrong, the failure mode that caused it, and how it was corrected — serving as a permanent record and an explicit warning to anyone using AI-generated content about specific character credits in vintage media.
The original clip page credited Paul Collins to “the Twins” — an unnamed pair of Lost Boys characters from the film. Paul Collins voiced John Darling. The Lost Boys Twins are entirely separate characters.
The failure mode: the AI model encountered “Paul Collins” in context with “Peter Pan,” “Lost Boys,” and “marching sequence” and associated Collins with the nearest group reference (“the Twins”) rather than performing a specific credit lookup. The YouTube oEmbed title “Bobby Driscoll, Paul Collins — Following the Leader” listed two named performers, which was a signal that two named characters were involved — not a principal and an unnamed pair. The signal was misread.
The original description said “Peter Pan leads his Lost Boys through Neverland.” John Darling is given the drum-major role at the head of the march procession. The Darling boys (John and Michael) participate in the march alongside the Lost Boys. A description that named only “Peter Pan” and “the Lost Boys” misrepresented the scene’s full cast in a way that was factually consequential for a page specifically about that sequence.
Language models produce fluent, confident prose even when the underlying data is uncertain, absent, or conflated. Training data about Disney’s Peter Pan (1953) is abundant at the thematic level (plot, characters, themes) and sparse or unreliable at the specific credit-attribution level (who voiced which supporting character in a 70-year-old film). The model did not “know” that Paul Collins voiced John Darling. It generated a plausible-sounding attribution by pattern-matching the name to the nearest available group reference in context.
This is not a rare edge case. Specific voice credits, minor character attributions, publication dates, and similar narrow factual claims are exactly the category where AI systems are most likely to produce confident wrong answers. The fluency of the output provides no signal about its factual reliability. Any AI-generated claim of this type should be independently verified before publication. It was not. The student caught it. The correction is now on the record — both on the clip page itself and in this chatlog.
Session 6 corrections applied:
movie_clips/followTheLeaderClip.html: "Paul Collins (the Twins)" → "Paul Collins (the voice of John Darling)" Opening paragraph: John Darling’s drum-major role now described Lost Boys paragraph: John and Michael Darling now included Correction callout added to Section 1 (links to Ask Copilot Entry #053) askCopilot.html: Entry #053 added (Pop Culture & CS | AI Accuracy) lastUpdate: 08/07/2026 → 08/08/2026 Meta description: "52+ entries" → "53+ entries" followTheLeaderChatlog.html: Session 6 added (this entry) Error type: AI attribution error (confident pattern completion, no fact verification) Caught by: student reviewer during post-upload inspection Resolution: visible correction + acknowledgment callout + column documentation + chatlog record
A trial run revealed that the Print option clips content in text inputs — verbose trail notes and long TNT URLs are cut off at the field boundary. The Export Summary (plain-text modal) correctly captures all content. This session documents the diagnosis, the CSS fix, and the decision rationale for the wrapping approach chosen.
I just did a trial run of this app, and it works well. However if a student is verbose, or if a URL is lengthy (and most are at TNT), when we use the ‘Print’ option, form fields are clipped; when we use the ‘Export Summary’ option, all the info is captured. Is there a way to modify the print option so that all information is shown? It’s ok if a lengthy URL must be ‘broken’ to move it to another line.
This prompt does three things well. First, it establishes the contrast precisely: Export Summary captures everything correctly; Print clips. That contrast is the most useful diagnostic frame a developer can receive — it immediately tells us the problem is in the print CSS, not in the data layer. Second, it grants explicit permission for a line-break approach on long URLs. That permission is not obvious. Some teachers would prefer horizontal scrolling or a reduced font size; naming the acceptable compromise upfront prevents a round of revision. Third, “most are at TNT” is a domain observation that reframes the problem from “edge case” to “expected behavior” — TNT URLs are characteristically long (e.g. MovieCredSPARK2026-07-29-Stg3/movieCreditsSim18.html). The fix must work for normal use, not just extreme cases.
One implicit question the prompt does not ask but the fix must answer: should the URL break at any character or only at word/path boundaries? break-word is the correct choice here — it breaks at natural opportunities first and only hard-breaks when no natural break exists. break-all is more aggressive and can split domain names mid-token, which looks worse. The answer was baked into the fix rather than added to the back-and-forth.
<input type="text"> elements are replaced elements: the browser renders them as a fixed-dimension widget, not as a flow box that grows around its content. In screen mode this is correct — an input that grows vertically while a student types would break every form layout ever built. In print mode it becomes a liability: the field’s rendered box is sized to the visible screen state, not the full content length, and anything that extends beyond the box is clipped.
The three CSS properties that together solve this:
overflow: visible— allows the text to paint outside the input’s box boundary rather than being clipped to it.white-space: pre-wrap— allows the text to wrap at natural points (spaces, after slashes in a URL path) rather than staying on one line.word-break: break-word— as a last resort, breaks at any character boundary when no natural break point exists within a line. This handles the case where a TNT folder name or query string has no spaces.
height: auto is added to release any fixed-height constraint so the element can expand vertically to contain wrapped lines.
Crucially, the table cells also needed the same treatment. An input that is told to wrap has nowhere to put the overflow if its parent <td> is still set to overflow: hidden. Adding word-break: break-word and overflow: visible to .ftl-table td opens the path from field to page.
break-word vs. break-allword-break: break-all breaks at any character boundary, unconditionally. A URL like MovieCredSPARK2026-07-29-Stg3/movieCreditsSim18.html might be split mid-folder (movieCredits / Sim18.html) with no visual cue that the break is arbitrary. This looks like a corruption to the reader.
word-break: break-word tries natural break opportunities first (spaces, slashes, hyphens) and only falls back to mid-character breaking when no natural opportunity exists within the line width. For TNT URLs, slashes in the path (/) and hyphens in folder names (2026-07-29) provide frequent natural break points, so hard mid-character breaks are rare in practice. break-word is the correct choice for content that is a mixture of English prose and URL strings.
The Export Summary modal builds a plain-text representation of the trail by reading each input’s .value property in JavaScript and writing it into a <textarea>. A <textarea> is not a replaced element — it is a block container whose content wraps by default and whose print rendering has none of the fixed-box constraints that affect <input> elements. The plain-text generation also implicitly strips all URL length issues because it writes the text into a single continuous string that the <textarea> then wraps naturally. No CSS fix was needed for Export Summary because the data-assembly method sidestepped the replaced-element problem entirely. The lesson: when a problem exists in one output path but not another, the difference in how each path assembles its output identifies the cause.
Session 7 fix applied:
styles/followTheLeaderStyles.css @media print block:
Added to input/textarea selector:
overflow: visible !important;
overflow-wrap: break-word !important;
word-break: break-word !important;
white-space: pre-wrap !important;
height: auto !important;
New .ftl-table td rule added:
overflow: visible !important;
word-break: break-word !important;
overflow-wrap: break-word !important;
followTheLeaderChatlog.html:
Session 7 added (this entry)
Decisions documented: 25, 26, 27
Total sessions: 7 | Total design decisions: 27
Effect: verbose field text and long TNT URLs now wrap to the next
print line rather than being clipped at the field boundary.
Export Summary was already correct and is unchanged.
After uploading the Session 7 CSS fix to the live server, the teacher reported that printing still clipped field content. This session documents why the CSS-only approach cannot work reliably in Chrome’s print engine, why reloading or resaving the form would not have helped, and the correct fix: the beforeprint/afterprint JavaScript event approach that substitutes <div> elements for inputs before the print layout is generated.
I just uploaded the adjusted styles into the live server and reloaded the page I had previously filled out. Because the form read localStorage, it was filled out and looked like it did before. However, when I printed, the same clipped info appeared in print form. This surprised me because I thought the styles would fix it, or would I have needed to reload the form, save it and then print to see everything in full? This also makes me think we ought to have some ‘default data’ we could load to test things, but let’s get to the bottom of things first.
The clipping is a rendering issue, not a data issue. The form’s fields hold exactly the same .value content whether they were just typed, restored from localStorage on load, or re-saved before printing. The print engine doesn’t read the saved state — it reads the current DOM. Reloading, saving, and printing again would produce exactly the same result as printing directly from the localStorage-restored state.
<input type="text"> is a replaced element: the browser renders it as a fixed-dimension native widget, not as a CSS flow container. Chrome’s print engine follows this same model. When it generates the print layout, each input is sized to match its visible screen state — which is a single-line box. Content that has scrolled horizontally out of view on screen is simply not in the paint buffer; it is never staged for printing.
overflow: visible allows text to paint outside the box boundary — but it cannot reconstruct content the browser never rendered into the visible viewport. word-break and white-space: pre-wrap affect how text wraps within the box, but if the box only contains the visible portion of the text, those properties are operating on a truncated string.
This is not a bug in Chrome. It is the defined behavior of replaced elements. The CSS-only approach from Session 7 works in some browsers (Firefox handles input content more generously in print mode) but is fundamentally unreliable in Chromium. The correct fix requires JavaScript.
beforeprint/afterprint ApproachThe Web platform provides two events specifically for print preparation. window.beforeprint fires before the browser generates the print layout; window.afterprint fires when the print dialog closes, whether or not the user actually printed. These two events are the correct hook for substituting content.
The fix in beforeprint: for every input and textarea, create a <div class="ftl-print-value">, set its textContent to the field’s .value, insert it immediately after the field in the DOM, and add ftl-print-hidden to the field to hide it. In afterprint: remove every substitution div and remove ftl-print-hidden from every field.
Why this works where CSS alone does not: a <div> is not a replaced element. It is a normal flow block container. Its textContent is the complete string from the input’s .value — including all content that was scrolled out of view on screen. CSS text-wrapping properties (word-break, overflow-wrap, white-space) work exactly as documented on block containers, and the div can grow vertically to accommodate any amount of content. The browser never had access to this content during print generation until JavaScript moved it into a flow element.
The Session 7 CSS additions (overflow: visible, word-break: break-word, height: auto on inputs) are kept as a fallback for browsers that handle replaced elements more generously. They do no harm. The beforeprint/afterprint substitution is the primary mechanism on Chromium.
The teacher correctly identified that testing print behavior requires a form filled with realistic content — specifically long URLs, which are the primary cause of clipping at TNT. A “Load Test Data” button that calls a single function populating all fields with pre-written values (including intentionally long URLs) would make print verification a one-click operation. This is deferred to a future session; the architecture is straightforward (a button calling a function that sets each input’s .value and triggers the auto-save debounce). The correct time to build it is after the print fix is confirmed working, using the test data as the verification vehicle.
Session 8 fix applied:
styles/followTheLeaderStyles.css:
Added above @media print:
.ftl-print-value { display: none; } /* hidden on screen */
Added inside @media print:
.ftl-print-hidden { display: none !important; }
.ftl-print-value { display: block; border-bottom: 1px solid #999;
word-break: break-word; overflow-wrap: break-word;
white-space: pre-wrap; font-family: inherit;
font-size: 0.9rem; color: #1a1812;
padding: 0.25rem 0.2rem; min-height: 1.2em; }
followTheLeader.html:
Added beforeprint/afterprint IIFE script block before </body>
lastUpdate updated to 08/10/2026
followTheLeaderChatlog.html:
Session 8 added (this entry) Decisions documented: 28, 29, 30, 31
Back-bar date range updated to 08/07/2026 – 08/10/2026
Total sessions: 8 | Total design decisions: 31
How it now works:
beforeprint → each input/textarea hidden; div.ftl-print-value
inserted after it with full .value as textContent
afterprint → all substitution divs removed; inputs restored
Result: Chrome’s print engine renders the div (a flow container,
not a replaced element) and wraps its full text content correctly.
Reloading, resaving, or refilling the form has no effect on this
behavior — the substitution runs fresh on every print invocation.
Decision 31 (Session 8) deferred a “Load Test Data” button as the correct next step after confirming the print fix works. The teacher supplied a text file (defaultFollowLeaderTestData.txt) with realistic content — six long TNT URLs in the location column, verbose prose in the quest and discovery fields — and requested the feature. This session documents its implementation and the rationale behind the hardcoded approach.
Actually, I have some default test data we can use in the text file I supplied. Let’s try a ‘Load Test Data’ feature and see if things work.
The test data lives in a .txt file alongside the app. Two approaches were available: (a) fetch and parse the file at runtime, or (b) hardcode the values directly in the JavaScript function.
Fetching introduces async boundaries, CORS restrictions when running from a file:// URL, encoding edge cases, and a parsing step for the custom format. All of that complexity for data that changes at most once per school year is engineering overhead with no payoff.
Hardcoding the six stops and two discovery fields directly in loadTestData() is single-function, synchronous, and readable. The text file is preserved as documentation and as the source of record; the function is the runtime artifact. That separation of record from runtime is the correct pattern here.
The button was added at the end of the actions bar, after Clear Trail and before the save-status badge — the natural position for a less-frequently-used utility that follows the primary workflow buttons (Add, Save, Print, Export, Clear).
The amber color (var(--ftl-amber) with dark text) distinguishes it from all five operational buttons: forest green (Add), gold (Save), dark green (Print), purple (Export), red (Clear). Amber is already used as the hero eyebrow color, so it reads as a consistent TNT accent. The fa-vial icon signals “laboratory / testing” without alarm connotation.
Session 9 build complete:
followTheLeader.html:
Actions bar: ‘Test Data’ button added (amber, fa-vial, after Clear Trail)
New script block: loadTestData() function
— Sets name, period, date, quest, start, destination
— Fills 6 trail rows (stops array) with full TNT URLs + findings
— Fills treasure + surprise with verbose multi-sentence prose
— btnAddRow safety loop: adds rows if table has < 6
— Calls btnSave.click() to persist to localStorage
followTheLeaderChatlog.html:
Session 9 added (this entry) Decisions documented: 32, 33
Total sessions: 9 | Total design decisions: 33
Verification path:
1. Click ‘Test Data’ — all fields populate
2. Click Print — long URLs wrap, not clip (beforeprint fix from Session 8)
3. Click Export Summary — full text captured
4. Click Clear Trail — form empties; click ‘Test Data’ again to restore
Ask Copilot Entry #039 describes the console.log() breadcrumb technique and notes that the Password Generator has deliberate breadcrumbs “left in place for you.” Follow the Leader is a natural demonstration vehicle: its lifecycle (load → restore → auto-grow → auto-save → print substitution → restore) maps cleanly to a readable console trace, and the beforeprint/afterprint pair is particularly educational. This session adds breadcrumbs to both files and documents the selection rationale.
It dawned on me there’s a lost opportunity I haven’t taken advantage of in this Follow the Leader app. In Entry #039 of Ask Copilot we discuss the use of ‘breadcrumbs’ in understanding the flow of logic and in error trapping in CS. Why don’t we implement breadcrumbs in ‘Follow the Leader’ to demonstrate that methodology? I’m thinking of simple ones like, if we call function ‘doodah’ we’d say with a console.log command: ...loading doodah... What do you think of this idea and can you implement it in a way that’s instructional and insightful without being burdensome? Let’s add this discussion to our chatlog.
Not every function is a good breadcrumb candidate. The criterion from Entry #039 is traceability without noise — breadcrumbs that tell the story of what the program is doing, not every micro-step along the way.
Functions that received breadcrumbs: loadData, initTable, growTable, saveData, the scheduleAutoSave callback, the auto-grow trigger inside buildRow, all four button/clear handlers, loadTestData, the Export Summary modal event, and both beforeprint/afterprint events. These are the lifecycle events and user-triggered operations — the moments a student asks “what is the program doing right now?”
Functions that did not receive breadcrumbs: buildRow itself (called 6–9 times during initTable alone — too noisy), getVal/setVal (utility helpers called a dozen times per restore), and collectRows (called inside saveData, which already logs). The rule: log at the level of user intention, not implementation detail.
Entry #039 shows bare function-name breadcrumbs: ...init..., ...generatePassword.... Follow the Leader extends this by adding context where the value is clear:
...initTable: 6 rows— students can verify by opening Elements and counting<tr>elements...growTable: adding 3 stops— shows theADD_COUNTconstant in actiontrail found — restoring fields and rows/no saved trail — starting fresh— shows which branch ofloadDataexecuted (a branching breadcrumb)N inputs substituted with flow divs— shows how many fields thebeforeprinthandler processed
Bare names were kept where context is already clear: ...saveData, ...loadData, ...btnSave clicked.
The scheduleAutoSave() function fires on every keystroke. It does not log at that point — doing so would flood the console. What it logs is its callback: the function that runs 900ms after the last keystroke stops:
autoTimer = setTimeout(function () {
console.log('...autoSave fired (900ms idle)');
saveData(false);
}, 900);
The student experience: open DevTools → Console, type quickly in several fields. The console stays silent while typing. The moment typing pauses for a second, ...autoSave fired (900ms idle) appears — once, regardless of how many keys were pressed. This makes the debounce pattern visible and visceral without requiring any explanation. It is the hardest concept in the file to explain abstractly and the easiest to demonstrate this way.
Compare Entry #039’s Password Generator breadcrumbs: ...init..., ...updatePassword..., ...processSymbolSet: all. Follow the Leader’s traces follow the same pattern but add the branching and count context that makes the lifecycle readable as a story, not just a call log.
Session 10 build complete:
followTheLeaderScripts.js: loadData — breadcrumb + branch messages (fresh vs. restored) initTable — breadcrumb with row count growTable — breadcrumb with stop count saveData — breadcrumb scheduleAutoSave callback — debounce breadcrumb (fires after 900ms idle) buildRow auto-grow trigger — breadcrumb before growTable call btnAddRow, btnSave, btnPrint, clearYes — click breadcrumbs followTheLeader.html: loadTestData — breadcrumb at entry Export Summary modal — breadcrumb on show.bs.modal beforeprint — breadcrumb + substitution count afterprint — breadcrumb with restore count followTheLeaderChatlog.html: Session 10 added Decisions documented: 34, 35 + debounce aside Total sessions: 10 | Total design decisions: 35 Demonstration path (open DevTools Console first): 1. Reload page — see ...loadData + branch message + ...initTable: 6 rows 2. Type in fields, pause — see ...autoSave fired (900ms idle) 3. Click Add 3 Stops — see ...btnAddRow + ...growTable: adding 3 stops 4. Fill the last row — see ...auto-grow triggered + growTable 5. Click Save — see ...btnSave clicked + ...saveData 6. Click Test Data — see ...loadTestData + ...btnSave + ...saveData 7. Click Print — see ...btnPrint + ...beforeprint + N inputs + ...afterprint 8. Click Export Summary — see ...Export Summary: building plain-text trail
Session 10 added console.log() breadcrumbs to the app’s code. The teacher then asked whether the technique should also appear in aboutFollowTheLeader.html — the novice-facing companion page. This session documents that addition and the reasoning behind it.
This breadcrumb idea seems like such an important concept, especially in the beginning of a novice’s training, that it should be mentioned in the ‘aboutFollowTheLeader’ to get it on a novice’s radar as to something they should do, sooner rather than later. Am I right about this? If so, let’s weave it in.
The teacher’s instinct is correct, and the reasoning is straightforward: aboutFollowTheLeader.html is aimed at students who have never looked at source code. That is exactly the audience who benefits most from learning the breadcrumb technique early — before they have a broken program to debug and no vocabulary for locating the failure.
The placement also benefits from a semantic hook available nowhere else in the ecosystem. The page is already about Follow the Leader, a form whose central metaphor is leaving breadcrumbs as you navigate. A reader who has spent five minutes with the trail form has already internalised the word “breadcrumb” as “a record of where I went.” Translating that directly to console.log() — “a record of what the program did” — requires no new metaphor. The connection is immediate and sticks precisely because it arrives at the moment when the word already has meaning.
The 6th DevTools experiment makes the addition demonstrable rather than theoretical: the app now has live breadcrumbs, so “click Test Data, watch the trace” is a three-second proof rather than an abstract promise. Building the habit before a bug appears is the correct pedagogical sequence: students who learn the tool in a working, visible context will reach for it instinctively when things go wrong.
Session 11 build complete:
aboutFollowTheLeader.html (three additions):
1. Tip box added after the debounce tip:
“Bonus concept — console breadcrumbs”
Explains console.log(), connects the two meanings of breadcrumb,
links to Ask Copilot Entry #039, shows specific messages to look for.
2. Vocabulary chip added to terms-grid:
console.log() — defined using “breadcrumb” as the primary analogy.
3. Sixth DevTools experiment added to Try It Yourself:
Click Test Data → watch loadTestData → btnSave → saveData trace.
Click Print → watch beforeprint report substitution count.
followTheLeaderChatlog.html:
Session 11 added Decision documented: 36
Total sessions: 11 | Total design decisions: 36