Dear : Any guidelines on E-Ink / B&W/grayscale / low-refresh rate app design / UI/UX?

I've recently come into possession of an e-ink book reader, and am discovering the joys (seriously) and limitations (dittos) of e-ink displays and software designed for them.

I've just begun looking for any information concerning design guidance for e-ink devices, and am coming up very short. If you're aware of any such resources please respond to thread.

Boosts welcomed.

@dredmorbius My main observation from using the Onyx Boox is that paging on eink is still nicer than scrolling, even with their fancy refresh tech. Also line art is nicer looking than any shaded look esp the popular flat shades that are everywhere now.

If I were to think about what I'd like to see, it would be the look of the old B&W MacOS interface, except hi-res.

@dl That would be one of my general recommendations.

E-ink interfaces should be paginated rather than scroll-based.

Scrolling works well on high-response displays with no ghosting or other artefacts. It's murder on E-ink:

  • Response is too slow to accurately interpret where you're scrolling.
  • The scroll action fills the display with ghosting artefacts (the faint impression of previous screen redraws). A full refresh, typically only applied every 20 or so rewrites, is necessary to clear these.
  • During the scroll itself, the display disolves into a mess of static. There's no clarity during the scroll itself.
  • Because scrolling is imprecise it's easy to either under-scroll (so that the display viewport only advances a small distance) or over-scroll (so that content between the prior and current positions is missed).

One of the worst applications for this is, ironically, Pocket, which is a "better readability than Web browsers" tool now owned by Mozilla. It has a half-assed "page-flip" mode, which is a neither-beast-nor-fowl worst of all worlds compromise between scrolling and pagination. It's bad enough on emissive displays, it's fucking worthless on E-ink.

It keeps engaging and disengaging randomly (though it can be disabled), it does not consistently paginate the article (page / screen breaks occur at arbitrary points depending on the initial position within the document when engaging flip mode), content is often missed (back-scrolling tends to reveal this though often doesn't), and generally just causes aggrevation.

Pocket should:

  • Define the view parameters (font face, size, margins, display/viewport size, landscape/portrait orientation).
  • Paginate the article accordingly.
  • Never motherfucking deviate from that.
  • Have a hard "engage" and "disengage" toggle rather than relying on simple gestures which touch displays always fuck up.

@dredmorbius from my hackery on a Kobo N905a:
White dominated ux with high contrast - "dark mode" produces a lot more artifacts and would need more frequent "wipe cycles".
Also partial screen updates are possible, but artifacts accumulate.
Screen latency is noticeable.

@tbr From what I'm seeing, the ghosting tends to be reasonable when paging through text --- the effect is one of a gradually greying background, until the next hard refresh (about 20 cycles). This in the built-in bookreader (NewReader).

Web browsing, or viewing interface elements with strong geometric high-contrast elements (e.g., line-delimited boxes and the like) tends to leave more distracting background artefacts, and I'll frequently refresh to clear those. The fact that browsers don't support page-at-a-time advance/reverse navigation is a major PITA. There is a "Navigation Ball" which can be used to paint forward-reverse scroll buttons on the screen, but these don't advance by a full screen (closer to 50%, and it seems to vary).

The Pocket app is for various reasons among the most frustrating I've encountered as its UI is highly unsuited to the device and display, while its usage is precisely what I'd like to be able to do.

Fennec (the Android Firefox browser) has inexplicably removed the "print to PDF" feature. Even though the browser doesn't permit ready paging through a document, a locally-saved PDF version would.

Onyx have a custom variant of the Chromium browser, badged as "NeoBrowser". It seems that this may have some display optimisation, though ultimately seems to suffer worse for ghosting than Fennec does. (I'm using Fennec almost exclusively on this device, Google's browsers are little other than frustrating, regardless of how badged.)

Latency is an issue. It can be traded for display quality, though for reading, that's a poor trade-off.

@dredmorbius I haven't bothered trying direct web browsing on mine, for good reason. I did frequently dump long reads into PDF files and move them to the device. As it has an ARMv7 Linux userspace there are quite a few convenient ways like SCP.
Fascinating was always that the stock UI was done in Qt5.

@dredmorbius Kobo Touch N905C - bought two in 2015. Initially wanted to hack them into low power wifi connected displays. But then we just used them as readers. 😄

@dredmorbius Correct, it's a modest Linux userspace. IIRC busybox with Qt5 driving the Framebuffer. There was a significant homebrew scene at some point including custom homescreen and stuff, but It wasn't *that* great. The basic hacks for networking and such were nice though. As simple as putting a command in the unsigned update file. They didn't mind.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!