ds300 / ds300/jetzt

WPM mapping

Open
#27 2 comments 0 reactions 0 assignees View on GitHub
enhancement starter
Dominant language
JavaScript
Stars
500
Forks
125
PR merge metrics
No merged PRs in 30d

Description

The number shown at the bottom-right corner is not currently an accurate WPM measure, but more of a semi-arbitrary speed measure. This was raised by #23 .

There is no way to get a 100% accurate WPM measure all of the time, since different passages of text can have radically different properties when it comes to the things which jetzt inserts extra pauses for, e.g. ends of sentences/paragraphs, quoted sections, commas, long words, etc.

So a simple way to at least make the number in the bottom-right corner an _approximate notion_ of the current WPM would be as follows:

_first, let's denote jetzt's internal speed by_ `s`
1. Gather lots of text from different types of sources, (Novels, blog posts, news-wire, etc), such that the text is comprised of `n` words.
2. Calculate the number of minutes `t` that it would take jetzt to display all of the text with `s` = 1.
3. Then calculate actual WPM `a` = `n` / `t`.
4. This forms a ratio which we can use to map the desired WPM to `s`. i.e, if the user wants to go at some specific WPM `w`, we set `s` = `w` / `a`.

At the moment I think there is a linear relationship between `s` and `a`, but that might not always be the case (plus the delay modifiers might change with user feedback). So I think it would be best to build a tool that could do the above for different values of `s` and output an if statement which provides values of `a` for a sensible range of `w`s (e.g. 200-1500wpm in 100wpm intervals) which we could then copy and paste into jetzt.js.

Obviously we shouldn't store the text corpus in the jetzt repo, but it would be good to upload it somewhere publicly.

Anyone want to do this? Should be fun!

Contributor guide

Open the contributing guide

Research direction

Start by reading jetzt.js, where the proposed WPM mapping would be used, and review the issue's corpus and timing procedure. Define how the calibration tool will gather or consume representative text and produce mappings for the stated WPM range; done means the output can be copied into jetzt.js and the displayed WPM is an approximate measure.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.