OLPC theme and display

A small review of a few theme elements and how they behave with color swizzling and high resolution screen

Last updated on August 21st, 2006.

Background & Disclaimer

Designing a good GTK theme and engine for the OLPC is not going to be a very straightforward task (and any GTK engine design requires a bit of dark magic anyway). We're dealing with three very strong constraints at once:

• The screen is very small (exactly 6 x 4.5 inches, about 15 x 11 cm).
• The screen has a resolution twice as high as our usual screens (200 dpi VS 96 dpi -- 1200 x 900 pixels).
• For power saving purposes, we work in a "color swizzling" mode, meaning that each pixel of the display can only be red, green or blue, according to the following layout:

In photographic terms, the display has high resolution, but low acutance. The display can resolve small details more or less fine, but it has a hard time with sudden contrast changes between pixels.

I have been working on simulation tools for the OLPC display.

1. Color swizzling with Xephyr

I made a patch for Xephyr that does the following:

1. Filter (antialias) the image the same way the OLPC does: for each pixel, first figure out what color it will be on the display (remember the color swizzling). Let's say it'll be green. Then take the following fraction of the around pixels' corresponding component (green):
   

   	1/8
   1/8	1/2	1/8
   	1/8

   and replace the current pixel's color component with the new value.
2. Perform the color swizzling (for each pixel, discard the two irrelevant color components).
3. Since the previous step darkens the image a lot (2/3 of the signal is discarded), the result is not loyal to the actual display. To restore a correct visual impression, a postprocessing step (thanks to David Turner) restores, for each pixel, the two lacking color components. For a red pixel for instance, compute the average of the green pixels on its right and below it, and the average of the blue pixels on its left and above it:
   
   This is a good approximation of what the eye will actually perceive, merging each pixel's own color with the colors around.

2. Shrinking images for correct visual dimension

The OLPC screen is very small, and has a resolution twice as high as our usual displays. Based on these observations, a "shrinking" process takes a 1200 x 900 pixels image and creates a 600 x 450 pixels image by reducing each group of four pixels into on as follows. For example, with a group of four pixels like this:
thus averaging the two green pixels among the four (same process for other cases).

3. What the images below are

Each image is a screenshot of Xephyr running in (color swizzling + antialiasing + postprocess) mode. The smaller images directly included in this page are the ouput of the shrinking process applied on these screenshots. If you click on either of them, you will get the full original screenshot.

Therefore, the small images are a good preview of what the display would look like at a normal distance. If you measure their width on your screen, you shouldn't find something very far away from 15 cm (probably even a little larger). The larger images are a good preview of what you would see if you had a closer look, but of course they don't have the right visual dimensions. Let me rephrase this: small images are not thumbnails of larger ones :-)

Disclaimer: I am aware that Sugar won't look like that at all. The desktop screenshots are for display purposes only, the laptops won't have a traditional desktop like this. Design plans seem to have changed recently and I don't know very precisely what they are, so I merely wanted to find out a few pieces of information about what looks good on this simulator and what doesn't. I change one parameter at a time, except fonts (otherwise things would just be unreadable all along).

Readability

Obviously, GNOME's default font size (10) wouldn't be suitable for us. It would look awful because of the color swizzling, and it would just unreadable (much too small). Here is what the default font looks like (size 10):

Make this a bit bigger (size 14)

is probably not quite enough yet. A bit bigger (size 16):

We could even go as far as 18:

This makes the title bar slightly higher, but I guess it's necessary (and probably won't have title bars anyway).

Same goes with web browsing: default size is

But that's even easier to change (and choose a good default -- the following one may be a bit too big):

Note that the color swizzling artifacts don't go away in the shrunk image. However, I'm confident in saying that this shouldn't bee too big a problem on the actual display (if you got one, please let me know what it looks like!).

All the following images use a 16 pt font, other parameters vary one at a time.

Thin lines

Because of the swizzling + antialiasing process, thin lines won't look good. More precisely, thin lines with high contrast won't look good at all. Not too dark grey lines on a white background will probably look okay.

Actually, thin lines have a kind of "tut-tuttering" look, as if they had been sewn onto the screen. A good example is the bottom border of the top panel (I know we won't have a panel, this is just a good example):

Removing it gives us:

Thin lines look bad and are easy to remove whenever they mark the limit between two very different color zones. Another example: window borders. Dark window borders look like this:

and removing the right/bottom/left ones produces this (still needs refining, but you get the idea):

Of course, the downside is that the limit between two windows is not so clear anymore (the front one has a border, back one doesn't):

but we're probably not going to display several windows at a time like this anyway.

The problem of thin lines will rise for lots of widget types, buttons for instance. Buttons with too heavy borders don't look so good:

The current OLPC theme's buttons look okay though (the border width might need an extra pixel), at the top of this window:

Common tab designs also have this "thin lines" problem, like here:

Light borders on a darker background look slightly better:

but we're probably going to need some neat fancy design for tabs if we use them.

Making lines much thicker works okay, but it might not be the most beautiful solution :-) See these icons:

Pictures

Good news, most pictures look fine in the simulator. Parts with high contrasts, sharp edges and thin dark lines are a bit noisy, but the overall feeling is really good. For example, a nice scenery:

Or a mockup of the current Sugar design (original image is 640 x 480 pixels: I made eog display it full screen -- 1200 x 900). Even with the whole resizing/swizzling/AA process, it looks fine:

Enlarge elements the user will be interacting with.

The Nokia 770 theme has pretty small elements (scrollbar, etc.), but first, the OLPC's trackpad won't be as precise as a touchscreen, and second, movements of children may not be as precise as ours. I think we definitely need to enlarge all the elements that users will need to drag or click on.

So, regular icons would be a bit small:

Enlarging them a little does this:

which looks more usable (always keep in mind that these small pictures are about the right size for the OLPC screen).

Same goes with scrollbars. One may have a hard time clicking on the right place with this (ThinIce default):

LargePrint already has a decent size:

The scrollbar itself is okay, but the buttons are still very small (notice, however, that the toolbar buttons have a pretty good size). This (tweaked Clearlooks) looks better:

The appearant size of this scrollbar (on the shrunk picture) should match more or less the size of the scrollbars you usually click on (look at the scrollbar on the right, it should be about the same size if you use a common theme).

Enlarging the pointer seems logical in this process; this default size looks really tiny:

This is better, and again, the appearant size of the pointer should not be very different from your current pointer (okay, we don't need the fancy shadow, nor the transparency):

Same kind of problem: using this slider this might be difficult:

This still needs some tweaking, but should be easier to use:

If we ever use window borders, the close/maximize/minimize buttons might be a little bit too small:

However, making them larger would make the title bar even higher, and this would waste a lot of space. Enlarging the buttons horizontally should be enough:

Using the space on a small screen

Sugar will already be designed to make good usage of the screen's space (fullscreen activities, etc.) and the theme itself can only have minor influence on this, but apart from choosing the right font size (see above), we can still remove a bit of space where we can. For example between the content of a window and its borders: let

become

Saving space while making everything bigger (because the resolution is so high) is hard... Another trick could be to use a condensed font (here DejaVu condensed):

I hope these few observations have been useful. For comments/suggestions, don't hesitate to drop me a mail at manu DOT cornet AT gmail DOT com.