S.P.A.R.K. with AI — Development Dialog

Renovating the Hot Seat Spinner

From a legacy classroom app to a TNT SPARK Edition —
what changed, what didn’t, and why every decision matters.

For Students — How to Read This Page

This log documents the session that renovated a working classroom spinner app from a legacy Bootstrap structure into the 2026 TNT SPARK ecosystem. The focus is on how decisions were made — which parts to preserve exactly, which to change, and why a classroom tool warrants a different visual approach than the other TNT apps.

Watch for Prompt Critique boxes (amber) and Design Decision boxes (teal). The code is a side effect of these decisions.

klp

I copied legacy code for this app and provided these files for us to retrofit into our new TNT ecosystem. The originals that were copied are still in the folder along with these others if that helps. This is a p5js application that I use nearly everyday in class to call on students for their responses. It works fairly well but I’m sure there could be improvements. I’m thinking that a more ‘light and bright’ look is favorable in this case since I want an upbeat, energetic feel. We’ll want to create a file: classDialSPARKChatlog.html to chronicle our renovations. We’ve done similarly with other apps. I have included the slotmachine app for your reference. Let’s start with adjusting the SPARK1.html file (and maybe the Sketch1 file) to fit into our framework, and begin our SPARK chatlog.

Prompt Critique — A Strong Renovation Opener

This is a well-formed renovation prompt for several reasons:

Stakes stated upfront — “I use nearly every day in class” immediately signals that broken functionality is not an option. This is the most important piece of context a developer can receive.
Direction, not prescription — “light and bright” communicates a feeling, not a hex code. This gives the developer space to make good choices that serve the intent.
Reference material provided — including the Slot Machine app gave the AI both the ecosystem standard (navbar, hero, footer patterns) and a contrast point (dark theme to diverge from).
Explicit deliverable named — asking for the chatlog as part of the work, not as an afterthought.

The only thing that would make it stronger: specifying which parts of the app work well and should be preserved. “The sketch logic is solid, touch the HTML shell only” would have been a precise constraint. As it stands, the AI had to read both files carefully before deciding what to preserve.

GitHub Copilot

After reading both files and the Slot Machine reference, here is the analysis:

classroomDialSPARK_Sketch1.js — preserve entirely. The sketch is mature, well-commented, and complex. It handles multi-class management, localStorage persistence, selection history, absence tracking, confetti celebration, and the p5.js wheel rendering. Touching it risks introducing regressions into logic that has been field-tested across many classroom sessions. The only legitimate change would be cosmetic (font family in injected HTML) and that can be handled by CSS overrides instead of script edits.

classroomDialSPARK1.html — substantial renovation. Currently uses a legacy Bootstrap navbar, a jumbotron-style hero, Dancing Script / Dosis fonts, inline <style> blocks, and a footer embedded inside <main>. All of this can be replaced with the TNT ecosystem patterns without touching the sketch at all.

Recommended approach: create styles/classroomDialStyles.css with the light & bright palette, replace the HTML shell (head → navbar → hero → footer → scripts), and leave the sketch untouched.

Design Decision — Read Before Touching Anything

The most common renovation mistake is starting to edit code before reading it. In this case, reading the sketch revealed that it dynamically builds its own UI inside the HTML shell — the controls panel, the intro bar, the result display are all created by JavaScript. The HTML file only needs to provide the correct container IDs (r1c1Div, r1c2Div, introDiv). Everything else is the sketch’s responsibility.

If the HTML renovation had been done without reading the sketch first, there was a real risk of adding placeholder content to those containers, which the sketch then overwrites — or worse, accidentally renaming an ID the sketch depends on. Read-first discipline caught both of those risks before any code was written.

The Light & Bright Decision — When to Diverge from the Design System

GitHub Copilot

The TNT standard palette is dark — #0a0e1a body, dark heroes, charcoal-to-black game cards. That works well for after-hours browsing, gaming apps, and cinematic demos. A classroom projection context has different requirements:

Projector brightness — projectors lose significant luminance in lit rooms. A white background reflects ambient light; a dark background absorbs it, making content harder to see from the back of the room.
Energy and tone — the spinner is used for student participation. The visual feeling should be exciting and welcoming, not the tension of a dark casino interface.
The wheel itself is already maximally colorful — fifteen saturated segment colors on a 600px canvas. A dark surround would compete with those colors; a light surround frames them.

Design systems should be followed until there is a clear reason to diverge. Here there are three clear reasons. The divergence is intentional, not accidental.

Design Decision — Adapting, Not Abandoning, the Design System

The light/bright theme does not abandon the TNT design system. It adapts it:

The navbar stays dark (#0a0e1a with red border) — TNT brand is consistent.
The footer stays dark — TNT brand is consistent.
The Boogaloo / Inter font pairing replaces Dancing Script / Dosis — TNT brand is consistent.
The hero uses a light overlay on the spinner image instead of a dark one — intentional departure.
The app section uses a light blue-tinted background and white cards — intentional departure.

The rule: TNT brand elements (navbar, footer, fonts, color tokens) stay consistent. Page-level tone (hero overlay, body background, card colors) adapts to the app’s context and audience. A classroom projection tool gets a bright classroom feel. A slot machine demo gets a dark casino feel. Both are correct for their purpose.

What Changed — The Renovation Inventory

GitHub Copilot

Here is the complete change inventory for classroomDialSPARK1.html, with the reason for each change:

Head section:

Removed inline <style> block — inline styles fight the stylesheet cascade and hide design decisions. All styles now live in classroomDialStyles.css where they can be inspected, overridden, and documented.
Replaced Dancing Script + Dosis with Boogaloo + Inter — TNT brand font pairing. Dancing Script reads as personal/calligraphic; Boogaloo reads as energetic/playful, which better matches the spinner’s purpose.
Added Font Awesome 6.5 — consistent with other TNT SPARK apps; provides the icon language used in the hero and footer.
Replaced site-styles.css with ../styles/tnt-base-styles.css + styles/classroomDialStyles.css — ecosystem standard.
Removed stageNoStr variable — stage numbers belong in legacy shell apps. SPARK editions are not “at a stage”; they are the destination.

Navbar:

Replaced the white navbar-light spinner-brand nav with the TNT dark #mainNav pattern — consistent with all other TNT SPARK apps. The spinner icon and local nav links (Chat Log, Generic Spinner) were removed from the nav; they belong in the About section or a dedicated index page, not the primary nav.

Hero:

Replaced the jumbotron div with a proper <section id="hero"> using the TNT hero pattern — semantic HTML and consistent structure.
Used the existing cpSpinner.jpeg as the hero background with a light pastel overlay — the image was already in the folder; it is the right image for this app.
Moved the loading indicator into the hero — the previous “…loading…” paragraph was a standalone element between the hero and the content. Moving it into the hero means there is never a flash of empty space.

Footer:

Moved footer outside <main> — the original used the Bootstrap flexbox sticky-footer pattern (footer inside a min-vh-100 flex main). The TNT ecosystem uses the footer-after-main pattern with the dark <footer> element. Both work; the TNT pattern is simpler and more consistent.
Updated icon paths to ../images/ — the old footer pointed to the local images/ folder. The TNT icons live at the site level.

Scripts section:

Simplified init() — removed console.log calls and collapsed redundant variable declarations. Same functionality, less noise.
Added linkGuard.js — site-wide script that prevents broken link issues on localhost.

The Hero Image — Using What’s Already There

GitHub Copilot

The images/ folder contained cpSpinner.jpeg — a colorful, classroom-themed spinner background that had been used in the legacy stylesheet for the jumbotron. It is exactly the right image for the hero: it communicates the app’s purpose, it is full-color, and it already exists in the project at the correct path.

For the light/bright theme, the overlay gradient becomes critical. The Slot Machine uses a dark overlay (rgba(10,6,26,0.72)) that makes the image essentially background texture. The spinner hero uses a pastel overlay (rgba(255,255,255,0.60) to rgba(200,255,210,0.55)) that lets the colorful image show through while keeping text readable. This is not just a lighter opacity — it is a different technique: mixing with white instead of mixing with dark.

The resulting hero reads as bright and energetic, with the underlying spin-wheel imagery subtly visible. Exactly the right feel for a classroom participation tool.

Design Decision — Dark Overlay vs Light Overlay Technique

Two fundamentally different overlay techniques produce two completely different results from the same background image:

Dark overlay: rgba(0,0,0,0.75) — image becomes dark texture, white text is readable, mood is dramatic/cinematic. Used by Slot Machine.
Light overlay: rgba(255,255,255,0.60) — image lightens toward pastel, dark text is readable, mood is airy/energetic. Used by Hot Seat Spinner.

The light overlay technique also requires inverting the text colors: where the dark overlay uses white titles (color: #fff), the light overlay must use dark titles (color: var(--tnt-dark)). This is why the app stylesheet explicitly overrides #hero .hero-title and #hero .hero-subtitle — the base styles default to white text for dark-background heroes.

Overriding base styles this way is intentional and correct. The base styles define the default; the app stylesheet defines the exception. This is exactly what CSS specificity and the cascade are designed to support.

Post-Session — Icon Choice & Cross-Listing

klp

We’ll need a card in the js_apps.html document to link to this new app. I provided a ‘fortune-wheel’ image that works well. In fact, I’d like to use it in our app instead of the circular loading symbol provided by Font Awesome. Let’s adjust our chatlog accordingly for these inclusions.

Prompt Critique — Image-First Icon Selection

This is a good example of the right order of operations: the user had an image that communicates purpose (this is a spinner app) and chose it over a generic icon that communicates state (loading / spinning). The Font Awesome fa-circle-notch was a placeholder during the renovation — it spins, which felt thematically related, but it says nothing about a classroom wheel. The fortune wheel icon says everything.

The secondary request — cross-listing in js_apps.html — was bundled efficiently with the icon change and chatlog update. Three related changes in one well-scoped prompt. This is the right amount of scope for a single request: the changes are related, none is large, and the expected output is clear.

GitHub Copilot

Three changes, all straightforward:

Hero icon swap: Replace <i class="fas fa-circle-notch"> in the <h1> with an <img> pointing to images/noun-fortune-wheel-7308069-FF001C.png. A new CSS rule (.hero-wheel-icon) sizes it to 2.8rem height and aligns it to the text baseline. The red-on-white image reads perfectly against the light hero background and immediately identifies the app as a spinner tool.
JS Apps card: A new <figure> added to #appGrid in js_apps.html, using the same site-level icon at images/noun-fortune-wheel-7308069-FF001C.png. It slots after Ambiguous Message as the newest entry in chronological order, and the page’s lastUpdate is bumped to today.
Chatlog updated: This section documents both decisions.

Design Decision — Purpose-Built Icons vs Generic Ones

Font Awesome is a library of general-purpose icons. Noun Project images are purpose-built for specific concepts. When a purpose-built image is available that directly represents the app, it is almost always the better choice for primary branding — hero titles, app grid cards, and navigation anchors.

The fortune wheel icon does three things the generic circle-notch cannot:

It communicates wheel / spinner specifically, not generically
It matches the icon used in the JS Apps grid card, creating visual consistency between the index listing and the app’s own header
Its red-on-white palette is already TNT-aligned — no filter or tinting needed

The implementation requires one CSS rule: .hero-wheel-icon sets height: 2.8rem and vertical-align: middle. The browser scales the image proportionally to match the heading height. No JS, no sizing math, no external library dependency.

Post-Session — SEO Meta Tags

klp

We need complete SEO information on each of these pages as we did in the magicEightBallIndex and its chatlog; please add this to our chatlog as well.

Prompt Critique — Referencing a Known Standard

Saying “as we did in the magicEightBallIndex and its chatlog” is a precise and efficient way to specify a standard without restating it. It points to a concrete example the AI can read and replicate, which is always more reliable than describing the desired output in prose.

This is a transferable prompting habit: when a pattern already exists in the project, reference it by name. “Match the SEO block in magicEightBallChatlog.html” is unambiguous. “Add good SEO” is not — every developer has a different idea of what “good” means.

GitHub Copilot

Full SEO blocks added to both pages, following the Magic 8 Ball pattern. Each block contains six tags:

description — a human-readable sentence that search engines display as the result snippet. Written to answer the implicit question: “what does this page do?”
keywords — a comma-separated list covering the app name, technology stack, use case, and ecosystem. Less influential for ranking than they once were, but still useful for site-internal search and analytics.
author — TechNoviceTools (TNT), consistent across all TNT pages.
og:type — website. Standard for pages that are not articles or products.
og:title — matches the page <title> element exactly. Used by social sharing previews.
og:url — the canonical URL at technovicetools.com.
og:image — the fortune wheel PNG at the site-level images/ folder. The same image used in the hero and the JS Apps grid card — one consistent visual identity across all surfaces.

Design Decision — One Image, Three Surfaces

The fortune wheel PNG (noun-fortune-wheel-7308069-FF001C.png) now appears in four places for this app:

The hero heading in classroomDialSPARK1.html
The JS Apps grid card in js_apps.html
The og:image in both HTML pages — what social media previews and link unfurlers display when someone shares either URL

This is intentional visual identity work. A student who sees a shared link to the app, a shared link to the chatlog, or the JS Apps index all encounter the same icon. The app has a face, and it is consistent.

The broader principle: choose your representative image early and use it consistently. The og:image is the thumbnail the world sees when your page is shared. It should be the same image that represents the app everywhere else. A generic placeholder or a screenshot of code is not a substitute.

Post-Session — Reclassification & Ecosystem Integration

klp

We need to update the explore and news pages for this classroom dial app. Since it’s a SPARK application, let’s replace the Yahtzee entry on the card with this one (because I use it a lot! keep the Yahtzee of course in the side call out.) This is also a simulation type app, so we need its inclusion there. Also, I just realized a mistake I made: the spinner is better classified as a Processing app rather than a JavaScript app. My mistake. Please move the JS_app card for the dial to the Processing page, and let’s make this entry the first one since I use it so often. Please update, as usual, the chatlog for these corrections and integrations.

Prompt Critique — Owning the Mistake

“I just realized a mistake I made” is exactly the right way to open a correction request. It is honest, clear, and tells the AI exactly how to proceed: not “the app is in the wrong place” (passive, possibly ambiguous) but “I put it in the wrong place” (active, unambiguous). That directness matters because it rules out the possibility that both locations are intentional.

The rest of the prompt is efficiently multi-tasked: classification fix, two ecosystem page updates, priority placement, and chatlog — all in one message. Each item is unambiguous. This is the right scope for a single prompt: related changes, clear expected outputs, no overlap between items.

GitHub Copilot

Five related changes, executed together:

Reclassified JS → Processing. The app is built entirely in p5.js instance mode — the wheel, the controls panel, the confetti, and all DOM construction happen inside the sketch. The HTML shell is a container for p5.js output. A p5.js app belongs in Processing, not JS Apps. The active navbar link on the app page corrected from js_apps.html to processing_apps.html.
Card moved from js_apps.html to processing_apps.html, inserted as the first figure — priority position for a daily-use tool. The fortune wheel icon already existed in the site-level images/ folder so no new asset was needed.
S.P.A.R.K. card on Explore: Yahtzee replaced by Hot Seat Spinner in the three featured slots. Yahtzee remains in full in the S.P.A.R.K. offcanvas. Both cards are correct; the featured slots simply show the teacher’s most-used app.
Simulations + Processing cards and all three offcanvases updated with Hot Seat Spinner as the first listed item.
News entry added as entry #023, above Ambiguous Message PHP, documenting the app’s renovation, its classroom purpose, and the reclassification.

Design Decision — Classification: What Language Does p5.js Count As?

This is a genuine taxonomy question worth settling explicitly. The Hot Seat Spinner is written in JavaScript — all the code in the sketch file is JavaScript. So why is it a Processing app and not a JS App?

The answer is about programming model, not language. The app uses p5.js, which provides a complete Processing-style creative coding environment: a canvas managed by a setup()/draw() loop, drawing primitives (p.arc(), p.ellipse(), p.text()), frame rate control, and coordinate transforms. The code is idiomatic p5.js — it could be translated to Java Processing or Processing.py line-by-line. The language is JavaScript; the paradigm is Processing.

The JS Apps category at TNT is for DOM-based JavaScript — apps where the primary interface is HTML elements (buttons, inputs, tables, modals). The Processing category is for canvas-based work managed by the Processing/p5.js paradigm, regardless of which underlying language implements it.

The rule: if the app’s primary output surface is a p5.js canvas and the code is structured around setup()/draw(), it is a Processing app. If the primary interface is the HTML DOM (Bootstrap cards, modals, input groups), it is a JS App. The Hot Seat Spinner’s wheel, confetti, and segment rendering are all on a p5.js canvas — the DOM is only the container.

Post-Session — Processing Card Curation: The Same Rule, Applied Again

klp

I see our Processing card needs the same treatment. I’d say we keep Pondering; what two others should be kept? Update the chatlog again too, please.

Prompt Critique — Anchoring on a Known Preference

“I’d say we keep Pondering” is a clean way to reduce the decision space before handing analysis to the AI. The user knows their curriculum best — Pondering has direct classroom value (three font-sizing algorithms that students can experiment with side-by-side). Stating that preference upfront means the AI reasons over four options instead of five.

This is a transferable habit: in any multi-option decision, anchor the non-negotiables first, then ask for analysis on the remainder. It produces faster, more focused recommendations because the AI isn’t reasoning about options that are already settled.

GitHub Copilot

Scoring the remaining four against the same two criteria:

App	Student interest	Organization
Hot Seat Spinner	Teacher tool — not a student browse target	Already #1 on S.P.A.R.K. card; first in offcanvas
Magic 8 Ball	Universal recognition, click-to-shake interaction	Sphere algorithm is the most “Processing” content — 50 circles making a 3D illusion
Slot Machine	Immediately playable; emoji themes engaging	Original p5.js app in the 2026 ecosystem; own SPARK chatlog
LightWrite	Stranger Things hook is strong	Hook reads as a simulation first — better foregrounded on the Simulations card

Recommendation: Pondering + Magic 8 Ball + Slot Machine. Remove Hot Seat Spinner (already prominent on S.P.A.R.K. card) and LightWrite (its student appeal is simulation-first). All five remain in the Processing offcanvas.

Design Decision — The Processing Card Represents a Paradigm, Not Just a Language

The three cards kept — Pondering, Magic 8 Ball, Slot Machine — each demonstrate a distinct corner of what p5.js can do:

Pondering — text rendering and font-sizing algorithms. Shows that p5.js handles typography, not just graphics.
Magic 8 Ball — the sphere shading algorithm: 50 concentric circles producing a 3D illusion using nothing but map(). The most technically “Processing” content in the ecosystem.
Slot Machine — the original p5.js animation in the 2026 collection, with spinning reels, win detection, and theme switching. Represents the game-engine side of Processing.

The pattern emerging across both curation decisions: when a category card is trimmed to three, the right three are not the most popular or the most recent — they are the ones that between them best illustrate the range of the category. A student who sees text + sphere + spinning reels understands what p5.js can do across three very different problem types.

Post-Session — Card Curation: The 3-Item Rule in Practice

klp

I’m noticing that our Simulations card on the explore page now shows 5 applications; we’ve set a goal of only showing 3. Looking at the ones listed, let’s determine the best ones to keep ‘front-facing’. From a student-interest and organizational viewpoint, which ones should stay?

Prompt Critique — Asking for Analysis Before Action

This is the right framing for a curation decision. “Which ones should stay?” with two explicit criteria (“student-interest” and “organizational viewpoint”) is a well-structured question. It does not assume the AI will just pick arbitrarily — it names the dimensions that matter and asks for reasoning on each.

This is also a good example of catching a constraint violation immediately. The three-item guideline exists in the page’s own comment block (). Noticing the overage and asking for a principled resolution rather than just deleting two random entries is exactly the right response.

GitHub Copilot

Analysis of all five items across both criteria:

App	Student interest	Organization
Hot Seat Spinner	Teacher tool — students appear in it, don’t browse it	Already #1 on S.P.A.R.K. and Processing cards
Magic 8 Ball	Universal recognition, immediately interactive	Teaches probability AND sphere shading — double educational value
Slot Machine	Familiar, immediately playable, emoji themes engaging	Canonical probability simulation; SPARK edition
LightWrite	Stranger Things hook is a guaranteed student click	Interactive simulation with cultural anchor
Matrix Rain	Iconic film reference, but it’s a cover/index page	Least directly playable of the five

Recommendation: keep Magic 8 Ball, Slot Machine, and LightWrite. Remove Hot Seat Spinner (already well-represented elsewhere) and Matrix Rain (cover-page level, less directly interactive). All five remain fully accessible in the Simulations offcanvas.

Design Decision — Card Curation: Audience vs. Ecosystem Representation

The three-item cap on category cards exists for a good reason: beyond three, the card becomes a list rather than a curated sample. The card’s job is to signal “here is the best of this category” — not to be comprehensive. Comprehensive is the offcanvas’s job.

The Hot Seat Spinner removal from the Simulations card illustrates a curation principle worth naming: an app’s best placement is determined by its primary audience, not just its category membership. Hot Seat Spinner genuinely belongs in Simulations (random selection is a simulation). But its primary audience on the Explore page is educators navigating to S.P.A.R.K. or Processing — not students browsing for something to play. Keeping it in the Simulations offcanvas serves the curious student; putting it on the card would surface it to the wrong audience at the wrong moment.

The three kept — Magic 8 Ball, Slot Machine, LightWrite — all share a common property: a student can understand what they are and want to click them from a single icon and title. That is the test a featured card item should pass.

Session Takeaways

“I use this every day” is the most important sentence in the prompt. It tells the developer not to touch working logic, not to rename IDs the script depends on, and not to experiment with new features at the expense of existing ones. Daily-use tools have a different risk profile than demo apps. Read the constraint before reading the code.
Design systems are defaults, not prisons. The TNT design system standardizes the navbar, footer, fonts, and color tokens. It does not standardize every hero or every background color. When the app’s context clearly calls for a departure (projector-bright classroom vs dim-room demo), take the departure — and document the reason so future developers understand it was intentional.
The best renovation leaves the sketch untouched. The entire Hot Seat Spinner renovation happened in the HTML shell and a new CSS file. The sketch — 600+ lines of p5.js logic, localStorage management, confetti animation, and dynamic UI construction — was not touched. This is the ideal outcome: change the presentation layer, preserve the behavior layer. The spinner now looks like a 2026 TNT app and still works exactly the way it did yesterday.

What This Renovation Produced

File	Status	What it does
`scripts/classroomDialSPARK_Sketch1.js`	Unchanged	All p5.js logic, multi-class management, selection history, confetti
`classroomDialSPARK1.html`	Renovated	TNT navbar, hero, light layout, footer, scripts; SEO meta block added
`styles/classroomDialStyles.css`	New	Light & bright classroom palette; replaces legacy site-styles.css
`classDialSPARKChatlog.html`	New	This page; SEO meta block added
`js_apps.html`	Corrected	Hot Seat Spinner card removed (reclassified to Processing)
`processing_apps.html`	Updated	Hot Seat Spinner added as first card (priority position)
`explore.html`	Updated	S.P.A.R.K. card featured, Simulations card, Processing card; all three offcanvases
`news.html`	Updated	News entry #023 added

Original legacy version preserved at: classroomDial7.html in the same folder.

Launch Hot Seat Spinner Legacy Version