I like that there is a fallback to read the full text, but why are there two such app modes? I think if the main (non-popup) one should absorb the other's features like scrolling and bookmarks.
For some texts the layout is also important to understand the context. Poems, structured text, paragraph breaks. If you read word by word and stumble into block of structured text, it's a lot of friction to figure out. I would love a background low fidelity representation of paragraphs, like the minimap in code editors, with the current word highlighted there. It could be passively monitored for places to switch mode to reading the full text, and to keep spatial orientation around character dialogs and such. It would have to not draw attention to itself though.
The theme circle icons are not useful, they should preview text background and color.
I see Dyslexic font is already built-in!
Code is not available? It would be fun to hook this to browser extension to fast-read article in a ReadKinetic popup.
I didn't mind the controls at all, they are obviously for touch and not mouse and it seems inspired by video player controls. This is a kind of app that you spend hours with, so better to have more features and options than to be beginner friendly. Very nice app, I like it so far.
The minimap is, in fact, the best idea anyone has given me today (and I think it addresses a concern 3 other people brought up in this thread). The underlying problem with all the suggestions is that you lose all the scaffolding, the paragraph breaks, the line spacing, the sense of where you are in the text that makes it easy to just jump into the text anywhere in the first place. I think this peripheral low fidelity map addresses it because you don't have to actively engage with it. Your concern about the control to not draw attention from the text is the entire point of this design. You can't make it too salient because that makes it steal the focus from the main text, which defeats the entire point.
I already have the info on paragraph and chapter breaks in the reader already, so this is more of a rendering issue rather than info display. The reason why I particularly like your first suggestion is that it lets you know something like a poem or different paragraph style is about to start so you can change your reading pattern accordingly rather than stumbling into it when you're already in prose mode reading at 400 wpm.
On the 2 modes thing, I feel like there isn't really a good reason to do it the other way. It was more that it happened that way rather than it needed to happen that way, and you're right that the main one should probably scroll and have bookmarks rather than making the user make a choice between 2 different interfaces.
Theme circles is definitely a solid suggestion, being a more practical implementation of visualising the underlying theme. Being able to see the actual colours of the background/text rather than an abstract blob is good, so that's a definite maybe.
Code isn't public yet, but extensions are something I've wanted to try for a while. In fact, someone sent me an email this morning asking precisely for that, to be able to paste a link and read articles. It can't be done directly in the page because of CORS policies, and doing it server side would involve routing the reading of articles through my server which is probably not ideal for everyone. An extension that pulls the article from whatever page you're on would be the most ideal version of this, from a privacy standpoint, so I'm considering it.
And finally, your last point is actually the first pushback I've had all day on the controls/interface. As far as 4 other people having difficulty finding the thing, I think you're right that something needs to be done, but I don't think hiding the options behind discovery is really the answer. There is a conflation in my brain between 'controlls are easily found and accessible' and 'controls are not hidden beneath layers of menus/bookmarks', and I think it's a false conflation, I had been treating them as one. Thanks for that.
Nice. I made a similar thing as a TamperMonkey script that I can turn on and off on any website, it even includes a speed-controlled-voice that can read it for me.
One small annoyance with your app is the instructions in the welcome were tiny. Took me well over a minute to figure out how to control the thing, until I finally found those small hand icons in the right corner. You should consider adding these to the first page of welcome using a large-er size or something.
The idea looks cool , i think along with optimization reading time if it also allows you set your frequency and then read the book accordingly it would really make an impact , for i sometimes want to read slowly if the topic is of my interest. Just a suggestion
We've got up and down arrows, or you can drag vertically to adjust. Funny, you're not the only one who missed that today, so the interface definitely isn't making it obvious. Fixing that is definitely a priority for me.
What you're getting at, about having a separate speed for each book, that’s a good idea and worth exploring. Right now, the speed is just one setting for everything. So if you slow things down for a book that needs a more leisurely pace, you have to remember to speed it back up manually when you switch to something else. Someone else mentioned the same thing earlier. It makes sense that it should remember the pace for each book, just like it remembers where you stopped reading.
Sounds like a pointless endeavour to me. This infinite efficiency quest for speed reading is chief pursued by those who don't read regularly, and so don't understand that ones comprehension comes from the pauses, the page turns, and the backtracks which make up reading traditionally. If one has no time to digest, are they truly reading a book or just an impromptu script?
A lot of what you're saying here resonates with me, I've touched on some of these points myself in this conversation. It definitely isn't great for anything that requires actual thought. Your comprehension does suffer as your reading speed increases. The whole industry surrounding this stuff really does oversell its capabilities, which is why I tend to set a practical limit rather than touting some massive number.
Where I think the argument starts to break down is by lumping all reading into a single category. Reading a novel for pleasure, and wading through forty pages of background information before you get to the five crucial ones, are fundamentally different activities. I'm a medical student, and the majority of my reading consists of that second type. You can't really "digest" a literature review in a way that makes it enjoyable. The only real goal is to get through it once, without getting bogged down.
Regarding the pauses, that's actually the area I put the most work into. It lingers three times longer at the end of sentences and twice as long at commas, specifically because a consistent, flat pace feels like reading a script rather than actual prose. And, of course, you can pause whenever you feel the need; there's no pressure to keep moving forward.
The part I'd really push back on is who this is actually for. The people who've given me the most in-depth feedback today are clearly avid readers. It's not really a tool for people who don't read much.
That's the profile I keep bumping into, people who already read a lot and want the volume rather than a shortcut. What does your load actually look like, out of interest? I'm trying to work out where the line sits between the reading you'd want this for and the reading you'd want to slow down for. Everyone seems to draw it somewhere slightly different and I don't think I've got it right yet.
It depends on the book, if I'm reading Lord of the Rings or something dense obviously I'd slow down. But for pulp fiction or nonfiction even, I'd go fast. I typically read between one and two books a week, generally pretty decent sized ones too.
You are the third person this afternoon asking for this extension, therefore the obvious next task is creating it. One person emailed me this morning asking to paste a url and have the article read to them, and it came up again in another thread here.
Of your two options, I think the forwarding version is the better primitive. Selection is always a possibility, but right clicking on the highlighted text and telling it to forward it to you doesn't require as many parsing heuristics, since the user already told you what they want. Whole page mode could be layered on top as an option with a readability pass.
The panel version is tempting because the reader itself is already a self-contained static app, and would require little modification to appear as a side panel in another app, but then I would have to maintain two apps for little purpose.
The cool thing is that no server is required at all! A content script on readkinetic.com could write directly to the app's indexedDB from your extension in the same origin, so the script merely takes the text from the page you already have open and gives it to the local copy of the reader. Nothing passes through my servers, which is the whole point of the thing.
The embedded version is something I haven't thought about before, but is actually really cool. Using the exact same trick in reverse, the embedded version already exists in the visitors browser, so there isn't a fetch to do at all! The only wrinkle is styling it such that it doesn't get mangled by the host app, hence the shadow dom and small bundle.
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.
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.
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.
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).
Nice, always good to see another implementation! Were you able to get past the pivot alignment issue? Because in a proportional font, the word seems to slide around your eye as it shifts the spacing of the characters immediately adjacent to the pivot, so I anchored the pivot character and allowed the rest of the word to extend freely from both sides.
What stood out to me as a major difference was pacing though - a flat interval makes for a pretty robotic reading experience since there's no sentence structure, and I found that using multipliers on the base duration was more effective, getting about 3x for sentence ending punctuation, 2x for commas, and a little extra for long words overall was more noticeable than any other adjustments I made.
I'm curious if DuoBook is actually trying to implement reading in a second language as a learning tool as the name suggests, and if so, how does that affect things? I would imagine the pacing would be overall lower (particularly for punctuation) and recognition of the words you're actually reading would have more impact on comprehension than the ones you're just learning to read.
Yes, DuoBook is a language learning app, so I added RSVP as an add-on feature for re-reading the stories in another language. It’s not the main experience.
My idea was that the learners can do a slow turn with the main reader, and then a quick read afterwards if they want to.
Honestly, I spent at least a week for the pivot alignment but at the end I accepted once in hundred words it’s shifted a bit. I might go back into it at some point though.
That's the right answer, and it's pretty much what I’ve been considering since someone earlier in the thread asked about figures.
Epub makes it manageable because the images are just files in the zip. They are positioned at a set point in the spine, so I know exactly where in the word stream a figure belongs. Show it there, pause, and wait for a press to continue instead of auto advancing. You can pace text, but you can't pace a graph. There’s no sensible way to guess how long someone needs to view it.
The detail I keep reconsidering is captions. Right now, a caption flows into the stream as regular words, so you see "Figure 3 shows the relationship between" appearing one word at a time with no figure in sight. Those should be linked to the image and displayed alongside it instead.
Your question also made me realize that tables should probably be images too. Extracting text flattens a table into a series of values in reading order, which is worse than useless. Rendering the region as an image and pausing would be much better than what I do now.
Pdf is more challenging since I’d have to determine which images are real figures and which are rules and logos. Storage increases significantly too; everything is stored in IndexedDB on your device. So, a book full of plates is very different from a novel. I’ll probably need to downscale on import.
Where did you see it before? I’d really like to check out how they handled it.
That's the one, thanks. Spritz is where most people discovered it and the reason why the highlighted pivot letter is the norm.
However, RSVP itself has a long history that dates back to reading research in the seventies done in the context of how quickly one can read words without eye movements. Spritz's main innovation was the optimal position of the recognition point, allowing to keep it fixed while the word around it moves to form a new word, plus the framing elements at the top and bottom. I'm using them, so no need to patent something that others have already pioneered.
What I didn't like about theirs is that it was only available as an SDK inside other apps, and not as a standalone reader. It came up on a Samsung watch and a couple of other readers, but you couldn't really submit your own epub. This is what gave me the idea to make this one.
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.
The hypothesis is that much of the time spent reading is not spent deciphering the words but rather on moving the eyes around. Your eyes flicker around constantly, lock onto a word, then sometimes flicker backwards to previous words (those are called regressions) and constitute somewhere between 10-15% of your reading time. The RSVP (rapid serial visual presentation) takes away this freedom, by displaying the word in a fixed place, and thus removes all of these eye movements. In principle this leaves you with just the time needed for word recognition, which is presumably what you want.
In practice, this is probably not as good as using your own eyes and here's why, in addition to the argument above about skipping words. You no longer can skip words, which people do all the time, especially short function words. You already have to preview the next word or two in order to know when you've lost your place, so even if you had perfect peripheral vision you would be no better off than before. There is also the fact that you can no longer backtrack if you lose your place or simply get bored. In principle, of course, this could be solved by always allowing the reader to step back to a previous line, but this requires extra time and in general these features are a mixed blessing.
As to whether you would want to use such a device, and assuming you could use it with other media, I would say not particularly. Unless you are an especially fast reader, in which case there just isn't anything for you to gain. The people most likely to benefit from this sort of device are the people who normally have the most regressions or lose track of where they are. It makes the sort of prose that is meant to be read in one sitting much easier, faster, and less confusing. But it fails spectacularly on more dense material or on material where the visual presentation is important in any way. It also does not help anyone who simply can't visualize a text in the same way others do.
Some people just don't have the right kind of brain, and this isn't really their fault.
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.
Up/down arrows, or dragging up/down on the reader itself. An overlay appears stating the new speed.
Which would be a great answer, except that several other folks have made the same comment today, so I'm afraid it's my fault and not yours. I checked it myself; the hint line in the reader says "Hold to read · ←→ scrub" and nothing about speed control. You followed the instructions I published, which were wrong. Just fixed it; a discoverability pass is now at the top of the queue this week.
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.
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.
I was just coming to ask about word frequency. I get that cadence being jumpy might be less enjoyable, but having a look ahead that validates if a “likely to be hard to one-shot” word is coming up and slightly ramps down the pace, might make this an even better tool! Love it!
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.
I like that there is a fallback to read the full text, but why are there two such app modes? I think if the main (non-popup) one should absorb the other's features like scrolling and bookmarks.
For some texts the layout is also important to understand the context. Poems, structured text, paragraph breaks. If you read word by word and stumble into block of structured text, it's a lot of friction to figure out. I would love a background low fidelity representation of paragraphs, like the minimap in code editors, with the current word highlighted there. It could be passively monitored for places to switch mode to reading the full text, and to keep spatial orientation around character dialogs and such. It would have to not draw attention to itself though.
The theme circle icons are not useful, they should preview text background and color.
I see Dyslexic font is already built-in!
Code is not available? It would be fun to hook this to browser extension to fast-read article in a ReadKinetic popup.
I didn't mind the controls at all, they are obviously for touch and not mouse and it seems inspired by video player controls. This is a kind of app that you spend hours with, so better to have more features and options than to be beginner friendly. Very nice app, I like it so far.
The minimap is, in fact, the best idea anyone has given me today (and I think it addresses a concern 3 other people brought up in this thread). The underlying problem with all the suggestions is that you lose all the scaffolding, the paragraph breaks, the line spacing, the sense of where you are in the text that makes it easy to just jump into the text anywhere in the first place. I think this peripheral low fidelity map addresses it because you don't have to actively engage with it. Your concern about the control to not draw attention from the text is the entire point of this design. You can't make it too salient because that makes it steal the focus from the main text, which defeats the entire point.
I already have the info on paragraph and chapter breaks in the reader already, so this is more of a rendering issue rather than info display. The reason why I particularly like your first suggestion is that it lets you know something like a poem or different paragraph style is about to start so you can change your reading pattern accordingly rather than stumbling into it when you're already in prose mode reading at 400 wpm.
On the 2 modes thing, I feel like there isn't really a good reason to do it the other way. It was more that it happened that way rather than it needed to happen that way, and you're right that the main one should probably scroll and have bookmarks rather than making the user make a choice between 2 different interfaces.
Theme circles is definitely a solid suggestion, being a more practical implementation of visualising the underlying theme. Being able to see the actual colours of the background/text rather than an abstract blob is good, so that's a definite maybe.
Code isn't public yet, but extensions are something I've wanted to try for a while. In fact, someone sent me an email this morning asking precisely for that, to be able to paste a link and read articles. It can't be done directly in the page because of CORS policies, and doing it server side would involve routing the reading of articles through my server which is probably not ideal for everyone. An extension that pulls the article from whatever page you're on would be the most ideal version of this, from a privacy standpoint, so I'm considering it.
And finally, your last point is actually the first pushback I've had all day on the controls/interface. As far as 4 other people having difficulty finding the thing, I think you're right that something needs to be done, but I don't think hiding the options behind discovery is really the answer. There is a conflation in my brain between 'controlls are easily found and accessible' and 'controls are not hidden beneath layers of menus/bookmarks', and I think it's a false conflation, I had been treating them as one. Thanks for that.
Nice. I made a similar thing as a TamperMonkey script that I can turn on and off on any website, it even includes a speed-controlled-voice that can read it for me.
One small annoyance with your app is the instructions in the welcome were tiny. Took me well over a minute to figure out how to control the thing, until I finally found those small hand icons in the right corner. You should consider adding these to the first page of welcome using a large-er size or something.
The idea looks cool , i think along with optimization reading time if it also allows you set your frequency and then read the book accordingly it would really make an impact , for i sometimes want to read slowly if the topic is of my interest. Just a suggestion
We've got up and down arrows, or you can drag vertically to adjust. Funny, you're not the only one who missed that today, so the interface definitely isn't making it obvious. Fixing that is definitely a priority for me.
What you're getting at, about having a separate speed for each book, that’s a good idea and worth exploring. Right now, the speed is just one setting for everything. So if you slow things down for a book that needs a more leisurely pace, you have to remember to speed it back up manually when you switch to something else. Someone else mentioned the same thing earlier. It makes sense that it should remember the pace for each book, just like it remembers where you stopped reading.
Sounds like a pointless endeavour to me. This infinite efficiency quest for speed reading is chief pursued by those who don't read regularly, and so don't understand that ones comprehension comes from the pauses, the page turns, and the backtracks which make up reading traditionally. If one has no time to digest, are they truly reading a book or just an impromptu script?
A lot of what you're saying here resonates with me, I've touched on some of these points myself in this conversation. It definitely isn't great for anything that requires actual thought. Your comprehension does suffer as your reading speed increases. The whole industry surrounding this stuff really does oversell its capabilities, which is why I tend to set a practical limit rather than touting some massive number.
Where I think the argument starts to break down is by lumping all reading into a single category. Reading a novel for pleasure, and wading through forty pages of background information before you get to the five crucial ones, are fundamentally different activities. I'm a medical student, and the majority of my reading consists of that second type. You can't really "digest" a literature review in a way that makes it enjoyable. The only real goal is to get through it once, without getting bogged down.
Regarding the pauses, that's actually the area I put the most work into. It lingers three times longer at the end of sentences and twice as long at commas, specifically because a consistent, flat pace feels like reading a script rather than actual prose. And, of course, you can pause whenever you feel the need; there's no pressure to keep moving forward.
The part I'd really push back on is who this is actually for. The people who've given me the most in-depth feedback today are clearly avid readers. It's not really a tool for people who don't read much.
Or someone like me who reads often, and at great volume, and wants to read more. Not everyone is like you.
That's the profile I keep bumping into, people who already read a lot and want the volume rather than a shortcut. What does your load actually look like, out of interest? I'm trying to work out where the line sits between the reading you'd want this for and the reading you'd want to slow down for. Everyone seems to draw it somewhere slightly different and I don't think I've got it right yet.
It depends on the book, if I'm reading Lord of the Rings or something dense obviously I'd slow down. But for pulp fiction or nonfiction even, I'd go fast. I typically read between one and two books a week, generally pretty decent sized ones too.
This is really cool!
The scrubbing feature is neat.
I wonder if you could create a browser plugin for this? It could either:
- Replicate the entire app in a panel.
- Integrate with the app - so it forwards the selected text/page for the app to process.
Perhaps another idea would be to offer a widget people can embed on their site like a "Speed Read This Page" button.
I really enjoyed playing with it.
If you could somehow make it easier to integrate with different environments - it would be something I could see myself using regularly.
You are the third person this afternoon asking for this extension, therefore the obvious next task is creating it. One person emailed me this morning asking to paste a url and have the article read to them, and it came up again in another thread here.
Of your two options, I think the forwarding version is the better primitive. Selection is always a possibility, but right clicking on the highlighted text and telling it to forward it to you doesn't require as many parsing heuristics, since the user already told you what they want. Whole page mode could be layered on top as an option with a readability pass.
The panel version is tempting because the reader itself is already a self-contained static app, and would require little modification to appear as a side panel in another app, but then I would have to maintain two apps for little purpose.
The cool thing is that no server is required at all! A content script on readkinetic.com could write directly to the app's indexedDB from your extension in the same origin, so the script merely takes the text from the page you already have open and gives it to the local copy of the reader. Nothing passes through my servers, which is the whole point of the thing.
The embedded version is something I haven't thought about before, but is actually really cool. Using the exact same trick in reverse, the embedded version already exists in the visitors browser, so there isn't a fetch to do at all! The only wrinkle is styling it such that it doesn't get mangled by the host app, hence the shadow dom and small bundle.
Genuinely appreciate your feedback!
You are welcome!
If you do go ahead with the browser extension, let me know. I will keep an eye on this thread.
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 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.
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.
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).
Oh okay, didn't notice it! Yeah, maybe the discoverability.
After reading a bit longer, I have one more nit on the auto mode. I expected a single tap to take me out of the auto mode. Again, awesome work!
Very cool! I like RSVP, I actually just implemented it in DuoBook as well.
https://x.com/eonurkara/status/2079867443338449135?s=20
Nice, always good to see another implementation! Were you able to get past the pivot alignment issue? Because in a proportional font, the word seems to slide around your eye as it shifts the spacing of the characters immediately adjacent to the pivot, so I anchored the pivot character and allowed the rest of the word to extend freely from both sides.
What stood out to me as a major difference was pacing though - a flat interval makes for a pretty robotic reading experience since there's no sentence structure, and I found that using multipliers on the base duration was more effective, getting about 3x for sentence ending punctuation, 2x for commas, and a little extra for long words overall was more noticeable than any other adjustments I made.
I'm curious if DuoBook is actually trying to implement reading in a second language as a learning tool as the name suggests, and if so, how does that affect things? I would imagine the pacing would be overall lower (particularly for punctuation) and recognition of the words you're actually reading would have more impact on comprehension than the ones you're just learning to read.
Yes, DuoBook is a language learning app, so I added RSVP as an add-on feature for re-reading the stories in another language. It’s not the main experience.
My idea was that the learners can do a slow turn with the main reader, and then a quick read afterwards if they want to.
Honestly, I spent at least a week for the pivot alignment but at the end I accepted once in hundred words it’s shifted a bit. I might go back into it at some point though.
Very nice implemenation re usability. I have seen this before, somewhere, years ago - perhaps even on HN.
Such a solution applies for text only instances. How would you solve it when graphs come into play? Display a graph next to it and pause the text?
That's the right answer, and it's pretty much what I’ve been considering since someone earlier in the thread asked about figures.
Epub makes it manageable because the images are just files in the zip. They are positioned at a set point in the spine, so I know exactly where in the word stream a figure belongs. Show it there, pause, and wait for a press to continue instead of auto advancing. You can pace text, but you can't pace a graph. There’s no sensible way to guess how long someone needs to view it.
The detail I keep reconsidering is captions. Right now, a caption flows into the stream as regular words, so you see "Figure 3 shows the relationship between" appearing one word at a time with no figure in sight. Those should be linked to the image and displayed alongside it instead.
Your question also made me realize that tables should probably be images too. Extracting text flattens a table into a series of values in reading order, which is worse than useless. Rendering the region as an image and pausing would be much better than what I do now.
Pdf is more challenging since I’d have to determine which images are real figures and which are rules and logos. Storage increases significantly too; everything is stored in IndexedDB on your device. So, a book full of plates is very different from a novel. I’ll probably need to downscale on import.
Where did you see it before? I’d really like to check out how they handled it.
Not sure if they are the "inventors", but https://spritz.com/ was where I first saw this ages ago
That's the one, thanks. Spritz is where most people discovered it and the reason why the highlighted pivot letter is the norm.
However, RSVP itself has a long history that dates back to reading research in the seventies done in the context of how quickly one can read words without eye movements. Spritz's main innovation was the optimal position of the recognition point, allowing to keep it fixed while the word around it moves to form a new word, plus the framing elements at the top and bottom. I'm using them, so no need to patent something that others have already pioneered.
What I didn't like about theirs is that it was only available as an SDK inside other apps, and not as a standalone reader. It came up on a Samsung watch and a couple of other readers, but you couldn't really submit your own epub. This is what gave me the idea to make this one.
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.
What's the theory behind this idea? Why would I want to read it like this?
The hypothesis is that much of the time spent reading is not spent deciphering the words but rather on moving the eyes around. Your eyes flicker around constantly, lock onto a word, then sometimes flicker backwards to previous words (those are called regressions) and constitute somewhere between 10-15% of your reading time. The RSVP (rapid serial visual presentation) takes away this freedom, by displaying the word in a fixed place, and thus removes all of these eye movements. In principle this leaves you with just the time needed for word recognition, which is presumably what you want.
In practice, this is probably not as good as using your own eyes and here's why, in addition to the argument above about skipping words. You no longer can skip words, which people do all the time, especially short function words. You already have to preview the next word or two in order to know when you've lost your place, so even if you had perfect peripheral vision you would be no better off than before. There is also the fact that you can no longer backtrack if you lose your place or simply get bored. In principle, of course, this could be solved by always allowing the reader to step back to a previous line, but this requires extra time and in general these features are a mixed blessing.
As to whether you would want to use such a device, and assuming you could use it with other media, I would say not particularly. Unless you are an especially fast reader, in which case there just isn't anything for you to gain. The people most likely to benefit from this sort of device are the people who normally have the most regressions or lose track of where they are. It makes the sort of prose that is meant to be read in one sitting much easier, faster, and less confusing. But it fails spectacularly on more dense material or on material where the visual presentation is important in any way. It also does not help anyone who simply can't visualize a text in the same way others do.
Some people just don't have the right kind of brain, and this isn't really their fault.
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.
There seems to be no way of changing the WPM setting after startup.
Was just about to say that. Beyond that, it's pretty cool though so far.
Up/down arrows, or dragging up/down on the reader itself. An overlay appears stating the new speed.
Which would be a great answer, except that several other folks have made the same comment today, so I'm afraid it's my fault and not yours. I checked it myself; the hint line in the reader says "Hold to read · ←→ scrub" and nothing about speed control. You followed the instructions I published, which were wrong. Just fixed it; a discoverability pass is now at the top of the queue this week.
Thanks for flagging it.
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.
Thank you for your honest reply.
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.
I was just coming to ask about word frequency. I get that cadence being jumpy might be less enjoyable, but having a look ahead that validates if a “likely to be hard to one-shot” word is coming up and slightly ramps down the pace, might make this an even better tool! Love it!
Love that attention to detail. I'll try this out for longer reading sessions, nice work!
I don’t know man. Just because you bike it doesn’t mean you have to share it. Why is this top news.
Look I vivbed the same thing 2 weeks ago.
https://tachys-d23ab0.gitlab.io/
excelleny one
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.
super brother