Previous | Table of Contents | Next |
4.3.2. Task vs. Object Orientation in the User Interface
At the beginning of dialogue design, it is necessary to determine whether the system should provide a task-oriented dialogue (i.e., the user is guided by the system through the tasks to be accomplished) or an object-oriented dialogue (i.e., the user knows which objects to work with and selects them in the appropriate order). Frequently, a hybrid will be required, with novice users often preferring task-oriented dialogues and more-experienced users preferring an object-oriented approach. There are a variety of design alternatives for providing the necessary guidance for tasks, e.g., use of wizards or task lists.
While users generally have some degree of flexibility in deciding in which order they want to do their days work, there is generally less flexibility in the order in which steps in a task are carried out. For example, money for a loan cannot be advanced to a customer unless a number of steps have been taken, e.g., the credit bureau check is in the customers favor, the loan application has been reviewed, the loan has been approved, and the necessary documents have been signed. The order of steps is important, e.g., the loan cannot be reviewed without the credit bureau check having been completed first. Experienced users know this, but less-experienced users may not. Organizations have policies and procedures that prescribe the sequence of steps, and these are enforced in an application to varying degrees. Policies and procedures are reflected in functional specifications and the current task definitions (see Section 3.3). Problems in this area are documented in the malfunction analysis of the current system(see Section 3.4).
A key issue in determining task vs. object orientation in a user interface is the amount of control given to users, especially with respect to variations in how to perform a task. For example, the business objective of the XYZ Finance & Insurance Company was to increase sales, and a means to do that was the sales approach taught in sales training. Therefore, corporate management at the XYZ Finance & Insurance Company wanted all users to use the sales approach taught in sales training courses. As a result, the sales presentations were predesigned for specific kinds of customers. The sales representatives, however, wanted to be able to create their own sales presentations for specific kinds of customers. For in-house business applications in particular, the issue of user control may raise differences of opinion between users and corporate management. While usability engineers may want to take a position on such an issue, it is the Usability Steering Committee that makes the decision. Such issues are no longer user interface issues; rather, they are business issues masquerading as user interface issues.
A frequent concern about task-oriented user interfaces is that users do not have easy access to the appropriate information at each step in a task. In the authors experience, this is a user interface design problem, not a problem inherent in task-oriented user interfaces. When designing a user interface with a stronger task orientation, it is essential to determine which objects are required for each step in the task and to ensure that these objects are indeed easily available at each step.
The degree of task vs. object orientation in the user interface is documented as part of the User Interface Architecture (see Section 5). A summary is posted in the usability engineering room, and the new task definitions are annotated to indicate where a sequence of steps must be adhered to. In fire prevention assignments, sufficient resources should be allocated to this project task. In firefighting assignments, only sample definitions for key tasks are annotated.
4.3.3. Designing the User Interface Horizontally First Opening Screen and Navigation Principles
The foundation for designing the opening screen and navigation principles is a database, mapping relationships among user objects, functions, user classes, new task definitions, and frequency of task performance. The authors experience has been that such a database is invaluable for making user interface design decisions about foregrounding/backgrounding objects and functions at the interaction level, as well as detail design level of the user interface. Generally, information or cues to frequently performed tasks will be in the foreground, at higher levels of a menu hierarchy, or on special hot keys/fast paths. On the other hand, information or cues to less frequently performed tasks will be placed in lower levels of a menu hierarchy or be presented in such a way that they are always accompanied by an explanation of when to invoke this task. Note that the foregrounding/backgrounding of tasks does not necessarily imply a task-oriented user interface.
The starting point for navigation design is the database of user objects, functions, user classes, new task definitions, and frequency of task performance. It is documented in the User Interface Architecture (see Section 5). Clusters in the user class and new task definition matrix suggest initial groupings for the navigation design, and the new task definitions themselves provide the initial flow. The first round of navigation design is aimed at ensuring that all tasks and user classes are covered by the high-level navigation design and that users are able to find and start key tasks.
Previous | Table of Contents | Next |