Tahti

Problem framing

Some reading problems start before comprehension. A long block of text can feel heavy before the first sentence is even read. Tahti looks at that starting moment: what if the interface reduced the visible amount of text and gave the user a simple rhythm to follow?

The starting point is personal: I have mild astigmatism, and ADD makes sustained reading focus harder for me at times. I am also not a particularly fast reader in the traditional line-by-line format. In my own use, Tahti has helped in some situations by reducing visual load, giving the reading session a clearer pace, and letting me move through text faster than I normally would. That is a useful signal, but not enough evidence on its own.

The product should not be framed as a speed-reading promise. Reading one word at a time can remove useful context, make backtracking harder, and flatten the natural rhythm of paragraphs. A more honest direction is reading support: pace, focus, and temporary structure when ordinary reading feels demanding.

Product principle: Tahti should help users control reading pace without pretending that faster reading is automatically better reading.

Why a Chrome extension first

The first useful test does not need accounts, a mobile app, reading streaks, PDFs, or AI summaries. It needs one core behavior: select text on a web page and read it in a focused overlay.

Selected text keeps the MVP technically small and gives the user control. Full article parsing can wait, because web pages contain headings, images, tables, embeds, code blocks, and layout patterns that would quickly turn the first version into a parser project instead of a reading experiment.

Research context

Tahti sits close to a known reading method called Rapid Serial Visual Presentation, or RSVP. The basic idea is not new: words or small chunks are shown sequentially in one fixed visual position, reducing the need for eye movements.

The evidence is mixed, which is exactly why I want to keep the product claim careful. A mobile readability study found that RSVP formats increased reading speed for short texts without significant differences in comprehension or task load, but longer texts increased task load. A study of Spritz-style RSVP found weaker literal comprehension and more visual fatigue, likely because users lose rereading, parafoveal preview, and some natural control over pace.

There is also a relevant accessibility angle. Research with visually impaired readers has found faster reading with dynamic text presentation, including RSVP, compared with more traditional page-style presentation. That does not prove Tahti works for attention or focus, but it supports the idea that alternative text presentation can be worth testing for specific reading constraints.

Design implication: Tahti should be tested as reading support for specific situations, not positioned as a universal speed-reading tool.

MVP scope

The first build is a framework-free Chrome extension. The user selects text, launches Tahti from the context menu or extension popup, and reads the selection one word at a time in an overlay.

Core reader: one-word display, play, pause, reset, back 10, and next 10.
Pace control: WPM starts lower, warms up toward the chosen pace, and pauses slightly longer after punctuation.
Comfort settings: font size, dark/light mode, and a short countdown so the first word is not missed.
Out of scope: accounts, analytics, streaks, mobile app, PDF support, AI features, and automatic article extraction.

Interaction decisions

The reader UI has one main job: reduce eye work. If the user only gets a short countdown before the first word appears, they should not have to scan the edges of the screen to understand controls, progress, or current state.

The current prototype keeps the reading word, controls, and progress close to the user's central focus.

The current direction keeps the word, controls, and progress in one central reading stack. WPM and font size use compact sliders instead of stepper buttons, because the steppers made the overlay feel too much like a control panel.

Selected article text with a browser context menu option to read with Tahti. — The first version required opening the extension after selecting text. Moving launch into the right-click menu removes that extra step.

Early Tahti reader overlay with settings panel and bottom controls. — The first overlay exposed settings, but split attention across too many areas.

Updated Tahti reader overlay with centered word, progress, and compact controls. — The later version pulls progress and controls into a tighter reading stack.

Risks

The main UX risk is false usefulness. Tahti may feel calmer while also reducing comprehension. One-word reading removes many things people normally rely on: sentence shape, paragraph rhythm, quick back-scanning, lists, visual grouping, and the ability to slow down naturally when the content gets harder.

That is why the project should stay in experiment mode until it is tested with real reading tasks. The useful question is not "can this move words across the screen?" but "does this help the user start, continue, and understand enough to make the tradeoff worth it?"

Next step

I would keep the next version narrow: use Tahti on real articles, notes, and documentation, then log where it helps and where it damages understanding. After that, I want to run user testing to understand whether the need exists beyond my own reading habits and whether the interaction helps other people with focus, visual load, or reading fatigue.

If that signal is positive, the next feature worth exploring is article mode with pauses for headings, images, tables, and other elements that should not be forced into a one-word stream.

Validation questions: do I start reading more easily, stay focused longer, understand enough, feel less tired, and know which text types are clearly wrong for this mode?

Overview

My role

Status

Project Takeaways

What I explored

What is worth preserving

What needs validation