We were concerned about users being overwhelmed by the complexity of all the features of a smart desk controller, with only a small screen to control it. In addition to keeping the organization of the user interface as clear and simple as possible, we knew that clear sensible fonts, graphical elements, and animations could also significantly contribute to users’ enjoyment.
Grayscale for free!
A big reason our display looks better than most desk handsets is that we have grayscale. The biggest advantage grayscale gives us is the ability to do anti-aliasing on the fonts and other graphical elements.
Just two levels of grayscale (values 1 and 2, plus 0 for black and 3 for white) are plenty to do anti-aliasing to smooth out the jagged edges and produce significantly nicer fonts and graphics.
Like all handset makers, we are interested in minimizing costs, so we use a black and white OLED display that does not have grayscale. Given that our display can only produce white or black, how do we display the gray values? Since our display can refresh at over 200 Hz, we can do pulse width modulation (PWM) to dither the gray areas. Essentially, we flash those pixels faster than the human eye can see.
White pixels (value 3) are on all the time, light gray pixels (value 2) are on 2/3 of the time, and dark gray pixels (value 1) are on 1/3 of the time.
Having only four brightness levels (0-3) means we only need 2 bits of memory per pixel to store fonts, other graphical elements, and frame buffers.
Now that we have anti-aliasing made possible by grayscale dithering, we have more options for nicer looking fonts than the usual embedded options. We used Processing (https://processing.org/) to try different fonts at the resolution we needed. Once we chose good fonts, we used Processing to format the images for each character into data structures that our embedded code could access efficiently. This also gave us fine control over things like tracking and kerning.
Animations between various screens contribute to the polished feel of a user interface. We use animations to smoothly scroll up and down through the items within a menu. Then to help users keep a mental image of where they are in the menu navigation, we pan right when they select an item to go into a submenu. Then when they exit a menu, we pan back left to the parent menu. We use other animations at other times, like drop-down menus to select between multiple options, and diagonal motion for information screens that fly in and out. The speed of animations is a subtle but important detail. Rather than move at a constant speed, animations feel more natural by accelerating and decelerating like a physical object would. To also help with orientation, scroll dots along the right edge show you where you are within a menu.
We mocked-up the whole user interface using Processing. This allowed us to experiment with different animations, fonts, etc., and quickly iterate. We were also able to email the mock-up to multiple people to evaluate, all before we had any hardware.