Scrolly English Speaking preview
Situation
Workplace English (A2–B1) stalls for many Russian-speaking specialists: the grammar is there, coherent speech is not
Task
Close the gap between grammar and live speech: give learners situations where phrases are used, not recognized
Action
Single ScrollyLayout, MDX narrative sections, typed data module for viz props, IntersectionObserver with lazy imports
Result
Narrative and visualization in sync: the chart changes as the reader reaches a paragraph; a new scene is just a data file plus MDX
Stack
AstroTypeScriptMDXD3Tailwind v4
Source View on GitHub → Updated: Nov 1, 2026
On this page
  1. Situation
  2. Task
  3. Actions
  4. Result
  5. Limitations
  6. Documentation

Scrolly English Speaking

▶ Architecture diagram — self-contained HTML, opens in a browser — no install, no build

Situation

Workplace conversations in English (standups, syncs, interviews) are a weak spot for many Russian-speaking specialists at A2–B1: the grammar is there, but coherent speech and real-time reactions stall. A textbook doesn’t help much: no context, no visuals, no link between phrases and situation.

The task is to build not an article but an interactive guide, where a narrative leads the reader through workplace-conversation scenes and visualizations show how the workflow, tools, and progress metrics are structured.

Task

I needed learners to practice workplace English inside a real situation rather than from a textbook, so I owned the interactive guide, its narrative scenes, and the visuals that carry the context.

Actions

Stack: Astro 6 (output: static) + MDX + Tailwind v4 (via @tailwindcss/vite), D3 v7 for visualizations, Shiki (nord theme) for code, @astrojs/sitemap. Deploy to GitHub Pages subpath, Node 22.

Architecture:

  • src/layouts/ScrollyLayout.astro — single template: hero, 2-column scrolly, viz panels, head meta.
  • src/posts/scrolly/*.mdx — narrative (section text) with <ScrollySection> blocks.
  • src/scrolly/data/*.ts — configId + sections + viz props + theme. Trusted HTML source: hero/footer always come from the data module, never from frontmatter — injection guard.
  • src/scrolly/scrolly-runtime.ts — IntersectionObserver, switchViz, theme-toggle; viz renderers via lazy import.

Content model: MDX frontmatter (configId, metadata, theme) is safely merged on top of the trusted data module. Hero/footer HTML always from data/*.ts, never from frontmatter.

Result

Synchronizing narrative and visualization holds attention better than a static article with pictures: the reader reaches a paragraph and at that moment the chart on the right changes. Splitting MDX and data modules solves the core pain of static sites — mixing text and logic: the narrative stays editable in Markdown, and the visualizations stay typed in TypeScript. A new scene is a new data file + MDX, with no rendering changes.

Limitations

The guide targets A2–B1 and covers workplace scenarios, not general English; the material is the author’s and has not been reviewed by a methodologist. Decoupling content from data modules guards against frontmatter injection, but not against the content itself.

Documentation

Need this reasoning applied to your data?

Tell me the task — I'll come back with a plan: what data it needs, what we test, and how long it takes. I reply within a day.

Discuss a task →