It takes more than the latest Integrated Development Environment (IDE) to develop a good GUI. It takes a sound GUI screen design strategy. This article provides design strategies to maximize the benefit of a GUI application.

GUI application development has revolutionized the computer industry. Developers now have the ability to combine nongraphical controls, such as text boxes, list boxes, and check boxes, with graphical controls, such as lines, shapes, and picture boxes—quite a step up from simple text-based, green-screen application interfaces.

In the early 1990s, the microcomputer world was introduced to visual development environments such as Microsoft Visual Basic. This visual programming strategy opened the door to simple and quick development cycles. Prior to visual programming, a developer had to build everything from scratch using a lower-level language such as C.

GUI programming combines procedural and structural programming with two innovative techniques: object-oriented programming and event-driven programming. In visual programming, an event is an action recognized by an object. For example, a user clicking a mouse or pressing a key is an event, and the object is the Windows component that reacts to that event. One way to make things happen in visual programming is to write code that enables the objects in your application to respond to events. You put this event response code in procedures (subroutines or functions) called event handlers or event procedures. Event procedures are specific to objects and events.

The objects are Windows components like buttons and list boxes, and the events are messages that are generated from the component in response to a user action like a key press or mouse click. For example, if your application is to provide special processing to respond to a user’s click of the left mouse button in a form, you code an event procedure with the custom code necessary to handle that mouse event. Note that any event routed by Windows to an application is handled automatically by Windows in some default manner. You do not have to write event procedures if you are satisfied with the default behavior of

an event procedure. The beauty of GUI programming is that you write event procedures only for those events that you want your application to handle in some special way.

Despite their apparent differences, you can also draw many parallels between old- style AS/400 programming and GUI processing. The table in Figure 1 illustrates the similarities between AS/400 programs and GUI programs.

The Desktop Paradigm

Applications that run in Windows may have functions that, while they are performed in a GUI environment, use the linear programming approach. Host AS/400 RPG or COBOL programs use the linear model. For example, an RPG screen-processing program has a single entry point where its main routine contains the big loop. The big loop controls processing by prompting the user for input and then executing subroutines. The entire DDS record format that contains data keyed by a user is sent to the RPG program for processing when the user presses the Enter key.

In the event-driven approach, the user, rather than the program, is in control. Every keystroke or mouse action is sent to Windows as an event. The Windows application program is designed to respond to each event individually. Because of the way graphical operating systems work with user applications, users can open many windows and place and size them in the same manner as they do with papers on a desktop. This empowers the users, putting them in the driver’s seat. With green-screen applications, the users were simply passengers. Another advantage of the event-driven GUI approach is that all events and objects may be presented to users in one consistent and simple interface.

MDI and SDI

Many GUI applications are designed to present multiple windows within the same application using a technique called Multiple Document Interface (MDI). MDI consists of one parent form that contains one or more child forms. Each child form displays a different view of the same document. When the document is changed, all the views are updated to reflect that change. An example of an MDI application is Microsoft Windows
3.1’s File Manager. In a single File Manager session, the user is able to open multiple views of the connected storage devices.

The alternative to MDI is a Single Document Interface (SDI), which allows one document to be open while the application is running. An example of SDI is Microsoft Windows 95’s Windows Explorer. In a single Windows Explorer session, you can have only one view of your storage devices. To see multiple views, say disk drive C and disk drive D, you have to show drive C in one Explorer session and drive D in another Explorer session.

The User Interface

There are three main component areas on every GUI screen or form: the menu, the document, and the command buttons. The menu should always be located at the top of the screen. The document itself may contain any number of Windows component objects to either accept input from users (edit boxes, list boxes, etc.) or clarify information on the document (picture boxes, status bar presenting help-related information). Input boxes should be positioned in a logical manner to allow for quick and simple data entry. A command button is a type of object that is contained in the form to enable the user to signal the execution of application-specific functions. Every form should contain a minimum of two buttons: OK (or Accept) and Cancel. Additional buttons may be defined that perform specific functions within the application. All buttons on a form should be the same size. Further, buttons should be aligned either on the right side or on the bottom of the form to present a consistent interface across all the forms of an application.

Adapting to Skill Levels

The GUI interface’s simplicity allows for a quick learning curve for a novice user. However, it often bogs down experienced users, because they must leave the keyboard to select a particular function or to position to a field elsewhere on the screen via a mouse. However, with proper screen design, experienced users can navigate within an application without leaving the keyboard. The developer must simply assign shortcut keys for all functions available in the application and then enable them via the Tab key. Typically, keyboard access requires pressing the Alt key in combination with a letter that is embedded in the text of the menu description. Tab keys are enabled simply by setting the edit field’s tab property to True and assigning the sequential tab order number property to each of the form’s edit fields. It should be considered standard Windows programming to enable user access to any menu option from the keyboard and to assign tab keys and tab key sequences to edit fields.

Windows Forms Design

A GUI application should contain one or more Windows documents or forms. A form may contain any number of components, such as labels, buttons, radio buttons, check boxes, edit boxes, and list boxes. Each component contains properties that may be set up at development time or, in some cases, at runtime. The table in Figure 2 illustrates the similarities between the behaviors of Windows form components and AS/400 display file (DDS) field types and keywords.

As with AS/400 screen design, it is good practice to ensure that data labels and their corresponding edit boxes be vertically aligned. Labels should be clear and concise, with the corresponding Windows component positioned immediately to the right of the label.

The Mode of a Dialog

A form may have many accompanying dialog boxes. A dialog box is similar to a form in that they are both capable of presenting information and accepting user input. A dialog box is typically used for setting parameters applicable to the form. Some common examples of dialog boxes include Open Document, Save Document, Set Document Options, and Find Text.

Dialog boxes may be presented to the user as either a modal or a modeless dialog. A modal dialog box prohibits the user from activating any other window of the same application until the user exits the dialog. An example of a modal dialog is Microsoft Word’s File Open dialog shown in Figure 3.

A modeless dialog allows and usually encourages the selection of other windows of the application. A modeless dialog box is useful if an input field may refer to a component’s value on the form. For example, the Find dialog of Figure 4 of Microsoft Word is presented as a modeless dialog box. It allows the user to find a string of text in a document, edit the document while the Find dialog is still active, and search for any further instances of that text.

Tabbed Dialogs and Trees

As application dialogs become more complex, the user interface can be enhanced with the use of two Windows components: trees and tabbed dialogs.

The tree component gives the user the ability to expand and collapse the system’s file directories and subdirectories. This should always be used for any type of File/Document operation (Open, Save, Save As, Find, etc.). A dialog box should cover one specific function. In some cases, a function may be subdivided into subfunctions.

Tabbed dialogs are used for each subfunction. All tabbed dialogs are contained in the one dialog box; however, the developer is free to design each tabbed dialog independent

of another. (The AS/400 analogy is a given display file containing different record formats.) An example of a common use of tabbed dialogs is the Options dialog shown in Figure 5. Options can encompass many aspects of the application: print parameters, view defaults, save defaults, general info, etc.

Help, Please

Online help should be present in every application. The bare minimum should include a detailed explanation of each component present on the form. The user should be able to call for help in one of three ways: by keyword index search, by context-sensitive help, or from a table of contents.

The keyword index allows the user to search on a given word and be directed to the appropriate Help screen for that topic. Context-sensitive help is enabled in a variety of ways—such as a right-mouse pop-up menu—each of which presents help in the context of the cursor location. The table of contents should be a hypertext listing that is similar in appearance to a table of contents found in a hard copy of an instruction manual. Beyond the basic forms of help mentioned above, a developer can add significant value to an application by providing online tutorials with examples and demos.

Put the User in Control

There may be a temptation, especially for experienced AS/400 programmers, to force GUI-style programs into a linear framework that is not of the Windows-oriented, event-driven model. This temptation should be resisted.

There are three golden rules of GUI design: Let the user stay in control, reduce the load on a user’s memory, and make the interface consistent. For example, don’t force the user to fill in a sequence of input boxes to get to a section of an application. Design input forms that the user can access from menus instead. Make sure you are giving enough feedback to the user. Use the graphical capabilities of Windows to provide visual cues, such as changing the mouse pointer’s icon to an hourglass when the application is busy processing. If processing is to take a long time, consider using a percent-complete task bar. Allow users to resize forms and move them around—unless there is some good reason not to.

Make it easy to navigate around the application. Leave control boxes on forms, and have the Windows standard shortcut key of ALT+F4 close the form. Scroll bars are helpful when users are going to have to work through lots of information. Don’t crowd your forms with too many buttons; use menus instead. On the other hand, don’t make menus too deep. Use custom or common dialog boxes as appropriate. Make menus look like what users expect. Programs that handle files should have the standard order in the File menu, with clearly defined captions including the shortcut keys (where appropriate). Users expect to see a File menu with some subset of the following list: New, Open..., Save, Save As..., Print..., and Exit. Similarly, the Help menu should have at least these items: Contents, Search for Help On... and About. If you are developing an MDI application, provide a Windows menu that allows the user to arrange or cascade the “child” windows—much like Windows itself does. The Windows menu should also include a list of the MDI child windows. An Edit menu should be available for applications that perform any type of data maintenance.

Chrome Plating

Sophisticated GUIs allow the user to customize the application. For instance, it’s not difficult to create a dialog that allows the user to set the font, font style, and size. This may be necessary if the user has a sight disability and needs a larger-than-normal font size. It is also relatively easy to provide color customization. I know of a PC-based software developer that customized an application for the colorblind vice president of a major

customer because he was unable to see underlined words. A quick color customization dialog saved the application. It is also easy to save the size and placement of windows to a Windows .ini file. Sometimes, just a little more work makes the GUI application much easier to use.

The Article Close Event

Today’s users want a GUI. They don’t want an application that runs on Windows but looks, smells, and walks like a green-screen application. They want an application that follows the desktop paradigm and puts them in control with an intuitive and graphical interface. To design that application, follow the three golden rules of GUI design: Let the user stay in control, reduce the load on a user’s memory, and make the interface consistent. And, when in doubt, look to a widely used Windows application, such as Microsoft Excel, for how to design your menus and forms.

Figure 1: GUI programming and AS/400 programming similarities

Figure 2: Many Windows components have behaviors analogous to DDS field types and keywords

Figure 5: Microsoft Word’s Options dialog makes effective use of tabbed dialogs to present a large amount of similar options in one dialog box