# Processing Cross Training — Proposal Analysis & Design Notes **Date:** 2026-09-25 **Author:** klp + GitHub Copilot **Status:** Planning / Decision stage --- ## The Core Distinction The existing Cross Training area is **concept-centric**: each entry is titled after a CS idea (Iterate & Display, Conditional Logic, Classes & OOP), the originating TNT app is the hook, and the payoff is seeing the same algorithm in three general-purpose languages (JS, Java, Python 3). The audience intent is analytical — "show me how this concept maps across syntax boundaries." **Processing Cross Training** would be fundamentally different in every dimension: | Dimension | Current Cross Training | Processing Cross Training | |---|---|---| | Primary question | "How does this concept work in different languages?" | "How does this sketch work, and how does each Processing flavor express it?" | | Anchor | Any TNT app | A p5.js sketch (always live, always visual) | | Language set | JS · Java · Python 3 | p5.js · Python Processing · Java Processing | | Audience intent | CS concept mastery, interview prep | Creative coding, visual craft, artistic exploration | | Project shape | Atomic — one concept, one page | Staged — a sketch evolves through multiple iterations | | What's the same | Algorithm / logic | The Processing vocabulary itself (colorMode, stroke, fill, sin, TWO_PI, frameCount…) | | Success metric | "I can write this concept in any language" | "I can port and evolve a sketch across Processing ecosystems" | These are two different *reasons* to learn, two different *rewards* when you succeed, and two different *audiences* even when the same student visits both. Treating them as one area would require awkward compromises in framing, navigation, and page structure. --- ## Pros of a Separate "Processing Cross Training" Area ### 1. The Processing ecosystem *is* a coherent, bounded teaching unit `colorMode()`, `stroke()`, `fill()`, `background()`, `sin()`, `TWO_PI`, `frameCount`, `mouseX/mouseY` — identical in all three flavors. That shared vocabulary is the lesson. You don't need to also teach Java's type system or Python's dict syntax; you're teaching *one* creative coding API expressed in three host languages. The comparison is tighter, cleaner, and more immediately rewarding for novices. ### 2. Live canvas changes what a page *is* Current Cross Training pages are read-and-analyse experiences. A p5.js sketch embedded on the page is an *interact-first, read-second* experience. The student clicks, sees the stars twinkle, *then* opens the code panel. The pedagogical sequence is reversed — and correctly so for creative coding. Mixing that into the current area's read-first card structure would dilute both. ### 3. Stage-based projects need a home Henry's Ghost has a five-stage saga: procedural Python → OOP Python → p5.js port → PyWave library → SketchWave library. That progression doesn't fit in the current model where one entry = one concept = one page. A dedicated area can host the full saga as a linked series, with a hub entry showing the arc and sub-pages for each stage. This is the "adventures" model already proven on TNT — apply it to Processing sketches. ### 4. Different assessment vocabulary Current Cross Training asks: *Why does the branch look different here?* Processing Cross Training asks: *What changed between Stage 2 and Stage 3? What did the class buy you?* Different S.P.A.R.K. questions, different "Know what you built" takeaways. ### 5. Artistic motivation is a legitimate entry point Many students — especially younger ones — come to TNT through the visual/artistic door. They don't care about binary search trees yet; they want to make ghosts float. A dedicated Processing area honours that entry point without forcing it through the CS-concept framing. Both paths lead to programming competency; they start in different parking lots. ### 6. Separation prevents false equivalence in the language comparison In current Cross Training, the three languages are truly parallel — any of the three could anchor the page. In Processing Cross Training, **p5.js is always the anchor** (it runs in the browser; it's the live experience). Python Processing and Java Processing are always "how do I do the same thing here?" That asymmetry would create structural awkwardness in the current hub's equal-weight card model. --- ## Cons / Risks ### 1. Site fragmentation Two "Cross Training" areas could confuse first-time visitors. Mitigation: clear naming (current = "Cross Training: CS Concepts", new = "Cross Training: Processing & Creative Coding") and bidirectional links between hubs. The top-level index.html card and the resources page must link to both. ### 2. Maintenance surface doubles Two hubs, two chat logs, two news cadences. This is real cost — manageable only if each area grows incrementally (one new entry at a time, same as today). Don't pre-build eight placeholder cards; start with two live entries and one placeholder. ### 3. Overlap risk for OOP-heavy sketches When Henry's Ghost Stage 2 introduces a Ghost class, it is *both* a Processing craft lesson and an OOP lesson. This creates a natural link to Cross Training Concept #6 (Classes & OOP) — exploit that with a visible cross-reference, not by trying to merge the two areas. A short "See also: Cross Training — Classes & OOP" note solves the problem cleanly. ### 4. The "three languages" claim needs verification per entry Python Processing has real limitations (Skulpt caveats aside, even the desktop Python Processing IDE has module restrictions). Java Processing works well but requires the Processing IDE. For every Processing Cross Training entry, all three versions must actually run before the page launches — same quality gate as today's Skulkt verification rule. --- ## Recommendation **Build the separate area.** The distinction in audience intent, page structure, pedagogical sequence, and project shape is large enough that the two areas genuinely serve different student needs. Forcing them together would compromise both. ### Suggested structure for Processing Cross Training ``` ProcessingCrossTraining/ processingCTHome.html ← hub page; one card per sketch/saga processingCTChatlog.html ← development diary (Sessions 1-n) TwinklingStars/ ← Henry's Ghost Saga Entry (first live entry) index.html ← p5.js live sketch + three-language comparison stage1/ ← procedural Python Processing stage2/ ← OOP Python Processing (Ghost class) stage3/ ← p5.js port ← already started! (stage4, stage5 later) [NextSketch]/ index.html ... ``` ### Hub card model Because p5.js is always the anchor, each hub card can embed a **live thumbnail sketch** (small canvas, interaction optional) rather than a static image. That's a much stronger hook than a screenshot. The hub becomes a gallery of running code. ### Linking strategy - `processingCTHome.html` ↔ `CrossTraining/crossTrainingHome.html` (sister links in each hub) - Each Processing CT entry ↔ relevant CS concept pages where overlap exists (e.g., Ghost Stage 2 ↔ Concept #6) - `HenrysGhostTwinklingStars2026-09-24/henrysGhostTwinklingStars1.html` (already built) becomes the natural first sub-entry under TwinklingStars/ - `movie_clips/henrysPythonicGhost.html` links forward to the full Processing CT entry --- ## On SketchWave The instinct to **separate SketchWave from Processing Cross Training** is correct. Here's why: ### Why it's not a "golden opportunity" yet SketchWave is an abstraction layer. Teaching abstraction to novices requires that they already understand what's being abstracted. A student who has never written `strokeWeight()` directly won't appreciate `SWDisk.breathe()`. The Processing CT area is where they learn the raw API. SketchWave becomes meaningful in a *third* phase — after the raw Processing CT entries establish the vocabulary. The pedagogical sequence is: 1. **Raw p5.js / Processing** — learn the API directly (Processing CT) 2. **Understand a CS concept through that API** (current Cross Training) 3. **See how a library abstracts the raw API** (SketchWave CT — a future third area, or a "SketchWave Deep Dives" section within Processing CT) ### The "golden opportunity" that does exist For Henry's Ghost Stage 4-5 (PyWave + SketchWave), showing the *before/after* comparison is the golden opportunity: - Stage 3: `sin(twinkleB * (frameCount + star.offset))` — raw math - Stage 5: `new SWSinusoid(...)` — same math, named and encapsulated That before/after is genuinely powerful for teaching abstraction. But it works precisely because Stage 3 came first. Don't skip ahead. ### Decision: keep SketchWave separate for now Continue building SketchWave as its own ecosystem. When a Processing CT entry reaches the stage where a SketchWave upgrade is natural (like Henry's Ghost Stage 5), that becomes the first explicit bridge between the two areas — a deliberate "graduation" moment that can be documented as a teaching design choice. --- ## Home Page Card Strategy ### Should `index.html` get a separate "Cross Training: Creative Coding" card? **Yes — but only when the hub is live, not before.** The reasoning follows directly from the core distinction already established above. Two different areas with genuinely different audience intents warrant two different cards. A student who arrives at TNT through the visual/artistic door and sees a card labeled "Cross Training" with a dumbbell icon and copy about "CS concepts" and "the interview room" will scroll right past it. A card with a live or striking Processing image, titled "Creative Coding" or "Processing Studio," is the card that stops them. #### The practical case for two cards The current "Cross Training" feature card (`index.html`, ~line 373) reads: > *"Same idea, different language. See how TNT concepts translate from JavaScript or p5.js into Java, Python or Processing — and discover what each language reveals about itself."* The mention of "Processing" in that description is already a muddying seam — it hints at something that belongs in the new area. When the split happens, the existing card's description must be tightened to clearly signal CS-concepts / interview-prep, so visitors understand immediately which door they're walking through. #### Timing rule **Do not add the second card until `ProcessingCrossTraining/processingCTHome.html` is live with at least one complete entry** (Henry's Ghost / Twinkling Stars is the natural first candidate). A placeholder card for an area that doesn't exist yet trains visitors to skip cards — and they don't come back. #### Card design for "Cross Training: Creative Coding" - **Badge:** `🎨 New!` (amber) — signals artistic focus, mirrors the `🏋️ New!` badge on the CS card - **Icon:** 🎨 or a Processing-themed icon - **Hero image:** `HenrysGhostTwinklingStars2026-09-24/` screenshot, the purple star-field, or a compact live p5.js canvas embedded directly in the card (more ambitious but striking — the hub itself becomes a gallery) - **Title:** "Creative Coding" or "Processing Cross Training" (see Open Questions below for naming) - **Description:** *"Same sketch, three flavors of Processing. See a p5.js canvas come to life, then compare the identical logic in Python Processing and Java Processing — side by side, stage by stage."* - **Accent color:** purple-family (`#5a1485` or the ghost purple) to visually distinguish from the blue `#1a5c8a` of the CS card #### Grid arithmetic `index.html` currently has 10 feature cards displayed as `col-sm-6 col-md-4` (3 columns at md+): ``` Row 1: SketchWave | Movie Clips | S.P.A.R.K. Speeches Row 2: Innovation | Ask Copilot | Image Gallery Row 3: DWR+Eureka | Adventures | Cross Training (CS) Row 4: Legacy TNT | (gap) | (gap) ← orphan ``` Adding the Creative Coding card brings the count to 11: ``` Row 1: SketchWave | Movie Clips | S.P.A.R.K. Speeches Row 2: Innovation | Ask Copilot | Image Gallery Row 3: DWR+Eureka | Adventures | Cross Training (CS) Row 4: Creative Coding CT | Legacy TNT | (gap) ← two orphans, centered ``` Functionally fine with `justify-content-center` — orphan cards center themselves. Aesthetically, placing the two Cross Training cards adjacent in the same row is the better choice: visually they form a natural "Cross Training family." This means shifting Legacy TNT one slot and placing the new card right after the existing CT card. Ideal final row order (rows 3–4): ``` Row 3: DWR+Eureka | Adventures | Cross Training: CS Concepts Row 4: Cross Training: Creative Coding | Legacy TNT | (gap, centered) ``` Or, if a 12th card ever arrives (say, SketchWave Deep Dives), four clean rows of three. #### Future consideration: grouping the learning-systems cards After Creative Cross Training went live, we discussed whether the home page destination tiles should be rearranged so that **SketchWaveJS**, **Cross Training: CS Concepts**, and **Creative Cross Training** appear together. Conceptually, the grouping is strong: - **Creative Cross Training** teaches raw Processing / p5.js sketch logic through visual projects. - **Cross Training: CS Concepts** teaches transferable programming ideas across languages. - **SketchWaveJS** shows what happens when those visual and conceptual patterns become a reusable graphics library. The advantage of grouping them is that visitors immediately see a coherent TNT learning pathway rather than three related venues scattered around the grid. It signals that TNT is not only a gallery of apps, but an intentionally designed curriculum ecosystem. It also helps the new Creative Cross Training card inherit meaning from the already-established SketchWaveJS and CS Cross Training cards. The risk is navigation churn. Returning students and regular guests often remember a site spatially: SketchWave first, Movie Clips nearby, Cross Training farther down, Legacy near the end. Moving too many cards at once can make the site feel less stable even if the new order is more logical. Because TNT should feel professional and dependable, rearrangement should be rare, deliberate, and ideally explained through a small News entry rather than done silently. Two possible approaches: **Conservative option (least disruptive):** keep SketchWaveJS in the first position and place the two Cross Training cards together on the next row or near their current location. This preserves the familiar flagship top-left tile while still making the two Cross Training areas visible siblings. ```text Row 1: SketchWaveJS | Movie Clips | S.P.A.R.K. Speeches Row 2: CS Cross Training | Creative Cross Training | Dept. of Innovation ``` **Stronger grouping option (clearer curriculum story):** put the three learning-system cards together as the first row. ```text Row 1: SketchWaveJS | CS Cross Training | Creative Cross Training Row 2: Movie Clips | S.P.A.R.K. Speeches | Dept. of Innovation Row 3: Ask Copilot | Image Gallery | DWR & Eureka Row 4: Adventures | Legacy TNT | (gap) ``` Recommendation for now: prefer the conservative option unless there is a broader home-page refresh. If the stronger grouping is chosen later, make it a one-time intentional change and announce it as the new "learning systems" family so returning visitors understand why the layout changed. #### The "All Sections" page-card grid `index.html` also has a compact page-card grid (`col-6 col-sm-4 col-md-3`) with 14 entries. Add a matching page card for the Creative Coding area immediately adjacent to the existing Cross Training card — same timing rule applies (live area first). #### Cross-linking between hubs When both are live, each hub's back-bar or hero section should carry a visible sister-area link: - `crossTrainingHome.html` → *"Also: [Cross Training: Creative Coding →](../ProcessingCrossTraining/processingCTHome.html)"* - `processingCTHome.html` → *"Also: [Cross Training: CS Concepts →](../CrossTraining/crossTrainingHome.html)"* This means a student who arrives at the wrong hub for their intent can pivot in one click, not three. --- ## Immediate Next Steps 1. ✅ Decision made: build separate Processing Cross Training hub 2. ✅ Decision made: separate `index.html` feature card (add when hub is live, not before) 3. Decide on folder name and hub title (see Open Questions — naming) 4. Build `ProcessingCrossTraining/processingCTHome.html` — hub page, one live card (Twinkling Stars), one placeholder 5. Add `processingCTChatlog.html` — begin development diary at Session 1 6. Add news entry for launch 7. **After hub is live:** add "Cross Training: Creative Coding" feature card to `index.html` adjacent to the existing CT card; update existing CT card description to say "CS Concepts" explicitly 8. **After hub is live:** add corresponding page-card to `index.html` "All Sections" grid 9. Add sister-area links to both `crossTrainingHome.html` and `processingCTHome.html` 10. Add "See also: Processing Cross Training" note to `henrysPythonicGhost.html` --- ## Open Questions - **Name:** "Processing Cross Training" is descriptive but long. Alternatives: "Creative Coding Lab", "Processing Studio", "Cross Training: Creative Coding". The "Cross Training" prefix preserves the family connection; "Creative Coding" signals the artistic focus. - **Hero image:** The ghost/purple theme from `henrysPythonicGhost.html` works well as a seed. A p5.js-generated hero canvas would be even more on-brand. - **Python Processing scope:** The desktop Python Processing IDE is required for students to run `.py` sketches locally. The p5.js version always runs in the browser. A note clarifying this tooling distinction should appear in every Processing CT entry's "How to run" callout. - **Java Processing scope:** Processing Java mode requires the Processing IDE. Same tooling note needed. JDoodle does not support Processing Java mode, so the "Try It" link model from current CT doesn't directly apply — the download-and-run model (same as current Java demos) is the right approach.