🎬 Building the Movie Credits Simulator

Every other TNT app opens with a hero section — a full-width banner with a background image, an eyebrow label, and a title. The Movie Credits Simulator is the first to forgo it deliberately.

The reason is visual hierarchy: the animation is the first experience. A hero above the canvas would push the 800×600 starfield below the fold on most screens, forcing the user to scroll before anything moves. Since the loading state (spinner) transitions directly into the starfield animation, the canvas is the hero — there is nothing to add above it.

Implementation: #canvas-container is given min-height: calc(100vh - 68px) so the canvas area fills the full viewport below the sticky navbar on first load.

The original file had a self-contained purple gradient navbar defined entirely in its own <style> block. When tnt-base-styles.css is loaded, it provides its own complete rules for #mainNav, .navbar-brand, and .nav-link.

Leaving the custom rules in place would create a silent specificity conflict — the cascade would resolve it differently depending on selector specificity and source order, producing unpredictable results across browsers.

The correct action is removal of the custom rules, not adding override selectors on top of them. Integration means subtraction as well as addition.

The integration added the Open Graph protocol tags (og:type, og:title, og:description, og:url, og:image) rather than just <meta name="description">.

The distinction matters for discoverability: search engines use og: tags to generate rich link previews. When a student shares the page URL, the platform shows the app name, description, and an image rather than a bare link.

The og:image was set to the TNT dynamite SVG as a deliberate placeholder. A production deployment would replace it with a screenshot of the animation in action — the starfield with a credit name zooming through it is immediately recognisable and more compelling than a site icon.

All three buttons are transparent with a colored border at rest. On hover, they fill solidly with their respective color. This directly serves the “don’t compete with the artwork” requirement:

• At rest, three hairline-bordered labels float above the starfield with minimal visual weight — the stars and credit names are never obscured
• On hover, the solid fill signals interactivity without the button dominating the scene when idle
• backdrop-filter: blur(6px) gives the buttons a subtle frosted-glass effect, integrating them with the dark canvas rather than sitting on top of it as opaque elements

The amber hover fill for RESET uses color: #111 (near-black text). Amber at full saturation does not provide sufficient contrast against white text — dark text on amber is the standard accessible combination for this hue.

When audio is muted, the MUTE button border and text shift from white to red (#ff6b6b). This is not merely decorative — it makes the muted state persistently visible without requiring the user to hover or test it.

The pattern follows familiar UX conventions: a recording indicator shows red when active, a crossed microphone icon appears red when suppressed. Red on the MUTE button reads immediately as “audio is off right now.”

Users who return to the tab after muting (or who are handed a device mid-session) will see the red border and understand the state at a glance, without needing to click anything to discover it.

The R-key reset shortcut existed since Stage 9 for developer convenience during testing. It was never documented in the UI. Exposing it as a visible RESET button required no new logic — only a DOM element, one event listener line, and a CSS rule.

Invisible functionality is inaccessible to anyone who doesn’t read source code. Any keyboard shortcut that performs a user-facing action should have a visible counterpart. The shortcut can remain for power users; the button serves everyone else.

The hero background image (movieCreditsCoverHeroImg.jpg) was restored after being accidentally removed in a manual edit between sessions. The image shows a blue warp-tunnel / hyperspace effect — visually consistent with the Superman-style starfield animation it represents on the chatlog page.

The overlay gradient was kept deliberately light (rgba(5,8,22,0.72) → rgba(10,20,50,0.55)) so the cinematic blue reads clearly through it. A heavier overlay would defeat the purpose of having the photograph.

The og:image meta tag was also updated from the generic TNT icon to the cover photograph, so social link previews now show the warp-tunnel image rather than a site logo.

The original body background (#f0f2f8) sat immediately after the near-black hero, creating a hard light-to-dark boundary. Darkening all content surfaces proportionally moves the whole page toward the hero’s tonal range without making the content area uncomfortable to read:

Each box retains its original color temperature — aside boxes stay cool grey, decision boxes stay warm amber-tinted, critique boxes stay cool purple-tinted. Only the lightness value shifts, preserving the visual grammar that distinguishes each box type.

The body background was changed from #e2e6f0 (muted blue-grey) to #57b9d6 (vibrant teal-blue). Where the previous value simply reduced the lightness of the original #f0f2f8, this shift pulls the page color into the same teal family as the warp-tunnel hero photograph — creating tonal continuity from the dark navy hero through the bright teal content area rather than a neutral-to-dark transition.

The content boxes (#edf0f7, #f4eedf, #e6ebf8) now sit on a warmer, more saturated background, which makes their individual color temperatures more visually distinct by contrast.

The log-divider text color was darkened from #aaa (light grey) to #666565 (mid grey). On the previous #e2e6f0 background the divider had workable contrast; on the more saturated #57b9d6 background a lighter grey risks washing out against the vivid blue.

The flanking rule lines (::before / ::after) remain at #ddd — they are structural separators rather than readable text, and their slight translucency against the blue reads as intentionally subtle.

The canvas was reduced from 800×600 to 800×500 so that canvas + control bar + footer fit within a typical 768–900 px laptop viewport without vertical scrolling:

All p5.js code that references the height variable (star spawning, credit/title vertical centering) adapts automatically because height is a p5.js live variable, not a hard-coded constant.

The original #controls div was position: absolute at the bottom of #canvas-container, which placed the buttons visually over the p5.js canvas. This overlap is fine when the canvas is large enough, but it becomes a problem when adding a second control row (the slider) — both rows would need to float above the artwork.

Moving the controls to a new #control-bar div in normal document flow (below #canvas-container) eliminates the overlap entirely. The control bar has its own background (rgba(0,0,0,0.55)), creating a clear visual separation between the animation canvas above and the interactive controls below — similar to a video player layout.

The timeline slider serves two roles:

• Scrubber: dragging and releasing calls seekToCredit(k), which jumps the animation to credit k instantly
• Live indicator: activateCredit(index) now updates slider.value = index + 1 every time a credit activates, so the thumb advances automatically during normal playback

Position 0 = “INTRO” (full sequence from the beginning, music included). Positions 1–N jump directly to that credit, suppressing the intro. The amber label to the left of the slider shows the credit name at the current thumb position as the user drags, giving a preview before committing.

When seekToCredit(k > 0) is called, the four intro phrase objects have their startTime property set to Infinity. The activation check in updateTitleObject() is:

Since no finite elapsed time can equal or exceed Infinity, the condition is permanently false. The phrases are never activated — they sit inert while the credits sequence runs normally from the target position.

The virtual clock is positioned by setting animationStartTime = millis() - creditsStartTime - 10, so timeSinceStart = creditsStartTime + 10 from the very first frame — credits start immediately without waiting through the intro or pause.

HTML5 Audio is not a black box. It exposes its internal state through readable and writable properties. The most important one here is currentTime:

Setting currentTime before calling .play() is exactly what every music player, podcast app, and video website does when you drag the progress bar. It is a standard, well-supported feature of the web platform — not a workaround or a trick.

Imagine laying two rulers side by side. One ruler represents the total animation (its length varies based on the number of credits). The other represents the music track (its length is always the same). To synchronise them, find the same percentage mark on both:

The credit animation duration used in step 1 is computed from constants already in the file — how fast the credit shrinks (CREDIT_SHRINK_RATE) divided by 60 frames per second, converted to milliseconds. No new magic numbers needed.

What “proportional sync” sounds like in practice: if you jump to the last credit in a long show, the music is near its climax. Jump to the first credit and the music is just warming up. The emotional arc of the track matches the visual arc of the sequence — which is exactly what you want from a credits roll.

The cover page (movieCreditsSimCover.html) is modelled on gLifeIndex.html from the Conway’s Game of Life project: a dark-themed entry page with three launch cards, a hero banner, and a brief “what students learn” callout. The dark theme (#0d1117 body) was chosen to match the animation’s own dark canvas rather than the chatlog’s teal palette.

The three cards follow the same semantic color hierarchy as the simulation’s buttons: blue-purple for the primary action (Run), amber for the development story (Chat Log), and silver for the archival reference (Legacy v16d).

The “Coming soon” paragraph in the callout serves a dual purpose: it informs the current visitor and creates a public commitment to the next development stages.

A .mc-spark-bar strip (modelled on the GOL .spark-bar) sits below the TNT navbar on the cover page and provides quick links between all project pages:

The bar is on the cover page for now. As the Settings and Content pages are added, they will be included here too — giving every project page one-click access to every other page without going back to the TNT main navbar.

The session established a clear three-stage plan before full TNT integration:

The legacy version already has working equivalents of these pages (customizeText3.html for settings, customizeContent1.html for content). They provide a useful starting reference for the new versions.

The customizeContent1.html (legacy) and customizeContent18.html (new) share the same localStorage key (movieCreditsContent), the same JSON structure, and identical validation rules. The JS logic was kept functionally identical.

The presentation layer was completely replaced: custom purple gradient navbar → TNT #mainNav; Bootstrap 5.3.0 → 5.3.3; Font Awesome added; inline style block replaced with named .cc-* classes on a dark (#0f1219) background. The spark-bar (with Content marked active) gives the page its place in the project navigation.

The simulator reads content under the key movieCreditsContent. The customizer writes to exactly the same key with the same JSON shape (introPhrase1/2/3, movieTitle, students, concepts). No changes to the simulator were needed.

The DEFAULT_* constants in the customizer match the simulator’s own defaults exactly, so a teacher who resets gets the same starting point they would see on a fresh simulator load — factory names and concepts appear identically in both files.

The legacy customizer required the user to navigate back to the simulator manually. The new version adds a Test in Simulator button (amber outline, matching the RESET button color in the simulator) that links directly to movieCreditsSim18.html immediately after saving.

This creates a tight workflow: edit → save → click → see results. The button is an amber outline — not a filled call-to-action — because it is a navigation link rather than a data action, and because amber already carries the meaning “secondary action” in this project’s visual grammar.

The key difference between customizeContent18.html and customizeText18.html is the live p5.js canvas on the Settings page. Content changes (names, phrases, title) are text — the user can mentally preview them. Visual settings (font, blur, tilt, stroke) have effects that are hard to imagine without seeing them. The canvas preview makes every slider change immediately tangible.

The canvas is 700×500 and sits in a col-lg-7 column, leaving col-lg-5 for the scrollable controls panel (max-height: calc(100vh - 180px)). This classic split-panel layout is standard for any tool that has both settings and a visual output.

The legacy customizer had two defaults that did not match movieCreditsSim18.html:

If a teacher uses the Settings page without changing these values and then clicks “Save to Browser”, the simulator will load exactly the defaults it would use without any saved config — no surprise behaviour.

Adding the Settings card gave the cover page five cards. The user had also introduced a structural HTML error while manually rearranging cards: the Content card was inside a nested <row> inside the main card row, which broke the Bootstrap grid. Both issues were fixed in a single pass:

• Row 1 (3 cards): Simulation, Content, Settings — the active tools
• Row 2 (2 cards, centered): Chat Log, Legacy v16d — reference and archive

The Settings card uses green (#66bb6a) — the fourth distinct color in the project’s card palette, after blue-purple (action), amber (navigation), and teal (content). Green suggests “configuration” or “fine-tuning” — a common convention in interface design.

HTML requires headings to descend in order: h1 → h2 → h3. Skipping a level (e.g., h1 → h3) is valid HTML5 syntax but produces a WCAG accessibility warning because screen reader users use heading structure as a navigation map. A missing h2 is like a table of contents with no chapter titles — you jump from the book title straight to sub-sections.

The Settings page had exactly this: a hero h1 followed by an h3 in the controls panel, with nothing at h2 level. The Content page had the inverse problem: the user correctly changed h3 to h2 for validation, but the CSS rule .cc-panel h3 no longer matched — leaving the heading unstyled (browser default bold serif).

The fix is a CSS class (.panel-title) that carries the visual style independently of the element type:

This means:

• The element (h2 or h3) communicates hierarchy to the browser, screen readers, and search engines
• The class communicates appearance to the CSS engine
• Changing one does not break the other

The same class is defined in both files with identical values, so a teacher who opens either customizer page sees the same panel heading style. The shared name (.panel-title) signals their intended equivalence even though the two files are independent.

alert() and confirm() are browser-native functions inherited from the early web. They work, but they come with significant limitations that become visible on a professional-quality tool:

The modal also uses the same .panel-title class established in Session 10, so the “Reset to Factory Defaults?” heading matches the rest of the UI without any additional CSS.

A speed bump is a deliberate UX friction point inserted before any action that cannot be reversed. Skipping it feels faster for the developer but creates a worse experience for the user — and worse outcomes when a mistake is made.

Three things make a good speed bump for a destructive action:

1. Specify what will be lost. “Are you sure?” is not informative. “Your student names, CS concepts, and intro phrases will be permanently erased” is. The user can make a real decision only when they know the stakes.
2. Make the safe path the easy path. Cancel is on the left — the natural first target. The destructive action is on the right, requiring a deliberate rightward movement and click.
3. Name the consequence explicitly. The amber line “This cannot be undone” is not decoration. It is the single most important sentence in the dialog: it tells the user they are about to cross a one-way door.

The data-bs-dismiss="modal" attribute on the confirm button lets Bootstrap handle the close animation cleanly, while the click event listener on the same button handles the actual reset. Both fire independently — no manual modal.hide() needed.

When this project had three pages, a simple “Back” link was sufficient. By Session 11 it has six: the cover, simulator, content customizer, settings customizer, chatlog, and legacy reference. At that scale a single back-link fails for two reasons:

• It only navigates one direction — you can reach the cover page from the chatlog, but not the settings page, or the simulator, without going via the cover
• Each page has a different version of “back”, so users on different pages experience different navigation

The .mc-spark-bar appears identically on all six pages, with only the class="active" attribute changing to indicate where the user is. This one-line difference per page costs nothing and gives every visitor a mental map of the whole project from any page they land on.

The .back-bar CSS was also removed from the chatlog’s <style> block — dead CSS is clutter that can confuse maintainers later. The rule for removing unused code is the same as the rule for adding new code: if it serves no purpose, it should not be there.

C.R.A.P. is a four-principle visual design framework popularised by Robin Williams in The Non-Designer’s Design Book. Each letter names a property of well-organised visual layouts:

The specific failure here — Contrast. The button used the project’s standard amber (#f0a500) for its text and border. That color has a relative luminance of approximately 0.454. The page background (#57b9d6 teal) has a luminance of approximately 0.416. The WCAG contrast ratio formula is (Llighter + 0.05) / (Ldarker + 0.05):

A ratio of 1.08:1 is effectively no contrast at all — both surfaces have almost identical brightness. The amber was not wrong in isolation; it reads perfectly on the simulator’s near-black canvas and on the cover page’s dark #0d1117 body. It fails only here because the chatlog’s bright teal background happens to sit at the same luminance level as the amber itself. This is the key lesson of the Contrast principle: contrast is relational — it depends on foreground and background together, not on either color alone.

The fix. The button color was changed from #f0a500 to #8b4800 — a dark burnt amber. Its luminance is approximately 0.101:

WCAG 2.1 Level AA requires a minimum of 3.0:1 for large or bold text. The button is rendered fw-bold (Bootstrap 700-weight), which qualifies. 3.09:1 clears that threshold — the label is now readable without guessing.

Practical rule: whenever a text or border color is chosen for a specific background, check that their luminances are not similar. If they are close, one must change. Make the foreground distinctly darker or distinctly lighter than the background — never almost-the-same. The WCAG contrast checker at webaim.org/resources/contrastchecker lets you paste two hex values and see the ratio instantly.

A TNT app is not “launched” simply because its files exist in the server folder. For a new app to be discoverable and documented, three files must be updated:

Two rules govern explore.html entries that are worth naming explicitly:

• Category cards are capped at 3 featured apps. When a card already shows 3 apps, new apps go only into the offcanvas panel. The S.P.A.R.K., Processing, and Simulations cards were all at or over their limits, so Movie Credits appears in the offcanvas panels only — not on the cards.
• Only the S.P.A.R.K. offcanvas links to chatlogs. Processing and Simulations panels list apps only. Chatlog links belong in S.P.A.R.K., where the development dialog is the primary subject — not in subject-matter categories where visitors are looking for apps to run.

Thirteen sessions. Thirty-two decisions. One page for the canvas, one for the cover, two for the customizers, one for the legacy, and one for the log. Everything connected by shared localStorage keys, a consistent sub-navigation bar, and a color grammar that starts with the simulator’s three outline buttons and flows outward to every card, offcanvas entry, and news headline in the ecosystem. The Movie Credits Simulator is live.