Not 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 really like this, what a cool idea!
Ask HN: In your experience, what are sound conventions for e-ink UI development?
31–40 of 75 posts
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#32Spitballing 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 r…
> 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.
I like this idea, definitely going to test it out.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#33Beyond the early MacOS UI/UX, I would look at pre-smartphone devices as well. Palm pilot, phones, etc. These will give you ideas on what you can accomplish with lower resolution UI screens. For that matter, look at good TUI applications... (not the render path, but the result as a whole) ... blocking/spacing and clear controls, etc... though you'll be more touch, less tab/enter, etc. A TUI App renders by characters,…
Early monochrome devices were largely liquid crystal rather than electrophoretic displays.
The key differences:
- LCD was far lower resolution, often element-based rather than pixel-based displays (though the latter also existed).
- Screen response is far faster, with no ghosting. Electropheretic refreshes tend to take time, particularly at higher-quality or colour settings. Modern LCDs are used in high-performance displays at 60--120 Hz refresh or greater. By comparison, a fast EP/e-ink display might reach a few herz, and many require a substantial fraction, if not more than a second, to fully paint.
- Contrast was low. LCD relies on polarisation filters which greatly reduces foreground/background distinction.
That's not to say that some lessons cannot be learned, but the media do differ.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#34Rmkit is a great foundation.
Not browser based. Not sure why it would matter.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#35Earlier quoted context omitted.
Out of curiosity: Why?
I'm constantly hitting the wrong button because some animation shifted it, some dialog popped over shit, or some notification decided now was a good time to cover the thing I was trying to do. The animations make things feel sluggish. And they don't even look good. The only advice that doesn't improve all UIs is the bit about filling in with white and adding black after.
[deleted]
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#36Earlier quoted context omitted.
Out of curiosity: Why?
I'm constantly hitting the wrong button because some animation shifted it, some dialog popped over shit, or some notification decided now was a good time to cover the thing I was trying to do. The animations make things feel sluggish. And they don't even look good. The only advice that doesn't improve all UIs is the bit about filling in with white and adding black after.
Moving elements on screens is viewed as slick but is also a strong statement that the website knows how it is best to consume itself and depriving the user of the control over how to interact with it. I think there's been a big misunderstanding from UX designers about what features users actually value over time and too great a reliance on short window A/B UX comparisons where the cool effect of animations has not yet worn through.
This is also complicated by the fact that _all UX changes are bad_ until the users get used to them. So if you genuinely believe you're providing a better UX you do need to ignore the initial wave of negativity - which makes it difficult to tell knee-jerk reactions from genuine criticism if you're glossing over the results.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#37I’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…
That's a good shout, surprised this didn't occur to me actually as I was only recently dealing with a print-based feature at work. That's a helpful link, much appreciated.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#38I 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.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#39A lot of times the e-ink display can handle much higher refresh rates but the driver board and software are trash.
See the modos for what a clean sheet eink design would look like.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#40I’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 the already-slow screen refresh so that the user can tell that there's something happening.