A phone
with two screens.
The Yotaphone 2. Five inches of AMOLED display on the front, 4.7 inches of always on E-Ink in the back. Take seven designers and a full hangar of developers. No basic apps for the front screen android. Not even a single reference point for the e-ink screen ui. Just some design cases of the e-ink readers.
In the beginning there was a complete vacuum.
Design of an interface system, widget system, basic infrastructure applications, graphic style, font, iconography and grid system for the e-ink back screen of the phone. Art-direct several teams that were building applications for the front screen.
UI\UX, Art-direction, Design lead.
Everything in 180 days.
I was the Design Lead and an Art Director of the team. We had six months to create everything. UX/UI for 50 e-ink infrastructure apps: Clock, Calendar, Calls, Messaging .. et cetera, et cetera. 10 apps for the front screen. Fully tested UX for all cases of interaction with the phone, ex.: flipping the phone from back to front, moving the app from front to back screens, locking & unlocking the screens.
A mammoth task.
There was a fork of decision-making beforehand: develop the back screen as a supplementary part of a phone, like an informative set of widgets, or develop a complete infrastructure of applications, so that the user might never need a front screen for his day to day activities.
The decision went for the latter: we are building a complete e-ink constellation of apps and widgets.
Full phone infrastructure
On top of being the Design Lead and an Art Director of the team, the situation required me to actually work on all designs aswell. Everything from the ground up, later to be picked up and continued by the team members under my direction.
It was a vacuum, no references, no design have been done for this kind of medium, conditional UIs was not applicapble, only e-ink reader design.
The most important groundwork for the UI was to define the grid system and typography that works on a 540×960 e-ink display, low contrast light, with and without antialiasing. Remember that e-ink doesn’t emit light? It also must update all screen pixels every time it changes state, to avoid leftover traces of previously opened pixels.
What is the minimum readable text size? Serif of sans serif? How will buttons work without the quick response of an OLED screen? We were been testing and building everything on the fly. In general we had to adopt a mixture of iOS and Material that was fitting the constrictions of our framework.
The animation. E-ink can only support antialiasing and 32 levels of grey. However, the whole screen has to be updated every time. Alternatively, it can have a pure black or white mode, with separate 50ms updates of any region of the screen. Unfortunately, this mode still left lots of garbage pixels in animation. The clock ticking 360º — a full circle glitch show. We were forced to abandon everything we have learned about animation idea and stick to the capabilities of the e-ink readers. Anyway, there was no time to cry about that.
