1. Towards a Pattern Language for User Interface Design
Costin Pribeanu
National Institute for Research and Development in Informatics, Bucureşti, Romania

2. Content Introduction Related work Domain-Task-Presentation mappings
Motivation
Objectives
Related work
Existing approaches
Domain-Task-Presentation mappings
A framework for model-based design
Presentation patterns
vizualization patterns
Conclusion
In this presentation we will first expose the motivation, the limitations of existing pattern-based approaches and the objectives of this work. Then we will briefly present our design framework and we will illustrate it with an example. In the third part, we will elaborate on a pattern language for UID based on the mappings between domain, task and presentation models.

3. Patterns in UID Patterns Model-based design of user interfaces
Used in urban design by Christopher Alexander
Three-part rules: problem, context and a solution
Patterns are combining themselves in a pattern language
Model-based design of user interfaces
Typical configurations featured by each model
Mappings between models
domain - presentation, user - task, task - presentation, task - dialog, platform - dialog, …
UI derivation
A pattern is a three-part rule expressing a relation between a certain context, a problem and a solution. The solution is a configuration that allows the forces acting in that context to resolve themselves. In his design philosophy, a pattern is itself a pattern of relationships between other patterns and it is both a thing and the way it is generated.
Welie and Veer proposed a pattern language structure which follows a top-down decomposition, along a scale of problems: posture type, experience, task and action. Molina et al are using conceptual patterns during the requirements specification and propagating them throughout the next development stages.
Seffah and Forbig proposed a layering of task models from the most general to the most context dependent as a foundation for a “multiple user interfaces” paradigm in model-based design.
Traetteberg proposed several patterns, which are focusing on the mapping between the domain and presentation models. The work of Sinnig et al is also discussing user interface patterns in the framework of model-based engineering.

4. Related work Existing approaches in using patterns for UID
Conceptual view: mental models for designers and lingua franca for communication between them and the clients
Welie and Veer (2003), Molina et al (2002), Nielsen (2002)
Layering of task models: separating context dependent from context independent parts
Seffah and Forbig (2002)
Mapping between domain and presentation models
Traetteberg (2000), Sinnig et al (2002)
Limitations of existing model-based approaches
Either too general: stopping at conceptual level
Either too detailed: focusing on only one model
Narrowly focusing on only two models
Existing approaches are either too general (stopping at conceptual level), either very detailed (focusing on only one model) or narrowly focused onto the mapping between two models (for example, domain-presentation). Little attention is given to the identification of the typical configurations featured by each model and how these patterns combine themselves.

5. Domain and task models
UID – progressive derivation of UI components from representations
users, task, domain and technology
Exploiting both domain and task models
Domain model
what information is needed in the interface
Task model
how to organize and present the information on the screen in a usable way
User interface design could be seen as a progressive derivation of the interface components from representations expressing relations between users, tasks, domain, and technology
Using the information contained in the domain model helps in deriving what information the user needs to manipulate in order to perform his task. Using the task model makes it also possible to derive how to present and organize this information in a usable way and the ordering of task performance.

6. Entities and relationships
Domain model
Domain objects (entities)
Attributes - widget level
Relationships – dialog unit level
Relationships
One-to-many - for example, a guideline is part-of a section guide
Many-to-many- for example a guideline respects one or more criteria and none or several guidelines respect a criterion
Logical model (relational approach)
Typical constructs (foreign key attributes and tables)
Make it possible to address control issues
There are three kinds of information in the domain model, which are of particular interest for the user interface design: domain objects (entities), object attributes and relationships between domain objects.
Relationships having the cardinality
- 1:N (one-to-many); for example, a guideline is part-of a section guide;
- N:M (many-to-many); for example a guideline respects one or more criteria and none or several guidelines respect a criterion.
The analysis will not start from the conceptual data model since the representation is too general and it illustrates early domain modeling results. Rather, we will use the logical data model, which is more complete in that it comprises additional constructs resulting from the logicalization process. These constructs (i.e. foreign key attributes and tables in a relational approach) are typical for each kind of relationship and make possible to address control issues in a model-based engineering approach.

7. Task model Task models Criteria used for task decomposition
Goals, actions, properties, task decomposition
Criteria used for task decomposition
data structure, functional structure
data processing, situations
nature of work - cognitive, manual, input, display
interaction objects used, interaction techniques
Representation
CTT – concur task tree graphical notation (Paterno, 1999)
Temporal relations between tasks (siblings)
Assigning properties and interaction objects

8. Example Task Relationships Target user
Create a guide using a tool for working with guidelines
Relationships
A guide can have several bases; a base contains several sections and each section contains several guidelines.
A guideline could be hierarchically structured, from more general to more specific guidelines
A guideline can be associated with other objects like references, examples and criteria
Target user
a designer or human factor specialist
collecting guidelines in source-based approach
create new bases, sections and criteria types.
In order to illustrate how the relationships between domain objects affect these mappings we will take an example. The task is to create a guide using a tool for working with guidelines. A guideline could be hierarchically structured, from more general to more specific guidelines. A guide can have several bases; a base contains several sections an each section contains several guidelines. A guideline can be associated with other objects like references, examples and criteria. The target user is a designer or human factor specialist, which is collecting guidelines in source-based approach. In this respect (s)he might need to create new bases, sections and criteria types.
A task decomposition using CTT graphical notation for the unit task “edit guideline” is presented next. For the sake of simplicity, only a part of basic tasks having as goal the data input have been included.

9. Representation - CTT
This figure shows the mapping between attributes in the domain model and interaction objects in the presentation model. How these interaction objects are actualy used is shown in the task model.

10. Layers in task decomposition
Initial task model
planning (functional) goals
Specified during early task analysis
platform independent
unit tasks: show “what to do”
Goals the user wants to accomplish
Designed task model
operational goals - basic tasks
Specified during user interface design
platform dependent
show “how to do it “
How the user is accomplishing a goal with a given technology
The first layer is the initial task model showing planning or functional goals. It is specified during early task analysis and is device
The operational part depends on the several UI design decisions: interaction style, interaction techniques and interaction objects.

11. Domain-task-presentation
Mappings in domain, task and presentation models
Horizontal mappings – between models
Vertical mappings – within one model
Mapping rules and design heuristics
Mappings from one model to another are done according to design heuristics and derivation rules

12. Edit entity attributes pattern
A simple pattern
Most used in model-based UID
Mappings between three pairs
Entity-attributes
Unit task - basic tasks
Dialog unit – abstract interaction objects
The task pattern: a sequence of basic tasks starting with a command selection, followed by data entry tasks (corresponding to object attributes) and ended by a confirmation command (usually ok vs. cancel). The pattern applies for editing attributes of both existing and newly created objects.
Most characteristic are the mappings between the three pairs: entity-attributes, unit task - basic tasks and dialog unit – abstract interaction objects. Attributes in the data model, basic tasks in the task model and AIOs in the interface model are the basic elements in our framework.

13. Identifying patterns Patterns afforded by relationships
Provide the user with means to visualize hierarchically organized data
Generic task flow: visualize-select-manipulate
Displaying patterns
Basic patterns afforeded by relationships
Interaction patterns depending on the relationship
One-to-many relationships
Many-to-many relationships
In most of the situations when the user wants to perform tasks using hierarchically organized data it is important to provide him with means to visualize the relationship between entities. In this respect, we can say that relationships are affording certain tasks. These interaction patterns are potential since they reveal inherent capabilities of the interactive system as provided by the domain model.

14. Displaying patterns Mirroring relationships among entities
consistent with the mental model of the user as regarding the data organization
placement of the higher / lower level entity above / below the AIO group used for data entry
Pattern combination
(c) is a composition of three patterns: show higher, edit entity attributes, and show lower.
a) Showing the higher level entity,
b) Showing the lower level entities, for example to display the more specific guidelines (recursive aggregation) – this is usually accomplished by using a list box placed at the bottom. This is also used to show associated entities since in a relational model the many-to-many relationship is mapped onto two one-to-many relationships.
c) Showing both the higher and lower for example to display the general guideline and the more specific guidelines – this could be accomplished using a text box and a list but also embedded dialog units showing a master-detail relationship
The pattern in 4c is a composition of three patterns: show higher, edit entity attributes, and show lower.

15. Example Presentation pattern Context: editing a guideline Show higher
Edit entity attributes
This is a better solution since the user is provided with some information about the existing state of association. Several criteria could be added (iterative task) before closing the window

16. Conclusion Identifying patterns
Displaying patterns refer mainly to the presentation
Selection patterns are relating the presentation and dialog model at widget level with the control model
Patterns for changing the associations are also relating the dialog model at dialog unit level
Pattern languages for UID for user interfaces should include both
Patterns occurring within the various models
Patterns of mapping between models
Display patterns refer mainly to the presentation parts, thus being static. Selection patterns are relating the presentation and dialog model at widget level with the control model while patterns for changing the associations are also relating the dialog model at dialog unit level. The main feature of this approach is that patterns are combining themselves and it is possible to specify large configurations of user interface parts with few patterns.
In order to have a generative power, a pattern language for user interfaces should include both the patterns occurring within the various models and the patterns of mappings. It is worthwhile to mention that the centrality of the domain objects is a contextual aspect, which gives a sort of directness of the user interface patterns.