There are some inspiring design ideas buried in the settings of einkbro and boox device settings.
Ask HN: In your experience, what are sound conventions for e-ink UI development?
51–60 of 75 posts
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#52Funny 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).
Not just faster but far more dramatic.
The sleep / boot / screensaver patterns for ebook readers tend to be line drawings, woodcuts, and the like.
One image I find especially apropos is Dürer's Rhinocerous, which looks phenomenal, especially on a larger screen.
https://en.wikipedia.org/wiki/D%C3%BCrer%27s_Rhinoceros#/med...>
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#53There are some inspiring design ideas buried in the settings of einkbro and boox device settings. https://github.com/plateaukao/einkbro
Einkbro is easily the best app I've found for Android (save Termux), and an absolute essential for e-ink Web browsing.
I'd prefer its pagination controls were even stronger, but they're quite good so far as they go.
Another very sweet feature (for a time) was the ability to save and append websites to an ePub document. This should be pretty easy to achieve independently, but solves a number of problems:
- Collecting a set of documents under a single cover, say for a research or communications project.
- Strips all the Web cruft from pages and presents them as a straight linear text. Images can be included, but the incidental stuff (headers, footers, sidebars, animations, etc.) are all removed.
- The resulting document can be paged through rather than scrolled. Read in Your Preferred Ebook Reader (OK, several of these are also quite good), you can also bookmark, annotate, highlight, etc., individual pages or sections of text, something ... Web browsers have utterly failed to implement.
- Because an ePub is simply a collection of HTML files, it's quite possible to add, delete, or edit the resulting document (gzipped HTML plus a bit of stuff).
- The entire work can be styled to your preference either in the ePub CSS itself or, far preferably, through your ebook reader's controls. (Styled ePubs intended for third-party use are a crime against humanity.)
- Collections can themselves be curated, shared, etc., modulo of course fucked-up copyright bullshit.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#54Funny 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).
[dead]
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#55Spitballing 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…
I used Oberon [1] in school, and it had a bunch of funky UI ideas. One I liked it if you clicked on the scrollbar then it would scroll that position to the top. Like if you click the exact middle of the scrollbar then it would scroll up exactly half a page. Right click went the opposite direction, and middle click went to an absolute position. When reading that means you can choose a paragraph as the break point, cli…
Interesting - that definitely seems like a more useful approach than "click to advance one page in that direction, but only if you don't click on the bar itself". I kinda wonder if that's possible to do OS wide nowadays...
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#56While not as good as a proper refresh, you can use alternating black and white drawing to help clear an area of the screen.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#57Spitballing 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…
Yeah, drag-scrolling and page-jumping on eink is solidly in the "not great" category.
Maybe you could draw a line showing where [some line of text] is moving to? Like starting from where the finger starts, draw a "timeline" of locations as they move their finger, and when they release you draw the whole page:
┌───────────────┐
│ │
│ drag │
│ ┌┐ │ │
│ │ └┘ │ │
│ └┐ │ │
│ └┐ │ │
│ └┐ │ │
│ │ ┌┐ │ │
│ └─ └┘ ▼ │
│ │
│ │
└───────────────┘
You can do small-bounding-box "draw black on top" extremely quickly, it's how reMarkable tablets get their near-20ms pen-to-display latency.
I'd probably also like a "this is where the previous top/bottom/where you dragged is now" temporary underline across the screen at the end, for easier visibility. Just clear it a second later.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#58@DANmode and @storywatch both called out good paths to explore.
I daily drive a monochrome PDA as my core "smart" device. The overall UX is excellent for what it needs to do. Despite color PDAs being widely available, I've found I prefer the B&W UI quite a bit more.
A common refrain from me is that digital calendar UX peaked somewhere around 1999-2000 with PalmOS 3.5 (particularly on later Handspring Visors). I've also written most of a little weather app using native UI elements for them.
Additionally, the Modos folks seem to be on to something with high refresh rate eink. It's quite smooth in practice and is almost uncannily like a normal LED screen with an e-ink look.
Early Macs also had pretty opinionated HIGs, as you said.
Feel free to reach out if you want to chat further. Frankly a lot of the design principles are the same as broader graphic, type, and UI design best practices--they just aren't often followed by anything modern. Something that's always stuck with me from a professor was that a good logo must pass the "fax machine test". Seems quite applicable to this day in an eink context! :)
Link to some PalmOS UI guidelines: https://cs.uml.edu/~fredm/courses/91.308-spr05/files/palmdoc...
^ These are a bit newer and include color. The UI elements originated in mono and were still backwards comptaible with mono devices, so I find the addition of the blue to be distracting rather than additive, but YMMV. Either way they also look much better on a proper 160x160 LCD vs a PDF!
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#59Earlier quoted context omitted.
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.
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-…
> 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.
No, they are not. And the Material Design 3 is the prime example of how NOT to do the UI.
It was optimized for such metrics as "rebelliousness" and "being in the know", rather than usability.
I'm firmly on Android because at least I can turn off all the animations there. I develop for iOS, and it always feels like swimming through molasses in comparison.
The only animations that make sense are small ones that are focused in the foveal area. So pretty much only animated button presses.
Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?
#60Earlier quoted context omitted.
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)
You don't need the developer settings. There's a "remove animations" option in the accessibility menu somewhere.