Chapter 1

Figure 15.9
In 1999 a new strategy evolved, in which Symbian would support only a limited number of
GUI reference designs, targeted at different types of hardware, from smartphones to higherend
communicators.
The first ideas for reference designs had a range of device parameters for each design, for
example,
� display in the range 320+ x 120+ pixels,
� optional pointer,
� keypad.
But it soon became clear that this kind of flexibility leads to significant nonoptimality in a
design.
Let's say that you design a view for exactly 320 × 120 pixels: you go to all kinds of trouble to
cram in text and abbreviate words; you use icons instead of text, popup displays, very simple
views that sacrifice functionality, perfect alignment of various columns and icons, and so on.
A display such as this will break if you make it even a single pixel smaller, but it will look
equally odd if you make it larger : Users will wonder why you didn't use the extra space.
To give another example, imagine that when you design, you take the view that there may or
may not be a pointer. Then you have pointer- driven ways of doing everything and
alternative joystick/keypad-driven ways of doing everything. These may not be very
compatible: a screen with a pointer can have many more buttons, for example, than one
using a joystick or arrow keys. If we deliver a design that is obviously optimized for pointers
rather than a keypad or joystick, users with only the keypad/joystick will consider it even
more awkward. Worse still, we might forget to optimize the design sufficiently for the needs
of keypad/joystick-only users.
It's clear that a GUI – especially at the smartphone-end of the market – has to be quite
inflexible in its design parameters. It must specify screen size and input devices exactly, and
allow for no variation.
Architectural consequences
The reference design strategy required that the GUI system (previously Eikon) be split into
three elements:
� A core GUI framework called Uikon (Universal or Unified Eikon). This includes the
Uikon Core (eikcore.dll) that contains framework classes such as CEikAppUi and
CEikonEnv and the Uikon Core Controls (eikcoctl.dll) that contained a number of
concrete controls, such as menus and list boxes, that are expected to be present on all
devices. You could write an application using Uikon alone that would be good enough to
test some engine APIs, but not much more.
� the reference design itself that would add more concrete controls,
� a look-and-feel (LAF) module, which could differ for each device. The LAF allows the
manufacturer to specify such things as system fonts and bitmaps.