Skip to content

Make the runbook scroll story shorter and let it play on its own - #702

Merged
gerardrecinto merged 2 commits into
masterfrom
fix-runbook-story-pace
Oct 31, 2026
Merged

gerardrecinto merged 2 commits into
masterfrom
fix-runbook-story-pace

Conversation

@gerardrecinto

Copy link
Copy Markdown
Collaborator

On the homepage, the pinned db-maintenance runbook is driven only by scrolling. A visitor needed about 3.5 screens of scrolling to light all five rows, and if they stopped, it stayed on row 1. On a phone that reads as the page being stuck loading.

This shortens the scroll track and lets the rows play on a timer once the stage is on screen. Scrolling still wins whenever the visitor is ahead of the timer. Reduced-motion visitors are unchanged and still get the finished story.

  • Intro track 150vh to 120vh, pinned runbook 340vh to 250vh.
  • Rows advance on their own: the first after 0.7 s, then one every 1.1 s.

Measured on a local build with Chromium, from the start of the story to all five rows lit:

scroll needed rows lit after 6 s idle
before 3.55 screens (phone), 3.50 (desktop) 1 of 5
after 2.45 screens (phone), 2.50 (desktop) 5 of 5

For the rest of the page I measured the live site with a cold cache on throttled 4G and a 4x CPU slowdown: loaded in about 1.7 s, 52 KB transferred, no layout shift, no long tasks while scrolling, and the engine active at about 10 s. I found nothing else on the homepage worth changing, so this PR only touches the story.

Tests: one new test (rows play without scrolling). Homepage, sound, animation, accessibility and hero tests pass on Chromium, WebKit, Firefox, mobile Chrome and mobile Safari (330 passed).

Not checked: real devices. The numbers above are synthetic.

Thanks,
Gerard

The pinned runbook needed about 3.5 screens of scrolling before all five rows were lit, and stayed on row 1 until the visitor kept scrolling. On a phone that reads as the page being stuck loading.

Shorten the scroll track (intro 150vh to 120vh, pin 340vh to 250vh) and advance the rows on a timer once the stage is on screen. Scrolling still wins when the visitor is ahead of the timer.

Thanks,
Gerard
@gerardrecinto gerardrecinto self-assigned this Oct 31, 2026
@github-actions

Copy link
Copy Markdown

Gemini PR Review

Reviewed commit: d6f36a909c782d23e27878def966ef1cf9d52be7
Verdict: FAIL

  • demo/index.html - The autoTimer is not cleared when the auto-play conditions are no longer met (e.g., when the user scrolls the "pin" element out of the auto-play active zone, specifically when pr.top > vh * 0.9). This can lead to an existing timer firing unexpectedly, causing auto to increment and frame() to be called when the feature is not active, potentially causing incorrect state or unintended visual updates. It also prevents a new, correctly timed autoTimer from being set if the user scrolls away and then quickly back to the auto-play zone before the initial timer fires. The clearTimeout(autoTimer) should be called when auto is reset or when the auto-play condition becomes false.

This result blocks merge. Push a fix and comment /gemini review. To contest a finding, see the Gemini dispute process in CONTRIBUTING.md.

@gerardrecinto

Copy link
Copy Markdown
Collaborator Author

/gemini review

The pending tick is now cleared whenever the stage is off screen, so it cannot advance the rows while nobody is looking at them. Story tests pass on Chromium, WebKit, Firefox, mobile Chrome and mobile Safari.

Thanks,
Gerard

@github-actions

Copy link
Copy Markdown

Gemini PR Review

Reviewed commit: 30138a8c316ec1b375472d320e1fb52e7468c625
Verdict: PASS

There are no actionable findings.

@gerardrecinto
gerardrecinto merged commit 233a3f6 into master Oct 31, 2026
36 of 37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant