What E-Ink Screens Teach You About Designing AI Streaming Interfaces

A developer named BoxOfRain posted a question on Hacker News a few days ago that's easy to dismiss as niche: what are the actual UI conventions for building browser based apps on an e-ink phone. They had switched to a black and white e-ink device, partly to get away from constant notifications, and were now trying to build two things for it: a Lemmy client and a frontend for an LLM chat tool. Their specific worry, in their own words, was that "streaming LLM output to the screen is basically the worst-case scenario for e-ink."

That thread ended up with dozens of comments and some genuinely specific, practical advice, most of it from people who had already hit the same wall building for slow-refresh hardware. It's worth reading even if you've never touched an e-ink device, because the constraint everyone in that thread is working around, a screen that cannot refresh cheaply, is the same constraint every team building a streaming AI interface deals with. It's just less visible on a normal display, so most teams never design for it deliberately.

The real constraint is refresh cost, not screen color

E-ink displays can't animate. Every redraw causes visible ghosting, and a full refresh takes a noticeable fraction of a second. One commenter, jeffnash, who is porting the drawing app Excalidraw to a reMarkable tablet, put it plainly: layout has to become "as monotonic as possible," and the app itself should never disturb what's already on screen unless it genuinely needs to. Another commenter, freeone3000, framed it even more usefully: think about print usability guidelines, not computer ones. Don't count on anything refreshing on its own. No animations, no transitions. Reserve fixed areas in the layout and fill them in once, rather than redrawing the same region repeatedly.

None of that is really e-ink specific advice, if you think about it. It's what you'd tell any team building for a slow network, a low-power device, or a user who has turned on "reduce motion" in their accessibility settings. Most product teams don't think about refresh cost as a design constraint at all, because on a typical screen it's nearly free. E-ink just makes the cost visible enough that you can't ignore it, which is exactly why the thread is a useful forcing function for thinking clearly about it.

What this means for streaming AI output specifically

The most useful part of the thread is jeffnash's answer to the exact problem BoxOfRain raised: how do you stream an LLM response onto a screen that can't redraw smoothly. Their approach was to treat every refresh as something that should line up with a moment the user already understands as a natural boundary, not something the interface does to itself mid-thought. Concretely: batch incoming tokens into chunks, do a full refresh only at a clear stopping point such as a paragraph break or the end of the response, and avoid reflowing text mid-word, meaning a word only gets placed on a line once you already know it will fit, the way a fixed-layout document renders rather than a resizable text box.

They also suggested something worth stealing even on a normal, high-refresh screen: a small "remaining space" indicator near the bottom of the response area, so the reader has some sense of how much more is likely coming before the layout has to jump or refresh. It turns an unavoidable disruption from sudden and annoying into anticipated. Anyone who has watched a chat interface abruptly rearrange itself mid-response, losing scroll position or cursor focus in the process, will recognize the underlying problem even without ever touching an e-ink device.

Where this generalizes past e-ink

If your team ships a streaming AI feature, a live dashboard, or anything with incremental updates, three ideas from this thread are worth applying directly, regardless of what screen it runs on.

Treat "in progress" as a real UI state, not a placeholder. If a response is still streaming, the layout should already know roughly where it will land once complete, instead of shifting every time new content arrives.

Batch visible updates around moments the reader already expects, not around whatever cadence the network or model happens to deliver at. A response that updates in sentence-sized chunks reads as more stable than one that updates character by character, even when the second approach is technically faster to first byte.

Give the reader a sense of what's coming, not only what has already arrived. A simple progress or "remaining" signal reduces perceived disruption more than most animation choices would.

What to actually do with this

None of it requires building for e-ink. It requires treating layout stability during incremental updates as a real design decision, instead of something that just falls out of whatever the framework does by default. If your team owns a streaming chat interface, a live dashboard, or any UI that updates itself without the user asking it to, open it up this week and watch, specifically, what happens to scroll position, cursor focus, and layout the moment new content arrives. That's usually where the actual problem is sitting, and it's usually fixable with the same discipline this e-ink discussion arrived at on its own: fewer intermediate states, refreshes tied to moments the reader already understands, and never surprising someone in the middle of reading.