Dynamic Pricing
Bad for consumers.
Great for e-ink device manufacturers.
Now we got this e-ink UI dev.
I don't like it one bit Tony
Ask HN: In your experience, what are sound conventions for e-ink UI development?
61–70 of 76 posts
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#62What if instead of pagination you have the screen mostly blank out when scrolling ? Maybe with the exception of an indicator bar at the left or right to show how far you have scrolled. Could be very thin and functional. On stop it would refresh the page / text
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#63I 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…
All the conditions you describe are a graphic designer's wet dream, I love it
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#64I 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 accurat…
Agree. But that is the OPs job then. The difference between good and bad design is that it will make those choices well.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#65Funny 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…
> bugbear
Dragon Strike board game who had it
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#66Earlier 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.
This stuff is user tested, many people prefer animations because they get confused if the UI changes instantly. For example if a button moves position when a sidebar is collapsed, the animation tells the user where the button has gone.
You are probably more observant and have good visual processing, so the animation is superfluous to you. Luckily it can be turned off on Android. On Linux I use XFCE which is almost instant - no animations by default.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#67I’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 Bigme's boot screen has a 1 Hz animation of the outlined logo filling in with black letter by letter which looks pretty decent in my opinion.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#68Asides 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.
Or even worse (looking at you Kindle) is an action that does a major context change and require more interaction to return you where you were. The Kindle’s tiny book menu three dot button is the worst.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#69...first and foremost, a durable display - durable in terms of the number of writes it can survive.
until then, the question is moot.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#70[flagged]