Designing for e-ink

Three properties of the medium drive every rule below: the display is reflective rather than emissive, it has no pointer, and changing it is slow and visible. Everything else follows.

There is no hover, so there is no hidden affordance

E-paper devices are touch or button driven. There is no cursor, so :hover never matches — and any information you put behind it is information the user cannot get. That rules out a surprising amount of common practice: tooltips as the only explanation, controls that appear on row hover, hover-underlined links, hover-revealed overflow menus.

The replacement is not "show everything always", it is to move state into attributes that are visible and semantic.

/* Not available on e-paper. */
.row:hover .row__actions { opacity: 1; }

/* Available, and better: real state, visible to CSS and to assistive tech. */
.ink-tab[aria-selected='true'] { border-bottom: var(--ink-border-strong); }
.ink-option[aria-checked='true']::before { content: '■'; }
.ink-row[data-active] { outline: var(--ink-border); }
.ink-btn:focus-visible { outline: 3px solid var(--ink-fg); outline-offset: 2px; }

This is the rare constraint that is purely a gift. Every one of those selectors works on a touchscreen phone too, where :hover has been a lie since 2007.

Signal state without colour and without motion

A monochrome panel has no red for errors and no green for success, and you cannot animate a spinner. So state has to be carried by the three channels that remain: text, shape and position.

• Text first. "Failed — retry in 30 s" outperforms any icon on any display. It also happens to be what a screen reader announces.
• Shape and fill patterns for categories. A hatched fill, a double border and a solid block are distinguishable at a glance and survive photocopying, which is roughly what 1-bit rendering is.
• Position for status. A metric that moves to the top of a list when it degrades communicates faster than one that changes colour in place.
• Explicit progress over indeterminate progress. A spinner is an animation you cannot have. A discrete step counter — "3 of 8" — carries more information and costs one small rectangle to update.

This is the same discipline WCAG asks for when it says colour must not be the only means of conveying information. Designing for e-ink makes that criterion structural rather than a review checkbox.

Contrast is a physical budget

A backlit screen emits; contrast ratios are stable regardless of the room. A reflective panel returns ambient light, so its contrast depends on the lighting the device happens to be in. Typical e-paper contrast ratios sit in the range of 12:1 to 16:1 under good light — respectable, but well below an OLED, and it degrades as the room dims.

The practical consequence is that mid-greys are not a safe design tool. A 40 % grey that tests fine on a monitor can be nearly indistinguishable from a 55 % grey on a panel in a dim corridor, and the panel's available grey levels — commonly 16 — are not evenly spaced perceptually.

1. Use pure black on pure white for anything that must be read.
2. Reserve greys for large flat areas — a table zebra stripe, a disabled surface — never for text or thin lines.
3. Do not encode meaning in the difference between two greys. If a reader must tell them apart, use pattern or a border instead.
4. Draw separators as real borders, not as light-grey rules. Two solid pixels beat four grey ones on a panel.

Typography on a slow, high-DPI, 1-bit surface

E-paper panels are usually high-DPI and non-backlit, which is close to ideal for reading — the medium's one genuine advantage. It rewards typographic care more than a screen does.

• Serifs work here. The resolution is high enough to render them cleanly, and the reflective surface makes long-form serif text genuinely comfortable. This is the opposite of the low-DPI screen advice most style guides inherited.
• Set larger than you would on screen. 16–18 px body text is a floor, not a ceiling, and readers frequently hold these devices further away than a phone.
• Line length matters more. 60–75 characters, enforced with max-width in ch, because there is no scrolling momentum to make a long line forgiving.
• Avoid hairline weights. A 200-weight face at small sizes disappears into anti-aliasing artefacts when the panel renders in a 1-bit mode.
• Left-align. Justified text without hyphenation opens rivers, and the panel's crisp rendering makes them more visible, not less.

Layout for a display that never scrolls smoothly

Scrolling on e-ink is either janky or ghosting-heavy, so the honest design target is a page, not a feed. Pagination beats infinite scroll on this medium by a wide margin — one update per page turn, arriving at a predictable moment, versus a continuous stream of partial updates the panel cannot keep up with.

• Prefer fixed regions with stable positions over content that reflows as data arrives.
• Give volatile values a fixed-width slot — font-variant-numeric: tabular-nums and a min-width — so a number growing from 9 to 10 does not reflow its neighbours and enlarge the dirty rectangle.
• Group things that change together, as the partial-refresh guide explains: update cost is the bounding box of the change.
• Make touch targets generous — 48 px minimum. The panel's update latency means a missed tap costs a full second of confusion before any feedback arrives.

Feedback when nothing can move

On a fast display, a button press is acknowledged by a ripple in 16 ms. On e-paper, the acknowledgement itself takes 150–300 ms, which is long enough for a user to conclude the tap missed and press again.

1. Acknowledge in the smallest possible region — invert the button, do not re-render the panel it sits in. A small rectangle in a fast mode is the closest thing to instant that the medium offers.
2. Make the acknowledgement 1-bit. An inversion is exactly the update a DU waveform is good at.
3. Never queue a second acknowledgement for a repeated tap. Debounce at the input layer, or the panel spends the next second replaying presses.
4. For anything slower than about a second, show a real progress state with a number in it, not an indeterminate one.

Colour e-paper changes less than you would hope

Colour panels — Kaleido, which puts a colour filter array over a monochrome panel, and Gallery/ACeP, which uses multiple pigments — are real and shipping. They do not lift the constraints above; they add one.

• Colour filter arrays reduce effective resolution and lower contrast, because the filter absorbs light on a display that has no light to spare.
• The gamut is narrow and saturation is low. A colour chosen on a monitor will arrive muted and slightly shifted.
• Multi-pigment panels are dramatically slower on colour updates — full-colour refreshes are measured in seconds, not milliseconds.

The workable approach is to design a complete monochrome interface first and treat colour as a redundant accent — a category tint that reinforces a label already carrying the meaning in text. That way the design still functions on a monochrome panel, in poor light, and for a colour-blind reader, which is the same requirement three times over.

A checklist

• No :hover-only information anywhere.
• No animation, no transition, no indeterminate spinner.
• Every state readable as text, not only as colour or icon.
• Pure black on white for anything that must be read; greys only for large flat areas.
• Body text 16–18 px minimum, 60–75 characters per line, left-aligned.
• Touch targets 48 px and up.
• Volatile numbers in fixed-width slots, grouped together on the page.
• Pagination rather than infinite scroll.
• Colour, if present, redundant with something already stated.

EPaper enforces the first two in code — base.css resets transition and animation inside .ink-page, and the library ships no :hover rule at all — so the remaining seven are the ones that stay a design responsibility.