[Home]  [Prev]  [Next]    A guide, a tutorial for developing well-designed cross-platform applications

4. Inside the layout

The content of any layout is the responsibility of the application itself. It's impossible to set up guidelines which cover each case. But there are some general points that should be considered for each application.


4.1 Colouring

Colouring anything usually enhances the readability but colour may never be the only visible info. Colour info must always be accompanied by other visible distinctions, i.e. bold, inverse or boxed. There are still some monochromes devices out there and there are colour blind people.

Use colour sparingly depending on the type of you application. If your application is used for working daily with on the job, use colour only to make information more clear. If your application is used in spare time at home it might be more colourful. But never leave the impression your application is just colourful because it hides missing functionality.


4.2 Used fonts

Regardless what type of application only a single font should be used. Only if a different font carries essential info, i.e. a proportional font displays description while a mono-spaced font displays code, several fonts can be used. Still it is preferable to use styles like italics instead of choosing another font.

Don't mix fancy fonts with normal fonts. While it's okay to use one or several fancy fonts for a game, standard fonts for tools are better (i.e. clearer). Consider for daily working good readable fonts are better that good looking.

Fonts for printing is a little different, think the resolution in dpi's is much higher for paper than screens. Therefore good looking fonts have their right to be used since the most probably are also good readable.


4.3 Field sizes

When you decide on how large a field should become, consider what the field contains. If the field holds a image with a dimension in pixels it's fine to declare the size of the field also in pixels. But if the field contains text it should be declared in font units. Since font units usually aren't available it can be computed the following ways:

Sample code: Average char width

    const int ch = GetCharWidth(); // get width of current font
    const int sz1 = 20*ch; // width of a text lable

Sample code: Dummy text width

    wxClientDC dc (this);
    dc.SetFont (wxSystemSettings::GetFont (wxSYS_DEFAULT_GUI_FONT));
    long width, hight;
    dc.GetTextExtent (_T("09.09.2999 23:59:59 "), &width, &hight); // date, time format

Take care that sizes of different fields have a recognizable relationship. Make the difference in size in steps, i.e. 1x, 1.5x, 2x, 3x ... of the smallest field. Make long fields exceptional long, fields with a defined content (i.e. always 2 char) exactly fitting. Sizing of fields have a large impact on the layout and therefore if a user feels comfortable.