WPM mapping

[ds300]

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 ws (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!

[matt-gardner]

Do you need to have a separate corpus to estimate this ratio? Can't you just compute it directly when you're parsing the DOM? After you've gone through the tokens, you know what your total delay is. So you can adjust the speed accordingly, or just tell the user what their actual WPM is, and let them adjust the speed if they wish.

[ds300]

Can't you just compute it directly when you're parsing the DOM?

Two issues with this:

1. It could lead to dense prose with no dialogue and/or long sentences being much harder to read than documents with short sentences and/or lots of dialogue. I think providing a consistent speed for the user should be a given.
2. The new parsing stuff I'm working on extracts tokens from the DOM lazily, for performance reasons, so we can only tell the length of the document in characters to begin with.