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.

Reboost on my E-Ink / Electronic Paper app design / UI/UX guidelines request.

Very few responses. I'm coming to suspect this is an under-served field.

Show thread

@dredmorbius The only thing that comes to mind is the OLPC project, and I have a feeling that didn't pan out as well as the marketing and hype would have you believe.


Only thing I know about E-ink is that it might be some sort of liquid crystal.

Ah; it's Liquid Crystal Display, but with something other than liquid crystal. Neat!

Liquid Crystal Display: Displays stuff by running electricity through liquid crystals to change their orientation. Often backlit, but originally was not. (i.e. cheap calculators, overpriced TI calculators)

Liquid Paper Display: Displays stuff by running electricity through an emulsion to change the orientation of suspended particles

@dredmorbius No, I see how it works now. This [ ] graphic was unclear, and how I interpreted it was colored by prior incorrect information.

Would shaking it while no power is applied cause the pattern to fade, or is there something that keeps the ink from dispersing?

@TransGal4872 In my experience, the display is not affected by physical shock or movement.

@TransGal4872 LCD requires constant power to the display to maintain the pattern. Electronic paper / e-ink does not. A charge is use to impart the pattern, but not to maintain it (the dispaly retains its last-applied state in the absence of power or charge).

LCD operates based on light polarisation, which means that the maximum light/dark contrast ratio is 50%. Electronic paper operates on direct light absorption, with contrast limited only by the lightness and darkness of the particles (white) and dye (black) within the display. LCD viewing is impaired by wearing of polarised lenses (as with many sunglasses).

The net effect has some similarities. The mechanisms and characteristics are quite distinct.

Electronic paper is not based on liquid-crystal technologies at all.

@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.

@tbr And yes, I've got Termux, so, ssh/scp rsync and the like. Utter game-changer / life-saver.


Regarding the Pocket App: I'm using a Kobo Clara HD, and it comes with Pocket integration. After I sync it with my Pocket account, my articles in Pocket appear as expected on the ereader. The built-in app pages through the articles (no scrolling).

I also use the ereader because it has Overdrive built it and I can borrow ebooks from my local library.


@dredmorbius I'd love such a resource too!

I'm curious how I'd design a web browser for it! Currently I suspect the output constraints would yield a similar design as smart TVs' input constraints do...

@alcinnz In practice, there seem to be a few specifically-designed apps. For the most part, users are expected to install apps from either the vendor's (Onxy) curated store (a pretty good selection), Google Play, or F-Droid (which works wonderfully on the device).

Interestingly, Termux is among the better-performing native apps, and if you install the "Styles" app, includes a black-text-on-white-background e-ink style.

I've tried running the aalib demo 'bb' (over an SSH session, for some reason Termux has failed to package this... ) on the device. I would not recommend this. Though it gives an honest effort.

(Might even be manageable at one of the faster display modes.)

@alcinnz For browsers:

  • Scrolling vs. paging is my biggest gripe.

  • Sites that fuck with foreground / background colours is a major PITA.

  • Animations ... really suck.

  • Anything that's based on gradients or colour differentiation is a total fail.

  • Small fonts are actually readable and render (Hacker News, I'm looking at you), but are a PITA to read. The effective resolution is 300+ DPI, far higher than even Retina (which suffers as well from a 3x reduction due to 3-colour output), and comparable to laserprint, though without the ink/toner bleed printing often experiences.

If Fennec's Reader Mode works, I use it. That would benefit from definable margins (there are some settings, but they're limited).

The Pocket extension / app's dialogs are exceedingly ugly, and often unreadable.

Fennec's Private Mode controls are similarly unreadable.

PocketBook (an alternate reader) suffers some weird glitches on menus and other elements. I've been reasonably happy with it on an emissive Android device. It does quite poorly on the e-ink device.

There are several other eBook readers (Kindle, Kobo, Nook, Wattpad, Scribd, Libby, Flipboard), most of which I've not yet tried. I suspect they'll have usability issues given other tools used.

The Wikipedia app seems reasonably low-frustration.

I was hoping for a device that would be a relatively poor Android tablet, if only to keep distractions to a minimum. It's delivering on that desire. I can fetch books from Gutenberg / / Standard eBooks / LibGen / Sci-Hub / ZLibrary, but tend to not want to spend too much time browsing.

Listening to podcasts works pretty well, though somewhat better sleep / shutdown settings would be preferred. Auto sleep intervals are 3, 5, 10, and 30 minutes, or "never".

Power-off is 15m, 30m, 1h, 12h, 1 day, 2 days, or never.

That's ... oddly grained.

A 2h standby and 2/4/8h power-off would be better IMO.

(Much of the batter life is attained by aggressively sleeping / powering off when not in use, though with the backlight disabled, power draw is very minimal whilst showing a static display.)

@dredmorbius This all makes sense!

And I was planning on using paging with enforced colour contrast for TVs...

@alcinnz One control I really wish I had was GIMP's thresholds tool.

That lets you map an input range to an output range. For relatively low-contrast content, say, a book scanned in colour or grayscale (see, e.g.,, what I'd like to do is be able to set floors and ceilings such that anything darker than a certain threshold is simply "black" and anything lighter "white".

You can monkey with that further to allow some tolerance within that for image (or define image fields within the work where contrast regimes differ). But if you're looking for straight readable text, that helps a hell of a lot.

The Onyx BOOX has some control over this, but I find myself fighting it a lot, and/or wanting to be able to set defaults for a specific application or website.

@geert Is that documented anywhere? The pgmtopbm(1) manpage (on Debian) only briefly mentions "-threshold" as an option, but not its use. There's the additional note:

The only reference you need for this stuff is "Digital Halftoning" by Robert Ulichney, MIT Press, ISBN o-262-21009-6.

Though that is on LibGen.


@dredmorbius @alcinnz Isn't that sufficient?
On Ubuntu (should be identical to Debian):
"The default quantization method is [...]. Also available are simple thresholding (-threshold) [...]"
"The -value flag alters the thresholding value for Floyd-Steinberg and simple thresholding. It should be a real number between 0 and 1. Above 0.5 means darker images; below 0.5 means lighter."

@dredmorbius Noted this down, and I will add it as an issue to my rendering engine once I find it relevant to create a repository for it!

@dredmorbius for the greyscale part, it might be worth looking into analysis of the MacOS 7-9 UI. I remember that was high contrast and effective on low-res greyscale displays.

@s0 I can remember working on some large (at the time) Sun workstations running X11 at 19" greyscale circa 1990. Probably at 1024x768 or better resolution (this at a time when PCs didn't even have graphical displays, though VGA was 640x480 -- I first saw that on Windows 3.0 in ~1992/93).

They were pretty crisp, all told.

Though as CRTs, also had high refresh, low artifacting, and emissive displays. Electronic paper lacks those (though the high-refresh-rate video performance is ... sufficient to an enabling level, you can actually watch video or GIFs on it).

The Mac 128K display was 512x342 pixels:

That resolution was retained on the SE, Classic, and Color Classic, though the latter could be switched to a whopping 580x384.

The G3 iMac was boosted to 1024x768. In 1998.

@s0 The first few (non-colour) generations of MacIntosh were notable for making heavy use of line patterns in charts and graphics. Since you couldn't differentiate regions by colour, you had to use patterns.

As here, an 8x6 grid with 42 patterns total.

@dredmorbius this image of Mac OS 8 is colour, but you can see some of the key design features that still apply without colour. Patterns (narrow horizontal or vertical striping) on things that can be dragged to move, inset or outset shadows to indicate clickable/editable elements, with darker & inset meaning active, lower contrast 'greyed out' inaccessible elements

@s0 Right.

That was released in 1997, and ran on a broad range of hardware. I wasn't a Mac owner at the time, though I'd encounter it occasionally through friends or work.

The Quadra, one of the older systems OS 8 ran on, could display 512x384 in "thousands" of colours (presumably at least 2,048, perhaps 16k), 648x480 at 256 to thousands (512KB vs. 1024 KB versions), and up to 1152x870 at 16 or 256 colours.

The 20th anniversary Mac (1997) ran 800x600 or 640x480 up to 16 bits (65k), PowerMac G3 up to 1024x768 (ATI Rage 128 GL 16 MB).

In other words: limited resolution, colour (though limited), and high refresh.

I'm looking at devices with:

  • Up to 1650x220 pixels / 300 DPI (13.3"), Smaller 10.3" (1872x1404 227 DPI), 7.8" (1872x1404 300 DPI), and 6" (1448x1072 300 DPI) devices / displays exist.
  • 16 level greyscale (some colour devices exist).
  • Refresh of up to about 8Hz, though typically about 2 Hz
  • Minimal power draw so long as image does not refresh.
  • Sunlight/daylight readable. (Best readability is actually under direct sunlight.) Backlight / frontlight is typically available.

Some of the contrast/pattern guidance may fit, though unless you can map that to specific attributes of source materials (e.g., applications, websites, colour-to-pattern map), ... you may end up with issues.

@dredmorbius @s0 Probably 1152x900, which is about the most you can get from 1 MiB of video RAM.

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!