Building Tool Time

Adventures are feature-focused (activities about TNT itself). Tool Time is code-quality focused (external novice code improved by AI). Mixing them would dilute both. A clean separate card on the home page, its own subdirectory, its own color identity — confirmed in Session 1 and never revisited.

The triple-layer pun — Home Improvement reference, Tool Time format, Al = A.I. — became the organizing metaphor for the entire venue. Tim is the novice (everyone). Al is the AI sidekick. The workshop is the code. Everything else flows from this.

The TNT snapshot confirmed what intuition suggested: no structured entry point for first-time students exists anywhere on the site. Tool Time’s short code + visible SPARK process + modeled improvement is exactly that on-ramp. This elevated the project from “fun addition” to “fills a documented need.”

Of seven naming candidates analyzed (Tool Time, The Workshop, Al’s Corner, More Code Power, The Upgrade Shop, SPARK Shop), “Tool Time: AI Edition” won because it names the format (a show about improving things), not just the content. It works for a visitor who has never heard of the show, and rewards the one who has.

An <a> element cannot legally contain another <a> element. This is one of HTML’s oldest and most commonly broken rules. The fix — using a div with click/keyboard handlers for the outer wrapper — is the standard workaround for “card that is clickable but also contains inner links.”

Cross Training’s entry cards solved this same problem and the solution was already in the codebase. Good developers reuse patterns they’ve already solved — and good AI users think to ask “have I seen this before?”

Other destination cards use opacity: 0.5 on the background image. Tool Time’s card uses opacity: 0.72 — a deliberate exception because the image is doing pedagogical work: Tim and the AI robot are the entire story of the venue at a glance. Muting that story to match grid convention would be the wrong trade. A custom body gradient (rgba(17,10,2,0.93) → rgba(100,45,5,0.18)) keeps the text readable while the image breathes at full warmth behind it.

Placement: immediately after Dept. of Innovation and before S.P.A.R.K. Speeches. Both neighbors are pedagogy-focused (course guide; student presentations). Tool Time fits naturally between them as the applied practice layer: learn the courses → watch SPARK in action on real code → present your own SPARK journey.

Three placement options were considered:

• Expand the principle cards (right column of “What is Tool Time?”) — rejected: would crowd the existing four principles and dilute both.
• Inline callout in the body copy — rejected: CRAFT deserves full visual treatment, not a parenthetical box.
• New section between Entry Gallery and S.P.A.R.K. links — chosen: restores the light→dark→light→dark alternating rhythm and positions CRAFT as the natural bridge between “here are the entries” and “here’s where to learn more.”

Framing: “Tim always had the tools in front of him. The difference between Tim and Al wasn’t the drill — it was knowing how to use it.” This opening ties CRAFT to the venue’s metaphor directly rather than introducing the acronym cold. The R card reads “Cast your Al” — a deliberate nod to the Al = A.I. pun that rewards close readers.

No third button. Instead:

1. Hero text-nudge — a small amber-on-translucent line below the two buttons: “🔧 New to prompting? Meet your five C.R.A.F.T. tools ↓” Fades from dim to amber on hover. Clearly subordinate; not competing.
2. “Your turn” callout link — the existing callout box in the What section gains one closing sentence: “Not sure how to write that first prompt? Meet your five C.R.A.F.T. tools ↓” Contextually placed at the exact moment the visitor is thinking about prompting.

This preserves the two-button hero hierarchy, adds zero visual noise, and creates two distinct entry paths to CRAFT for visitors at different scroll depths.

Four design decisions worth noting:

1. Hero image: the Tool Time AI-generated photo. Not a Home Improvement still (copyright risk) but our own generated image — Tim with the drill, Al the robot in red flannel. It tells the whole story and is entirely TNT’s own asset.
2. Amber palette throughout. The iRobot page uses I,Robot’s steel-blue. This page uses Tool Time’s amber #E8862A consistently. The color signals which TNT venue this clip belongs to before the visitor reads a word.
3. Tim vs. Al comparison cards. Instead of a plain text explanation of the TNT connection, a two-column comparison grid (Tim’s side in warm red, Al’s side in amber) makes the parallel visual and immediately scannable.
4. Clip descriptions flagged as TTG-to-update. A <!-- TTG: update clip-label and intro paragraph --> comment marks both clip sections. The structure is complete; only the scene-specific context needs filling in once the clips are confirmed.

Per-app chatlogs, in each entry’s folder, starting with Entry #2. Rationale:

• Different readers, different questions — venue vs. entry
• Scale: 20 entries × detailed chatlog = unmanageable main document
• Navigation: the entry chatlog is a natural companion to the entry page, one link away
• Self-containment: each app folder holds everything about that app

The main Tool Time chatlog will note this transition: “Starting with Entry #2, app-specific development logs live in each entry’s folder. See jacksonIrisChatlog.html in JacksonIris/ for the Entry #1 model.”

Root cause: #hero in jacksonIrisStyles.css used display: flex; align-items: center (vertical centering only) but was missing text-align: center (horizontal text centering). The exemplar (iRobot) never set display:flex on the hero — it used simpler layout and relied on .hero-content from tnt-base-styles.css. When the Jackson hero added flex for vertical alignment, it deviated from the exemplar without carrying over the text-align that the base styles had been providing.

Fix: Two properties added to #hero in the shared stylesheet:

justify-content: center;
text-align: center;

Why one fix covers two pages: Both jacksonIrisOriginal.html and jacksonIrisChatlog.html link to the same jacksonIrisStyles.css. Shared stylesheets mean shared fixes — and shared bugs. This is why the shared-style architecture was the right call.

The Home Improvement movie clips are a venue-level hook, not an entry-level element. The connection works like this:

• The Tool Time home page explains the Tim/Al/A.I. metaphor and links to the movie clips — that is the right place for that context.
• The Tool Time chatlog documents the clips as the venue’s founding hook — also the right place.
• Individual entries are about a specific student’s code. The clip connection is irrelevant once a visitor is inside an entry. Adding it there creates navigation noise without adding value.

For all future entries, the back bar standard is: ← Tool Time Home  |  Entry Chatlog  |  (optional: any entry-specific companion link). No Home Improvement clip link.

The base styles already define #hero { text-align: center } — so every page that loads tnt-base-styles.css gets text centering in the hero for free. But that is not what is failing.

The problem is .hero-content { max-width: 820px } with no margin: 0 auto. Here is the full nesting chain:

<section id="hero">              ← text-align: center (from base styles)
  <div class="container">        ← full-width Bootstrap block
    <div class="hero-content">    ← max-width: 820px, but LEFT-aligned!

On wide screens where .container exceeds 820px, the .hero-content box starts from the LEFT edge and only fills 820px of the available width. Text inside it is centered within that left-positioned box — so the text is technically centered in its container, but the container itself is stuck against the left margin. Visually: left-aligned.

margin: 0 auto is what centers a block element horizontally within its parent. Without it, max-width: 820px constrains the width but does not move the box to the center of the page.

Updated in both jacksonIrisStyles.css and seanWeightlifterOriginalStyles.css:

/* BEFORE (broke on wide screens) */
.hero-content { max-width: 820px; }

/* AFTER (correct) */
.hero-content {
    max-width: 820px;
    margin: 0 auto;       /* centers the box within .container */
    text-align: center;   /* centers text within the box */
}

Two properties, two different jobs: margin: 0 auto positions the block; text-align: center positions the text within it. Both are required.

C.R.A.P. is a four-principle design framework used in graphic design, UI design, and document layout. It stands for:

Quick rule of thumb: If something looks “a bit off” in your layout, it is usually a C.R.A.P. violation. Ask: is the contrast too weak? Is something inconsistently styled? Is an element misaligned? Is something placed far from what it describes?

The before: Each card had an emoji icon floating over the thumbnail image. This violated Proximity — the icon identified the entry content, but it was placed adjacent to the artwork rather than beside the entry label it belongs to. For Jackson’s eye sketch the icon happened to reinforce the image; for Sean’s weightlifter artwork it actively competed with it.

The fix: Move the icon to sit immediately to the left of the Entry #N / Title stack — exactly the pattern Creative Cross Training uses (cct-entry-header). Now the icon, entry number, and title form a visual unit that reads left-to-right as a single piece of identifying information.

Which C.R.A.P. principles this satisfies:

• Proximity — the icon and its label now live together, creating a clear header unit
• Alignment — icon and text are vertically aligned on a flex baseline
• Repetition — every card now has the same header structure: icon | entry# / title. Consistent across all entries.
• Contrast — the artwork (thumbnail) and the entry identity (header) are now visually separated and serve distinct purposes

The <pre> code blocks in Sessions 14 and 15 were styled with color: rgba(255,255,255,0.80) (near-white text) and background: rgba(255,255,255,0.04) or rgba(232,134,42,0.07) (nearly transparent backgrounds). On a dark page those colors work. On this chatlog’s warm cream body (#f8f4ef), both backgrounds render as cream — and white text on cream is invisible.

The same error appeared on three data tables styled with color: rgba(255,255,255,0.82).

Root cause: The AI generated these color values thinking in terms of a dark-background page (the per-entry chatlogs use dark backgrounds). The main Tool Time chatlog uses a light background. The AI did not check the rendering context before assigning text colors — and did not notice the mismatch. TTG did.

Code blocks: Changed to background: #1c1208 (dark warm) with color: #fbbf24 (amber). Dark background + warm amber text = high contrast code display consistent with the Tool Time palette.

Tables: Changed color: rgba(255,255,255,0.82) to color: #2d1b04 (dark brown) — inherits the page’s dark text convention and reads clearly on the cream background.

Mojibake (from Japanese: “garbled character”) is what happens when text encoded in one character encoding is read and displayed using a different one. In this case:

1. The chatlog had correctly encoded UTF-8 emoji (e.g., 💡 LIGHT BULB, stored as bytes F0 9F 92 A1).
2. A PowerShell Set-Content command re-saved the entire file. PowerShell’s default encoding on this system read those bytes as Windows-1252 (CP1252), treating each byte as a separate character: F0→ð, 9F→Ÿ, 92→’, A1→¡.
3. Those Latin characters were then saved back as UTF-8, permanently encoding the wrong characters. What was 💡 became ðŸ'¡ in the file.
4. A UTF-8 BOM (Byte Order Mark, EF BB BF) was also prepended by Set-Content -Encoding UTF8, which can cause further rendering issues.

The PowerShell command that caused it: The table-color fix in Session 16 used Get-Content $path -Raw (which read with the wrong encoding) followed by Set-Content $path $fixed -Encoding UTF8 (which saved with BOM and preserved the corrupted content).

Because the corruption was complex (four distinct mojibake patterns, some with undefined CP1252 bytes stripped at different stages), three Python fix passes were required:

• Pass 1: Stripped the BOM, replaced 692 direct Unicode characters (bullets •, em-dashes —, nbsp) with HTML entities.
• Pass 2: Computed the CP1252 mojibake form for each emoji and replaced 201 garbled sequences (check marks, warning signs, em-dashes in text, arrows, pencil icon).
• Pass 3: Handled 8 truncated sequences where an undefined CP1252 byte had already been stripped (the 4th byte of 🔍 and the 3rd byte of ←).

Result: Zero suspect characters remaining. All emoji are now HTML entities (encoding-neutral) and the file has no BOM.

Rule 1 — Never use Get-Content / Set-Content on HTML files. This single command is the root cause of every mojibake session we experienced. Any time a bulk string replacement must happen in PowerShell, use the safe pattern instead:

$txt = [System.IO.File]::ReadAllText($path, [System.Text.Encoding]::UTF8)
$txt = $txt -replace 'old-pattern', 'new-value'
[System.IO.File]::WriteAllText($path, $txt,
    (New-Object System.Text.UTF8Encoding $false))
# The $false = no BOM. Bypasses PowerShell's encoding layer entirely.

Rule 2 — Use the edit tool for all file modifications. The AI’s built-in edit tool handles encoding correctly and never touches PowerShell’s encoding layer. PowerShell is only needed for bulk multi-line replacements — and even then, use Rule 1.

Rule 3 — Write emoji as HTML entities from the start. 🎯 survives any text-processing pipeline. A direct 🎯 in source code does not. Every Tool Time chatlog session uses HTML entities in SPARK banner icons for exactly this reason.

If mojibake ever appears again in any TNT HTML file, give the AI this single prompt and nothing else:

The vibe code phrase:

"Fix UTF-8 mojibake in [filename]. Strip BOM,
replace all direct emoji and special characters
with HTML entities, remove all C1 control
characters (U+0080–U+009F), and save as
UTF-8 without BOM using Python."

That phrase contains every piece of information the AI needs to generate the correct fix script in one pass:

• “Fix UTF-8 mojibake” — names the problem type precisely; triggers the correct diagnosis path
• “Strip BOM” — addresses the UTF-8 Byte Order Mark that Set-Content adds
• “Replace emoji/special chars with HTML entities” — the encoding-neutral fix that survives any future pipeline
• “Remove C1 control characters (U+0080–U+009F)” — kills the invisible residue left by undefined CP1252 bytes like 0x8F
• “UTF-8 without BOM using Python” — specifies the safe write method that skips PowerShell’s encoding layer

TTG’s observation is exactly right, and the phrasing “I’m embarrassed I just noticed” is worth examining: the prompts are the human side of the AI-human conversation. Without them, a chatlog is a monologue — Copilot talking to itself. With them, it’s a record of a real collaboration that novices can study, pattern-match against, and improve upon.

Specifically, prompts serve three functions that the Copilot analysis alone cannot:

1. They are the model for novice prompting. Seeing what TTG asked — and being able to critique it — is the entire pedagogical point of the chatlog critique boxes.
2. They make the record honest. What was the human’s role? What did they decide vs. what did the AI suggest? Without the prompt, the record suggests Copilot operated autonomously. It didn’t.
3. They anchor the K-Know takeaways. Advice like “name the task” or “attach the context” has no example to point to without the actual prompt in front of the reader.

Every session in every app-level chatlog must include TTG’s prompt in a chat-turn bubble-user element. Applied retroactively to:

• JacksonIris/jacksonIrisChatlog.html — Session 1 initiating prompt added; Sessions 2–3 marked as “continuation of Session 1”
• SeansWeightlifter/seanWeightlifterChatlog.html — Session 1 initiating prompt added; Sessions 2–3 marked as continuation; Session 4 editor-error prompt added

For all future app entries: The session with the initiating build prompt comes first, before any analysis or decision boxes. If a session was generated as a sub-analysis of the same prompt (no new user input), mark it explicitly as “Continuation of Session N — no separate prompt.” Never leave a session without clear attribution of where the direction came from.

Two placements, both woven rather than appended:

1. Callout box in “What is Tool Time?” — full-border amber box after the “Your turn” callout, with the vibe-code-talent-recruiter framing and a direct link. Lives in the light section where first-time visitors read the explanation.
2. Featured full-width card in the S.P.A.R.K. cross-links — below the 2×2 grid of link cards, spanning the full column width with enlarged icon and emphasized text. Visible to visitors who have scrolled through the entries and are looking for depth.

The mojibake illustration in Session 17 used ðŸ'¡ to show the garbled form of 💡 (the 💡 emoji). Three of the four entities are valid. One is not.

The conceptual trap: When Windows-1252 decodes byte 0x9F, it displays the character Ÿ (U+0178, LATIN CAPITAL LETTER Y WITH DIAERESIS). But HTML5 numeric references map directly to Unicode code points — and Unicode code point U+009F is a C1 control character, not Ÿ. The byte and the code point share the same hex number, but they are in completely different encoding systems.

The fix: Replace Ÿ with Ÿ (U+0178 = Ÿ). This represents the character that actually appears when Windows-1252 decodes byte 0x9F, which is the correct character for the mojibake illustration.

The rule: HTML5 forbids numeric character references in the range U+0080–U+009F (the C1 control block). Never use € through Ÿ as HTML entities. Use the corresponding Windows-1252 character’s actual Unicode code point instead if you need to display it.

The critique across 26 sessions has flagged a missing “deliverables list” as a recurring weakness. TTG’s challenge forces a cleaner definition of what that actually means. There are two different things that could be required:

The corrected rule: A deliverables specification is complete when all expected outputs are named and the AI can identify each one unambiguously. A numbered list is the clearest format — but it is not the only valid format. Session 26 met the substance of the requirement, even without the canonical format.

The A−→A upgrade is warranted. The deliverables were present. The critique was penalizing a stylistic preference, not a genuine gap. If a prompt names every output and the AI produces every output without a follow-up round, the deliverables specification was sufficient. Session 26 qualifies.

The brownish haze comes from opacity: 0.28 on .tt-entry-thumb-bg in ToolTime/styles/toolTimeHomeStyles.css. At 0.28, 72% of the dark warm-brown card background (#2a1d0b) bleeds through the artwork. The hover rule lifts it to opacity: 0.52.

Tuning range (with hover at 0.88–0.92 for meaningful contrast):

Design principle: The hover lift only reads if the resting state has meaningful headroom. A default of 0.65–0.72 with hover at 0.90 gives both vivid art at rest and a clear response on hover.

None of the seven challenges dispute the core idea. What they challenge are its boundaries and preconditions:

The pattern is consistent across the entire site. Every venue on TNT was worth a news announcement at launch; no individual piece of content inside a venue is worth one.

Tagline: “You look at it and see a poster. Learn to look at it and see display:flex; font-weight:900; background:#000.”

Concept: The Matrix red-dress monologue as a curriculum. Every image is two things: what a human eye sees and what a browser renders. The venue teaches the transition — the moment when a student stops seeing the picture and starts seeing the layout, the typography rules, and the box model beneath it.

Format: Image on the left, live HTML/CSS render on the right. The gap between them is the lesson. Students iterate until the gap closes. Gallery provides source images; a 🔨 “Build It” badge marks images that have live “See the Code” entries.

Tagline: “The gallery shows you the picture. The Reverse Gallery shows you how to build it.”

Concept: The image gallery is already built. Reverse Gallery is its active companion — each gallery modal gets a “🔨 Build It” link when a challenge entry exists. The gallery becomes a navigation surface; the workshop is behind every image.

Why it works: No new navigation item required for the source images. Turns the existing passive gallery (view) into an active practice venue (build). Launch with 3–4 entries; the gallery badge grows over time.

Tagline: “Real designers build posters. You’ll build them without Photoshop, without Canva, and without a single image file.”

Concept: Scoped specifically to typographic posters — the gallery category with the most CSS-eligible images. Teaches font-weight, font-family, letter-spacing, text-transform, flexbox, color, and border-bottom through real poster recreation. Entry #1: Zero Talent. Entry #2: “Fonts Matter” — a poster about fonts, recreated with CSS fonts. The meta-quality is irresistible.

Why it works: Narrow scope, learnable skill set, concrete success criterion. 8–10 gallery images are immediately eligible.

Tagline: “In the real world, your boss emails you a screenshot. Your job is to build it. This is that class.”

Concept: Frames image-to-code as the professional front-end skill it is. Matching a design spec (Figma, Zeplin, a screenshot) is what junior developers do on Day 1. Blueprint teaches it through gallery images used as “design specs.” The CRAFT framework is built directly into the process — Context (describe the image), Role (front-end developer), Action (build this spec), Form (HTML + CSS), Tight Constraints (no JS, no image tags).

Best for: The hiring-skills angle. Connects image-to-code to industry reality rather than academic exercise.

Tagline: “Every image has a poem written in HTML and CSS. Your job is to find it.”

Concept: A more artistic framing — students are translating, not copying. Natural difficulty tiers emerge: Haiku (~20 lines, typographic poster), Sonnet (~50–80 lines, moderate layout), Epic (100+ lines, complex design). The tier system creates a progression ladder without a formal curriculum. Zero Talent is a Haiku; Mission Venn (CSS circles) is a Sonnet; The Mandelbrot Set is an Epic.

Best for: Students who respond to creative/artistic framing over technical framing.

Scene: Tank (or Cypher) watches the code cascade and says: “I don’t see blonde, brunette, redhead anymore. I just see the code.” About 90 seconds. No violence. Widely available.

Why it’s the right hook: The metaphor is exact. The scene is literally about learning to see beneath surface appearance to the underlying structure — which is precisely what this venue teaches. A student learning to see font-weight: 900 when they look at a bold poster headline is doing exactly what Tank describes. The clip is culturally iconic; students know it and respond to it.

Alternative: The Paycheck (2003) clip already in TNT — Michael Jennings reverse-engineering from visual artifacts. Weaker metaphor but no new clip acquisition needed.

The original Java source contains System. out.println with a space between System. and out. This is a genuine compile error that Java will flag immediately. Rather than fix it silently, the entry preserves the bug exactly and calls it out in a prominent red warning box. Students who copy and paste into JDoodle experience the error first-hand, find it, fix it — and are unlikely to make the same mistake again. Real discovery beats being told every time.

The entry chatlog includes three ready-to-use C.R.A.F.T. prompt starters for students:

1. Fix + explain main: Find the compile error, explain every word of public static void main(String[] args), and produce a hardcoded version for JDoodle.
2. ArrayList with no-duplicates: Refactor to ArrayList<String> using .contains() before .add(); add Shemp; test duplicate guard.
3. Add a Scanner: Accept keyboard input in a while loop with a sentinel; add names only once.

The HTML structure has two separate Bootstrap row divs inside the entries section:

<!-- Row 1 — got the id; contains Entries #1–3 -->
<div class="row g-4" id="ttEntryGrid">
    ...entries #1, #2, #3...
</div><!-- /row (after Entry #3) -->

<!-- Row 2 — no id; contains Entries #4–7 -->
<div class="row g-4 mt-0">
    ...entries #4, #5, #6, #7...
</div>

The filter JavaScript used '#ttEntryGrid .tt-entry-col' as its selector. This only queries inside the first row div (the one with the id). The second row has no id, so its four entries are completely invisible to the query — they will never be counted, searched, or filtered.

The fix — one word: Change #ttEntryGrid to #ttEntries in the JavaScript selector. #ttEntries is the parent <section> element that wraps both rows. The selector '#ttEntries .tt-entry-col' finds all entries regardless of which row they live in.

// Before — only sees 3 entries (first row only):
var cols = Array.from(document.querySelectorAll('#ttEntryGrid .tt-entry-col'));

// After — sees all 7 entries (both rows, via section parent):
var cols = Array.from(document.querySelectorAll('#ttEntries .tt-entry-col'));

The lesson: When you add a targeted search/filter to a page, the query selector must scope to the highest reliable container, not a specific inner element. The section tag (#ttEntries) is stable — it will always wrap all entries regardless of how many internal rows are added. A specific row div is fragile — it only covers entries added to that row. This is a case where the infrastructure break was planted by an implementation detail of how early entries were grouped into separate rows as they grew.

The filter code compared the active filter value against the data-langs string using String.indexOf():

var langs  = 'p5js javascript';          // ← data-langs value for Entry #1
var langOk = langs.indexOf('java');       // → returns 5 (found as SUBSTRING of "javascript")
// Result: Entry #1 matches the 'java' filter — incorrect!

indexOf() checks for the presence of a substring anywhere in the string. The string 'java' exists inside the string 'javascript' at position 0. So every entry tagged javascript also matched java. The JavaScript filter worked correctly in the other direction because 'javascript' is NOT a substring of 'java' — the asymmetry made it invisible until Java entries existed.

The fix — split into tokens and compare exactly:

// Before — substring match: 'java' found inside 'javascript'
var langs  = (col.dataset.langs || '').toLowerCase();
var langOk = currentLang === 'all' || langs.indexOf(currentLang) !== -1;

// After — token array: check for exact whole-word match
var langs  = (col.dataset.langs || '').toLowerCase().split(/\s+/);
var langOk = currentLang === 'all' || langs.indexOf(currentLang) !== -1;

split(/\s+/) converts the string 'p5js javascript' into the array ['p5js', 'javascript']. Array.indexOf('java') then checks for an exact element match — 'java' is not in that array, so it correctly returns -1. Entry #6’s data-langs="java" splits to ['java'], which does contain 'java' exactly.

The lesson: String.indexOf() is a substring search — it will find 'cat' inside 'concatenate'. When you need to check for whole tokens in a space-separated list, always split first and use Array.indexOf() for exact element comparison. This same class of bug affects CSS class checks ('btn' found inside 'btn-primary'), tag matching, and any token-list filter built with string search.

Python 3 (data-lang="python3") — added as a dimmed future button (tt-future). This distinguishes standalone Python 3 programs (scripts, data work, command-line tools) from Python Processing entries, which use the Processing IDE’s Python Mode and are tagged python. Both coexist in the filter strip; neither is a substring of the other, so the token-split fix from Session 39 keeps them cleanly separated.

Other (data-lang="other") — added as a full-opacity button (not dimmed), because it is a permanent utility category, not a future language placeholder. Any entry that genuinely defies the existing language classifications gets data-langs="other" and will be found only by this button. Currently returns zero results, which is the expected honest behavior. To use it: add other to an entry’s data-langs attribute.

The single most important factor: discoverability. A filter strip shows all available options simultaneously without any interaction. A visitor to the Tool Time home page sees instantly that there are Java, Python, and p5.js entries — before they touch anything. With a dropdown, those categories are hidden behind a click. Users who do not know they exist will not look for them.

The second factor: active state visibility. When a filter button is active, it glows in the amber Tool Time palette. The currently active filter is visible from across the room. With a dropdown, you must read the selected value inside the control to know what filter is active — a small friction that compounds when you switch filters rapidly.

Context also mattered: this section has one primary interactive feature (filtering entries). When filtering is the main job of a UI zone, the filter controls should have presence on the page — they should communicate “this is something you can do here” without requiring the user to discover the affordance. The askCopilot select menu works because filtering is one of many things on that page, space is tight, and the topic list is long (50+). Here, the filter is the hero of the section and the option count is small enough to show all at once.

Rule of thumb: use buttons when options are ≤12, always-visible, and filtering is the primary interaction. Use a dropdown when options exceed ≈15, space is tight, or filtering is one of many competing controls.

TTG noted they “weren’t following CRAFT very well” because the prompt gave no Form constraint for what the filter UI should look like. This is a good self-catch. “A search/filter option like we’ve used on the processing page” references text-search only (the processing page has no filter buttons). “Like the image gallery page” would have pointed at type-filter buttons. Because both exemplars were named and the processing page search was listed first, either interpretation was defensible — the button strip was chosen because it better matched the gallery pattern and the Tool Time context. Specifying “pill-style toggle buttons matching the amber palette, consistent with the gallery’s DWR/Eureka buttons” would have guaranteed the desired shape with zero ambiguity.