Interface Architecture: Key Ideas

The interface architecture is an abstract model of the "places" in the user interface where the users interact with all of the information and functionality needed to carry out a task or set of related tasks. It consists of

• Content Model: how information and functionality are grouped together into "Contexts" or "Interaction Spaces"
• Navigation Map: how users may move from one context to another.

Content Model (Contexts)

A context is an abstract model of the information and functionality (tools and workspaces) that will be available together in the software (i.e., will be on the screen at the same time). A context is a collection of abstract interface elements, described in terms that the users understand. For example, it might contain things like "font picker" rather than "font menu."

Ideally, each use case will be supported by one context so as to minimize navigation between contexts. However, this goal must be balanced with the goal of keeping the contexts simple and not overloading the screen. A context could support more than one use case if they are very similar.

Navigation Map

The navigation map shows how contexts will be accessible from each other. When you construct the navigation map consider the following structural guidelines.

• The navigation map should include at least one context for each use case.
• Every context in the navigation map should support at least one use case. Similarly, every information object or tool in each context should support a use case, and every transition between contexts should be required for some use case.
• Minimize the number of contexts needed to enact each given use case, except where this would excessively crowd the context with information and tools. Also minimize the number of transitions between contexts needed to enact a use case.
• When one use case extends another, the corresponding contexts should be the same or should be immediately adjacent in the navigation space.
• When a use case is composed of subclasses, the subclasses should be in adjacent contexts in the navigation space.
• In general, contexts that support similar or related use cases should be accessible from each other (see examples of violations, figures 6.3 and 6.4 of text).

Building a Model

Model contexts by taking a paper and labeling it with the purpose it is intended to support. Then use Post-it notes or something similar to indicate the information, tools, and workspaces that will be available in the context. You might use different colors to represent these different kinds of content. The Post-it method is easy to rearrange until you are sure you have it right, and it helps remind designers and users that you are working on an abstract model, not a specific interface layout.

Start by going through the essential use cases line by line and identifying the information, tools, and workspaces needed to carry out the use case. Put these in the context you are constructing for the use case.

Don't worry about layout at this point, although you may want to group related content together within a context and jot down any ideas you have about layout for later use.

Once you have constructed the contexts, construct the navigation map by drawing boxes for each context and drawing arrows between the boxes to indicate transitions. You will have a transition wherever a use case requires moving between contexts, and should also have transitions as needed to make all contexts accessible, especially from contexts that support related tasks. Label the transitions with the actions that cause the transitions. The textbook provides some reasonable notation for this purpose.

At the end, review all the use cases to be sure they can be enacted with the navigation map, to see how much context switching is required by the model, and to check the other design considerations listed above. You may need to go back to revise your contexts and possibly even your use cases if you discover a problem.

Assignment

I suggest that you use the Post-it technique for your interface architecture. Show it to your users and rearrange it if needed. When done, turn in/post both the content model (either as a list of content as on page 131, or as a drawing that replicates your Post-it model), and the navigation map (for which a drawing program is preferred).