Section 3: Mechanics and Style Guide

The mechanics of designing a form couldn't be simpler or more intuitive. When you start a new project, Delphi automatically creates and displays an empty form (overlayed with a grid of dots to help you to line up your controls in a tidy fashion). Adding a control to the form is simply a case of deciding what you need, clicking on the relevant button in the Control palette, and then clicking on the form at the position you want the control to appear. It is also possible to create controls more rapidly, by double clicking on the required icon in the component palette. Once placed, the control can be stretched (if appropriate) and dragged around, until you as the form designer are satisfied with the position and size. There are a number of style guidelines around for the development of Windows applications. As with web site design, you ignore these guidelines at your peril. The "useability" of your Windows application will be dictated not only by the functionality you provide, but also by the quality of the user interface.
You have probably by now spent many hours using Windows applications, and will have a set of implicit ideas about what works and what doesn't. For example, you will rarely see applications with luridly coloured backgrounds for all their forms. You will rarely see forms where the components are spread around in a totally random fashion. The reason for this is that such poor choices impact user performance when using the application. (or they impact the user's willingness to use the application). We will now lay out some simple design guides for the development of user interfaces.

Delphi provides a great many components by default, buttons, lists, drop down "combo" boxes, memo editors, scroll bars, progress bars, and a million others. Each component is self contained, and knows how to respond to user interaction. It is an essential part of learning to be a Delphi programmer that you become acquainted with these components, and use them appropriately in your application.

NOTE - Each component on the palette is implemented as a special kind of "Object". For those unfamiliar with object oriented programming, we will be saying a lot more on that subject in the next lecture, but for now, all you need to know about objects is that they are very similar to records, with one major difference... Some of the fields of an object represent variables (data) and some of the fields represent functions or procedures (methods). As with records, the fields of an object (sometimes referred to as properties), as well as the methods, are accessed using the dot operator. Just as a record can have fields which are in turn records in their own right, an object can have sub objects as part of its makeup. This means that to access a particular method or property of an object, it is sometimes necessary to use several dots, to provide a path to that part of the object you want to access. Consider changing the colour property of a label for example:

Label1.Font.Colour := clRed;

Here we are accessing the colour field of the Font object of the Label component named Label1. Some of the components in the palette have literally hundreds of properties and methods, so it is an uphill learning curve to fully understand all of them. Fortunately, Delphi's help file comes to the rescue here, providing full information on all the standard components. What you must concentrate on for now, is understanding for what purpose each of the components was intended.
Below are some of the issues you should consider when creating your user interface. One of the most important issues, if not the most important issue, is consistency. In a nutshell, what you do is not as important as doing it consistently

Relationship To Other Standards

  • Does the program follow the Microsoft Windows user interface standards?
  • Will the application be an SDI or MDI application? (Single or multiple document interface)
  • If the application uses a MDI what kinds of windows can be presented as MDI children?
  • What is the form background colour? Is it hard coded, or based on a system settings?

    Dialogs


    Flow among dialogs

  • Are both modal and modeless dialogs allowed, or is one style to be preferred?
  • Are multiple paths to the same dialog allowed, or is only one path to each dialog allowed?
  • Are circular paths among dialogs allowed (e.g., Dialog A opens Dialog B, Dialog B opens Dialog opens Dialog A)?

    Dialog Functionality

  • How is Help accessed from dialogs (i.e., Help button, F1 key, other help icon, etc.)?
  • Are tabbed dialogs allowed?
  • Do dialogs support the Apply button? If so, under what circumstances should Apply be supported, and under what circumstances is it not needed?
  • Are "common dialogs" used whenever possible (e.g., file open, file save, print, etc.), or does the program use custom dialogs?
  • Are dialogs resizeable?
  • What title-bar buttons appear on each dialog (e.g., only close, or close plus others)?
  • How are title-bar captions determined?

    Dialog Appearance

  • What font is used?
  • What style of group boxes is used?
  • If 3D effects are used, what standards apply to them (e.g., recessed vs. raised panels, thickness of panel borders, single recess vs. double recess, etc.)

    Buttons


  • How big is a standard button?
  • Under what circumstances can you create a button that is not the standard size?
  • How much space is there between buttons?
  • Are buttons generally to be stacked vertically or lined up horizontally?
  • Is there a standard set of buttons that should be present on every dialog? (Help, Cancel, OK)
  • Are buttons allowed to contain pictures, or just text?

    Toolbars

  • Are toolbars moveable, resizeable, dockable, and so on?

    Status Bars

  • Does the program have a status bar?
  • What fields are on the status bar?
  • Under what circumstances should each field be updated?

    Menus

  • How are keystroke mnemonics selected (e.g., by first letter if possible; dominant consonent otherwise, or some other plan)?
  • Are pop-up menus supported?
  • How are the contents of each pop-up menu determined (e.g., just the local action, or local plus more general actions)?

    Error Processing


  • How is the user notified of errors (e.g., program doesn't do anything; program beeps; message displayed in status bar; program displays pop-up dialog and requires user acknowledgment, etc.)?
  • Under what circumstances should the program just beep?
  • Under what circumstances should the program display an informative message?
  • Under what circumstances should the program require user acknowledgment?

    Colours


  • Does the program support 16 colours, 256 colours, or both?
  • What colours are allowed to be used in creating icons, toolbar buttons, and so on? Do you want to work from a specific set of colours that have been chosen to give the program a consistent look and feel, or may all colours be used?

    Accessibility


  • Does the program provide keyboard equivalents for all mouse actions?
  • Does the program use system settings for all colours (e.g., dialog background colour, dialog text colour, dialog text size, button face colour, button text colour, button text size, and so on)?
    One of the best pieces of advice going on the subject of User interface design is Don't proof-read your own work... Get someone else (preferably selected from your end user target audience) to look through your design for you or better still with you!
    Some concrete pieces of advice:

    Be careful with colour. Choose subtle colours unless you are designing an emergency dialog box that requires immediate action and will not be on screen for more than a few seconds. Strong colours are very tiring to look at for long periods of time.

    Avoid using too many bounding boxes. These merely add visual clutter, and distract the eye.
    Ensure that all the edges of components line up, failure to do this will rapidly make the interface look as if it has been thrown together at random, and your users will end up operating in the belief that the code was put together in the same way - in short it destroys confidence.

    Ensure that all of your controls are sensibly sized. Don't make anything that will be a target of a user mouse operation (i.e. buttons, scroll bars, check boxes) too small, it increases the amount of time the user will take to hit the target, and decreases their apparent accuracy.
    Include short cut key strokes wherever possible, and remember that your target audience may include disabled users, who do not access your software with a mouse. (Try disconnecting your mouse, and see how far you get without it!)

    Don't cram too much text into too small a space. Be especially careful of this if there is any danger your application will need to be translated into another language. English is a very compact language, you need to allow up to double the space for a button label (for example) if you are translating the interface in to German or Italian.

    Be careful with your choice of button images, try and use standard images wherever possible. This is especially true for dialog boxes that present information or error messages.
    Think very carefully before presenting an error message dialog box. Most unexpected conditions should result in a Warning message - not an error message. Presenting too many error messages will destroy user confidence in the application.

    A before and after shot of a software interface
































    Problem Analysis



































    After tidying:




































    There are a number of resources available on the Internet about user interface design, but tracking down Microsoft's own information on the subje ct is hard, because... surprise surprise, they turned it into a book, and make it available to you through the Microsoft press at £29.99! For more information on user interface design try these sites, or perform a search with AltaVista using the search crite ria HCI + GUI + DESIGN:
  • http://www.guiguy.com/
  • http://www.chesco.com/~cmarion/



    Menu: Home, Services, Events, Features, Interviews, Profiles, Reviews, News, Resources, Press