Ask HN: In your experience, what are sound conventions for e-ink UI development?

The strongest answer was a compact design doctrine that set the tone for everything else: persistence is free, pixels are cheap, paints are expensive, refreshes are slow, color is limited, and pagination beats scrolling. That framing held up across almost every practical reply. People with hands-on experience on Boox, reMarkable, Kobo-style devices, and e-ink phones all pushed toward the same interaction model. Treat the screen more like print, an ebook, or a terminal than a glossy phone app. Pre-allocate space, avoid animations and transitions, keep layouts stable, maximize contrast, and make each screen update feel intentional. What pushed the conversation past obvious advice was where people drew the line. It was not just “make it simpler.” It was “stop producing intermediate states unless the user truly needs them.” Several comments argued that refreshes should happen at semantic boundaries the user already expects, like page turns, form submit, finger release, or the completion of a long-running action. When continuous feedback is unavoidable, the pattern that survived was degraded feedback first and full fidelity later. Use wireframes, outlines, placeholders, progress bars, or chunked text updates. Then commit a cleaner localized refresh when the action is complete. That directly addressed the LLM case. Do not stream character by character. Buffer by words or chunks, prevent retroactive text reflow, and consider temporarily disabling scrolling while generation is in progress. There was also a consistent push to make navigation and targeting more forgiving because every mistaken touch costs much more on e-ink. Large touch targets, direct actions, fewer nested menus, and page-based reading patterns came up repeatedly. Several commenters reached for older interaction models not out of nostalgia but because they fit the medium: Palm OS, Oberon, TUI apps like less and emacs, drag proxies, and print layout conventions. The useful through-line was not “copy old UIs.” It was that those systems were built under scarcity and already solved how to preserve orientation, reduce motion, and communicate state without color. A practical web-specific wrinkle emerged too. Browser support is thin. At least one builder noted that e-ink phones do not reliably expose the CSS monochrome media query, so adaptation may need to be manual rather than feature-detected. That nudged the conversation away from pure styling tweaks and toward dedicated modes with different navigation, pacing, and rendering behavior. The overall landing point was blunt: an e-ink web app is not a normal responsive site in grayscale. It is a different interaction model with different costs, and the good versions lean into that instead of imitating OLED software badly.