Window design

Window design

50.1 Purpose

A window is a screen box or a portion of a screen that holds a message, a menu, or some other unit of information. With the growing popularity of Microsoft Windows and the Apple Macintosh platforms, windows have become a de facto user interface standard. This chapter discusses several different types of windows and the windows design process.

50.2 Strengths, weaknesses, and limitations

Most users are familiar with the Microsoft Windows and Apple Macintosh interfaces. Consequently, adopting windows as a user interface standard means reduced user learning time because of skill carryover. Key windows design elements exist as standard reusable objects in Visual BASIC and other windows-oriented programming tools, and such reusable code can significantly reduce programming, debugging, and maintenance costs. A windows-based interface requires a great deal of memory and a relatively powerful processor, however.

50.3 Inputs and related ideas

Windows are typically designed in the context of a user interface (Chapter 48). The user interface defines the required set of screens and windows and their order of execution. A dialogue (Chapter 49) is designed and created for each screen or window in the user interface. Windows design provides a template for dialogue design. Much of the specific information needed to define and test the windows is collected during the problem definition (Part II) and analysis (Part IV) stages of the system development life cycle.

50.4 Concepts

A window is a screen box or a portion of a screen that holds a message, a menu, or some other unit of information. With the growing popularity of Microsoft Windows and the Apple Macintosh platforms, windows have become a de facto standard for user interface design.

50.4.1 Types of windows

Menu bars (or command bars) appear at the top of most Microsoft Windows and Apple Macintosh application screens. Major functions (e.g., file, edit, view, help) are displayed on a horizontal menu bar. The subcommands related to a particular function are displayed in a pull-down or drop-down menu when the user clicks or selects the function; for example, save, save as, andprint might be listed under the file option. Third and fourth level menus are used to select additional details, such as a data type (percentage, currency, comma) or a font (12-point, Times New Roman).

Button bars usually appear under the command menu bar, but buttons are sometimes displayed at the edge or the bottom of the screen, too. Each button holds a symbol or icon that represents a function and provides a short cut to the function. Generally, there is no hierarchy of subfunctions associated with a button, although pop-up windows are sometimes used to display available options (e.g., a color palette).

Split screens allow the user to divide a screen into several subscreens (or subwindows). For example, most spreadsheet programs allow the user to freeze columns, freeze rows, and define custom windows to simplify working with large spreadsheets. Typically, specific commands or actions allow the user to split the screen, return to the original screen, hide, recall, size, or move a window. The contents of a given window can usually be manipulated (paged, scrolled, etc.) independent of the other windows. Because certain operations are valid only on the active window, a command (or some other mechanism) to transfer control between windows is essential.

Icon windows display multiple icons. Each icon is essentially a shortcut to an executable routine, a file, or an application. The initial (post-startup) Microsoft Windows 95 screen is a good example; note such icons as My Computer above the Start button.

Some windows are designed to provide feedback. For example, most installation routines display a window that shows an installing message or a bar chart that indicates percentage completion. Consider also the status windows that display loading, searching, or working messages; the FORMAT window shown in Figure 50.1 is a good example.

Other windows provide prompts or cues. For example, the user might be asked to input some data by typing a value (e.g., a social security number or a user name and a password), filling out an electronic form, pressing Y or N, or selecting a choice from a list or a menu.

Figure 50.1  A FORMAT window provides feedback.

Windows are also used to provide error messages and warnings. For example, in response to an error, a window might appear showing a symbol (a question mark, a stop sign) followed by a header and an error message, an error code, or a warning number, perhaps accompanied by a button to request additional details. Some error or warning windows give the user a set of options (yes, no, cancel, retry, help, etc.).

Finally, many windows provide help. Help windows can be organized by command and/or syntax (often in alphabetical order), error or warning message number, or by function (e.g., file, view, edit, etc.).

50.4.2 Opening a window

A given window can be opened (activated, triggered, launched) in several different ways. The most common approach is to use a mouse to point to the desired icon or menu choice and then left click (to make a selection), right click (to cancel a selection), or double click (to open an application). An option is to open a specific window in response to pressing a function key. The function key approach is particularly suited to such tasks as switching back and forth between the windows on a split screen.

In some cases, pressing a hot key (usually, a combination of several keys) triggers a response. For example, most of the sample screens that appear throughout this book were captured using a program named HiJaak. To activate HiJaak, the author displayed the screen to be captured and then pressed the hot key combination Ctrl, Shift, and C. Hot keys should be used only for experienced users.

50.4.3 Designing windows

Windows are typically designed in the context of a user interface (Chapter 48). The user interface defines the required set of screens and windows and their order of execution. A dialogue (Chapter 49) is designed and created for each screen or window in the user interface. Windows design provides a template for dialogue design. In effect, the window is the vessel and the dialog is the content.

An ideal windows design incorporates all the parameters associated with an ideal user interface design (Chapter 48) and an ideal dialogue design (Chapter 49). Additionally, a well-designed window is easy to access (maximize, minimize), easy to operate (move, resize, hide, and recall), easy to maintain (modify, add, and/or delete a menu item), and easy to exit.

50.4.3.1 Define window contents

For each window required by the user interface, the designer identifies and documents such parameters as the window name, the window objectives, the window type (Section 50.4.1), the information that must appear in the window, any constraints that affect the window, and additional information about the window as appropriate. Many organizations have standards (often in the form of reusable objects) for each window type.

Menu bar windows require additional planning because they are typically linked to lower-level pull-down menus. Consequently, the designer must study the system objectives, identify the primary functions, determine the relevant subcommands, generate a command hierarchy, and test the design.

Note that sophisticated users and naive users have very different preferences. Consequently, a good understanding of the user is an essential component of windows design. If a given window is not meaningful to the user, system performance will be negatively affected.

50.4.3.2 Verify window flow and sequence

The user interface design defines window flow and sequence, but the designer often performs additional tests before beginning detailed design and writing the code to implement the windows.

Window flow analysis is a preexecution analysis technique used to determine if the sequence of calls to and exits from the various windows is correct. Unidirectional flow implies that control is transferred from the top-level (calling) window to a lower level (called) window. Bidirectional flow implies that the called window can transfer control back to the calling window after execution.

Window sequence analysis is particularly important when menus are used. The objective is to ensure that each window is properly linked to the next window during execution. Basically, the designer documents the return value (the value returned when the user selects a particular option) and the goto value (the name of the next menu) for each menu item in the window. For example,Table 50.1 shows the menu options, return values, and goto values for a retail customer transaction. Some designers use such tools as data flow diagrams (Chapter 24) and simple hierarchy charts (Chapters 48 and 62) to support this step.

Figure 50.2  A Microsoft Excel screen with several key windows elements identified.

50.4.3.3 Design each window

Figure 50.2 shows a Microsoft Excel screen with several key windows elements identified. Each of these elements exists as a standard reusable object in Visual BASIC and other windows-oriented programming tools. Standard objects or templates also exist for other window types. Windows designers are strongly urged to follow the established standards whenever possible.

The detailed content of each window (the specific menu items, the narrative wording, etc.) is defined during the dialogue design process (Chapter 49).

50.4.3.4 Test each window

The purpose of this step is to test the paths and execution sequences so any operational errors or difficulties can be identified and corrected before the windows are released to the user. Most fourth-generation languages and CASE packages that support prototyping allow the designer to test the windows, screens, and menus. After the paths and execution sequences are tested, the windows undergo user testing as part of the user interface design process (Chapter 48).

50.5 Key terms

Bidirectional flow —

A control flow in which the called window can transfer control back to the calling window after execution.

Button bar —

A set of buttons that(typically) appears under the menu bar; each button holds a symbol or icon that represents a function and provides a short cut to the function.

Dialogue —

The exchange of information between a computer and a user.

Hot key —

A key or (more commonly) a combination of keys that triggers a response.

Icon —

A graphic symbol that represents a processing option, a file, or an executable routine.

Icon window —

A window that displays multiple icons.

Menu bar (command bar) —

A window that (typically) appears at the top of the screen and lists such major functions as file, edit, view, and help; the subcommands related to a particular function are displayed in a pull-down or drop-down menu when the user clicks or selects the function.

Pull-down menu (drop-down menu) —

A menu of detailed options that appears when the user clicks or selects a major function on a menu bar.

Split screen —

A windows technique that allows the user to divide a screen into several subscreens or subwindows.

Unidirectional flow —

A transfer of control from the top-level (calling) window to a lower level (called) window.

User interface —

A point in the system where a human being interacts with a computer.

Window —

A screen box or a portion of a screen that holds a message, a menu, or some other unit of information.

Window flow analysis —

A preexecution analysis technique used to verify that the sequence of calls to and exits from the various windows is correct.

Window sequence analysis —

An analysis technique intended to ensure that each window is properly linked to the next window during execution.

50.6 Software

Standard window templates exist as reusable objects in Visual BASIC and other windows-oriented programming tools. Windows designers are strongly urged to follow the established standards whenever possible. Most fourth-generation languages and CASE packages that support prototyping allow the designer to design, create, and test windows, screens, and menus.

50.7 References

1.  Dewitz, S. D., Systems Analysis and Design and the Transition to Objects, McGraw-Hill, New York, 1996.

2.  Hoffer, J., George, J., and Valacicho, J., Modern Systems Analysis and Design, Benjamin/Cummings, Menlo Park, CA, 1996.

3.  Powers, M., Cheney, P., and Crow, G., Structured Systems Development: Analysis, Design, Implementation, 2nd ed., Boyd & Fraser, Boston, MA, 1990.

4.  Whitten, J. L., Bentley, L. D., and Dittman, K. C., Systems Analysis and Design Methods, Richard D. Irwin (McGraw-Hill), New York, 1997.