The User-Interface Prototype should be created as soon as you
need to expose the user-interface design to people other than User-Interface Designers. The prototype
should approximate the look-and-feel and behavior of the primary and secondary windows. Through these
initial User-Interface Prototypes, you begin to establish a mental model of the system's user interface.
Note that the focus should not be on achieving a good structure and modularization of the source code for
the executable prototype; instead, the focus should be on creating a throw-away prototype that visualizes
the significant aspects of the user interface and that provides some of its significant user
actions/behaviors. Moreover, a prototype is likely to change several times when it is designed and exposed
to others, and these changes are often made as cheap patches. As a result, the source code of the prototype
is often of very limited value, and not "evolutionary," when the real user interface is to be implemented.
In general, a prototype is cheaper to implement than an implementation of the real user interface. The
following are some differences between the prototype and the real implementation of the user interface:
- The prototype need not support all requirements scenarios (e.g. Use Cases).
Instead, only a small number of scenarios may be prioritized and supported
by the prototype. In subsequent iterations, the prototype may be expanded,
gradually adding broader coverage of the scenarios and deeper exercise of
the architecture.
-
The primary windows are often the most complicated to implement; if you make an advanced user interface
that really takes advantage of the visualization potential, then it may be difficult to find ready-made
components. Rather than implementing new components, you can normally use primitive components, such as
push-, toggle- or option buttons, as an approximation of how the user interface will look for a certain
set of data. If possible, make several prototypes showing different sets of data that cover the average
values and object volumes.
-
Simulate, or ignore, all user actions on windows that are non-trivial to implement.
-
Simulate, or ignore, the internals of the system, such as business logic, secondary storage, multiple
processes, and interaction with other systems.
|