Previous Table of Contents Next


5.1. ROUGH LAYOUT

The goal of this phase is a set of rough layout sketches of the screens and windows that support the primary user scenarios. There are five steps in constructing the sketches:

  Choose the basic interaction paradigm, procedural or object-oriented.
  Select the user scenarios that are central to the application’s use.
  Exract the important objects in these scenarios and choose their representation.
  Layout the views and add the controls.
  Check the flow of the scenario using the sketch.

When the underlying metaphor has a strong visual appearance an alternative design approach is to mimic the visuals and interaction elements of the metaphor. Use this with care as it often leads overly cute, cluttered graphics that are difficult to visually parse and whose controls, such as tabs, are limited in comparison to the graphical widgets in platform-specific tool kits. On the positive side, this type of design often leads to a very distinctive visual appearance that can be quite appealing to casual users, though it can also become tiresome when used day after day.

The sketches of the layouts should follow applicable platform-specific guidelines and show the different view areas, their essential content, and the controls, while eliding unnecessary details. They can be shown to potential users and members of the development team for comments and used in preliminary usability studies. The quality of the comments however is limited because the study participants must use significant mental effort to visualize the dynamic operation and feel suggested by the static sketches, forcing a logical and intellectual consideration of an interface intended to be used in an intuitive manner.

Readers are encouraged to develop their own sketches as the example evolves in the following sections, or refer to Figure 4.3 which shows some of the alternative layouts that were prototyped for this example.


Figure 4.3  Prototype of alternative layouts. (A) Tabs; (B) four views; (C) overlaid views; and (D) web-browser.

5.1.1. Procedural or Object Oriented

The first design decision is whether the windows should be procedurally or object-oriented. Procedural design focuses on the task, prompting the users at each step in the task, giving them few options to do anything else. This approach is best applied in situations where the tasks are narrow and well-defined or where users may be inexperienced, e.g., automated tellers and order entry. Object-oriented designs focus on the objects, allowing the user a wide number of options, and should be applied to situations where experienced users will use them as tools in a range of situations. The searching, reviewing, and selecting tasks described in the example’s scenarios indicate that the more flexible and adaptable object-oriented approach would be best.

5.1.2. The Central User Scenarios and their Objects

The elements in an application should be laid out in the same way that any physical workspace would be, by designing for the most important tasks. The primary user scenarios should be selected and grouped based on the objects they involve and the likelihood that their tasks will be performed together. These objects are mapped into views that show either multiple objects or a single object’s content, depending on the needs of the tasks. Sketches of the views should show only the essential structure and content; details should be suppressed. For example, a sketch of a view of unread e-mail messages might show only a list of lines where each line represents some information about a message. Details should be added later only as the need becomes apparent. If possible, use the types of views defined in the platform-specific guidelines since users will likely be familiar with their appearance and use, and it will save implementation effort.

The primary task from our example is “Get a component”. The subtask “Locate candidate components” generates a collection of candidate components, so we need a view for that collection. One way to generate that set is to “Turn to a section” so we need a view that shows the set of sections. Another way to generate the candidates is to “Find by description” so we need a view for the query. The second subtask is “Find a suitable component from the candidates”. There is already a view for the candidates. The next level subtasks are “Select a candidate” — the “candidates” view again — and “Show the data sheet”, a new view. The other subtasks in the scenario don’t suggest any new views. The example has four views: query, components, sections, and data sheet.

The type of each view depends on the objects and/or data it contains. Reviewing the environment and metaphor for existing representations that might be appropriate, we find that the data sheets generally show some text and maybe graphics. The “candidates” view is a collection of components, i.e., objects, and objects are generally rendered either iconically (spatial) or by name (list). The typical pattern of a query is a form: a collection of type-in fields, and a “find” button. The “sections” view is the most interesting. The catalog metaphor suggests a set of tabs but the number of sections is likely to be large if the catalog contains thousands of components. Typically large numbers of categories, the sections, are organized hierarchically, so some sort of hierarchical view seems appropriate.


Previous Table of Contents Next