Previous Table of Contents Next


5.1. USER INTERFACE ARCHITECTURE

The reason for preparing the User Interface Architecture is to provide high-level user interface design information. In the framework for information systems architecture (Sowa and Zachman, 1992), the user interface architecture (called a Human Interface Architecture in Sowa and Zachman, 1992) expresses the model of the information system from the users’ view. By comparison, a data model expresses the data view, and a distributed systems architecture expresses the network view of the application. The user interface architecture document should contain:

  Key information from the usability analysis phase and its implications for the user interface design:
  Business objectives for the application.
  A brief definition of new user classes and the implications from the comparison to existing user classes.
  Salient points from the current task definitions.
  A summary of the malfunction analysis of the current system.
  A summary of training and documentation strategies and their implications for user interface design.
  A brief description of the hardware/software environment and its implications for user interface design.
  New task definitions.
  Usability performance objectives.
  A system model, including metaphors.
  The degree of task vs. object orientation.
  Implications from the analysis of the database of user objects, functions, user classes, new task definitions, and frequency of task performance.
  The opening screen (rough sketch) and navigation principles.
  The rough designs for each task.

Each section of the user interface architecture document should contain the design rationale (i.e., a brief description of which alternatives were examined and accepted or rejected) and a rationale (e.g., based on test results from sessions with users or because of technology constraints or opportunities). Just like a distributed systems architecture, a user interface architecture is written over a period of time as the tasks during the user interface design phase are being completed.

The audiences of the user interface architecture include the software engineers who will be building the application and those who will work on fixing usability problems or extending the functionality of the redesigned application after initial roll-out. Usually, these are software engineers who were not part of the initial redesign effort and therefore are not familiar with the history and rationale of the user interface design.

In fire prevention assignments, the user interface architecture is part of the set of architecture documents prepared during the application design phase. In firefighting assignments, no such document usually exists, and there usually is no time to prepare one. However, where time and budget permit, the findings from a firefighting assignment should be documented in point form in a reduced user interface architecture document or they should be included in the application style guide.

5.2. APPLICATION STYLE GUIDE

The point of the application style guide is to document the guidelines and prescriptions for detailed user interface design. In the framework for information systems architecture (Sowa and Zachman, 1992), the application style guide would be part of the technology model expressing this model from the user’s view (called the Human/Technology Interface in Sowa and Zachman, 1992).

An application style guide is usually based on a vendor style guide, but considers user classes, tasks, and implementation tool capabilities and constraints. For example, application style guides specify the subset of widgets appropriate for the users and tasks at hand, screen layouts for specific types of objects, use of common functions, use of the corporate logo, or use of business-specific terminology (and translations of this terminology if the application is multilingual). Each section of the application style guide should contain the supporting design rationale. The construction of a prototype representing the concrete user interface design is recommended as a living illustration of the application style guide. The scope of such a prototype usually includes the opening screen and the detailed design for one or several key tasks.

The audiences of the application style guide include the software engineers who will be building the application and those who will work on fixing usability problems or extending the functionality of the redesigned application after initial roll-out. The application style guide is also relevant for the quality assurance specialists who will be checking the software for conformance to the application style guide.

In fire prevention assignments, the application style guide and prototype are prepared during the detailed user interface design phase. In firefighting assignments, the application style guide may have to be reduced and sections of a vendor guide may have to be referred to or substituted. The prototype is essential but can be reduced in scope to a few sample screens.


Previous Table of Contents Next