Another side-issue we need to deal with is that although the 70 templates we've created contain code to enable them to run on touch-screens, the graphics loose their functionality when run on Android ( and most likely on I-Phones ) phones.
How do we go about solving this ?
Claude Sonnet 5 Said :
" Let me actually look at the drag/touch handling code directly rather than guess — that'll tell us more than symptoms alone would.
Ran 3 commands, viewed a file
That's a real, confirmed issue — I found the root cause by comparing your drag-coordinate code directly rather than guessing. Here's what's actually happening.
The root cause: most templates convert a touch/mouse position into SVG coordinates one of two ways. The robust way — already established as project convention — is getScreenCTM().inverse(), which reads the SVG's actual live transform matrix, so it's correct no matter how the SVG is scaled or positioned on screen. The fragile way is getBoundingClientRect() with hand-rolled ratio math, e.g. in ROM-GTCV-Generic's frame-drag function:
js
const svgRect = svg.getBoundingClientRect();
const svgX = ((clientX - svgRect.left) / svgRect.width) * 160 - 30;
This assumes the SVG's viewBox maps edge-to-edge onto its bounding box. It doesn't. SVGs default to preserveAspectRatio="xMidYMid meet", which letterboxes — adds invisible padding on the sides or top/bottom — whenever the container's aspect ratio doesn't exactly match the viewBox's. Desktop browser windows happen to land close enough to the assumed ratio that the error is small and easy to miss. Phone screens — especially portrait orientation — are far more extreme, so the padding is much bigger, and the ratio math ends up pointing at completely the wrong spot on the curve. That reads exactly like "the graphics lose functionality": the frame either won't track your finger, jumps to the wrong place, or sticks.
The interesting part: this exact lesson is already recorded as a project convention ("always use getScreenCTM().inverse() — getBoundingClientRect() is fragile") — but it clearly wasn't applied uniformly everywhere it needed to be. I checked across families to see how widespread this actually is:
File
Uses getBoundingClientRect
Uses getScreenCTM
ROM-GTCV (frame drag)
yes
no (but text drag in same file does)
ROM-GT5L-7TB
yes
yes (mixed)
ROM-DU
yes only
—
ROM-VL
yes only
—
ROM-HL-BI
yes
yes (mixed)
ROM-IT5L
no
yes only — clean
LOG-CR-CLK
neither (different UI paradigm, click-based)
—
So it's real, it's inconsistent rather than universal, and it's mechanical to fix once identified — not a redesign, just swapping the coordinate-conversion method to the one that's already correct elsewhere in the same files.
Proposed approach, matching how we handled the HL sliding-text sweep: fix one file first as a test case, have you confirm it actually solves it on your Android phone, then sweep the rest systematically rather than assuming the fix generalizes untested.
I've gone ahead and fixed the test case — ROM-GTCV-Generic.html's frame-drag function now uses the same getScreenCTM().inverse() method its own text-drag function already uses correctly:
Viewing file
This file doesn't have a working copy I can edit directly — project files here are read-only reference copies. Let me copy it to a working location, apply the fix there, and add the required timestamp so you get a ready-to-test file back.
Ran 3 commands, edited 2 files, read a file · 2 notes
One targeted change, nothing else touched: the frame-drag function's coordinate math now matches the correct method the file's own text-drag function already used. Everything else — layout, vocabulary logic, quiz behaviour — is untouched.
What I'd like you to test on your Android phone before we go any further:
Open this file directly (or swap it in for your deployed GTCV template)
Try dragging the frame along the curve in States mode — check it tracks your finger accurately across the full width, including near both edges
Try the text drag in Transitions mode too, just to confirm it still behaves correctly (it wasn't touched, but worth a sanity check)
If you can get an iPhone to test on too, even better — same fix should apply, but Safari's touch-event handling has its own quirks worth confirming independently
If this fixes it, the next step is a systematic sweep: audit every template for getBoundingClientRect used in drag coordinate conversion (I can identify the exact list quickly), fix each one the same targeted way, verify syntax on each, and you test in batches — same workflow as the HL sliding-text sweep. Given the survey above, DU and VL look like they rely on the fragile method with no correct fallback anywhere in the file, so those are worth prioritizing early in that sweep.
If it doesn't fully fix it, that's useful information too — it would point to a second, separate cause (possibly touch-action scope, or something CSS-level in how the phone's browser handles the SVG), and we'd narrow it down from there rather than guessing further.
One housekeeping note: since this is a template already uploaded to your project files, once you've tested and are happy with it, you'll want to replace the version in your conceptionary-app repo — I can't push to GitHub directly.
" 4th of September 2026