---
# System prepended metadata

title: Technical restraints imposed by eink which need to be taken into account for UX
tags: [ux, general, psych-ux]

---

# Technical restraints imposed by eink which need to be taken into account for UX

## Authors
* Tom Phillips
* Wenting Zhang
* David Boddie


## Overview
This document is for gathering knowledge about the technical restraints imposed by eink, using them to reason and ideate guidelines for eink UI/UX. (e.g., slow screen updates >> pagination rather than scrolling).

(The idea is to continue growing the list as much as possible)
* see also [eink text editor](/YpI3eg2mTkSxtAb1aTw0Hw) for ideas applied to a specific use case

###### tags: `psych-ux` `ux` `general`


<br/>

**1. Slow screen updates**
* Eink screen updates are slow
* both partial and full updates take the same amount of time, worst case ~<300ms (though @wenting is looking into how to speed this up). 
    * For comparison, a typical LCD monitor updates at 60Hz, taking about 20ms.


* This means the screen is less responsive to the users input than traditional interfaces (e.g., LCD), and that animations to guide/feedback user actions must be relied on less
    * For example, Light phone OS is "designed to be 'frame-by-frame' with few dynamic segments and virtually no animation"
* *UX guideline 1:* users must receive feedback and guidance about their actions via shorter animations and other methods meaning other forms of guidance must be made stronger
    * For example, physical based UI (e.g., keyboard buttons) can be made more prominent
    * Haptics/sounds
    * Can't use a mouse/cursor in the same way, >> touch screen / keyboard shortcuts are an alternative
        * How would you select text to copy and paste? Click and drag? What animation signifies that text is selected? - is it just a slower version of the LCD equivalent? Or do we need something new?

    * note: look into other methods of guidance/feedback
* *UX guideline 2:* no video
* *UX guideline 3:* pagination; no scrolling


<br/>
<br/>

**2. Eink is bistable**
* Once the screen is updated, an eink screen maintains content (effectively) for an indefinite amount of time without power (i.e., it is bistable).


* *UX guideline 4:* utilise this where possible, e.g., use lock screen to display relevant information, pagination rather than scrolling

    


<br/>
<br/>

**3. Screen updates are expensive**
* While eink can maintain content for long periods, updating the screen content is expensive (see Figure 1 below)
<br/>
#### Figure 1
![Figure 1](https://i.imgur.com/VSgCrZN.png)
<br/>

* N.B. Partial updates use less power than full updates, although both take the same amount of time
* however, worth noting that light phone had trouble with partial updates, and always used full updates


* *UX guideline 5:* to maximise use of partial updates, screen layouts should be maintained where possible throughout interaction with the device, avoiding the need to fully refresh all elements on the screen
    * (this may be difficult in practice)

<br/>
<br/>

**4. Difficult refresh = ghosting**
* because each refresh involves resetting to either full black or full white, you can often be left with ghosting 
* partial updates are more likely to create ghosting (is this true??)


* see guideline 5 above, keep the UI elements at the same place whenever possible (no animation, no moving things, avoiding scrolling, etc) so that each instance of ghosting is local to the elements.

<br/>
<br/>

**5. Display is monochrome**
* ...
* e.g., contrast needs to come from black vs white
* Could you create a black and white filter that makes it easier to distinguish colours?


    * e.g., if a website has red and green next to each other, alter the way the content is displayed, maybe make one stripy etc.


<br/>
<br/>

**6. Technical restraints imposed by current waveform implementation**

* With the current waveform implementation from E-ink Inc., turning to grey is more expensive. 


    * Because each pixel can't turn from one level of grey to another level of grey without first going to black or white. The result is the grey area would looks to be flashing during update


        * *UX guideline:* use this flashing quality as a visual feedback response to user interaction on the screen, like e.g., the kindle does when you press a button


* Theoretically, turning to black should be more expensive. (is this because you have to send the particles a longer distance ??)
    * We are looking to change this with open-source waveform and variable frame rate driving techniques


* Do a partial update, better if the pixels are turning to full black or full white. But really, these power differences are margainal.


**7. Tiling window managers**

* Would tiling window managers be a good match for the technical limitations of e-ink and similar displays? Seems that existing environments which compose overlapping windows really bring out the disadvantages of these displays, though eink can be configured to work without the effects that can cause most problems.
* If you take a look at older computers from the 80s, they had similar limitations to EPD: limited colorspace, not enough horsepower and mouse dexterity to do visual effects (in our case it's low refresh rate, but the same solutions can be applied). Windows 1.0 used a tiling window manager and that worked pretty well for them: 256 colors (although mostly limited to a 16 color palette), no gradients, no animations... all that would apply perfectly for EPD.