Comments URL: https://news.ycombinator.com/item?id=49732936

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49693613

Points: 219

# Comments: 80

Comments URL: https://news.ycombinator.com/item?id=49647752

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49584697

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49563506

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49533821

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49528771

Points: 32

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49210193

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49166952

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49131924

Points: 2

# Comments: 0

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.

Reading a couple of books weekly, and switching between these reading styles, also makes me think the reading speed should be set per book, not as a general setting. If you're reading Tolkien at 250 words per minute and a fast-paced paperback at 450, you shouldn't have to adjust the speed every time you pick up a different title. Since it already tracks where you are in each book, remembering the reading speed for each one seems like a logical next step.

Anyway, that's a really helpful point.

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.

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.

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.

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.

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!

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.