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.
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.
freeone3000
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.
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.
philosopherNoob
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.
FabCH
Beyond 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, but you can still learn from the overall layouts. Simplified menu lists with fewer items in a hierarchy, etc.
If you can and have physical buttons, think long and hard about their functions, especially if you have a limited number... these should do your most important things.
tracker1
I've been experimenting with a Remarkable Paper Pro.
Additive inking works pretty well. As long as I am adding black ink to the page, everything is responsive. But if I want to push other updates asynchronously, or (god forbid) erase something, then there is the danger of clobbering the user's inkwork. I don't have any deep insights here, beyond waiting for human confirmation before updating anything.
I wonder if it is possible to detect when the pen tip has "left" the proximity of the page? If I knew this, I'd know when it was safe to update the UI.
I have decided not to use any scrolling at all. I am paginating everything and positioning input areas near the vertical middle of the device for comfort.
pshc
A 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.
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.
comments (10)
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).
dredmorbius
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.
freeone3000
Disclosure: I work at TRMNL.
[1] https://github.com/usetrmnl/trmnl-framework
[2] https://github.com/usetrmnl/trmnl-firmware
ronakjain90
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.
philosopherNoob
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.
FabCH
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, but you can still learn from the overall layouts. Simplified menu lists with fewer items in a hierarchy, etc.
If you can and have physical buttons, think long and hard about their functions, especially if you have a limited number... these should do your most important things.
tracker1
Additive inking works pretty well. As long as I am adding black ink to the page, everything is responsive. But if I want to push other updates asynchronously, or (god forbid) erase something, then there is the danger of clobbering the user's inkwork. I don't have any deep insights here, beyond waiting for human confirmation before updating anything.
I wonder if it is possible to detect when the pen tip has "left" the proximity of the page? If I knew this, I'd know when it was safe to update the UI.
I have decided not to use any scrolling at all. I am paginating everything and positioning input areas near the vertical middle of the device for comfort.
pshc
See the modos for what a clean sheet eink design would look like.
https://www.crowdsupply.com/modos-tech/modos-flow#products
storywatch
[0]: https://inka.page
longnguyen
Marsymars