Parabola Saga — S.P.A.R.K. Development Log

The template already wires showElements to the E key and a checkbox with id showElementsCheck. In the Glow Lab version this toggled focus points and focus lines. For the parabola app those elements don’t exist. Rather than add a new variable and new DOM element — which would require editing the template file — the existing hook was repurposed: the label changed from “Elements” to “Labels,” and drawMyDesign() uses if (showElements) drawAxisLabels(ctx.grid).

The E key shortcut, the checkbox wiring, and the reset behavior all come for free. No template changes needed. This is what working with the framework looks like instead of around it.

The prompt asked for a controllable grid. It said nothing about axis labels. Copilot added drawAxisLabels() anyway — a correct inference. A coordinate system without numbers is not usable for the educational goal: students need to read vertex x- and y-values from the graph. A grid without labels is a decoration, not a tool.

The implementation uses an adaptive density formula to prevent label overcrowding at small-step/large-grid combinations:

// Adaptive: prevents overcrowding for any slider/select combination
const totalTicks = Math.round((g.LR.x - g.UL.x) / g.xStep);
const labelEvery = totalTicks <= 12 ? 1 : totalTicks <= 30 ? 2 : 5;

Default grid (±10, step 1 → 20 ticks): labelEvery = 2, labels at −10, −8,… 8, 10. Small grid (±5, step 1 → 10 ticks): labelEvery = 1, every tick labeled. Large grid (±25, step 1 → 50 ticks): labelEvery = 5, one label every 5 units. This formula should be tested against all slider/select combinations before Phase 2 begins.

The theme color #2a7a2a (forest green) was not specified in the prompt. Copilot chose it by connecting the attached context: onlyHadABrain2026.html and analyzingOnlyHadAVertexLyrics.html both use a deep forest-green palette. Aligning the Parabola Saga app to that palette makes the educational connection visible when both pages are open.

This is context doing design work for free. The more coherent the attached source material, the more coherent Copilot’s visual choices will be. No specification needed.

In the original Glow Lab HTML the grid checkbox had no checked attribute, so it appeared unchecked on initial render. The template’s wireControls() corrects this at runtime (it sets showGridCheck.checked = showGrid where DEFAULT_SHOW_GRID = true). The new HTML adds checked directly to the element so the visible state matches the correct default before JavaScript runs. A minor fix, but visible to any developer reading the source — and a clean habit to form: the HTML should reflect the intended initial state.

The parabola is a 600-point polyline via p5.js beginShape() / vertex() / endShape(). With a ±10 grid (20 user units across), 600 segments = 30 per unit — visually smooth at any slider setting.

For larger grids (±25, 50 user units), 600 segments gives 12 per unit, which may appear angular on steep parabolas. Phase 3 could scale segment count with gridHalfSize * 60 instead of a fixed 600.

The parabola uses HSB stroke(35, 90, 85) — warm gold/orange. This contrasts with the gray canvas background and dark green grid without clashing with either, and ties visually to the Oz gold accent throughout the project. The vertex marker uses red-orange fill(5, 88, 92) inside a white halo (fill(0, 0, 100, 88)), making it pop from both the curve and the background.

The top of the Parabola Design card shows y = ax² + bx + c with each coefficient in the same color used in the “If I Only Had a Vertex” parody display on onlyHadABrain2026.html. Students who read the lyrics analysis recognize the color coding. The direction indicator (“Opens UP — minimum”) connects the a sign to Verse 2 of the parody, closing the loop from text to interactive tool.

All three sliders share one handler. When any slider moves: (1) all three coefficient variables are read from their sliders, (2) all three display spans are updated, (3) updateVertexDisplay() recomputes h and k, (4) one canvas redraw is triggered. A separate handler per slider risks the equation display or vertex showing stale values if one update fires before another. One handler, one source of truth, one redraw.

Given the family y = ax² + bx + c with a and c fixed and b varying, the vertex is at (h, k) where h = −b / (2a). Substituting b = −2ah:

k = a·h² + b·h + c
  = a·h² + (−2ah)·h + c
  = ah² − 2ah² + c
  = −ah² + c

// The vertex (h, k) always satisfies:  k = −ah² + c
// i.e., the vertex trace IS the parabola  y = −ax² + c

The vertex trail is always the parabola y = −ax² + c. Three things to notice:

• It opens the opposite direction from the family. If the family opens up (a > 0), the vertex trail is a downward arch. This makes visual sense: the vertex rises as the parabola narrows, and falls toward ±∞ as the vertex moves off-axis.
• It passes through (0, c) — the y-intercept shared by every member of the family. When b = 0, h = 0, k = c, and the vertex sits exactly on the y-axis at the common y-intercept.
• It depends only on a and c, not on b. The trail parabola is a fixed curve; b just determines where along it the vertex currently sits.

The classic p5.js trail technique: instead of painting the background fully opaque each frame, paint it at reduced alpha. Old pixels fade toward the background color on each redraw, leaving ghost images of previous positions.

// Template calls this every draw() — alpha controls how much of the
// previous frame survives.  100 = full clear (no trail); 15 = strong trail.
bgCurrentColor = SWColor.fromHex(bgHex, bgTrailOpacity);
background(bgCurrentColor.col);  // semi-transparent → old parabolas fade

In noLoop() mode, redraws only fire when a slider is dragged. Each drag event fires a redraw(), building up the trail as the slider moves. When the slider stops, the trail freezes at the current state — until Reset clears it or the trail slider is set back to 0.

Educational payoff: dragging the b slider from −10 to 10 with a medium trail setting reveals the family of parabolas organically — a hand-drawn preview of Phase 3. The vertex trace parabola (y = −ax² + c) emerges visually as the cluster of vertex dots arches over the canvas.

After a clarifying exchange, the design was refined: the vertex dot (white halo + red-orange fill) is always drawn when the vertex is within grid bounds. The Show vertex label on graph checkbox controls only the V( h, k ) text annotation — nothing else.

The label defaults to unchecked because Phase 3 will draw one parabola per b value. Labeling every vertex would clutter the canvas, while the bare dots form a clean visual trail that reveals the vertex parabola y = −ax² + c organically.

The observation is correct: the grid is configured once (rarely changed thereafter); the parabola coefficients are the primary interaction point. Placing Parabola Design first means students immediately see the equation y = ax² + bx + c and its sliders — not the coordinate system size.

This is the information hierarchy principle applied to UI layout: the most important controls occupy the most prominent position. Secondary configuration (grid size, step, background color) belongs below the primary task, visible on demand.

Grid Settings collapses via Bootstrap’s built-in data-bs-toggle="collapse". The card header gains a small chevron button (▾) that rotates 180° when the panel opens, using a CSS transition on .ps-grid-toggle. Default state is collapsed (aria-expanded="false").

This is the progressive disclosure pattern: show what’s needed for the primary task, hide secondary configuration until the student chooses to access it. Grid settings still exist and are fully accessible — they just don’t compete for attention during the core exploration of how b affects the parabola.

The template’s Reset button starts disabled in the HTML and only becomes enabled after Start is clicked (via syncStartPauseBtn()). After each Reset click, the template re-disables it with resetBtn.disabled = true. Since Phase 2 users never need to click Start — the app is reactive (slider → redraw() in noLoop mode), not animated — Reset stays permanently disabled. No error, no warning; it just sits gray and inert.

This is a “designed for animation” assumption baked into the template. The template assumes the flow: Start → dirty state → Reset. Phase 2’s flow is: slider drag → dirty state → Reset, with no Start in between. The template can’t know that.

Start is hidden with Bootstrap’s d-none class rather than removed from the HTML. All template wiring remains intact. When Phase 3 adds animation (e.g., sweeping b from b_min to b_max automatically), Start can be restored by removing d-none. Neutered, not deleted.

Reset is fixed with a small enableReset() helper called after every control interaction (sliders, checkboxes, trail). The resulting UX pattern is correct: drag any slider → Reset enables → click Reset → Reset disables → drag again → Reset enables. Reset is only available when there is something to reset — which is the right behavior.

Phase 3 role of Start: if Phase 3 animates b sweeping with loop(), un-hiding Start (removing d-none) is the only HTML change needed. The infrastructure — the Start handler, running flag, loop()/noLoop() coordination — is already there, just dormant.

The template’s wireControls() wires the Start button to toggle running and call loop()/noLoop(). Phase 3 has no animation loop — it draws the entire family at once and stays in noLoop() mode. The two wiring approaches are incompatible.

The fix: in initAppVars() — which runs before wireControls() in the template’s setup() — add a click listener with e.stopImmediatePropagation(). Because listeners fire in registration order, and stopImmediatePropagation() cancels all later listeners on the same element, the template’s handler never fires:

startBtn.addEventListener('click', function(e) {
    e.stopImmediatePropagation();  // blocks template's loop toggle
    familyStarted = true;
    bValues = computeBValues();
    enableReset();
    refreshCanvasImmediate();
});

Teaching point: stopImmediatePropagation() prevents later listeners on the same target from firing. stopPropagation() only prevents the event from bubbling to parent elements — a common confusion. The distinction matters any time two unrelated libraries both want to handle the same click.

The two color pickers return CSS hex strings. p5.js’s color('#hexvalue') parses them into color objects regardless of the current colorMode(). lerpColor(ca, cb, t) then interpolates in the current color space — HSB here. The result is a smooth hue sweep rather than a muddy linear RGB midpoint:

function familyColor(i, n) {
    const t = n > 1 ? i / (n - 1) : 0;
    return lerpColor(color(startColorHex), color(endColorHex), t);
}

A gold → blue picker pair sweeps through green and cyan — a natural rainbow arc across the family. Students can observe that the midpoint hue is determined by the shorter or longer arc around the hue wheel depending on which direction HSB interpolates. This is a subtle but real color theory lesson hiding in the slider.

p5.js has no native dashed-line API; dashes require dropping down to the Canvas 2D context. drawingContext is p5’s direct reference to the underlying CanvasRenderingContext2D. The pattern: save state, set the dash array, draw, restore:

drawingContext.save();
drawingContext.setLineDash([7, 4]);   // 7px on, 4px off
stroke(0, 0, 100, 82);               // near-white in HSB
beginShape();
// ... vertex() calls ...
endShape();
drawingContext.restore();             // solid lines for everything after

The save()/restore() pair is essential — without it, every line drawn after the locus (including the grid on the next frame) inherits the dash pattern. This is the same principle as p5’s push()/pop(), but for the raw 2D context instead of p5’s state stack.

Each vertex dot is filled with the same lerpColor() result as its parabola, not a fixed red-orange. This makes the color gradient legible at the vertex level as well as the curve level — students can follow any individual dot up the locus arch and trace it back to its parabola by color.

The app stays in noLoop() throughout. Drawing all N parabolas at 600 segments each (up to 200 × 600 = 120,000 vertex() calls) is a one-time operation; looping at 30fps would waste CPU for no visual benefit. Reactive redraws via refreshCanvasImmediate() are triggered by each control change, giving full interactivity without a render loop.

Range sliders work well for single continuous values (Phase 2’s a, b, c). For b_min, b_max, and b_inc, number inputs are more appropriate: the user needs to set exact values, and the relationship between the three determines the count. A slider for b_inc with values from 0.1 to 5 would have 50 positions; a number input with step=0.1 is more precise and easier to type into.

The computed count is displayed live below the inputs. With b_inc = 0.05 and a ±10 range, that’s 401 parabolas × 600 segments. The safety cap at 200 keeps worst-case rendering bounded. The cap is shown as “N (cap)” in the count display so the user knows it was hit.