Describing the UserUser Interface

This section describes the modeling elements needed to capture presentation requirements for a system specification. This same model is also used to formally model the content of user interface design patterns.

Modeling Presentation Requirements

In principal it would be very nice to capture every detail of an abstract user interface design as a part of the software specification. In practice, this is just too tedious, at least with current tool support and is rarely done. Instead, the goal is to capture the requirements at the level of Primary Tasks and Secondary Tasks. This means the model needs to have a place to put these requirements. The ETP architecture marks presentation-related elements as Presenters. This user model introduces Primary Presenter and Secondary Presenter, specializations of Presenter, to fill this need.

This part of the model is deceptively simple. For each Primary Task there will be a single corresponding Primary Presenter. Similarly, for each Secondary Task there will be a corresponding Secondary Presenter. The instances of Primary Task and Second Task—created to reflect the Scenario or Scenarios that define them—represent the entities, attributes, and relationships that must be presented in order to complete the task. These Task instances also define the Actions that must be available within their corresponding Presenters. The corresponding instances of Primary Presenter and Secondary Presenter are used to define whatever additional presentation requirements are known.

A concrete example might help. Let's say we are modeling a task that requires a presentation of an organization's structure. If the organization is structured as in our metamodel, we could conclude that the presentation requirement was to display the decomposition of an organization into the hierarchy of contained organizations and members of each organization. Depending on the task, we might or might not have a requirement to graphically render multiple membership of members into organizations using either a network graph or a hierarchical graph with notations—that choice comes a bit later in the process.

The remaining step, as described in the ETP architecture section, is to go through the list of Presenters and cull out duplicates or near duplicates—not only saving development resource but saving the user the overhead of dealing with multiple units of presentation that do essentially the same thing.

When complete, this model of presentation includes a description of the functionality that must be supported—the Primary Tasks and Secondary Tasks, the function points that must be supported—the Actions, and the rough number and complexity of Primary Presenters and Secondary Presenters. The complexity of presentation is expressed as the description of the entities, attributes and relationships that must be displayed—as derived from the Task instances—and the description of how to display them—as derived from the Presenter instances. This should be sufficient for the purposes of sizing and of assigning content to development iterations.

One final aspect of presentation description which is not handled during requirements definition is an understanding of the mapping of individual presentation elements onto the domain model. Because this is so closely allied with knowledge of the domain it is the responsibility of the Tasks—though this mapping is thought of as application logic in older terminology. As shown in the diagram below, a special kind of Task called an Aspect Adapter can be used to set up this mapping. Typically, this mapping is known by the Primary or Secondary Tasks which are capable of setting up a tree of Aspect Adaptors in order to correctly extract and update domain values based on changes in the domain or changes in selection or value in the presentation. Though this is really more an issue for design and development—and framework design—it is raised here because this mapping from task to domain is an integral part of the users' domain and, therefore, of our model.

Modeling UI Design Patterns

Many kinds of UI design patterns can be described. There are patterns that express canonical configurations of widgets to support certain kinds of tasks. There are also design patterns for tasks. The notion of Primary Task or Secondary Task, for example, are themselves design patterns as are the ways in which these patterns can be surfaced in the design of user interface navigation. These patterns are the basis of discussion for the Patterns topic area. The discussion in this section concerns the modeling elements needed to support this discussion of user interface design patterns.

All of the modeling elements we have discussed are part of a language of user and user interface description. When describing user interface design patterns, constructs like Scenario take on less importance. This is because design patterns are all about the semantics of design, not the procedural content.

User interface design pattern discussions focus on the semantics of presentation including what is being presented (entities, relationships, and attributes) as well as what the presentation supports (tasks). The presentation itself needs to be described in more detail than we have yet used.

Visual Formalisms

The main element missing from our discussion so far is the notion of a Visual Formalism. A visual formalism [see Nardi and Zharmer 1993] is simply a visual interaction language that is equivalent to a command language—sometimes known as a macro language. Nardi and her colleauges were inspired by spreadsheet applications and the ways in which they tend to be used. Spreadsheets provide a rich direct manipulation interface that is often mirrored by an equivalent command language. Among other things, they obsreved that the command language imposed a consistency and completeness of interaction on the visual language. Though they were interested in the implications of mirroring the visual language with the command language, they introduced the notion that visual interaction mechanisms need to cohere as a language as well.

This concept of Visual Formalism can be extended to all of our familiar interaction mechanisms. Approaches such as forms, trees, tables—in a sense, a specialized version of a spreadsheet, network graphs, composed documents, and maps are all examples of visual formalisms. These all correspond to user interface design patterns.

So, what is needed is a way of describing visual formalisms, the pieces that make up a formalism, and the mapping of these pieces to a user domain in the form of a concept model. In the class diagram, below, the modeling elements Visual Formalism and Formalism Element are used to represent a formalism and its component pieces, respectively. Any formalism can now be modeled as a specialization of Visual Formalism with specializations of Formalism Element for each type of presentation element that formalism supports.

Substantial examples of models of Visual Formalisms will be found in the Patterns topic area. For now, we do have one very lightweight example of a Visual Formalism in the way we have modeled Primary Presenter and Secondary Presenter.

A Primary Presenter is a unit of presentation that provides an independent unit of interaction to the user. It can contain any other Visual Formalism. It organizes access to Actions via various Menus—where Menu is one of the Formalism Element specializations peculiar to Primary Presenter and is itself a formalism. The Primary Presenter is responsible for visually containing the state of the task including persistence in the system and visibility to other users. Depending on the implementation of this formalism (Windows® and the Macintosh® are but two) there can be variations in the details behind these mechanisms but the essential behavior remains—just as there are many spreadsheet implementations but really only one visual formalism albeit with variations.

The figure below shows a UML diagram modeling the presentation needed to solve a task. This same metamodel supports both domain (requirements) modeling as well as UI design pattern modeling.

Figure: a UML class diagram, over 650 pixels wide—click here to open it in a separate window.