Roles and Activities >
Analyst Role Set >
User-Interface Designer >
Prototype the User-Interface
Roles and Activities >
Analyst Role Set >
User-Interface Designer >
Prototype the User-Interface
Activity:
| ||||||||||||
Purpose
|
|
| Steps
For each use-case storyboard to be prototyped in the current iteration, perform the following steps:
Note that these steps are presented here in a logical order, but it is likely that you will need to alternate between them, and perform them in parallel. Initially, you spend the most time designing the prototype; then, after a while when you know more about the prototype, you spend the most time implementing it and getting feedback on it. |
|
| Input Artifacts: | Resulting Artifacts: |
| Role: User-Interface Designer | |
| Workflow Details: |
The following are different aspects of designing the user-interface prototype:
These aspects are presented below. However, a project need not consider all of these aspects in the prototype. Instead, it can often be appropriate to leave some aspects to the implementers and thus not deal with them in the prototype. In this case, we recommend that you leave the lower aspects in the list, and focus on the upper aspects.
While you design the prototype, you should:
Each boundary class aggregate yields a candidate for a primary window in the user interface. However, recall that one of the goals when building the object model was to identify as shallow aggregation hierarchies as possible; the purpose of this was essentially to minimize the number of primary windows and thereby also the window navigation paths required between them. In addition to adding needless interaction overhead, window navigation paths that are too long make it more likely that the user will "get lost" in the system. Ideally, all windows should be opened from a main primary window, resulting in a maximum window navigation length of two. Try to avoid window navigation lengths greater than three.
The main primary window should be the window that is opened when the user launches the application. It is normally always open as long as the application is running, and is the place where the user spends a considerable part of his "use time." Since it is always open and since it constitutes the user's first contact with the system, it is the foremost vehicle for enforcing the user's mental model of the system.
The most obvious candidate for the main primary window is defined by the top boundary class of the aggregation hierarchy, for example the Document class in a document editor. For details, refer to Guidelines: Boundary Class. If there are several aggregation hierarchies, choose the one that is most important to the user, that is, where the major part of the use time is spent.
When the main primary window is identified, you should consider the other aggregate classes that are part of the aggregation hierarchies, and decide whether or not they should be designed as primary windows. The default recommendation is that they should be designed as composites instead of primary windows of their own, if possible. Again, this is to minimize the number of primary windows and thereby also the window navigation paths required between them. Moreover, a composite is often justified by the fact that its constituents need to be shown together, and in spatial relation to, the constituents of other composites; note that this is hard to achieve if (primary) windows are used instead.
The Paragraph aggregate in a document editor is designed as a composite instead of a primary window of its own. This is partly because the constituents of a Paragraph, i.e. Characters, should be shown together, and in spatial relation to, the Characters of other Paragraphs.
As an alternative design, imagine the usability of a document editor where the user had to navigate to a separate (primary) window each time the contents of a specific paragraph is to be viewed.
However, it is often the case that all aggregates cannot be designed as composites, due to limitations in screen area. If there is not room for designing all aggregates as composites, try at least to design the following aggregates as composites:
Note that the average object volumes is an important input to this step, since they state how many objects that potentially need to be shown at once. Too many objects may imply that they cannot be designed as composites; instead, they may have a compact representation in the primary window in which they reside, and then define primary windows of their own.
The visualization of the primary windows, and the main primary window in particular, will have a significant impact on the usability of the system. Designing this visualization is about determining which parts (attributes) of the contained objects should be visualized. The flow or events and storyboard descriptions help prioritize which attributes to show. If the user need to see many different attributes of the objects, you may implement several views of a primary window, each view visualizing a different set of attributes. Designing this visualization also means that you have to look at how the parts (attributes) of the contained objects should be visualized, by using all visual dimensions. For details, refer to section "Visual Dimensions" in Guidelines: User Interface (General).
If a primary window contains objects of several different classes, it is important to find "common denominators" for these classes, for example. attribute types that are contained in all or most classes. By visualizing common denominators by some dimension, the user can relate objects of the different classes with each other and start to see patterns. This greatly increases the "bandwidth" of the user interface.
Assume you have a customer service system, where you want to show aspects like:
The customer's complaints and questions over time.
What products the customer has purchased over time.
How much the customer has been invoiced over time.
Here, a common denominator is "time." Thus, displaying complaints/questions, purchases and invoices beside each other on the same horizontal time axis will enable the user to see patterns of how these are related (if they are).
The responsibilities of the boundary classes specify the operations required by their corresponding windows. It is common that the operations of the primary windows and their contained objects are provided as menu items in a menu bar, and are provided as an alternative and complement via shortcut menus and toolbars. If a primary window contains objects of several classes, and these have different operations, you can assign one menu for each class, or one menu for each group of cohesive operations.
In a document editor, there is an Edit menu, grouping cohesive operations such as Cut, Copy, etc.
Note also that some operations may require a complex interaction with the user, thereby justifying a secondary window of their own.
In a document editor, there is a Print operation on a Document that, due to its complex interaction, justifies a separate dialog window.
Property windows need to be designed for all boundary classes, thereby making all their attributes available to the user. Note that some objects may only be partly visualized when they reside within a primary window (see the section "Design the Visualization of the Primary Windows" above); their property windows will, on the other hand, visualize all their attributes. Note that any average attribute values are an important input to this step, since they help in deciding the optimal visualization of a specific attribute.
Some of the simple responsibilities of boundary classes, such as setting the value of a specific attribute, are often provided as an operation by the property window. Such an operation is then either unavailable in the primary window in which the object resides, or it can work as an alternative or complement to a similar operation in the primary window.
Also, if a boundary class is part of an association, this association (including the associated objects) is normally visualized in the property window.
If a boundary class defines a large number of objects to be visualized in the user interface, it is often delicate to design operations involving these objects. The following are different variants of such operations:
Refer to Guidelines: User Interface (General) for more detail.
Add the necessary dynamic behavior to the user interface. Most dynamics are given by the target platform, like the select-operate paradigm, open by double clicking, pop-up menus on right mouse button, etc. There are, however, some decisions you need to make, including:
Also evaluate other common features that can enhance usability, including:
Refer to Guidelines: User Interface (General) for more detail.
There are basically three kinds of implementations of a user-interface prototype:
In most projects, you should use all three kinds of implementations, in the order listed above. This order allows for the simple incorporation of changes early on, since their typical implementation times differ greatly (drawings are much faster to create and modify than executables). However, drawings do not properly reflect limited screen area; it is easy to put more in a drawing than there is room for on the screen.
The best way to finally specify the user interface is through a combination of bitmaps and executables. This should be done as soon as you need to expose the prototype to people other than user-interface designers. A bitmap can specify the exact look of the primary windows, whereas the executables can approximate the look of the primary windows and support their operations, as well as the looks and behavior of the secondary windows. Naturally, if you can implement the exact looks of the primary windows in the executable, with a reasonable effort, this is better than combining the executable with a bitmap. If you don't have enough resources to produce an executable, you can use bitmaps as the final implementation of the prototype. In this case, it can be useful to complement them with use-case storyboards describing their dynamics; otherwise, chances are high that the implementers of the user interface will get the dynamics wrong.
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 operations. 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, it is of value that an executable 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:
|
Rational Unified
Process
|
