Very interesting, thank you for making it and releasing it for free!
Do you get faster as you practice reading like that? I read ~50-60 pages per hour in English. That would be maybe 375-425 words per minute and also seems to be about the maximum I can more or less follow with ReadKinetic just trying the demo text.
Although, I don't feel like I understand quite as well what I have just read and it felt a bit aggravating? Almost anxiety inducing for some reason. Maybe it's just because it is a new thing and I'm not used to it.
Also, as others have mentioned, the controls took a bit of time to figure out.
Oh nice, the pre-processing hooks are a way cleaner way of solving the format issue than I was doing. When you are on the terminal you can shell out to pdftotext or pandoc and people use the format convertor that they already know and trust. But when you are writing stuff for the browser you have to include the format convertors in the download so I was including pdf.js, JSZip and mammoth in the build and still could not handle formats that I had not seen.
Your method also nicely solves that thing that I keep on getting asked for which is copy and paste a url and have it fetch the article and display the text. I had somebody email me about that today! On the terminal you just get something like: curl some_url | readable and you are pretty much done. On the browser it's a cross origin request so you will want to include a server that fetchies it and well that would kinda be missing the point of having local rendering.
Something that i was wondering is if monospaced text would have made it easier for you to find the alignment for the pivot? Fixed-width is simple, since your optimal offset is just a character offset. For proportional text i'm just taking my best effort pivot character and anchoring it, and then extending word fragments from that point in both directions. Otherwise the words can tend to wander as you eye flows from character to character.
Great idea, great execution! Took me a while, but I got used to controls.
The only small annoyance i had was the “saved” notification popping up making me miss a few words. Would love a “zen” mode with no UI other than the text.
The saved toast is a reasonable hit and frankly is worse than annoying. The whole format is based on your eyes never having to leave the same area, so popping anything up next to the word display forces exactly the saccade you are designed to eliminate. It directly attacks the one function it is designed to fulfil. There’s no need for Auto-save to pop anything up at you either; it never received a request to save and there is no need to echo that action back at you.
Good call on Zen-mode, and I’m of the opinion that is what should be the default, once you start reading; when words begin moving make thechrome fade out, when words stop, make it reappear. I will consider both of these.
Was the control issue the Hold to Read option, out of interest? Just wondering what it was.
Intuitively, i thought there would be a toggle to play, and that I would be able to maybe pause by holding, and then scrubbing up/down (or left/right).
Yeah the toggle is there-double press and it locks it into playing continually. But if you didn't find it, that’s on me because it’s not discoverable. There is that line of text at the top which says hold to read, left/right to scrub, and obviously if that isn’t making clear there is another mode of play lurking just behind a gesture no one ever brings up.
I did default to hold because the read stops the instant you are not reading – if your attention is drifting, words aren't racing on ahead.
Which felt right for an application whose whole purpose is concentration. But you are almost certainly going to react the way most people will, and there should be an easy toggle instead of one you’re only likely to find when you stumble over it by accident. Scrub is already mapped to left and right-up and down would be an excellent match to speed, never thought of it that way until you said it. Let me know how you get on with the longer pieces, that’s where I’d expect either that it just clicks (or fails miserably).
Wow that was a fascinating experience - honestly the biggest revelation for me is how much I skim content without realizing it. Reading and remembering every single word, one at a time, and comprehending what was being said was more effort than I expected! I also took away how much I need the inter-word formatting to keep track of what's being said
Yeah, the skimming thing surprised me too when I started looking into it. In regular reading, people skip about a quarter to a third of the words, mainly small ones like "the" and "of." Your eyes grab the next word or two out of the corner of your eye before you actually see them.
With RSVP, you save the eye movement, but you also lose the skipping. You have to look at every word, no matter if it’s important or not. Those two factors might balance each other out, which I think is a big reason the actual speed gain is much less than what most speed reading products promise.
The formatting issue you brought up is something I haven’t figured out. You miss line breaks, the shape of paragraphs, punctuation that sits in your peripheral vision, and even just keeping track of where you are on the page. I add longer pauses at punctuation to restore some of the sentence rhythm, but the structure of paragraphs and dialogue is still missing. That’s why it doesn’t work for me with fiction that has a lot of dialogue.
Thanks. Calibre’s crossed my mind a few times, the obvious hook is the content server, but the browser integration makes it clunky. Calibre-server doesn’t spit out CORS headers that you can use from another origin, so a web app can’t just read your library over HTTP unless you do a bit of reconfiguring it, and making people set CORS flags just for my little tool seems like a bad bargain.
The avenue that actually looks viable is directory import. Calibre keeps everything as normal files in Author/Title folders with a metadata.opf next to each book, so if I point a directory picker at your library directory, I can traverse it, grab the opf file to get the actual title/author rather than having to guess based on the filename, and then suck the epub files directly in. Would be a properly slick bulk import.
Catch is the File System Access API only works in Chromium at present, so anyone using Firefox/Safari would still be forced to pick their files one by one. Would be a worthwhile trade-off though as it gracefully degrades.
Nice idea. I like the local-first approach. How are you handling large EPUB or PDF files? Have you noticed any performance issues with very large books?
Thanks. The parsing cost is the entire one-time cost, the rest of the operation involves simply walking an array of words, a 900 page novel and a short story will perform the exact same. There is essentially zero cost in rendering a word at a time no matter the size of the book.
PDF is significantly the worst. We use pdf.js, and it has to page by page to retrieve the text layer, so a large book takes a little while and the tab feels 'busy' while doing so. EPUBs are considerably faster, it's mostly a case of unzipping and parsing xhtml.
The main thing that was the difference maker was separating storage into two IndexedDB stores, one for metadata, and one for the full text. When we open the library list we only read from the metadata store, not pulling the entire content of all books you own into memory. We only pull in the one you actually want to read.
The biggest edge case by far are scanned PDFs that have no text layer (there is no OCR, so nothing is returned) that are currently not failing audibly enough to make it clear.
Thanks. To be frank, the images and graphs are the weak spot at the moment. The parsers extract just the text layer and that’s the extent of it, so images are just discarded and you don’t even get told there was one.
Tables are worse than dropped - PDF extraction de-flattens them into a stream of values in reading order, so you just get a torrent of disconnected numbers flitting past which don’t mean a great deal.
I would read figures in the normal way for this type of book and then use the tool for the prose. It’s not really fixable at the format level too, there is no good way of showing a person a graph word by word. I suppose what I really should add is some kind of flag to say there was a figure here instead of just letting the process go ahead and drop everything. Otherwise, you can’t really know that you’re missing things.
i have tried variations of this many time, it personally doesn't work for me. the word flashes into my brain, and i can keep up with "reading" at high wpm's, but the whole sentence doesn't register. i am not seeing the forest because of all the trees.
Thanks, that's the detail I was most hoping someone would pick up on.
It started as a flat interval and felt terrible. Every word got the same slot, so sentences never landed and it read like a stock ticker.
Now there's a base duration from the WPM setting, with per word multipliers on top: 3x on sentence-ending punctuation, 2x on commas and semicolons, and an extra 0.7x if the word is 8 characters or longer.
The punctuation weights came from reading passages out loud and noticing where I actually stopped. Those are the breath points, so giving them proportionally more time puts the sentence structure back in. The long word bump is closer to the eye tracking literature, where fixation duration scales with word length. It felt wrong for a 12 letter word to get the same slot as "the".
The actual numbers were tuned by ear over a lot of real reading. I tried syllable estimates and word frequency weighting too, but neither was noticeably better than punctuation plus length, and they made the rhythm less predictable, which turned out to matter more than being clever.
This is a great experience. I wonder how an e-ink friendly version would look like. I don't think word by word would work but maybe sentence by sentence? but then would that break the effect? Either way, I'll definitely try with a book I've been procrastinating on reading ahahah.
E-ink is the frustrating part because it's where people actually read books, yet it's the display least capable of doing this. Partial refresh allows for a handful of updates each second, but it comes with ghosting. At 300 words per minute, which is a word every 200 milliseconds, you'd be reading through the residue of the last two or three words. Full refresh clears that, but it flashes the entire panel and takes long enough that you would only read about a word per second.
Your idea about sentences does affect the experience, but I don’t believe that makes it worse; it’s just a different approach. Once a whole sentence appears on screen, your eyes move across it again, so the no eye movement part is lost. What remains is the return sweep, the long jump back to the start of the next line, and the moment when you lose your place on a dense page. Those are real challenges in normal reading, and chunking by sentence removes both. You would end up closer to guided pacing than RSVP, which might suit a book better anyway.
Let me know how the procrastinated book turns out.
Very interesting, thank you for making it and releasing it for free!
Do you get faster as you practice reading like that? I read ~50-60 pages per hour in English. That would be maybe 375-425 words per minute and also seems to be about the maximum I can more or less follow with ReadKinetic just trying the demo text.
Although, I don't feel like I understand quite as well what I have just read and it felt a bit aggravating? Almost anxiety inducing for some reason. Maybe it's just because it is a new thing and I'm not used to it.
Also, as others have mentioned, the controls took a bit of time to figure out.
I have a similar project for speed-reading in the terminal: https://github.com/0hAodha/ogma
It works on plaintext, but you can define pre-processing hooks to convert, e.g., a PDF or webpage into readable content using the config file.
Oh nice, the pre-processing hooks are a way cleaner way of solving the format issue than I was doing. When you are on the terminal you can shell out to pdftotext or pandoc and people use the format convertor that they already know and trust. But when you are writing stuff for the browser you have to include the format convertors in the download so I was including pdf.js, JSZip and mammoth in the build and still could not handle formats that I had not seen.
Your method also nicely solves that thing that I keep on getting asked for which is copy and paste a url and have it fetch the article and display the text. I had somebody email me about that today! On the terminal you just get something like: curl some_url | readable and you are pretty much done. On the browser it's a cross origin request so you will want to include a server that fetchies it and well that would kinda be missing the point of having local rendering.
Something that i was wondering is if monospaced text would have made it easier for you to find the alignment for the pivot? Fixed-width is simple, since your optimal offset is just a character offset. For proportional text i'm just taking my best effort pivot character and anchoring it, and then extending word fragments from that point in both directions. Otherwise the words can tend to wander as you eye flows from character to character.
Great idea, great execution! Took me a while, but I got used to controls. The only small annoyance i had was the “saved” notification popping up making me miss a few words. Would love a “zen” mode with no UI other than the text.
Thanks, I'm glad the controls eventually clicked.
The saved toast is a reasonable hit and frankly is worse than annoying. The whole format is based on your eyes never having to leave the same area, so popping anything up next to the word display forces exactly the saccade you are designed to eliminate. It directly attacks the one function it is designed to fulfil. There’s no need for Auto-save to pop anything up at you either; it never received a request to save and there is no need to echo that action back at you.
Good call on Zen-mode, and I’m of the opinion that is what should be the default, once you start reading; when words begin moving make thechrome fade out, when words stop, make it reappear. I will consider both of these.
Was the control issue the Hold to Read option, out of interest? Just wondering what it was.
Nice!
Intuitively, i thought there would be a toggle to play, and that I would be able to maybe pause by holding, and then scrubbing up/down (or left/right).
But great work! Will try on a longer text.
Yeah the toggle is there-double press and it locks it into playing continually. But if you didn't find it, that’s on me because it’s not discoverable. There is that line of text at the top which says hold to read, left/right to scrub, and obviously if that isn’t making clear there is another mode of play lurking just behind a gesture no one ever brings up.
I did default to hold because the read stops the instant you are not reading – if your attention is drifting, words aren't racing on ahead.
Which felt right for an application whose whole purpose is concentration. But you are almost certainly going to react the way most people will, and there should be an easy toggle instead of one you’re only likely to find when you stumble over it by accident. Scrub is already mapped to left and right-up and down would be an excellent match to speed, never thought of it that way until you said it. Let me know how you get on with the longer pieces, that’s where I’d expect either that it just clicks (or fails miserably).
Wow that was a fascinating experience - honestly the biggest revelation for me is how much I skim content without realizing it. Reading and remembering every single word, one at a time, and comprehending what was being said was more effort than I expected! I also took away how much I need the inter-word formatting to keep track of what's being said
Yeah, the skimming thing surprised me too when I started looking into it. In regular reading, people skip about a quarter to a third of the words, mainly small ones like "the" and "of." Your eyes grab the next word or two out of the corner of your eye before you actually see them.
With RSVP, you save the eye movement, but you also lose the skipping. You have to look at every word, no matter if it’s important or not. Those two factors might balance each other out, which I think is a big reason the actual speed gain is much less than what most speed reading products promise.
The formatting issue you brought up is something I haven’t figured out. You miss line breaks, the shape of paragraphs, punctuation that sits in your peripheral vision, and even just keeping track of where you are on the page. I add longer pauses at punctuation to restore some of the sentence rhythm, but the structure of paragraphs and dialogue is still missing. That’s why it doesn’t work for me with fiction that has a lot of dialogue.
Cool idea!
Maybe you could somehow integrate it with Calibre [0].
https://calibre-ebook.com/download
Thanks. Calibre’s crossed my mind a few times, the obvious hook is the content server, but the browser integration makes it clunky. Calibre-server doesn’t spit out CORS headers that you can use from another origin, so a web app can’t just read your library over HTTP unless you do a bit of reconfiguring it, and making people set CORS flags just for my little tool seems like a bad bargain.
The avenue that actually looks viable is directory import. Calibre keeps everything as normal files in Author/Title folders with a metadata.opf next to each book, so if I point a directory picker at your library directory, I can traverse it, grab the opf file to get the actual title/author rather than having to guess based on the filename, and then suck the epub files directly in. Would be a properly slick bulk import.
Catch is the File System Access API only works in Chromium at present, so anyone using Firefox/Safari would still be forced to pick their files one by one. Would be a worthwhile trade-off though as it gracefully degrades.
Nice idea. I like the local-first approach. How are you handling large EPUB or PDF files? Have you noticed any performance issues with very large books?
Thanks. The parsing cost is the entire one-time cost, the rest of the operation involves simply walking an array of words, a 900 page novel and a short story will perform the exact same. There is essentially zero cost in rendering a word at a time no matter the size of the book.
PDF is significantly the worst. We use pdf.js, and it has to page by page to retrieve the text layer, so a large book takes a little while and the tab feels 'busy' while doing so. EPUBs are considerably faster, it's mostly a case of unzipping and parsing xhtml.
The main thing that was the difference maker was separating storage into two IndexedDB stores, one for metadata, and one for the full text. When we open the library list we only read from the metadata store, not pulling the entire content of all books you own into memory. We only pull in the one you actually want to read.
The biggest edge case by far are scanned PDFs that have no text layer (there is no OCR, so nothing is returned) that are currently not failing audibly enough to make it clear.
I like it. Feels solid and cool. I read a lot of books with some images and graphs how they get processed?
Thanks. To be frank, the images and graphs are the weak spot at the moment. The parsers extract just the text layer and that’s the extent of it, so images are just discarded and you don’t even get told there was one.
Tables are worse than dropped - PDF extraction de-flattens them into a stream of values in reading order, so you just get a torrent of disconnected numbers flitting past which don’t mean a great deal.
I would read figures in the normal way for this type of book and then use the tool for the prose. It’s not really fixable at the format level too, there is no good way of showing a person a graph word by word. I suppose what I really should add is some kind of flag to say there was a figure here instead of just letting the process go ahead and drop everything. Otherwise, you can’t really know that you’re missing things.
i have tried variations of this many time, it personally doesn't work for me. the word flashes into my brain, and i can keep up with "reading" at high wpm's, but the whole sentence doesn't register. i am not seeing the forest because of all the trees.
I like how it pauses near where I would normally pause while reading. How did you choose the cadence?
Thanks, that's the detail I was most hoping someone would pick up on.
It started as a flat interval and felt terrible. Every word got the same slot, so sentences never landed and it read like a stock ticker.
Now there's a base duration from the WPM setting, with per word multipliers on top: 3x on sentence-ending punctuation, 2x on commas and semicolons, and an extra 0.7x if the word is 8 characters or longer.
The punctuation weights came from reading passages out loud and noticing where I actually stopped. Those are the breath points, so giving them proportionally more time puts the sentence structure back in. The long word bump is closer to the eye tracking literature, where fixation duration scales with word length. It felt wrong for a 12 letter word to get the same slot as "the".
The actual numbers were tuned by ear over a lot of real reading. I tried syllable estimates and word frequency weighting too, but neither was noticeably better than punctuation plus length, and they made the rhythm less predictable, which turned out to matter more than being clever.
This is a great experience. I wonder how an e-ink friendly version would look like. I don't think word by word would work but maybe sentence by sentence? but then would that break the effect? Either way, I'll definitely try with a book I've been procrastinating on reading ahahah.
E-ink is the frustrating part because it's where people actually read books, yet it's the display least capable of doing this. Partial refresh allows for a handful of updates each second, but it comes with ghosting. At 300 words per minute, which is a word every 200 milliseconds, you'd be reading through the residue of the last two or three words. Full refresh clears that, but it flashes the entire panel and takes long enough that you would only read about a word per second.
Your idea about sentences does affect the experience, but I don’t believe that makes it worse; it’s just a different approach. Once a whole sentence appears on screen, your eyes move across it again, so the no eye movement part is lost. What remains is the return sweep, the long jump back to the start of the next line, and the moment when you lose your place on a dense page. Those are real challenges in normal reading, and chunking by sentence removes both. You would end up closer to guided pacing than RSVP, which might suit a book better anyway.
Let me know how the procrastinated book turns out.