Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| a5819f0c72 |
@@ -9,6 +9,30 @@ Format: [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) — versi
|
||||
|
||||
---
|
||||
|
||||
## [1.1.2] — 2026-05-27
|
||||
|
||||
### Fixed — High WPM in Sentence / Paragraph modes was clamped by a too-conservative minimum-display floor
|
||||
|
||||
After v1.1.1 raised the WPM cap to 3000 in Sentence and Paragraph modes, David noticed that pushing the slider from 1500 to 3000 didn't actually speed up reading — the chunks were still sitting on screen for the same amount of time.
|
||||
|
||||
Root cause: the v1.1.0 minimum-display floor was **1500 ms per chunk** (set conservatively to prevent flash-frame illegibility). At 3000 WPM, any sentence under ~60 words mathematically wants to display for under 1500 ms — but the floor clamped them all to 1500 ms, so the calculated speed-up never reached the user.
|
||||
|
||||
Lowered floors:
|
||||
- **Sentence mode**: 1500 ms → **400 ms** (eye can absorb a short sentence in well under half a second once it's on screen)
|
||||
- **Paragraph mode**: 1500 ms → **800 ms** (paragraphs are denser; need slightly more time even at high WPM)
|
||||
|
||||
Maximum cap stays at 12 s for very long paragraphs at very low WPM.
|
||||
|
||||
At 3000 WPM with the new floors, a 20-word sentence displays for **500 ms** (was 1500 ms — 3× faster) and a 60-word paragraph displays for **1750 ms** (was 1500 ms — uncapped formula now visible).
|
||||
|
||||
This makes the WPM slider actually behave the way users expect: higher WPM = faster reading, all the way up to 3000.
|
||||
|
||||
### Clarification
|
||||
|
||||
The reader does NOT iterate word-by-word inside a chunk in Sentence or Paragraph modes. The whole sentence or paragraph is rendered in one DOM update; only the auto-advance interval is calculated from word count. The word count is used as a proxy for "how long does a reader need to absorb this chunk," not as a per-word display loop.
|
||||
|
||||
---
|
||||
|
||||
## [1.1.1] — 2026-05-27
|
||||
|
||||
### Changed — Mode-aware WPM ceiling
|
||||
|
||||
+15
-5
@@ -250,7 +250,7 @@ textarea:focus {
|
||||
</div>
|
||||
|
||||
<span class="meta" id="meta">Paste text below, drag a .txt file in, then press Play</span>
|
||||
<span class="version">v1.1.1</span>
|
||||
<span class="version">v1.1.2</span>
|
||||
</div>
|
||||
|
||||
<div class="stage mode-word" id="stage">
|
||||
@@ -448,12 +448,22 @@ textarea:focus {
|
||||
const base = 60000 / wpm;
|
||||
return base * pauseMult(chunk);
|
||||
}
|
||||
// Sentence / paragraph: time = words / WPM, with a comprehension multiplier
|
||||
// Sentence / paragraph: in these modes the whole chunk is displayed
|
||||
// in one DOM update — no per-word iteration. We only need to decide
|
||||
// how long to leave the chunk visible before advancing.
|
||||
//
|
||||
// Time = (words in chunk) / WPM × 60 s × comprehension multiplier.
|
||||
// At low WPM the formula dominates. At high WPM the floor kicks in.
|
||||
// v1.1.2: lowered floors significantly — the previous 1.5 s sentence
|
||||
// floor was clamping any value above ~1500 WPM, making 3000 WPM
|
||||
// feel identical to 1500 WPM. Lower floors let high-WPM skim mode
|
||||
// actually skim. The maximum cap stays at 12 s for very long
|
||||
// paragraphs at very low WPM.
|
||||
const wordCount = splitWords(chunk).length;
|
||||
const baseMs = (wordCount / wpm) * 60000;
|
||||
const multiplier = mode === 'sentence' ? 1.25 : 1.40; // brain needs more time on chunks
|
||||
// Sensible bounds: 1.5s min, 12s max
|
||||
return Math.max(1500, Math.min(12000, baseMs * multiplier));
|
||||
const multiplier = mode === 'sentence' ? 1.25 : 1.40;
|
||||
const floor = mode === 'sentence' ? 400 : 800;
|
||||
return Math.max(floor, Math.min(12000, baseMs * multiplier));
|
||||
}
|
||||
|
||||
function tick() {
|
||||
|
||||
Reference in New Issue
Block a user