Yes, from the README, it's not clear why the author would maintain a project with main features being saving 10Mb of ram&storage and 10ms startup time... followed by a wall of hard-to-read AI-generated text.
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.
This seems great, I was wondering. there should be an option to upload lab reports and save them on the file, can also act as context if you decide to include an LLM/ AI assistant later on. If you ever need assistance please feel free to approach.
Exactly — chart-only TA is tough without fundamentals context. For Korean markets this is even more pronounced since retail flow dominates. I've been working on fundamental data for KOSPI/KOSDAQ if you ever want to add an Asian market mode.
Yeah I’d say sorting by relevance is similar but MEANS is strictly a boolean operator only allowed in WHERE clauses at the moment.
The way it works is:
1. Prune rows based on semantic index
2. Run surviving rows through the LLM which answer yes or no to the given predicate.
3. Collect final result.
Order by relevance is on the roadmap but I haven’t given it much thought.
The use case I’ve been working with is querying meeting transcripts. May I ask what your use cases are and how you’d like order by relevance to work?
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.
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.
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.
Yes, sorry let me explain a bit more.
The idea is that we have custom agents each having a model version of their own. So, if we have a planning agent that uses Opus and a worker agent that uses Sonnet, then the planning agent writes the plan and hands it over to the worker agent. This way, the handover here is not going to retain the context.
When the worker agent picks it up, it'd have a new context and only the todo list from the plan, so it shouldn't be reading all the files again.
This already has a name — people call it GEO/AEO. I do the legitimate end of it for my own site: structured data, clean factual pages, llms.txt, so that when an assistant answers a question in my domain it cites the source correctly. Right now the incentives are healthy, because the only way to "rank" in an answer is to be genuinely accurate and citable.
Paid placement inside answers breaks that alignment. Why invest in being citable when you can buy the token stream? Search took about fifteen years to fully make that trade. LLMs seem to be starting on it in year three.
