Towards a Pattern Language for User Interface Design Costin Pribeanu National Institute for Research and Development in Informatics, Bucureşti, Romania E-mail pribeanu@ici.ro

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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

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.