Previous Table of Contents Next


5.1.3. Layout

Once the object views have been defined they can be grouped into windows. Each window should represent an object, with its views representing either that object’s content or other objects that have a clear relationship to the window’s object. At one extreme each object view could be in its own window, but this is likely to lead to a busy interface that involves much window opening, closing, moving, and resizing that is otherwise unnecessary. At the other extreme, all the views could be placed in one window either side-by-side, resulting in a very large window, or the views could be overlaid, forcing the user to switch views to begin a new task. Small applications should be able to fit into a single window, large applications in just two or three. Overlaid views should be used primarily to allow a user to configure a desired style of interaction, e.g., the “spatial” and “list” views for Macintosh folders allow the user to either manually group related icons spatially or to have the computer maintain an ordered list. They can also be used to begin a new scenario, as in our example below, provided the need to switch views is infrequent.

Views should be laid out within the window in “reading” order such that, as the user performs the series of subtasks in a scenario, the next items needed are where the next words would be. For western languages this would be left-to-right, top-down. Information within a view should also be laid out the same way. A person’s eyes see only a small portion of the screen at any one moment, often failing to note related items only a few inches away. Poorly placed information will be missed by casual users and even by experienced users when they are deeply focused on the task or in a hurry.

Controls used to initiate each action are added to the layout as needed by the user scenarios. Use restraint when adding buttons and task bars to windows; while users have shown a preference for buttons over pull-down menus, large numbers of buttons are confusing and take valuable screen space. Platform-specific guidelines usually indicate appropriate uses and locations for each type of control.

In our example there are two high-level, independent objects: the application under construction and the catalog. This suggests two windows, one for each, both of which will likely be on the screen at the same time. A frequent task is copying a component from the catalog to the application being built, so the windows should not overlap if possible. Since the application construction window will likely be large, the catalog window will fit best if it is tall and narrow.

Arranging the four views based on the scenario flow, the starting views, “sections” and “query” are first, the “candidates” next, and the “data sheet” last. Since the catalog window is tall and narrow, the views would be arranged top-down. Initial sketches suggest that arranging four views vertically will make them short so that they won’t be able to display very much content. Since the scenarios always begin with either the “sections” view or the “query” view but never both, they can be overlaid in the same space and a button added to switch between them.

5.1.4. Scenario Flow

The scenario flow through the sketches is checked by drawing arrows to indicate the sequence of user actions for a given scenario. Usually a single sketch is sufficient to illustrate a single scenario, though a complex one involving many subtasks may require a storyboard, i.e., a sequence of sketches showing how a window changes as the scenario proceeds. As additional subtasks are added, secondary windows can be created for tool palettes and non-modal dialogues as necessary; modal dialogues should be avoided when possible in object-oriented designs.

5.2. INTERACTION DESIGN

Human-computer interaction designs should be based on how people interact with things and with other people. These patterns are sometimes considered “natural” because they are so ingrained due to physics, physiology, and continuous repetition. Interaction can be modeled as a kind of dialogue, a sequence of actions and responses. In a human-computer dialogue the computer presents to the user what is possible, the user makes a request, and the computer acknowledges the request, makes the change, and responds with the results or confirmation. As with dialogues between people, the dialogue must be at the right level: too high and it is difficult to understand, too low and the extraneous detail becomes tedious. In either case the user must divert attention from the task to the dialogue itself, resulting in wasted time, effort, irritation, and reduced task performance. The challenge for the designer is to select the right dialogue level, i.e., the tasks, objects, and actions; to chose the most appropriate form of human-real world interaction; and then to map that interaction into the very limited set of interactions supported by the user input and output devices attached to the computer.


Previous Table of Contents Next