Human factors
Extensive documents on Human Factor Engineering describe GUI design in scientific terms (see the Reference section). In particular, font choice may be based on calculating the arc subtended by a character from a point 20 inches from the character (the viewing position). While I have worked on projects where it was necessary to actually measure these angles to confirm compliance with specifications, it is not usually necessary to be so precise.
When designing an application that includes a GUI, you should consider the following human factors:
1 Ensure that the application meets the end user's expectations. If a paper system is currently being used, the GUI application should mimic at least some of that operation, for example.
2 Keep the interface simple and only request necessary data from the user; accordingly, only display pertinent data.
3 Select fonts that make the interface work effectively. Use as few different fonts as possible within a single screen.
4 Lay out the information in a logical sequence, grouping areas where appropriate, so that the user is led through the information in a smooth fashion, not jumping between key areas.
5 Use color sparingly and to achieve a specific purpose. For example, use color to highlight fields that must be entered by the user as opposed to optional fields.
6 Provide multiple navigation methods in the GUI. It is not always appropriate to require navigation to be mouse-based; tabbing from field to field within a form may be more natural to users than clicking on each field to enter data. Provide both so the user may choose.
7 Ensure consistency in your application. Function keys and control-key combinations should result in similar actions throughout a single application and between applications in a suite.
8 Some platforms may have GUI style guides that constrain the design. These should be adhered to, even if it means developing platform-specific versions.
9 Provide help wherever possible. Balloon help* can be useful for beginning users but may be annoying to experts. Consequently it is important to provide the user with a means of turning off such facilities.
10 The UI should be intuitive so that it is not necessary to provide documentation. Careful field labeling, clues to input format and clear validation schemes can go a long way to achieve this goal.
11 Whenever possible, test the UI with end users. Building prototypes in Python is easy, so take advantage of this and get feedback from the target audience for your work.
16.2.1 Choosing fonts
Choosing an appropriate font for a GUI is important to ensure that an interface is effective. Readability is an important factor here. A font that is highly readable when displayed at a screen resolution of 640 x 480 may be too small to read when displayed at a resolution of 1024 x 768 or greater. The size of the font should, therefore, be either calculated based on the screen resolution or selected by the end user. However, in the latter case, you should ensure that the end user is given a range of fonts that the application can display without changing screen layouts or causing overflows, overlaps or other problems.
Font selection can be crucial to achieving an effective interface. In general, serif t fonts should be avoided. Most of us are used to reading serif fonts on printed material (in fact, the body of this book is set in Adobe Garamond, a font with a light serif) since we believe that we are able to recognize word forms faster in serif as opposed to sans serif fonts. Unfortunately, many serif fonts do not display as clearly on screens as they do when printed, since the resolution of most printers is better than that of displays.
Take a look at figure 16.8. This shows a screen grab, at 1024X 768 resolution, of Times New Roman and Verdana fonts in three point sizes. The sans serif font results in a crisper image, although the overall width of the text is greater. In most cases, it is easier to select Arial.
This is an 8£t serif font This is a 1 Opt serif font This is a 12pt serif font
This is an Spt sans serif font
This is a 1Optsans serif font This is a 12pt sans serif font
Figure 16.8 Comparing Serif and Sans Serif Fonts
* Balloon help is displayed when the cursor is placed over a field or control without moving it for a short time. The help may be displayed as a message in the status area of a window, if it has one, or in a popup balloon close to the field or control. t A serif font is one in which each of the letters contain small artistic flourishes that appear to give the glyphs ledges and feet. Common serif fonts include Times, Bookman, Palatino, and Garamond. A sans serif font is one that does not contain these extra flourishes. Common sans serif fonts are Helvetica, Arial, Geneva, Gothic, and Swiss.
or Verdana for Windows and Helvetica for UNIX and MacOS, since these fonts are usually installed on their respective systems. Figure 16.9 illustrates these fonts.
|
This is Arial This Arial Bold This is Verdana This is Verdana Bold This is Switzerland This is Switzerland Bold | |
|
Figure 16.9 Arial, Verdana and Switzerland Fonts |
Now let's take a look at what can happen if a font is selected that is just not meant to be used for a GUI. The fonts used in this GUI look great when printed, but when displayed on the screen, they produce the effect shown in figure 16.10. Although the weight of the font is adequate, it just does not look right on the screen.
|
■ dllliUJFffil Nama |
|john |
|E |Cray |
on |
|
Position |
|The Boss |
_rj Employas gl 12345 | |
|
Phono |
(|4oT) [555 |
-|]2]2 |
ssw|l23 -|45-|67S9 |
|
Address 1 |
¡My Street | ||
|
Address E |
1 | ||
|
City |
My City |
Stria |RI Hp |01234 | |
|
OK 1 | |||
Figure 16.10 The effect of selecting the wrong font
Figure 16.10 The effect of selecting the wrong font
In summary:
1 Choose sans serif fonts wherever possible.
2 Use a minimum of font types, sizes, weights and styles within a single screen.
3 Allow for different screen sizes, if possible.
4 If the user is able to choose fonts from a theme or style, use that font, even if the result offends aesthetics.
16.2.2 Use of color in graphical user interfaces
The process of selecting color schemes for a GUI is highly subjective. In many cases it is best to allow the end user complete control over the colors that will be used within an application. The current trend in systems (Windows and UNIX CDE) is to allow the user to select a theme or scheme and then apply the selected colors, extrapolating alternate colors as appropriate. If you design your GUI to look good using just shades of gray and then calculate colors based upon the user-selected scheme, the GUI will probably work well. That way the user is allowed the privilege to select bizarre combinations of colors; after all, who are we to judge?
The basic rules to be followed with color are these:
1 If you need to distinguish a graphic item, select color as the last method.
2 Use color to draw the user to the most important features on the screen.
3 Remember that your user might be color blind* and might not perceive color contrast in the same way as you do.
4 Create optimal contrast between your graphic components. You should avoid 100% contrast in most cases.t
5 Avoid reverse video (light on dark) except where you must draw attention to a graphic component. A good example of reverse video is to indicate a validation error in an input field.
As an illustration of how color selection can become a problem, take a look at figure 16.11. Although it is not possible to see the direct effect of color on the page, the color scheme chosen is quite pleasing, in warm tones of brown, olive green and cream. However, an application with GUIs implemented with these colors would prove tiring in practice, though it might look good for a short demonstration. The major problem is the use of low-contrast reverse video in the entry fields. Incidentally, the colors used in this application were adapted from a commercial application; I'm sure the designer was proud of the result that had been produced.
- Figure 16.11 Problems with color combinations
* It is relatively easy to design color use to accommodate individuals with color-blindness. Do not use primary colors; mix each color with varying amounts of red, green, and blue so that the overall chrominance varies. The overall effect will not appear greatly different for individuals with normal color vision, but it will appear distinct for those with color blindness. If you have an application which is in a mission critical environment and might be used by individuals with color blindness, it may be prudent to have your GUI checked out by someone with less-than-perfect vision. t Not all monitors display black on white as clearly as they display black on grey (or some other light color combination). Try black on 90% gray, for example. (Note that 90% gray is really 90% white and 10% black).
16.2.3 Size considerations
Apart from the need to ensure that a GUI works at different screen resolutions, consideration must be made to determine whether the user is permitted to change the size of the displayed GUI. Having designed a well-proportioned screen, it can be difficult to allow the user to change the size of the display at will. In many cases it is better to disallow resizing of the screen rather than attempting to maintain an effective GUI regardless of what the user requests (see "Geometry methods" on page 307 for details about how to do this).
In the examples presented earlier in this chapter, resizing was handled by assigning one field on each line to stretch if the window was made larger. This is generally appropriate, but it may result in strange screen appearances. Shrinking a window is much harder to handle and may be impossible.
If the screen does not contain scrolled widgets (text, lists, etc.), it is probably better to fix the size of the window and maintain optimal layout.
Post a comment