Connecting Patterns: An Ontology-Based Approach for a Pattern Language Definition

Claudia Iacob University of Milan

Department of Computer Science Via Comelico 39/41, 20135 Milan, Italy

+39 025 0314007

iacob@dico.unimi.it

Daniela Fogli University of Brescia

Department of Information Engineering Via Branze 38, 25123 Brescia, Italy

+39 030 3715666

fogli@ing.unibs.it ABSTRACT The paper describes an approach for identifying relationships between design patterns in a collection, in order to define a pattern language. Starting from an initial collection of design patterns and building an ontology for representing the domain addressed by the collection, relationships between the patterns are identified. The pattern language is then defined by the design patterns themselves together with the identified relationships. The paper reports on the approach and its application on a collection of patterns addressing the design of software applications for synchronous collaboration. Finally, a software tool able to answer queries on the pattern language based on the defined ontology is described.

Categories and Subject Descriptors D.2.10. [Software Engineering]: Design – Methodologies.

General Terms Design, Human Factors.

Keywords Design patterns, design issues, degree of recurrence, synchronous collaboration, pattern language.

1. INTRODUCTION The origin of the concept of design pattern dates back in the ‘70s when the architect Christopher Alexander defined it as follows: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [1]. Soon after, the concept has been adopted in other fields such as software engineering and Human-Computer Interaction (HCI). On one hand, software engineering applied design patterns for expressing object-oriented software design experience. An example of a design pattern in software engineering is the Singleton, which is used to restrict the instantiation of a class in one object [5]. On the other hand, HCI designers adopted the design pattern approach to document and describe “the reasons for

design decisions and the experience from past projects, to create a corporate memory of design knowledge” [2]. Several collections of design patterns for interface and interaction design are now available in the Web (e.g. [11, 12]). An interesting critical review on existing HCI patterns is presented in [3]. The authors propose a comparison based on different views, including the view that sees patterns as artifacts for explicit representation of design guidance. Such design guidance should take into account that design problems are more than often interrelated: they refer to each other, smaller problems arising in the context of larger ones. Larger complex problems may be refined into less complex problems and smaller granularity problems may be composed into larger granularity problems. As a consequence, design patterns, being descriptions of proven solutions to recurring design problems [2], must be conceived as interrelated artifacts. This is in accordance with the approach originally proposed by Alexander [1], who structured his collection of design patterns in the architecture domain as a network, defined as a pattern language. In the language, each pattern includes indications about its relationships with the other patterns. Extrapolating, a pattern language is a collection of patterns belonging to the same domain [6] together with the relationships that can be identified between them. As suggested in [2, 10], relationships between patterns represent the added value of a pattern language with respect to a loose collection of patterns. Borchers [2] proposes to organize a pattern language as an acyclic directed graph, where each node in the graph is a pattern and an edge between two patterns represents a “context/reference” relationship. As an example, a pattern P is the context for a pattern Q (or, in other words, P references Q) if there is an edge from P to Q. This allows one to organize the patterns according to different levels of abstraction so that they can be considered at different stages of system development. As example, Gamma et al categorize patterns into architectural patterns, design patterns, and idioms [5]. However, many proposals of pattern collections in literature are not conceived as pattern languages. Design patterns are often defined as isolated entities, thus providing a narrow and local view of design solutions. This is evident for example in the most famous software engineering pattern collection [5], but also in HCI pattern collections, such as that proposed by Yahoo! [13], where patterns are clearly classified in different categories but do not include any references to other patterns. For example, in the "Layout" category the design pattern "Page grid" is not related to patterns described in the "Navigation" category, which, however, often depend on the page layout. Therefore, the problem addressed by this paper is how to determine the relationships existing between the patterns belonging to a collection, so to transform such a collection into a

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PLoP’11, October 21–23, 2011, Portland, USA. Copyright 2010 ACM 1-58113-000-0/00/0010…$10.00.

pattern language. Examples of such relationships are association (two design patterns can be directly associated), and specialization (a design pattern can address a subproblem of the problem addressed by another pattern). This open issue has been scarcely addressed in the literature. For example, authors such as Martin et al. [8] feel that relationships between patterns “should emerge once a number of patterns have been developed and put to use”. In [6], Herrmann et al. suggest that “much work has to be done to create a true pattern language from interrelated patterns and that profound knowledge of the domain is necessary to perform this work”. An agreed thing is the idea proposed by Alexander, according to whom once a meaningful path has been identified through a collection of patterns, each project can develop its own pattern language from the collection [1]. The solution proposed by this paper consists in defining an ontology for representing the domain addressed by the collection of patterns. This ontology can then drive the creation of the relationships among patterns so as to obtain a pattern language. A further and related question we would like to answer in this paper is: having available a design pattern language addressing a specific domain, how can a designer make use of this language throughout his/her work? To explore this issue, we have designed and developed a tool for representing and querying a pattern language, based on the ontology of the considered domain. More precisely, this tool should be able to answer the following questions: 1) Given a design pattern, what are the patterns related to it and how are they related?, 2) Given two design patterns, what relationship exists between them (if any)?, 3) What are the design patterns between which there is a given relationship R?, 4) Given a keyword, what are the design patterns associated to it?, 5) Given two design patterns, what are their common keywords (if any)?, 6) Given a set of keywords, what are the patterns related to them? The paper is structured as follows: Section 2 presents the ontology-based approach for defining a pattern language; Section 3 describes the application of this approach on a collection of design patterns addressing synchronous collaboration; Section 4 presents the tool supporting designers interested in working with a pattern language defined; Section 5 concludes the paper.

2. AN ONTOLOGY-BASED APPROACH FOR DEFINING PATTERN LANGUAGES This section describes an approach for identifying relationships between design patterns in an existing collection. The collection of patterns together with the identified relationships between the patterns defines a pattern language [1]. The approach is based on the definition of an ontology for representing the domain addressed by the pattern collection, domain which is initially described by a set of design issues. As examples of domains, one could consider interactive exhibits [2], e-government [9], web accessibility [4] or, as in the case study considered in this paper, synchronous collaboration. Design issues are collected during design workshops and software application analysis, according to the method proposed in [7]. They represent problems, solutions, examples, consequences, and any other information relevant to the design of a system in the area targeted. Design patterns are documentations of those design issues with a higher degree of recurrence (i.e. the design issues mostly discussed throughout the workshops and mostly considered in the implementation of concrete applications). The ontology is build by identifying a set of keywords for each design issue and of different relationships between pairs of keywords. Then, given the design patterns obtained from the collected design issues, the

ontology drives the definition of a structure connecting design patterns to each other, i.e. a pattern language. More formally, three phases are defining the approach (Figure 1): 1) the concepts identification phase, 2) the relationships identification phase, and 3) the pattern language definition phase. Figure 1 – Three-phase process for a pattern language definition

2.1 Identifying Concepts 2.1.1 Collecting Design Issues During a series of design workshops and through the analysis of a set of software applications, a collection of design issues, D = {d1, …, dn}, is collected. During a design workshop, a team of designers is asked to design the Graphical User Interface (GUI) and the interaction process of an application in the domain targeted. These activities is observed and recorded and the design issues discussed by the participants are collected. The software application analysis consists in walking through a scenario for each application and in collecting the design issues - relevant to the interaction affordances provided - considered in the application’s implementation. The scenarios cover all the different features provided by the applications and each scenario is tailored to a particular application.

2.1.2 Associating Keywords An initial step towards the definition of a pattern language consists in associating each design issue (di) with a set of keywords (Ki), thus obtaining a folksonomy [17] - keywords are freely chosen by designers and do not refer to any controlled vocabulary. In order to avoid undesired noise in the finally generated pattern language, a word can be a keyword only if used in less than 10% of the associations. Hence,

These keywords are words belonging to the statement of the issue and/or words strongly related to the statement of the issue. The process is subject to automation providing that a natural language processing tool is being used for extracting the keywords (this possibility will be explored as future work). As example, the design issue “Support collaborators in providing tags, comments, annotations, rankings” is associated with the set of keywords - {tagging, ranking, comments, social, community}. Associating each of the design issues considered with a set of keywords leads to:

The set is defined as the Design Issues Map and represents all the pairs associating a design issue with a keyword. The set of keywords is

.

Concepts Identification

Relationships Identification

Pattern Language Definition

Figure 2 – Input/Output elements for the Concepts Identification

Phase The input of this first phase consists in the collection D of design issues, used for describing a specific design domain. The output, on the other hand, is the set of keywords K and the set DIM, pairing design issues with associated keywords (Figure 2).

2.2 Identifying Keyword Relationships A second step towards the pattern language definition is the identification of relationships between the keywords, i.e. the elements of the set K. The approach makes use of 5 types of relationships, R: a). Equality (“=”). Two keywords – k1, k2 – are in a “=” relationship if k1 is equal to k2. As example, “collaborator” = “collaborator”.

b). Equivalence (“ ”). Two keywords – k1, k2 – are in a “ ” relationship if k1 is a synonym of k2. As example, “online”

”web_based”.

c). Specialization (“ISA”). Two keywords – k1, k2 – are in a “ISA” relationship if k1 is a sub-type of k2. As example, “tabletPC” ISA “device”. d). Composition (“HASA”). Two keywords – k1, k2 – are in a “HASA” relationship if k2 is a part of k1. As example, “library” HASA “templates”. e). Association (“RELATEDTO”). Two keywords – k1, k2 – are in a “RELATEDTO” relationship if k1 is associated to k2. As example, “Instant_Messaging” RELATEDTO “communication”. Moreover, the RELATEDTO relationship is enhanced with a description explaining the association between the 2 keywords. Going back to the example, “Instant_Messaging” RELATEDTO<used-for> “communication”. Identifying all the relationships between the keywords, leads to the definition of the Keywords Map:

where R ∈ {Equality, Equivalence, Specialization, Composition, Association}. KM represents all the pairs of related keywords.

Figure 3 – Input/Output elements for the Relationships Identification Phase

The input of the second phase is the set K of keywords, decided on during the first phase. The output of the relationship identification phase consists in KM, the keywords map which pairs any two related keywords (Figure 3). The Design Issue Map (DIM) and the Keywords Map (KM) make up the ontology supporting the definition of the pattern language as specified below.

2.3 Defining the Pattern Language The definition of the pattern language requires two sub-phases: 1) the definition of the Design Issue Language, and 2) the definition of the Pattern Language.

2.3.1 Design Issue Language Definition In identifying the relationships between the design issues collected, the following rule is applied:

This is to say that a design issue, dα is in a relationship R with another design issue, dβ if dα is associated with a keyword, kαx which is in a relationship R with another keyword kβy to which dβ is associated (Figure 4).

di dj

Ki Kj

ki1

ki2 kiu

kinikj1

kj2kjv

kjnj

R

R

Figure 4 – Identifying relationships between design issues

The rule is applied to all the design issues in the set D, generating the Design Issue Language (DIL), comprising all the design issues and the relationships between them.

For outputting the DIL, this sub-phase takes as input the collection of design issues, D, together with the set KM, the output of the previous phase, and the set DIM (providing information on the keywords associated to each design issue) (Figure 5).

Figure 5 – Input/Output elements for the Design Issue Language Definition Phase

2.3.2 Pattern Language Definition Not all the design issues are design patterns. All the design issues discussed throughout the workshops and all those considered in the implementation of concrete applications are collected. For each design issue, its degree of recurrence (DoR) is computed as the percentage in which the issue has been addressed throughout the workshops and the implementations considered, as defined in [7]. Further on, the design issues are sorted based on their DoR, and those design issues with the highest DoRs are documented through design patterns. A threshold of recurrence (ToR) has been established to 50%. Hence, a design issue, di, is considered to be documented as a pattern, pi, if DoR(di) > ToR.

Consider the set of design issues with the highest degree of recurrence and which are further documented as design patterns. Therefore, the Pattern Language is defined, as:

Concepts Identification Phase D

K, DIM

Relationships Identification Phase K KM

D, KM, DIM

DIL Design Issue

Language Definition Sub-Phase

For outputting the Pattern Language, the input for this sub-phase is the collection of patterns, P, and the language DIL (Figure 6).

Figure 6 – Input/Output elements for the Pattern Language Definition Phase

The generation of the DIL offers the possibility of placing the pattern language in a context, modeling - together with KM - the domain addressed by the patterns, and supporting a better understanding of each pattern and the implications of its use. Moreover, design issues that are not documented as patterns might contain information relevant to the considered design patterns. This allows designers to better investigate specific design problems/solutions that have not been included in the patterns yet.

3. DEFINING A PATTERN LANGUAGE FOR SYNCHRONOUS COLLABORATION To demonstrate how the ontology-based approach works, we describe here the definition of a pattern language for the design of software to support synchronous collaboration. Synchronous collaboration requires users to work together in the same time on a shared resource, whether they are co-located or in different locations [14]. As example, synchronous drawing is documented as a frequent activity in fields such as architecture, or graphic design [15]. Moreover, based on interviews with teachers, librarians, and researchers, it is concluded in [16] that there are many situations in which “groups of people gather around a single computer to jointly search for information online”. This section briefly describes the method used in mining for the collection of patterns, and the application of the ontology-based approach described in Section 2 on this collection.

3.1 Mining for the Pattern Collection The mining method used for identifying the design patterns consisted in two phases. During the first phase, the results of the design workshops followed by 1 team of professional designers, 9 teams of graduate students in Computer Science, and 3 teams of undergraduate students in Computer Science were analyzed. Further on, during the second phase, 20 applications existing on the market (developed as either research projects or commercial products) were examined. These applications support synchronous collaboration in activities such as drawing, text editing, searching, and games. The two phases were developed independently one from another, their results being triangulated after both phases were conducted. During a design workshop, a team of 3-5 designers was asked to design the GUI and the interaction process for an application in the domain of the mining process and the design issues they address were collected. These design issues were used for describing the domain targeted by the pattern mining, in this case the domain of synchronous collaboration. To support the results of the workshops, an additional set of software applications in the area of the mining process were analyzed in order to identify in what measure the design issues discussed during the workshops were considered in the implementation of existing applications. The most recurring design issues in both the workshops’ results and the results from the analysis of the software applications were considered to be documented as design patterns.

3.2 The Collection of Patterns The mining process led to the collection of 90 design issues and after the analysis of their degree of recurrence, 15 design patterns were identified and are listed below. Each design pattern is described by a name, a unique ID1, a picture, the problem addressed by the pattern together with the set of forces which influence this problem, the description of a solution to tackle the problem, possible symptoms that might require the application of the pattern, a set of consequences that the application of the pattern triggers, examples of the patterns applied. The brief description of all the patterns identified in the synchronous collaboration domain is presented below, together with the complete description of one of the patterns (Figure 7).

Figure 7 – Shared Summary design pattern – complete description Who is the coordinator? (ID = 14) addresses the problem of providing a coordination mechanism which: a). allows all collaborators to take part in the collaboration and b). maintains the resource in a consistent state at all times.

1 The ID is the design issue ID and, if the issue is considered as a

pattern (based on its degree of recurrence), the ID is kept as the ID of the pattern.

Pattern Language Definition Sub-Phase

P, DIL

PL

Integrated chat (ID = 6) addresses the problem of supporting the communication among collaborators, suggesting the integration of an instant messaging feature in the design of the application. Eyes wide open (ID = 7) addresses the problem of allowing each collaborator to be notified about and visualize what the others are contributing to the process at any time. Choose your collaborators (ID = 4) suggests allowing each user to be able to choose the people s/he wants to work with during the collaboration. Collaboration, always social (ID = 9) suggests integrating mechanisms of tagging, ranking, annotating, and commenting in the application in order to support the collaborators in forming a community. With or without collaboration (ID = 1) addresses the issue of providing users with an additional private area, not available to the other collaborators, where each collaborator has total control and where s/he is provided with tools specific to the context of the application. My contribution (ID = 24) addresses the problem of supporting the identification of each individual’s contribution to the collaborative process. Track history of collaboration (ID = 23) suggests saving the history of the collaborative process and making it available through repositories, log files, or timelines. Adapt application to device (ID = 22) suggests supporting the materialization of the application on various devices so that users are allowed to collaborate even if they use different devices for that. Shared summary (ID = 39) suggests providing the collaborators with an automatic way to create summaries of their collaborative processes. These summaries could include intermediary results of their process, statistical data, or simplified versions of the shared resource. (Figure 7) Annotate (ID = 27) suggests allowing users to enhance the shared resource with textual, audio, or video notes on the misunderstandings, additional explanations, or inquiries they might have. Any annotation is in itself a thread-like entity, allowing the collaborators to answer back through text, audio, or video material. Support versioning (ID = 23.1) indicates enhancing the application with a versioning mechanism able to support the collaborators in viewing and editing older versions of the document they are working on. Collaborative undo (ID = 23.2) suggests supporting the users in undoing changes performed on the shared document, maintaining the resource consistent.

Customize collaboration (ID = 33) points to providing the collaborators with the possibility of customizing the parameters of their collaborative process. These parameters could be simple visualization or editing options, or more complex options such as assigning roles and rights among the collaborators. Resume collaboration (ID = 41) suggests allowing the collaborators to pause their collaborative process, store its state, and restore it later without affecting any collaborator’s contribution.

3.3 From the Pattern Collection to the Pattern Language The collection of patterns was identified starting from a set of design issues (D) containing 90 issues. As described in Section 2, each of the 90 design issues was associated with a set of keywords. Table 1 presents some examples of design issues and the keywords associated to them.

Design issue Keywords

6 (Integrated chat) communication, Instant_Messaging, chat

7 (Eyes wide open) visualization, awareness

9 (Collaboration, always social)

tagging, ranking, comments, social, community

1 (With or without collaboration)

separate layers, non-collaborative, collaborative, brainstorming

33 (Customize collaboration)

customize, collaboration, community, rights, roles

Table 1 – Design issues map (fragment) Furthermore, relationships have been identified between the keywords. As examples of such relationships, consider: a). awareness = awareness, b). groups

teams, availability

user_status, initiator

first_editor, c). pdf ISA format, education ISA goals, first_editor ISA coordinator, d). session HASA session_state, community HASA library, collaborators HASA roles, groups HASA collaborators, e). visualization RELATEDTO<supports> awareness, track RELATEDTO<applies-to> changes, invites RELATEDTO<triggers> join, highlight RELATEDTO<used-for> identify_data, join RELATEDTO<applies-to> groups.

Figure 8 – Design issues (identified by an ID), keywords, and the DIM and KM sets (graph representation)

Figure 8 illustrates the graph representation of the 90 design issues (represented by their IDs), the set of keywords, and both the DIM (set of pairs mapping a design issue to a keyword) and KM (set of pairs mapping two keywords) sets. Different colored arrows represent different types of relationships. Based on DIM and KM, relationships between the design issues were inferred, generating the design issue language, DIL. In the following we report some examples of relationship inferences: a). tabletop ISA device, hence 22.6 ISA 22, b). groups

community, hence 4

9,

c). visualization HAS shared_resource, hence 7 HASA 27, e). rights RELATEDTO<applies-to> shared_resource, hence 33 RELATEDTO<applies-to> 27, f). community RELATEDTO<requires> coordination, hence 9 RELATEDTO<requires> 14. The pattern language, PL, comprising the collection of patterns described in Section 2, was finally obtained after eliminating the design issues which were not considered for being documented through design patterns and all the relationships involving such design issues. Figure 9 illustrates the pattern language obtained, representing the design patterns using their IDs.

D

D

B

B

B

C

C

C C

C

E

E

EEE

E

E

E

E

E

E

EE

E

E

E

E

E E

E

E CA

A

A

A

E

Figure 9 – A pattern language for the design of synchronous collaborative systems

4. TOOL SUPPORT A software application able to answer a set of queries related to a pattern language has been developed (Figure 10). The application exploits a knowledge base that is built on the basis of the domain ontology. Such knowledge base consists of: i) the set of the unique IDs of the design issues, ii) the set of all the keywords used to describe these design issues, iii) the mapping of the design issues to the associated keywords, iv) the set of pairs of related keywords and the relationship between them, and v) the unique IDs of the design issues considered for being documented as patterns (i.e. the IDs of the design patterns identified). Therefore, the application can generate both DIL and PL. As far as the generated PL is concerned, the application is able to answer 6 types of queries: 1). Given the ID of a design pattern, it returns the set of design patterns associated to it, specifying for each pattern the type of relationship. 2). Given the IDs of 2 design patterns, it returns the type of relationship existing between them. 3). Given a type of relationship (R), it outputs the pairs of design patterns between which R exists. 4). Given a keyword, it returns all the design patterns associated with that keyword.

5). Given 2 design patterns, it returns the set of keywords associated to both patterns. 6). Given a set of keywords, it returns the collection of design patterns related to the keywords. A design pattern (pi) is related to a keyword (k) if the set (Ki) of keywords associated with pi contains a keyword (kiα) such that k R kiα.

Figure 10 – Tool support in ontology querying

The tool’s interface provides a simple query editor allowing the user to input his query (i.e. a set of keywords or the IDs of one or more design patterns), an area containing the possible types of

Red (A) – Equality Navy (B) – Equivalence Blue (C) – ISA relationship Black (D) – HASA relationship Violet (E) – RELATEDTO relationship

The Patterns: 1 (With or without collaboration)

4 (Choose your collaborators)

6 (Integrated chat)

7 (Eyes wide open)

9 (Collaboration, always social)

14 (Who is the coordinator?)

22 (Adapt application to device)

23 (Track history of the collaboration)

23.1 (Support versioning)

23.2 (Support reverting changes)

24 (My contribution)

27 (Annotate)

33 (Customize collaboration)

39 (Shared summary)

41 (Resume collaboration)

queries the user might be interested in, an area containing the possible relationships existing between patterns (useful for queries of type 3), and an area designated for the results obtained after executing the query. The results are displayed as lists of one of the following tuples: 1) (ID_pattern1, ID_pattern2, relationship_type, relationship_description), where ID_pattern1 is given as input, and ID_patterns2 is the ID of a pattern related to the input pattern by the relationship relationship_type. In case relationship_type is of type RELATEDTO, the relationship_description provides information on the relationship type. 2) (ID_pattern1, ID_pattern2, relationship_type, relationship_description), where ID_pattern1 and ID_pattern2 are given as input, and relationship_type is the relationship existing between them. In case relationship_type is of type RELATEDTO, the relationship_description provides information on the relationship type. 3) (ID_pattern1, ID_pattern2), where ID_pattern1 and ID_pattern2 are related by relationship R, provided as input. 4) (ID_pattern), where ID_pattern is the ID of the pattern to which the keyword provided as input is associated. 5) (keyword), where keyword is associated to the patterns given as input. 6) (ID_pattern, keyword, relationship_type, relationship_description), where ID_pattern is the ID of the pattern related to one of the keywords given as input, and keyword is associated to the pattern ID_pattern and related by relationship relationship_type to one of the keywords given as input. In case relationship_type is of type RELATEDTO, the relationship_description provides information on the relationship type. The tool is designed for any software designer interested in using a knowledge repository of design patterns represented by a pattern language. Some of the scenarios of use for the tool are described below: a). Facing a design problem, one would be interested in knowing what are the design patterns to be looked at and how are these patterns interrelated. For that, one would create a query containing a set of keywords related to the problem and get as result a collection of design patterns related to the query. b). After identifying a useful design pattern and applying the solution proposed by the pattern, one would be interested in knowing how does this impact the overall design process and what consequences are triggered. Moreover, the application of one pattern might ask for the application of a related pattern, as well. The tool supports the identification of such related patterns. c). Using two different patterns (possibly in different parts of the project), one would need to know if these two patterns are in some way related and, if so, how are they related. d). Not being familiar with the domain addressed by the patterns, one would like to explore it for getting insight on the issues to be faced during such design processes.

5. CONCLUSIONS The paper describes an ontology-based approach for the definition of a pattern language, starting from a collection of design patterns. The pattern language is in itself a dynamic entity, hence it can evolve becoming larger and larger based on the growth of the domain’s ontology. New design issues may lead to the

identification of other design patterns which would be integrated in the already defined pattern language through the regeneration of the language. A software application able to answer a set of queries related to a pattern language has been developed. This tool answers 6 types of queries on the defined pattern language, based on which relationships between patterns can be inquired. Also, the tool supports the search of design patterns related to keywords provided as query input. As future work, the authors are considering evaluating this application allowing design teams to use it during their work. They are also planning to process existing pattern collections – e.g. Yahoo! one – through the proposed application, in order to transform such collections into actual pattern languages.

6. ACKNOWLEDGMENTS The work of Claudia Iacob was supported by the Initial Training Network "Marie Curie Actions", funded by the FP 7 – People Programme entitled "DESIRE: Creative Design for Innovation in Science and Technology”.

7. REFERENCES [1] Alexander, C. 1977. A pattern language: Towns, buildings, construction. New York: Oxford University Press.

[2] Borchers, J. 2001. A Pattern Approach to Interaction Design. John Wiley & Sons, Inc.

[3] Dearden, A., Finlay, J. 2006. Patterns Languages in HCI: a Critical Review, Human-Computer Interaction, 21, 49-102.

[4] Fogli, D. Parasiliti Provenza, L., Bernareggi, C.. 2010. A design pattern language for accessible web sites, In Proceedings of AVI 2010, pp. 307-310.

[5] Gamma, E., R. Helm, R. Johnson, Vlissides, J. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley.

[6] Herrmann, T., Hoffmann, M., Jahnke, I., Kienle, A., Kunau, G., Loser, K-U, Menold, N. 2003. Concepts for usable patterns of groupware applications. In Proceedings of the Conference on Supporting group work (GROUP '03). ACM, New York, NY, USA, 349-358. [7] Iacob, C. 2011. A Design Pattern Mining Method for Interaction Design. EICS2011, Pisa, Italy, June 13-16, 2011

[8] Martin, D., Rouncefield, M., Rodden, T., Sommerville, I.,Viller, S. 2001. Finding patterns in the fieldwork, Proceedings of ECSCW 2001 (Bonn, GER, 16-20 September, 2001), 39-58. [9] Pontico, F., Winckler, M., Limbourg, Q.: Organizing User Interface Patterns for e-Government Applications. In: Proc. Engineering Interactive Systems (EIS 2008), LNCS 4940, 601-619 (2008) [10] Seffah, A. 2010. The Evolution of Design Patterns in HCI: From Pattern Languages to Pattern-Oriented Design. Proc. Int. Workshop on Pattern-Driven Engineering of Interactive Computing Systems (PEICS’10), Berlin, Germany, 4-9. [11] Tidwell, J. 2005. Designing Interfaces: Patterns for Effective Interaction Design. O'Reilly Media. [12] Welie, M. Patterns in interaction design. Retrieved: June, 20th 2010. Available at: http://www.welie.com

[13] Yahoo! Developer Network, Design Pattern Library, Retrieved: May 2nd, 2011. Available at: http://developer.yahoo.com/ypatterns [14] Grudin, J. 1994. Computer-supported cooperative work: History and focus. IEEE Computer, 27(5), 19-26. [15] Margaritis, M., Avouris, N., Kahrimanis, G. 2006. On Supporting Users' Reflection during Small Groups Synchronous Collaboration. 12th International Workshop on Groupware, CRIWG 2006. LNCS 4154. Springer. [16] Saleema Amershi and Meredith Ringel Morris. 2008. CoSearch: a system for co-located collaborative web search. Proceeding of CHI '08. ACM, New York, NY, USA, 1647-1656. [17] T. V. Wal. Folksonomy, February 2007. http://vanderwal.net/folksonomy.html

Annex 1 – A pattern language for the design of synchronous collaborative systems (table version) 1 4 6 7 9 14 22 23 23.1 23.2 24 27 33 39 41

1 - E

4 - B B B

6 - E E

7 - A D D

9 B - E E E A E E

14 E E - E E

22 - E

23 E E - E E E E A

23.1 C -

23.2 E - E E

24 E E C C E - E E E

27 B E C E E E - A A E

33 B A E E -

39 E E A - E

41 E C C E E E E -

Red (A) – Equality Navy (B) – Equivalence Blue (C) – ISA relationship Black (D) – HASA relationship Violet (E) – RELATEDTO relationship

The Patterns: 1 (With or without collaboration)

4 (Choose your collaborators)

6 (Integrated chat)

7 (Eyes wide open)

9 (Collaboration, always social)

14 (Who is the coordinator?)

22 (Adapt application to device)

23 (Track history of the collaboration)

23.1 (Support versioning)

23.2 (Support reverting changes)

24 (My contribution)

27 (Annotate)

33 (Customize collaboration)

39 (Shared summary)

41 (Resume collaboration)