Ask HN: In your experience, what are sound conventions for e-ink UI development?
TL;DR I'm looking for advice regarding browser-based frontend development from people with practical e-ink UI experience. My specific device is a Bigme Hibreak Pro BW but I'm aiming for relatively broad compatibility. I've recently switched to a black-and-white e-ink smartphone with the motivation of withdrawing from the attention economy somewhat and it's a genuinely cool piece of hardware. While the majority of my needs are met by this device there are a few things I'd like to have which don't work terribly well with the e-ink screen. I'm planning to implement a couple of projects to fill these gaps, at the moment I'm planning a Lemmy frontend and an OpenRouter frontend specifically for e-ink. Both are to be browser-based rather than native, to maximise compatibility and because I'm much more familiar with the web than Android development. I would like to study the principles of sound e-ink UI design before approaching these projects to avoid creating unusable slop, in particular I am not entirely sure how to approach treating the refreshes as a first-class aspect of the design when I can't control them from the browser, and how to apply comprehensible UI conventions when a greyscale, high-contrast display is the target. Some specific problems I have out of the gate are: * Streaming LLM output to the screen is basically the worst-case scenario for e-ink, I need to buffer it and paint it in chunks without this becoming horrible to use. * Ghosting is a serious problem, browsing HN on the device is a particularly obvious example. Ideally I want to avoid scrolling as far as possible and rely on pagination instead, which I feel has the potential to become annoying if not done well. * Given I must rely exclusively on layout and type to carry the UI, what design languages emphasise these qualities best? My gut says the early Mac OS versions wouldn't be a bad place to start, this seems relevant given the display constraints of the early macs. I would greatly appreciate any advice on the design and implementation of e-ink UIs from people with practical experience in this area. This is purely to scratch a personal itch, once they're nailed down I'll put them out in the wild under the GPL.
评论
5 条预览评论 · 正在加载完整讨论请先登录 h4cker 账号，然后连接 Hacker News 后发表评论。
Funny you should ask, something of a bugbear of mine: 1. Persistence is free. 2. Pixels are cheap 3. Paints are expensive 4. Refreshes are slow 5. Colour is limited to nonexistent. 6. Pagination over scroll. 7. Full refresh (of page or portion) over pan. 8. Reflective rather than emissive. 9. Minimise animation. 10. Line-art or halftones over shade gradients (images). <https://news.ycombinator.com/item?id=31396797> I've reiterated (and occasionally revised) that a few times, see: "E-Ink Design Principles for Web and Applications" <https://diaspora.glasswings.com/posts/638a8d10e041013afba844...> That's source of the above list, gives a bit more explanation and rationale for each choice. I wrote it after failing to find any UI/UX development guidelines myself, and have had some positive responses from it. And on HN, search for "pixels are cheap" by me: <https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...> (about 15 results, this comment included).
I’d focus more on print usability and readability guidelines than computer guidelines. 5Hz eink is closer to a moving newspaper than a slow computer. https://www.mediapoint.com.au/design-tips/composition-layout... might be moderately helpful. But my advice: do not count on anything refreshing ever. Do not have animations, or transitions. Preload things to the correct spaces, then fill in. Reserve fixed white areas for output, and then fill in with black. (This works much better than the reverse!) For quite long running processes, it might be worth having it behind a second page load.
TRMNL recently open sourced a CSS framework made specifically for ePaper display [1], you can use the opensource firmware[2] and quickly hack together a good solution using off the self components. Disclosure: I work at TRMNL. [1] https://github.com/usetrmnl/trmnl-framework [2] https://github.com/usetrmnl/trmnl-firmware
Spitballing an idea. I don’t use e-ink stuff but had my hands on it back when personal readers were new to the market. When scrolling arbitrary text on a computer via keyboard, I generally become mildly frustrated hitting Spacebar, PageUp, and/or PageDown because I lose continuity with what I’m reading. (Perhaps the momentary 60hz blur makes it worse?) I attribute that to having a hard time identifying where I last read. If there’s a dedicated button to scrolling, consider having an adjustable distance. EX: 100% screen height down, 95% screen width down (keeps a sliver of the last page), or 80% screen width down (keeps a chunk of the last page). If you’re working with a touch display, perhaps a hold-and-drag-to-scroll feature could work? Have no indicator when pressed and only refresh the screen when the user lifts their finger. (It’s certainly not ideal to provide no feedback that it’s being used. But it may be useful to a user aware of how it works. Would probably need a training demonstration in-device like what older operating systems had.) Perhaps a dedicated scroll undo button? For when one makes a mis-input and wants it back where it was. I know I’ve seen my grandma get frustrated at that sort of thing on desktop/phone where it’s quick to fix.
I use eInk as my daily driver and do everything including ssh into tmux into vim and code on eInk. I build all my UIs with Rust and Ratatui. It works very well. So for web, I think it would translate to: 0) NO ANIMATION. You have like, 0.3 fps. You might poke somebody’s eye out if you animate something. 1) NO SCROLLING. Pagination only. 2) Use actual added visual element to tell the user where their input control / cursor / selection is. Don’t rely on color, font weight etc. Put an asterisk, Unicode arrow or something. 3) Direct(?) action controls. A button should DO something. Don’t give me a button that opens a drop-down that opens a menu to do something. 4) Use the whole screen! Keeping a pixel on/off costs nothing. Only changes do. So any whitespace is just sacrificing screen real estate and forcing more frequent changes.