Asides from what's been mentioned, I'd suggest big touch targets. Because the UI is so slow, it's comparatively painful to miss a touch target, especially if the result of a miss is a UI refresh that then has to be undone before the original action can be retried.
Ask HN: In your experience, what are sound conventions for e-ink UI development?
41–50 of 74 posts
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#42Not a web UI, but I recently built this[0] for my Boox Note Air 5c tablet. You may find it useful (check the source code in GitHub) [0]: https://inka.page
I wish it worked with a Kobo Clara too!
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#43I’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 fo…
> 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!) I would ammend to this that if you have an operation that can't complete quickly, it's better to have some kind of animation, even if it's notably slower than…
Progress bars still work. Gratuitous animations don't.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#44Funny 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…
Thank you for this! This is perfect and what I was looking for while building the UI components for an SDK for Kobo e-ink apps https://github.com/BandarLabs/Cobalt
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#45Earlier quoted context omitted.
In general, we only really notice the animations that go wrong, like the ones that are too slow or get in the way, but when executed by the book (like the numbers material design published, or perhaps even slightly faster), they are a valuable way of communicating intuition for how to use the UI to a user. But yes, I can understand the desire to remove them, or at minimum drastically reduce their visual impact for e-…
Did I stutter? I would like them all gone. I would like all visual elements to appear exactly in their final position and not resize, except in direct response to user interaction. Animations are one of the things that I dread about using modern UIs. There are others too, no doubt.
I always turn off Android's animations in the developer settings and it makes everything so much more usable. (Animation Scale: 0x, I believe is the setting)
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#46Funny 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…
> 10. Line-art or halftones over shade gradients (images).
This is particularly true for eink, because black white is dramatically faster and more reliable (less ghosting) than anything involving any gray. It's why basically all of the "fastest" modes are pure black and white, and why UI shapes are generally pure black and white (though text might have grays).
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#47I actually built a Partiful event clone [0] for my friends and I and this was one of the first features. One of the "unlocks" for me was a scroll component that auto paginates any screen on the site. I have The Minimal Phone and it works quite well as a PWA. Not at all a promotion (like actively I'm losing money on this product) but feel free to check out eink mode. You login with 4152127777 and test code 123456 (going to disable this tomorrow fyi). eink mode is in the top right profile menu.
I wish these phones complied with `monochrome` media query [1] but they don't.
[0]: https://littleinvite.com/e/vfu8mn4b/test-invite
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#48Earlier quoted context omitted.
In general, we only really notice the animations that go wrong, like the ones that are too slow or get in the way, but when executed by the book (like the numbers material design published, or perhaps even slightly faster), they are a valuable way of communicating intuition for how to use the UI to a user. But yes, I can understand the desire to remove them, or at minimum drastically reduce their visual impact for e-…
Did I stutter? I would like them all gone. I would like all visual elements to appear exactly in their final position and not resize, except in direct response to user interaction. Animations are one of the things that I dread about using modern UIs. There are others too, no doubt.
[flagged]
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#49I 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 / c…
> 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.
That works until it doesn’t. Screen real estate is limited and touch accommodations are expensive. You have to be mindful of what you expose and what you hide. There’s no point in flooding the UI with buttons when people can barely make them out or even interact with them accurately—a mistouch is a lot more expensive than two correct touches.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#50[dead]