Model based design patterns Hallvard Trætteberg Dept. Computer and Information Sciences O.S. Bragstads pl. 2e 7491 Trondheim, Norway +47 7359 3443 [email protected] ABSTRACT

In this paper, we suggest using model fragments as the basis for defining user interface design patterns and pattern languages. Based on conceptual modeling and task modeling languages, examples of patterns are presented.

quently discussed. Model fragments are then suggested as a natural component of design patterns and examples of model based patterns are presented. We summarize with requirements for modeling languages used for design pattern representation and directions for future work.

Keywords

MODEL BASED USER INTERFACE DESIGN

Design patterns, model based user interface design, user interface model

Model based user interface design is characterized by its use of explicit, semi-formal representations of the user interface throughout the design process[4]. These models cover different perspectives and are elaborated and detailed until the design is complete. The perspectives may vary, but

INTRODUCTION

In “Essential English Dictionary” design is defined as: “[] the process of and art of planning and making detailed drawings of something.” The process nature of design indicates that it consists of several steps, includes non-deterministic choices and takes time. The art nature suggests that design is a creative process, requiring skill and labor. The quoted definition misses the fact that a design is made for a purpose, i.e., the “something” that is to be drawn in detail, addresses a problem or situation that has been previously identified. Design can be thought of as the transformation of a problem description into a description of an artifact. This involves pin-pointing, detailing and formulating the problem, identifying which properties of the artifact that will address particular parts of the problem, and handling conflicting requirements. Design patterns have been suggested as an aid for performing this problem-solution transformation. Such a pattern tries to capture design experience by packaging previous solutions for later reuse. This paper discusses design patterns in the context of model based user interface design[3]. First, a simple view of model based design is presented. The concepts of design patterns and languages are subse-

Abstract High

Concrete

perspectives

Domain/task

level

Dialog

Look & feel

design models

Low Figure 1:

User

interface

modeling

typically they can be placed along the abstract-concrete dimension, covering functionality, behavior and interaction details, as shown in figure 1. Each perspective covers the design from high to low level. The design process usually starts out in the high level, abstract corner, and the design model is extended towards lower levels and more concrete aspects. The modeling languages may provide some validation to ensure consistency among perspectives and levels[2]. E.g. the dialog should support all and only the task sequences allowed by the task model. What is missing, however, is guides for where and how to move towards the bottom right corner. E.g. how do we decompose tasks, how should the dialog be structured to support the tasks and which concrete interaction elements should we use? Previous designs may be an aid for the designer, both as an inspiration and for direct reuse. The advantage of the model based approach is that it provides an explicit representation

of several perspectives and levels. In principle, it should be possible to reuse different aspects of a design, by reusing model fragments[5]. As for all kinds of reuse, the main problem is finding the relevant fragments to reuse and adapting the fragments to the new context. The formal nature of models may provide some support for matching a new design problem to previous ones. Design patterns may provide a sound approach to model fragment reuse. DESIGN PATTERNS AND LANGUAGES

Design patterns were conceived as a means for capturing and reusing design experience in architecture, as an aid for less experienced designers. The patterns are extractions and abstractions of the lessons learned. Hence, the pattern user avoids being confused by irrelevant context and circumstances. By abstracting from the experiences, the pattern has greater relevance and potential for reuse. Although various formats have been suggested, a design pattern normally includes 1) a description of a problem and a possible solution, 2) examples of usages of the solution in actual designs, 3) reasons for why the solution actually solves the problem, 4) criteria for when to use and when to avoid this particular solution and 5) relations to other design patterns. Since individual design patterns are supposed to address single problems, a pattern collection is needed to cover whole application domains, perspectives and design levels. When such a collection provides a coherent whole and relatively full coverage of a domain, it is termed a pattern language. By using all the patterns of a language together, the resulting user interface is supposed to have a certain quality consistent with the values embodied in the pattern language. MODEL BASED APPROACH TO DESIGN PATTERNS

We believe the use of model fragments in formulating a pattern is promising. Patterns are used for taking small design steps in a design context, resulting in a new design context. Using our model of design presented above, design patterns are used for extending the (boundary of the) design model in a given direction, as suggested by the pattern. E.g. a pattern could help us in • • • • •

decomposing a task model, building a dialog model that supports a specific task, composing a presentation for domain information, designing the interaction required by the task model in a specific style or mapping abstract dialog elements to look & fell specific widgets

The problem description of a pattern is often split into three: 1) the design context where this problem occur, 2) the specific problem addressed by this pattern, and 3) the often conflicting requirements or forces that make design difficult. Model fragments may be useful for the formulating

the former two, since the modeling perspectives and levels offer both the ability to abstract the context and to focus on the particular problem. The solution is often presented as an abstraction of the examples, in order to factor out the essence of the solution. By using language features for generalization, model fragment should be able to support this. Different specialized solutions may be given, based on the context. E.g. one dialog fragment could be used when space requirements are tight, another if space isn’t a problem. Design patterns can be generic or specific to a problem, application domain or interaction style. Patterns can be vertical or horizontal by covering different levels within a perspective or several perspectives, respectively. Since model fragments can cover several perspectives and levels, either kind of pattern could be supported. Figure 2 shows a design pattern in the format suggested by [1]. Although the pattern is mainly textual, the context is defined by the domain model fragment: a set and an element (of the set), and the problem by a dialog model fragment: that of outputting the set and inputting the element. The model is very generic, but could very well be specialized to particular sets of entities. Since the problem description is based on a formal language, it should be easier to match the pattern with the actual problem than with a pure textual pattern. An interesting extension to searching for a pattern for a particular model fragment, is collecting all patterns for the same/similar problem. The problem of selecting an item from a list has several solution, each depending on context and particulars of the problem: A complementary pattern is shown in figure 3, where several solutions to the essentially same problem are presented. A design pattern may span several perspectives as shown in figure 4 In this case, the model fragment provides both a decomposition of a dialog for navigating and selecting a part in a set of containers, and a suggestion for a presentation structure. Our final and most complex pattern, again addresses the problem of selecting items from sets. However, this time a task model is used to capture a typical interaction pattern: that of defining some items as more likely to be used than others. The domain model fragment (top) defines two categories of elements: “typical” and “less used” elements. The task model fragment (middle) expresses that when selecting a “less used” element it can be promoted to the set of “typical” elements. The dialog model fragment (bottom) suggests an abstract design for this situation. Models and fragments have problems however: • •

Models are considered difficult to understand and use. Few all approaches integrate all the perspectives.

Problem: The user needs to select an item from a set before invoking a function. Select element

Principle: Use output element for input Context: Many user interfaces are built around a presentation of the important entities in the domain. Quite often, the user wants to invoke a function taking one of these entities as input parameter.

Set ∈

Forces: Element

• • •

If the set of entities is long, it is difficult to get an overview of the set. What information on each entity is relevant for presentation and user functions? The goal of presentation and input is different

Solution: Make a tabular window for listing the important fields of the entity and let the user click in or navigate in the list with the cursor keys. Use this selection as the function parameter. Include sorting so it is easier to find entities with specific characteristics. Examples: Eudora email, Windows 95 file explorer. Usability impact: Saves space by using output as input. Gives sense of direct interaction. Rationale: The desire to act on information often comes when seeing it. Hence, it makes sense to be able to use presented information as input. Figure 2:

Design pattern 1: Item selection

Problem: Item selection.

Select element

Principle: Utilize domain characteristics in widget selection. Context: Field value entry, where a limited number of options are available, from which one must be chosen.

Set ∈

Forces: • •

Space utilization. Visibility of current value and total set of options.

Element

Solution: Use a set of radioboxes when the set is small and static. Use a drop-down listbox when the set is larger or dynamic and space is important and it is not so important to always see the set of options. Use a listbox when the set is large or dynamic and it is important to quickly see the set of options.

red green blue Peter

Examples: See screen shots. Usability impact: Using different control for essentially the same function may confuse the user. Important to select the most practical control for each field.

Jane aunt Ann uncle John

Rationale: The radioboxes show all options and clearly shows the selected value. The drop-down listbox uses less space, but hides the other options. The listbox allows control over how many options are visible, but lets the user scroll away from actual selection. Figure 3:

• •

Design pattern 2: Item selection

Tool support is lacking, while considered essential. Fragments and incomplete models are not handled well.

In the context of design patterns, the situation is slightly remedied by the fact that the model fragments are mainly used for human-human communication, so formal consistency and completeness is less of a problem. In addition, the model fragments are complemented by the textual

description, so they should be easier to understand. Future research should target which kinds of design patterns that can benefit from model support and how to integrate the modeling perspectives and the design patterns. REFERENCES

1. Martijn van Welie’s web page “Patterns for User Interface design”. Available at http://www.cs.vu.nl/~martijn/ patterns/ (last visited 27. January).

Name: Browsing a container Browse aggregation

Problem: The user needs to browse the parts of an aggregation and select one of the parts. Principle: Navigation through causally linked panes.

1.1 Container

Context: Many application contains aggregated data, which the user must browse through. Quite often, the user wants to invoke a function taking one of the parts as input parameter.

• •

container. parts

Parts

Forces: Freedom for the application to visualize the set of containers, parts and individual items in specific ways. Freedom for the user to resize each viewer.

Select element

1.2

Select element

∈

Part

Solution: Split a window into three panes, one for the viewing a set of containers, one for viewing a set of parts, and one for viewing individual parts. The former two must provide item selection using the mouse and arrow keys. The selection of a container should determine the content of the parts pane, and the selected part should determine the content of the part pane. The selections may be used as parameters to invoked functions. Each pane should be specialized to the type of content it presents. E.g. if the containers form a hierarchy a tree pane providing selection of leaf nodes could be used. The panes should be individually scrollable and resizable.

1.3

1.1

View element

1.2

1.3

Examples: Eudora email, Netscape news. Usability impact: The layout should aid in understanding the causality among the panes. Each pane can be tailored to the domain and user. Individually resizable panes gives user freedom. Rationale: By configuring the panes according to the western way of reading (left to right, top to bottom), we support the causal relationship based on selection. By providing selection, other functionality besides navigation is supported. Figure 4:

1.2

1.1

1.3

Design pattern for browsing aggregations

2. Campos, J.C., Harrison, M.D. The role of verification in interactive systems design. In Proceedings of DSVIS’98. Springer-Verlag.

Development Methodology of Interactive Applications. Chapter 7 in Critical Issues in User Interface Systems Engineering. Springer 1996.

3. Vanderdonckt, J. (ed) Computer-Aided Design of User Interfaces. Proceedings of the CADUI’96. Presses Universitaires de Namur.

5. Breedvelt, i., Paternò, F., Severiins, C. Reusable Structures in Task Models. Proceedings of Design, Specification, Verification of Interactive Systems '97, Springer Verlag.

4. Bodar, F., Hennebert, A.-M., Leheureux, J.-M., Provot, I., Vanderdonckt, J., Zucchinetti, G. Key Activities for a

Problem: The user needs to select an item from a set. Items can be categorized as “typical” or “less used”.

Select element

Elements

element

Principle: Provide separate connected panes for specialized viewers. Typical

Less used

Context: Many entities are so numerous that selecting elements elements from the whole set is cumbersome, while typing in is tedious. However, often some of the entities are more relevant than others.

Select typical element

Select less used element

Select element

element

Define as typical

Forces: • •

Select element

Keeping the design simple Adding complexity by supporting quicker interaction.

Select element

Solution: Let the user define which elements are more relevant or provide good rules, and provide a means for quicker selection of these. Provide a good initial set of “typicals”. Use one dialog for the “typical” ones and one for “less used” ones, and let the user promote “less used” elements to “typical”.

Elements ∈

∈

Typical elements ∈

Element Element

Examples: Color pickers with standard colors and ability to name new ones, URL bookmarks/favorites in Netscape and Internet Explorer, Recently Used folder in Mac Finder.

Element

Usability impact: The user should find the simplified selection among the most used elements relieving. Remembering which elements are “typical” might be a burden.

Less used elements

Rationale: By streamlining the common case, overall performance is better. Figure 5:

Design pattern 3: Item selection from favorites

Select element

∈