Design Specifications and Guidelines - Window Management
To present your application's collection of related tasks or processes, consider a number of design factors: your intended audience and its skill level, the objects or tasks to be presented, and the effective use of the display space.
The view or window management models in this chapter are not exclusive design techniques. It may be advantageous to combine them or design others. However, keep these techniques in mind because these models are used frequently.
To help you decide how to present an object's view, determine what the object represents, how it is used, and how it is related to other objects. Some objects — such as device objects like the mouse, keyboard, and display — may not even require a primary window; instead, these objects use only a secondary window for viewing and editing their properties.
It is also possible for an object to have no windows and an icon as its only representation. However, in this rare case, make sure that you provide an adequate set of object menu commands to allow a user to control its activity.
More typically, objects require a primary window supplemented with secondary windows. For other scenarios, where the composition of an object requires multiple views or the nature of the user's tasks requires views of multiple objects, you may need a construct that logically groups and supports management of these views.
To design object views for your application, you need to consider how these views will be used; for example, how many simultaneous views does the user need to work most efficiently? You must also determine how much data needs to be shown in the views.
Take into account the type of configuration you recommend to your users. For very high-resolution displays, the presence of menu bars, toolbars, and status bars still allows for information to be adequately displayed in a window. These common interface elements in each window have little impact on the overall presentation. At VGA resolution, however, this many elements on screen can limit the amount of data the user can see.
The interface components for a window or view should not so dominate the user's work area that the user cannot easily view or manipulate data. Consider a design that allows interface components, such as menu commands or other controls, to be shared among multiple views. However, make it clear that a particular interface component applies to a particular view by appropriately enabling or disabling it. Identify which functions are common to all views and present them in a consistent way for interface stability. For example, if multiple views share a Print button on the toolbar, place the button in a consistent location. If the button's location changes when the user switches views, the user's efficiency will decrease.
However, shared interfaces can make it harder for users to customize the interface components because your application must indicate whether the customization applies to the current context or across all views. However, when supporting user customization, don't neglect your application's default configuration — most users do not make any changes.
Fundamentals of Designing User Interaction
Design Specifications and Guidelines