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:
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 users 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 |