a pattern language for the interaction with web-based business intelligence applications

A master of science thesis incomputer science in media

Department of digital media

Furtwangen University of Applied Sciences,Germany

A pattern language for

business intelligenceapplications

the interaction with web-based

Felix Kaiser

Contents at a glance

Preface 9

Acknowledgments 11

I. Research design 13

1. Basics 15

2. Research context 21

3. Pattern languages for human-computer interaction 31

4. Business intelligence and its interactions 49

5. Research approach 65

6. Conclusion 71

II. The pattern language 75

7. Basics 77

8. Conceiving information architecture 83

9. Developing content components 107

10.Designing interactions 119

III. Appendix 145

A. Miscellaneous 147

B. List of Figures 149

C. List of Tables 151

3

CONTENTS AT A GLANCE

D. Bibliography 153

E. About the author 159

4

Contents in detail

Preface 9

Acknowledgments 11

I. Research design 13

1. Basics 151.1. Definition of terms . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.1.1. Pattern language . . . . . . . . . . . . . . . . . . . . . . 151.1.2. Business intelligence . . . . . . . . . . . . . . . . . . . . 161.1.3. Web-based applications . . . . . . . . . . . . . . . . . . 161.1.4. Human-computer interaction . . . . . . . . . . . . . . . 16

1.2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2.1. Problem statement . . . . . . . . . . . . . . . . . . . . . 171.2.2. Research question . . . . . . . . . . . . . . . . . . . . . 18

1.3. Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4. Research objectives . . . . . . . . . . . . . . . . . . . . . . . . . 191.5. Research focus . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6. Assumptions and premises . . . . . . . . . . . . . . . . . . . . . 20

2. Research context 212.1. Direct research context . . . . . . . . . . . . . . . . . . . . . . . 212.2. Scientific surroundings . . . . . . . . . . . . . . . . . . . . . . . 212.3. State of researchconnectivity & differentiation . . . . . . . . 25

3. Pattern languages for human-computer interaction 313.1. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 313.1.2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2. Concept of a pattern language . . . . . . . . . . . . . . . . . . . 353.2.1. Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.2. Language aspect . . . . . . . . . . . . . . . . . . . . . . 363.2.3. Formalization . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3. Language structures . . . . . . . . . . . . . . . . . . . . . . . . 413.3.1. Patterns agglomeration types . . . . . . . . . . . . . . . 41

5

Contents in detail

3.3.2. Structures . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4. Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.4.1. Pattern optimization . . . . . . . . . . . . . . . . . . . . 453.4.2. Language optimization . . . . . . . . . . . . . . . . . . . 45

3.5. Using pattern languages in human-computer interaction . . . . 463.5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 463.5.2. Special potential . . . . . . . . . . . . . . . . . . . . . . 48

4. Business intelligence and its interactions 494.1. The core of business intelligence . . . . . . . . . . . . . . . . . . 49

4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 494.1.2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.1.3. The business intelligence concept . . . . . . . . . . . . . 534.1.4. Business intelligence applications . . . . . . . . . . . . . 54

4.2. Interacting with business intelligence applications . . . . . . . . 574.2.1. Interaction contexts & elicitors . . . . . . . . . . . . . . 574.2.2. Typical and comprehensive business intelligence . . . . . 59

5. Research approach 655.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2. Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.1. Pattern design . . . . . . . . . . . . . . . . . . . . . . . 655.2.2. Pattern language contrivance . . . . . . . . . . . . . . . 66

5.3. Practical procedure . . . . . . . . . . . . . . . . . . . . . . . . . 68

6. Conclusion 716.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.2. Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.3. Further research . . . . . . . . . . . . . . . . . . . . . . . . . . 73

II. The pattern language 75

7. Basics 777.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.2. Language structure . . . . . . . . . . . . . . . . . . . . . . . . . 787.3. Using the language . . . . . . . . . . . . . . . . . . . . . . . . . 807.4. Language substantiation . . . . . . . . . . . . . . . . . . . . . . 81

8. Conceiving information architecture 838.1. Structuring contents . . . . . . . . . . . . . . . . . . . . . . . . 84

8.1.1. Sign-in page . . . . . . . . . . . . . . . . . . . . . . . . . 848.1.2. Information architecture . . . . . . . . . . . . . . . . . . 848.1.3. User home . . . . . . . . . . . . . . . . . . . . . . . . . . 878.1.4. User salutation . . . . . . . . . . . . . . . . . . . . . . . 87

6

Contents in detail

8.1.5. Index page . . . . . . . . . . . . . . . . . . . . . . . . . 898.1.6. Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . 898.1.7. Meta application component . . . . . . . . . . . . . . . 908.1.8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.1.9. Help manual . . . . . . . . . . . . . . . . . . . . . . . . 928.1.10. Error page . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.2. Navigating through contents . . . . . . . . . . . . . . . . . . . . 938.2.1. Navigation . . . . . . . . . . . . . . . . . . . . . . . . . 938.2.2. Split navigation . . . . . . . . . . . . . . . . . . . . . . . 948.2.3. Meta navigation . . . . . . . . . . . . . . . . . . . . . . 958.2.4. Searching information . . . . . . . . . . . . . . . . . . . 958.2.5. Content shortcut . . . . . . . . . . . . . . . . . . . . . . 978.2.6. Related information . . . . . . . . . . . . . . . . . . . . 988.2.7. Personal content shortcut . . . . . . . . . . . . . . . . . 988.2.8. Whats new? . . . . . . . . . . . . . . . . . . . . . . . . 998.2.9. Recently viewed pages . . . . . . . . . . . . . . . . . . . 1008.2.10. Breadcrumb navigation . . . . . . . . . . . . . . . . . . 1018.2.11. Content preview . . . . . . . . . . . . . . . . . . . . . . 1028.2.12. User feedback . . . . . . . . . . . . . . . . . . . . . . . . 1038.2.13. Progress bar . . . . . . . . . . . . . . . . . . . . . . . . 1038.2.14. Processing indicator . . . . . . . . . . . . . . . . . . . . 1048.2.15. Accomplishment indicator . . . . . . . . . . . . . . . . . 104

9. Developing content components 1079.1. Modeling contents . . . . . . . . . . . . . . . . . . . . . . . . . 107

9.1.1. Content component . . . . . . . . . . . . . . . . . . . . 1079.1.2. Graphical content component . . . . . . . . . . . . . . . 1099.1.3. Textual content component . . . . . . . . . . . . . . . . 1109.1.4. Numerical content component . . . . . . . . . . . . . . . 1119.1.5. Graphic legend . . . . . . . . . . . . . . . . . . . . . . . 1129.1.6. Content module . . . . . . . . . . . . . . . . . . . . . . 1139.1.7. Geographical mapping . . . . . . . . . . . . . . . . . . . 1149.1.8. Information explanation . . . . . . . . . . . . . . . . . . 114

9.2. Content layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159.2.1. Assigning dimensions to axes in spreadsheet reports . . 1159.2.2. Balance information volume . . . . . . . . . . . . . . . . 1169.2.3. Information in context . . . . . . . . . . . . . . . . . . . 117

10.Designing interactions 11910.1. Interacting with content . . . . . . . . . . . . . . . . . . . . . . 120

10.1.1. Customizing displayed information . . . . . . . . . . . . 12010.1.2. Remember customizations . . . . . . . . . . . . . . . . . 12210.1.3. Reset to defaults . . . . . . . . . . . . . . . . . . . . . . 12310.1.4. Feasible default . . . . . . . . . . . . . . . . . . . . . . . 123

7

Contents in detail

10.1.5. Sorting numerical content components . . . . . . . . . . 12410.1.6. Selecting time ranges . . . . . . . . . . . . . . . . . . . . 12510.1.7. Selecting measures . . . . . . . . . . . . . . . . . . . . . 12610.1.8. Drilling & slicing . . . . . . . . . . . . . . . . . . . . . . 12810.1.9. Selecting an entity from a list . . . . . . . . . . . . . . . 13010.1.10.Selecting an entity from a hierarchy . . . . . . . . . . . 13010.1.11.Selecting a graphic type . . . . . . . . . . . . . . . . . . 13110.1.12.Problem alert . . . . . . . . . . . . . . . . . . . . . . . . 13210.1.13.Content feedback . . . . . . . . . . . . . . . . . . . . . . 13310.1.14.Rating content components . . . . . . . . . . . . . . . . 13410.1.15.Context-sensitive help . . . . . . . . . . . . . . . . . . . 13410.1.16.Tooltip . . . . . . . . . . . . . . . . . . . . . . . . . . . 13510.1.17.Meta information . . . . . . . . . . . . . . . . . . . . . . 13610.1.18.Function explanation . . . . . . . . . . . . . . . . . . . . 13610.1.19.Export content component . . . . . . . . . . . . . . . . 13710.1.20.E-mail content . . . . . . . . . . . . . . . . . . . . . . . 13810.1.21.Print content . . . . . . . . . . . . . . . . . . . . . . . . 13910.1.22.Export content to application . . . . . . . . . . . . . . . 139

10.2. Interacting with the application . . . . . . . . . . . . . . . . . . 14010.2.1. Application-wide preference . . . . . . . . . . . . . . . . 14010.2.2. Support request . . . . . . . . . . . . . . . . . . . . . . 14010.2.3. Warning message . . . . . . . . . . . . . . . . . . . . . . 14210.2.4. Transparent communication . . . . . . . . . . . . . . . . 14210.2.5. Explain user rights . . . . . . . . . . . . . . . . . . . . . 14310.2.6. Common parlance . . . . . . . . . . . . . . . . . . . . . 143

III. Appendix 145

A. Miscellaneous 147A.1. Pattern language markup language (PLML) DTD . . . . . . . 147A.2. Use of graphical icons . . . . . . . . . . . . . . . . . . . . . . . 148

B. List of Figures 149

C. List of Tables 151

D. Bibliography 153

E. About the author 159

8

Preface

Introduction This thesis aims at the contrivance of a pattern language forthe interaction with web-based business intelligence applications. Apart fromthis challenging objective, the author would appreciate if its readership tookdelight in the rationales and findings of this thesis. Enjoy reading!

Organization of this document This document consists of two major parts.The first part, called research design, describesafter explaining some basicsthe research context, the concept of a pattern language and business intelligenceas well as the approach taken by this study. It concludes with a summary andan assessment of the outcomes.The second part, entitled the pattern language, then details the language

created within this research. It starts with a visual overview of the patternsand then gives some basic instructions for using the language. Finally, it de-scribes the actual patterns themselves that design the interaction with businessintelligence applications.The appendix gives some detail on the authors background and provides

indexes of all tables and figures in this document.

Time of research The research for this study was started in August 2005 andcompleted with the publication of the thesis in March 2006.

Contacting the author The author of this thesis, Felix Kaiser, will hap-pily accept feedback on this document. Remarks, questions and criticismmay be sent at [email protected]. This thesis website can be found atfelixkaiser.com/go/bi-patterns. To learn more about Felix background consultsection E on page 159.

9

Preface

10

Acknowledgments

During the process of conducting this research, the author has experiencedsupport from the following persons, for which he wants to express his gratitude:

Prof. Dr. Wolfgang Taube, Furtwangen University of Applied Sciences,adviser of this thesis, who has made the author aware of the patternlanguage concept

Prof. Dr. Christoph Zydorek, Furtwangen University of Applied Sci-ences, adviser of this thesis, who has challenged the author with alienperspectives

FCBi Deutschland, the authors employer, whose flexibility has openedthe time-frame for this research and

the authors team at FCBi, whose tolerance created the freedom to takeadvantage of this time-frame.

Gustav, the composer, who has provided the soundtrack

Christina, Sibylle and Dieter: thank you for being there.

11

Acknowledgments

12

Part I.

Research design

13

1. Basics

Contents

1.1. Definition of terms . . . . . . . . . . . . . . . . . . . . 15

1.1.1. Pattern language . . . . . . . . . . . . . . . . . . . . 15

1.1.2. Business intelligence . . . . . . . . . . . . . . . . . . 16

1.1.3. Web-based applications . . . . . . . . . . . . . . . . 16

1.1.4. Human-computer interaction . . . . . . . . . . . . . 16

1.2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17

1.2.1. Problem statement . . . . . . . . . . . . . . . . . . . 17

1.2.2. Research question . . . . . . . . . . . . . . . . . . . 18

1.3. Significance . . . . . . . . . . . . . . . . . . . . . . . . 18

1.4. Research objectives . . . . . . . . . . . . . . . . . . . 19

1.5. Research focus . . . . . . . . . . . . . . . . . . . . . . 19

1.6. Assumptions and premises . . . . . . . . . . . . . . . 20

1.1. Definition of terms

1.1.1. Pattern language

Pattern languages are first of all a special kind of pattern collections. Patternsin turn are written generalized solutions to common problems that are reusable.Whenever several patterns form a collection that is

built to be used for a specific application domain,

delineated from other domains,

somewhat complete for its domain, and

helping to generate new applications in this domain

it is called a pattern language.The concept of a pattern language and its possible definitions are discussed

in detail in section 3.2 on page 35. To anticipate the result of the discussion,this work uses the following definition:

15

1. Basics

A pattern language is a finite system of patterns which may be usedto generate an infinite variety of different applicationsof the samedomainand whose use will allow the applications designers andusers to generate a balance of uniformity and variety, which makesthe application a good one.

1.1.2. Business intelligence

This thesis delineates the business intelligence concept and business intelligenceapplications. See section 4.1 on page 49 for a detailed discussion.

Business intelligence (as a concept) is the capability of an enterpriseas a whole to support its employees in their business-relevant ac-tions by providing data, information, knowledge or wisdom relevantin this context, extracted from business data.

To support this concept and provide the means that allow an enterprise (andits employees) to pursue it, business intelligence applications are implemented:

Business intelligence applications are software applications, whichsupport its users in pursuing the business intelligence concept. Todo so, they gather, analyze and evaluate relevant data and elevateit to information, knowledge or wisdom in interaction with the en-terprise user towards the goal of improving the quality of businessactions taken by this user.

1.1.3. Web-based applications

The term application in the title of this thesis refers to a software programthat is employed by users to solve or support solving problems within a givenarea. An example for such an application is the e-mail software Thunderbird.Whenever an application does not need to be installed locally on a computer,but instead is accessible via an Internet browser software over the Internet (orby using Internet technology) that application is considered to be web-based.Gmail, for example, is a web-based e-mail application that may be used fromall over the world with many different browsers.This document is thus using the following definition:

A web-based application is a software program that is accessible byInternet technology via a browser.

1.1.4. Human-computer interaction

Human-computer interaction (HCI) is a broad scientific and hands-on domainthat is concerned with different aspects of the interaction of one or many humanusers with computers and computer programs. Hewett et al. have defined HCIin 1992 as follows:

16

1.2. Introduction

Human-computer interaction is a discipline concerned with the de-sign, evaluation and implementation of interactive computing sys-tems for human use and with the study of major phenomena sur-rounding them. [HBC+92, p.5]

1.2. Introduction

1.2.1. Problem statement

It is a commonly accepted fact that the competition in western markets has Competitive advantageis vitalbeen highly intensified over the last decade. Therefore, a competitive advan-

tage is vital for businesses to retain profitability and ultimately exist in thosemarkets. While many different concepts and instruments exist that provide afoundation or even claim to be the cure to this problem, the idea of businessintelligence (BI) has proved to be an efficient way of coping with it.

Whenever a business decides to have the concept of business intelligenceimplemented in its organization and procedures, its pervasion considering itsuse becomes crucial for the business success. Every employee that should butdoes not follow the business intelligence concept prevents the company fromgaining the competitive advantage to its fullest possible degree.

In turn, the use of applications, implementing the BI approach, in part BI depends on itsusabilitydirectly depends on the usabilityor interaction qualityof the software. Of

course, other aspects, as e.g. the employees BI knowledge, are interfering withthe applications usage, too. The usability however plays a decisive part as itsextensive realization is considered as an absolute basic by the users.

It thus may be said thatto a certain degreethe success of business in-telligence within a company is contingent upon the interaction quality of itsimplementation.

As BI applications usually deal with a lot of data and consider extensivecorrelations, using them normally becomes a complex task. For this reason,designing the interaction of those applications is even more complex.

Additionally, the know-how of BI interaction designers does not seems tobe documented in a publicly available form. On account of this, creatingapplication concepts means creating them from scratch, only using personalexperienceif present. This prevents interaction designers from spending theirmain efforts on the implementation of the BI idea, which could and should betheir main focus.

Apart from that practically oriented aspects, a method for the devision and Language creationmethodcreation of a pattern language does not seem to be available. The process of

securing know-how in such a language is thus unsettled.

17

1. Basics

1.2.2. Research question

According to the above stated argumentation the leverage of usability of busi-ness intelligence applications would provide a vital support to the idea of busi-ness intelligence. As shown, the implementation of this usability depends onthe quality or know-how of the interaction designers conceiving it. Those inturn lack support for the recurring tasks of application conception.The existence of a pattern language that deals with this context would pro-Support of a pattern

language vide this support. Such a pattern language would

assure and increase the applications quality, structure and lead the process of conceptual design, document the person-dependent know-how in a person-independent way,and

save the main effort, so far spent on conceiving the interaction design,for the implementation of the business intelligence idea.

Scope of this thesis is thus to develop such a language for web-based1 appli-cations.

1.3. Significance

This thesis is intended to meaningfully enhance the field of scientific publica-Scientific advancementtions concerning pattern languages and the connected research. By creatingand using a methodology for the development of a pattern language, this studyhopefully enhances the knowledge in this area and enables others to use thisas a foundation for further studies.It moreover tries to connect the scientific research with the hands-on oriented

approach of using a pattern language, so that both fields may be judged fromthe respective opposite side.Regarding the hands-on assistance, the outcomes mainly support interactionHands-on support

designers in conceiving business intelligence applications. As argued in sec-tion 1.2.1 on the preceding page, this directly supports the implementation ofthe BI idea and of course the implementation process.Furthermore, the documentation of the knowledge contained in the BI pat-

tern language builds the currently unavailable basis for future enhancementsboth in academic and practically oriented areas.As a consequence, the intended audience of this study are mainly people fromIntended audience

the pattern language community (both scientists and users) and respectivelyinteraction designers that deal with the concept of BI applications. Whilst1See 1.5 on the next page for an explanation why the study is narrowed down on web-basedBI applications.

18

1.4. Research objectives

the latters interest will mainly concern actual pattern language part of thisdocument (beginning at page 77), the pattern language communitys interestprobably lies in both parts with a focus in the research design (this part).

1.4. Research objectives

The objective of this research is to develop and provide a pattern language for A BI pattern languagethe interaction with web-based business intelligence applications.Apart from that apparent intention it strives for other subordinate goals: Subordinate goals

Enhance the interaction with business intelligence applications

Document those interaction patterns and their enhancements

Test the creation of a pattern language in practice

Connect the spectra of knowledge of BI and pattern languages

Document the research in parallel to its progress to ensure replicability

Section 6.2 on page 71 critically assesses the achievement of these objectives.

1.5. Research focus

The title of this thesis spans a broad field of research, which cannot be settledby a single work. The focus thus needs to be narrowed down to define thevalidity of the outcomes for a focused area and of course to ensure a reachablegoal. The constriction follows the terms used in the title.The pattern language created by this research, is intentionally not restricted Pattern language

in its focus regarding the scope or the level of concreteness of its patterns. Thedesign of the pattern language itself needs to be unrestrained to enable it tofulfill the prerequisites of the other areas.As to the interaction, this study focuses on an end-user clientele, which Interaction

directly uses the data or information gathered from the business intelligenceapplication for its business means. It does not cover the interaction with BIexperts using the application to develop and provide this information or eventechnical administrators. If a BI application is considered to have a front- andback-end and the respective user interfaces, the latter is not treated.As the interaction possibilities of locally installed and web-based applications Web-based

differ decisively2, the patterns found in the pattern language of this study onlyconsider web-based applications. This decision was made by the author basedon his personal background and experiences, as few people will start to create

2The difference emerges in the different underlying technologies as well as the availableperformance of the whole systems.

19

1. Basics

a locally installed business intelligence software from scratch, whereas creatinga web-based one is a lot more likely.Regarding the type of web connection this study focuses on clients having

broadband access3 to the Inter- or local area net, the BI application is availablefrom.The character of the examined business intelligence is mainly a quantitativeBusiness intelligence

not a qualitative one, meaning that the information presented is primarilyfigure- and diagram-based and less textual.Considering the character of the applications, this research deals with, in-Applications

dividuality per user and configurability need to be considered. While bothshould be implemented in a meaningful way, they should not be overdone sothat the number of similarities between two users applications highly exceedsthe number of distinctions. Considering the individuality of single businessintelligence reports, those shall not be freely configurable but instead rely ona default setting that is adaptable.The size and complexity of the considered applications also needs to be

reflected. The applications volume should comprehend at least 20 with a max-imum of around 80 application areas and/or pages or reports.Apart from the above mentioned qualitative delineation, it is also importantNot in this work

to state what this work is not: it does not cover the roll-out of business intel-ligence in a business or the design or planning of such a project. Also it doesnot explain basic principles of interaction design as these are considered to bewell-known by the target audience of interaction designers.

1.6. Assumptions and premises

This research acts on several assumptions that were made when its design wasconstituted. First of all it assumes that it is possible to formulate the patternPotentiality of a

pattern language language that is advised by the study. This in turn requires the field of researchto have interaction problems, which may be generalized. These assumptionsare made as a basis for the establishment of this studys research question andare very probable. It is however still a possible outcome that they may bedisproved.Apart from that it is assumed that there are web-based business intelligenceSuboptimal interaction

applications (which the author can tell from own experience) and the user-interaction with these are suboptimal.In sum this leads to the assumption that there is a market for this workMarket

as well as a scientific and hands-on audience that is interested in its outcomes.This thesis has been conducted within the European cultural context, which

certainly has influenced its character implicitly.

3with at least 1Mbit/s but usually between 10 and 100MBit/s, shared by several corporateusers

20

2. Research context

Contents

2.1. Direct research context . . . . . . . . . . . . . . . . . 21

2.2. Scientific surroundings . . . . . . . . . . . . . . . . . 21

2.3. State of researchconnectivity & differentiation . 25

2.1. Direct research context

Starting from the title of this thesis, the context comprises of the four fields thework originates from: Pattern languages, business intelligence (BI), human-computer interaction (HCI) and web-based applications. The focus of thisresearch lies in the intersection of these four domains but has a distinct offsettowards pattern languages and business intelligence.This is the case, because the concept of a pattern language both forms the in-

strument and the outcomes of this research and these cover and consider aboveall the particularities of (the interaction with) business intelligence applica-tions. Regarding interaction design this study relies on existing foundationsand only uses them. The same is true for the technological basis of the con-ceived applicationsthe web. Thus, the influences of the fields of HCI and theweb are a lot smaller than those of pattern languages and BI. This in turn isthe reason for the latter two being described in detail in sections 3 on page 31and 4 on page 49.

2.2. Scientific surroundings

Each of the four stated fields in the context of this thesis again has its owncontext which may directly influence this work. These influencing domainswill be described briefly in this section to illuminate the ambiance of the actualtopic and allow for a deeper understanding of the whole field.The strongly interdisciplinary area of human-computer interaction probably Human computer

interactionspans the most broad and diversified field of all. As stated in a first HCI curricu-lum recommendation in 1992, its protagonists range from naturally computerscientists over psychologists, sociologists and anthropologists to industrial de-signers1 and all the people working in between, e.g. HCI student instructors.

1Cp. [HBC+92]

21

2. Research context

As the kernel of HCI is what all these disciplines bring together, this topic canhardly be understood in detail without knowledge of its the individual fields.The main function of HCI is the conceptual and graphic design of naturally

interfaces to computers, used by human beings. In practice these interfacesmay be software or hardware interfaces and those again may be differentiated.As an example, different types of software interfaces range from interfaces foroperating systems2 over application interfaces to those of websites.In HCI several very lively topics exist: one of the most often stated probably

is the concept of usability, which measures the extent to which a product canbe used by specified users to achieve specified goals with effectiveness, efficiencyand satisfaction in a specified context of use [Int98]. The implementationof high usability today is considered to be the basis for a good interfaceor the respective application as a whole. In the experience of the author,the realization of high usability, which is often simply referred to as usabilitywithout a qualifier, is considered to be a key requirement of most HCI projects,but seldom is given enough personal and financial attention to be reached.The HCI community is widely represented by the Special Interest Group on

Computer-Human Interaction (SIGCHI) within the Association of Comput-ing Machinery (ACM), which organizes and sponsors the CHI conferences onhuman factors in computing systems as well as other specialized speeches andworkshops as theMobileHCI conference. Apart from this more theory-orientedenvironment many practitioners conduct huge amounts of commercial projectsthat may be settled in the HCI field.The area of business intelligence is less broad but as a whole a lot moreBusiness intelligence

confusing as A the term business intelligence is commonly used with differentmeanings and B other terms are used for more or less the same thing.3 Theprimary reason for this confusing plurality probably lies in the need, marketinghas felt to give every new characteristic of BI a new name.As a confession to the industry-related character of BI (and its namesakes)

there are less scientific texts available than on HCI, architecture or computerscience. Actors in the field of BI primarily consider its application in the contextof corporate management. Its applications as a management tool range fromoperational over tactical to strategical use. BI may be connected as data sourceor drain to planning systems (such as enterprise resource planning (ERP)),business operating systems (e.g. business process management (BPM) or event-driven architectures (EDA)); it might as well be integrated into knowledgemanagement systems (e.g. to compare with competitors strengths) and manymore.Business intelligence is present in a broad range of industries, naturally mass-

producing manufacturing industries being the blueprint application domain.

2E.g. K Desktop Environment, Mac OS X Aqua, Windows Vista Presentation Foundation3BI (or at least very similar approaches) is also referred to as analytics, performance man-agement, management information system or decision support system; each of these alsoprefixed with the terms business, enterprise or corporate.

22

2.2. Scientific surroundings

Considering the size of industries, BI applications can mostly be found butare not limited to larger companies, as cost and effort for implementing andusing BI and benefits need to be in a rational proportion. Within enterprisesusers of BI applications can be found in organizational contexts of accounting,budgeting, financial and management reporting, forecasting, marketing as wellas sales.Apart from the industries actually using BI, the topic is given extensive

coverage by research and consulting specialists, particularly Gartner4 [Gar] andMeta Group5 [Met], as well as manufacturers of business intelligence softwareframeworks like Business Objects [Bus], Cognos [Cog] or Oracle [Ora].Regarding its backbone in information technology, business intelligence ap-

plications rely on various data storage, access and manipulation techniques,mainly implemented by data storage artifacts like databases, data warehousesor data marts. The extract, transform & load procedure as well as on-lineanalytical processing (OLAP) or data mining may be mentioned as exemplarymethods. The data storage artifacts may either be part of an out-of-the-box BIsoftware solution or the BI application accesses an underlying multi-purposedatabase. Regarding the databases themselves, various types are used, rangingfrom relational to multi-dimensional set-ups.As already stated above, sciences are only marginally connected to the area

of business intelligenceit seems that these are very pragmatically consultedwhenever this seems appropriate for the solution of a hands-on problem. Forexample in Jottings from the business intelligence jungle [Sel02], David Selby re-ports his research for particular BI solutions with the more scientific A program-ming language6 (APL) of which the results are re-coded in a more industry-typelanguage and then included in IBM software products.The sciences business intelligence is connected and reverts to are mainly eco-

nomics, social sciences and structural sciences. Examples of BI-related subjectsin science are

behavioral finance in economics, describing principles and empiric findingson human economic decisions,

information democracy in social sciences, considering the social aspectsof information made available to demosor a at least a previously un-reached wide range of people, or

artificial intelligence in structural sciences, which e.g. has conductedresearch on pattern recognition used for the devision of actions fromdata.

4as BI as a subsidiary of information technology is within core focus of Gartner5Recently acquired by Gartner6Actually a programming language called A programming language, although originally con-ceived as Iversion notation by its creator Ken Iverson.

23

2. Research context

The core subject of this thesis, patterns and their languages, do not seemto have found application in BI until 2005, when this research was conducted.The term pattern in BI context is usually used differently than in this workand refers to a recurring pattern within data or information that e.g. may beautomatically recognized.Regarding the field of architecture the only contact point with this work isArchitecture

the concept of pattern languages which originates from this area. The architec-tural surroundings thus have hardly any influence. It is nevertheless interestingto examine the feedback pattern languages have received in its original back-ground. The concept is generally discussed controversially: although the Royalinstitute of British architects lists A pattern language [AIS77] by ChristopherAlexander et al. as one of 11 recommended books on (architectural) designand as a design standard [Roy05], other architects consider it overestimatedand expose it to criticism7. It seems that in the past architects have feared aloss of control over their work as the concept empowers their customers, the in-habitants of designing their buildings of high quality themselves. The conceptis thus often criticized by architects and praised by normal people.The pattern language concept in general is considered to be an important

theory of architecture. However Alexanders buildings are few and are said tofail fleshing out his ideas. When it comes to the less architectural but morecosmological or ideological part of his theories, the acceptance or rejection itexperiences naturally becomes more intense. This for example became clear ina 1982 debate between Alexander and the post-structuralist Peter Eisenmanon Contrasting concepts of harmony in architecture [aut83] which consequentlyis only marginally about architecture.The use of pattern languages in architecture seems restricted to projects

Christopher Alexander and his direct colleagues pursue, as well as to teachingin architectural contexts. The author was unable to find other, if need becompetitive, pattern languages neither for architecture as a whole nor for singlesubsidiary aspects.However the influence Alexanders work had and still has on other domains

is recognized and appreciated even in architectural context. It may be that hisconcept has been rejected in architecture because it claims exclusive validity, afact that users in other domains simply have neglected to ease adoption. Thelatter is also the reason why most of the criticism in architectural context doesnot effect the application of pattern languages in human-computer interaction.In software engineering, the field within computer science where patternComputer science

languages first gained a broader recognition, the concept has initially beenused for the description of common solutions in object-oriented programming.In 2005 the topic is known so widely that there is even a series of conferences inseveral places of the world, called Pattern languages of programs (PLoP)8 that7Cp. e.g. [Don05]8Other PLoP conferences are called ChiliPLoP, EuroPLoP, KoalaPLoP, MensorePLoP, Sug-arLoafPLoP or VikingPLoP.

24

2.3. State of researchconnectivity & differentiation

is entirely dedicated to finding and improving software engineering patternsand languages. These conferences also provide sporadic points of contact withthe HCI community.The fact that the concept of pattern languages had first been established in

software engineering has influenced the way, computer scientists and HCI peo-ple look at pattern languages: the perception of the pattern language concepthas moved from a user-centered to a developer-centered one. The technically-oriented character and prosaic thinking of those IT practitioners also haveresulted in the loss of some of the more emotive aspects of pattern languages.The intersection of the other described fields with computer science leads to

the fact that many ideas and concepts of the latter are transfered from there.For example, the very technical form of a document type definition (DTD) thatemanates from the SGML/XML area is used by HCI people for the descriptionof a pattern language9although it is very far from both architecture and thenon-technical way, the inventors of the pattern language concept used for theirdescription. Another example may be the unified modeling language (UML)which is paired with patterns in A UML pattern language [Evi00].


With the exception of the World Wide Web part of the Internet, all fieldsthat surround the focus topics of this thesis have existed for several decades.Therefore, a lot of knowledge in those areas has been gathered, may it bein research or practically oriented context. This thesis is based on some ofthis previous work to that it is meaningful to connect to but also needs todistinguish from some of its antecessors.The domain to which the connection of this work may be considered the Publications in HCI

most intense is pattern languages in human-computer interaction. In this fieldthere have been many scientific publications in the last five years from the year2000 to 2005.10 The types of texts published in this area have followed a clearpath: they first explained the preliminary unknown concept of the patternlanguage and at the same time considered its general applicability for HCIpurposes. After this question was answered positively, actual pattern languagesand their usage were extensively covered, followed by research on the questionhow pattern languages could be managed, structured and optimized. The lattertopic lead to the first serious review process, which criticized the existing HCIpattern languages that were supposed to be most relevant and have been citedthe most. This review phase is considered to be the most recent developmentby the author. To recapitulate: using, structuring, optimizing and discussingpattern languages have been described in detail.

9See 3.2.3 on page 3810A detailed history of the concept of pattern languages in HCI is outlined in section 3.1.2

on page 33.

25

2. Research context

Surprisingly along the described path the actual creation of a pattern lan-Creation not coveredguage has only been examined very marginally. Although pattern languageshad emerged and even the procedure of writing single patterns had been de-scribed and discussed there seems no text available that has covered the processof creating such a language. This work, which is aimed at the creation of anactual pattern language, may thus rely on a sound background regarding someimportant aspects of pattern language usage but cannot fall back on previouslygathered knowledge regarding their construction. It has thus been necessaryto develop an original research approach, which is described in section 5.In the wider realm of (non-pattern) human-computer interaction, the knowl-

edge that may be relied on is more broad, more mature and more complete,because the whole field first is older and second relies on other even older dis-ciplines like psychology. From all the findings of this area, the relevant andsuitable ones have thus been picked and used for this thesis.In the process of creating a single pattern, existing HCI findings support all

stages of the process: the division of the actual kernel of the pattern is outlinedby requirement definition methods and supported by tacit knowledge that ananalyst has gathered against the background of his HCI experience. For theactual process of conceptual design of the user interface, guidelines as well asdesign methods are at hand and models for the cognitive processes involvedare available. Regarding the description of the achieved solution, verbal andvisual methods are also accessible. When it comes to testing and optimizinga developed pattern, sophisticated but simple test methods can be used. Anoverview of design stages and examples for the respective methods available isgiven in table 2.1 on the facing page.Apart from the single methods there also exist approaches that span several

stages of the pattern creation process. Participatory design, which extensivelyconsiders and integrates the end-users and their demands during requirement,design and implementation phases and even tests whether they were met af-terwards, may be mentioned as an example.Two topics in the HCI-related discipline psychology also are of high interestPsychology

for this thesis: the cognitive processes that A influence the interaction with theapplications interfaces, created byf the pattern language of this work; and Bthose, which influence the processing of the information presented within theapplication.The findings of psychology in the field of the cognitive capabilities and limita-

tions of humans regarding the interaction with a computer interfaceor morespecifically a business intelligence applicationhave already found its way intoHCI. For example, many of the heuristics or rules of thumb that exist for ef-fective interaction design are ultimately psychological findingsmay they be aresult of scientific psychological experiments or more pragmatic usability tests.It is thus needless to consider them in a psychological context and translatethem to HCI.Although this interface interaction includes some degree of human informa-Semantic information

processing

26


Pattern creation stage Exemplary HCI methods availableRequirement definition

Hierarchical task analysis (HTA), e.g. de-scribed in [PRS02]

Volere requirements specification template(on an application level) [Atl04]

Personas for the modeling of users, e.g.[CR03]

Conceptual design

Usability & interaction guidelines, e.g.[Nie99]

Pen & paper storyboards, e.g. [PRS02] Wire frames representing applicationscreens/pages (design phase)

Solution description

Use cases for a transactional view, e.g.[Jac04]

Scenarios for a behavioral view, e.g. [CR03] Wire frames representing applicationscreens/pages (documentation phase)

Testing & optimizing

Application prototypes Usability testing, e.g. [Rub94]

Table 2.1.: Stages of pattern creation and respective HCI exemplary methods

27

2. Research context

tion processing, the latter needs to be examined in further detail: while forexample the simple question of the maximum number of items, a user is cog-nitively capable to choose from, can be answered with HCI guidelines, no suchheuristic is available for the semantic layout of a spreadsheet report showingprofit numbers. These more complex issues address the information processingregarding the semantics of the displayed information. In this area, so-calledcognitive biases that have been found in psychological research may impactthe perception of the actual information. Those biases often are the result ofpsychological heuristics humans use instead of judging exactly. An exampleof such bias within rational choice theory is framing11, which states that thepresentation (frame) of an information may influence its perception. In par-ticular cases, different framings actually lead to diametrical decisions. Otherpsychological heuristics have similar outcomes. The reasons, as well as theeffect of those heuristics and the possibly resulting cognitive biases are welldocumented.When transferring these psychological outcomes to this work, it first and

foremost is important to avoid these effects to the maximum possible degree.This is the case as BI applications need to provide neutral information in aneutral presentation frame, as only those provide an optimal basis for theconclusions a human user may draw. Nevertheless the need to avoid thoseeffects imperatively requires awareness of their existence.In the non HCI-connected remainder of the business intelligence areaasBusiness intelligence

noted beforeless research has been conducted in a scientific surrounding. Thisresults in the knowledge being generally less publicly documented and beingmore industry-driven: BI know-how can mostly be found in white papers,case studies and professional articles naturally including marketing-orientedparts which need to be cross-checked thoroughly but also hands-on experiencethat science can hardly offer. Furthermore, practitioners books are available,which cover theneed, the purpose and the realization of business intelligence incorporate environments.Fortunately, no more findings from science regarding BI are required for this

thesis than those on human information processing. What is needed beyondis a general understanding of business intelligence applications in terms of atypical and comprehensive overview of its capabilities, functions and currentcharacters, as these build the basis for the design of human interaction, whichagain is the core of this research. The educt of this information is availablefrom the BI industry; its distillate is devised in chapter 4 on page 49.For the description of actual interaction patterns, abstracted samples of BI

information as well as contemporary interaction principles are helpful. In thisarea the author of this work can revert to his experience with the conceptualdesign of a BI application, which is based on the products of a prominent BI

11Cp. e.g. [BBF98], which refers to the original approach and then duplicates its framingresulting in almost neutral outcomes.

28


software solutions manufacturer.As outlined in section 2.2 on page 21, a connection of this thesis with the Architecture

field of architecture outside of pattern languages is not imperative. The studyof the pattern language sub area12, which can be treated without its archi-tectural context, is sufficient. Regarding the connectivity to the architecturalpattern languages, extensive research that can be reverted to has already beenconducted in the field of HCI.

12including the feedback the concept has received from architecture

29

2. Research context

30

3. Pattern languages forhuman-computer interaction

Contents

3.1. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.2. History . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2. Concept of a pattern language . . . . . . . . . . . . 35

3.2.1. Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2. Language aspect . . . . . . . . . . . . . . . . . . . . 36

3.2.3. Formalization . . . . . . . . . . . . . . . . . . . . . . 37

3.3. Language structures . . . . . . . . . . . . . . . . . . . 41

3.3.1. Patterns agglomeration types . . . . . . . . . . . . . 41

3.3.2. Structures . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4. Enhancements . . . . . . . . . . . . . . . . . . . . . . 45

3.4.1. Pattern optimization . . . . . . . . . . . . . . . . . . 45

3.4.2. Language optimization . . . . . . . . . . . . . . . . . 45

3.5. Using pattern languages in human-computer inter-action . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 46

3.5.2. Special potential . . . . . . . . . . . . . . . . . . . . 48

3.1. Basics

3.1.1. Definitions

The description of pattern languages in section 1.1.1which is meant as a quickintroductiongave a very brief idea of the concept: pattern languages are ag-glomerations of patterns, which in turn are solution descriptions. A refinementof this short presentation first needs to consider the patterns separately andthen the languages, in which they are collocated.The inventors of pattern languages and therefore of the pattern Alexander Pattern definition

et al. define a pattern as follows:

31

3. Pattern languages for human-computer interaction

Each pattern describes a problem which occurs over and over againin our environment, and then describes the core of the solution tothat problem, in such a way that you can use this solution a milliontimes over [. . . ]. [AIS77, p.x ]

This definition focuses on the recurring occurrence of a problem and itssolution and is not restricted to the field of architecture, for which Alexanderet al. have developed the concept. At the time of creation, the authors alreadyLanguage definitionthought of a pattern as an integral part of a wider framework: the patternlanguage. Descriptions of the language concept can be found in several worksof the architects1. A significant definition is the following:

We know that it [the pattern language] is a finite system of ruleswhich a person can use to generate an infinite variety of differentbuildingsall members of a familyand that the use of languagewill allow the people of a village or a town to generate exactlythat balance of uniformity and variety which brings a place to life.[Ale79, p.191]

As this definition descends from an architectural context, it needs to beadapted to gain general validity. This generalization results in the followingderived definition:

A pattern language is a finite system of patterns (as stated be-fore) which may be used to generate an infinite variety of differentapplicationsof the same domainand whose use will allow theapplications designers and users to generate a balance of unifor-mity and variety, which makes the application a good one.

To avoid misinterpretation it is important to differentiate the meaning of thenotion language in natural or programming languages from the one in patternlanguage. As stated by the definition above it should be seen as a systemthatfor reasons given in the followingis given the name of a language.The given definitions were diversified by various authors that adopted theHCI pattern language

definition concept for their purposes and domains. In human-computer-interaction, par-ticipants of the CHI meets PLOP: an interaction patterns workshop acquiredthe following:

An Interaction Pattern Language generates space/time interac-tion designs that create a system image close to the users mentalmodel of the task at hand, to make the human-computer interfaceas transparent as possible. [Bor00a, p.10]

1Cp. [ASA+75], [AIS77], [Ale79]

32

3.1. Basics

While the workshop attendees considered this to be a definition, the authorof this thesis disagrees in that matter, because the text defines what a patternlanguage does and which goals it should achieve in spite of defining what itactually is.2 Though generalized, the aforementioned definition derived fromAlexanders is still more precise even for the field of HCI. This thesis will thusrefrain from using this HCI-based definition and rely on the one generalizedfrom Alexanders work.

3.1.2. History

The concept of a pattern language (and the associated concept of a single pat- Origin in architecturetern) was introduced by the architects Christopher Alexander, Sara Ishikawaand Murray Silverstein in the year of 1977 for their book A pattern language:towns, buildings, construction. This book is the second of a series of threebooks, the first The timeless way of building [Ale79] being a theoretical intro-duction to pattern languages and the last The Oregon experiment [ASA+75] adescription of a real-life implementation of the theory.The work deals with the design of architecture in a citys context and gives

hands-on support on various levels of architectural considerations: as indicatedby the books title, they range from a town level down to buildings (and evenrooms or room parts) and also handle the construction part. To give an ex-ample, the book illustrates that a neighborhood needs to be able to establishan identity [AIS77, p.80] as well as it describes why every balcony needs aminimum depth of six feet [AIS77, p.781] or states how a pillar supports thestatics of a construction.The first computer-related discipline that has adopted the pattern language Computer science

adopts patternlanguages

idea was interface design. Ten years after the publication of Alexanders firstbook in 1987, Ward Cunningham and Kent Beck made an attempt to use thepattern language idea in a consulting job to design a user interface. Theywere quite surprised of their success and presented the case in a workshopon the ACM conference on object-oriented programming, systems, languagesand applications (OOPSLA) in 1987. In the following years till 1991, thepattern idea has matured in the heads of many software architecture orientedconference attendees, including Erich Gamma and Richard Helm. Then in1991, both started to compile design patterns into a collection. The same First software

engineering publicationyear at the European conference on object-oriented programming (ECOOP),they met with Ralph Johnson and John Vlissides, with whom they publishedthe renowned book Design patterns in 1995 [GHJV95]. While other authorspublished pattern-oriented books at about the same time3, this publicationconstituted the pattern idea in computer science all over the world.

2This remains true even with Borchers more detailed explanation of the definition in hislater work, [Bor01, p.38]

3To name just one: Frank Buschmann et al. with Pattern-oriented software architecture[BMR+96].

33


Some other attendees of the the ECOOP met in 1993 on the side of a hillto use patterns in a generative way in the sense that Christopher Alexanderuses patterns for urban planning and building architecture [Por05]. TheyFoundation of Hillside

Group founded the non-profit Hillside Group, which today is the unofficial steeringcommittee for software patterns and provides a lot of information on patternsat its website [Hil05].Although the first usage of patterns (in computer science) was in interaction

design, the concept did not receive broader attention in this domain until theconference on human factors in computing systems (CHI97) in 1997. There, aA pattern language for

interaction design workshop called Putting it all together: towards a pattern language for inter-action design [BBC+98] faced the challenge that human-computer interactionprojects had experienced a distinct increase in complexity and diversity. Theworkshop identified the concept of a pattern language to be a possible solu-tion and discussed a broad variety of application ideas, from creating patternsthat represent HCI guidelines to using the original architectural patterns forcyberspace design. As the workshop attendees felt that they were at the verybeginning of the enterprise of understanding the role and utility of patternlanguages for interaction design [BBC+98], the outcomes are not more thanan overview of the potentialities.In the following years until the turn of the millennium the pattern languageHigh conference

attention topic was widely discussed at conference workshops4 and was pushed forwardby a couple of its protagonists. In the year 2000, Jan O. Borchers moderateda CHI meets PLOP: an interaction patterns workshop which compiled a firstimperfect definition of an interaction pattern language [Bor00a]. He has alsodescribed an actual pattern language, he had used for an interactive musicexhibit in A pattern language for interaction design [Bor00b]. One year later,a panel of six key players in the emerging field of HCI design patterns [BT01,S.225] collectively stated its interest in HCI patterns (and languages) but madeclear that they would apply differing focuses.At the CHI02 a one-day workshop organized by Martijn van Welie, Kevin

Mullet and Paul McInerney was dedicated to the patterns topic and provided aforum for sharing experiences using and writing HCI patterns [WMM02]. Itsoutcomes are very practically oriented and reflect that the concept had foundits application in non-scientific projects. This is also visible from some of theposition papers, the attendees have provided [Wel01].Also in 2002, Ian Graham put the knowledge he had been gathering overHands-on publications

two decades of consulting into the book A pattern language for web usability[Gra03], which holds 79 patterns. After the turn of the year The design ofsites was published by Douglas van Duyne, James Landay and Jason Hong[DLH02b], for which the authors had analyzed 100 of the highest qualityWeb sites and compiled the results into patterns, principles and processesfor crafting a customer-centered web experience [DLH02a]. Both books were

4e.g. UPA99, INTERACT 99, ChiliPlop 99

34

3.2. Concept of a pattern language

published in and for a primarily non-scientific environment and have thus re-ceived controversial reviews.In Pattern languages in interaction design: structure and organization [WV03], Meta topics discussed

which was published at the Interact conference 2003, the authors Martijn vanWelie and Gerrit van der Veer have answered the need for an enhanced naviga-tion through pattern languages: they have created a general language structureby transferring Alexanders scale of architectural geometry to one of problemsand came up with a taxonomy of four different pattern types. As this paperdeals with the meta content of organizing pattern languages and not with usingor creating them, it may be seen as an indicator that the actual concept hadarrived and settled in HCI.In 2004 E. Todd, E. Kemp and C. Philips of the Institute of information

sciences & technology New Zealand asked What makes a good user interfacepattern language? and scrutinized the quality of some of the publicly availablepattern languages [TKP04]. They summarize their analysis as none of thecollections5 can be described as mature. The same year several other authorsadapted the pattern languages concept to their domain of interest (in- andoutside of HCI) and have also cross-checked the recent work with the originalconcept.At mid-year 2005 when this research was started one can truly say that

the concept of a pattern language has found its way into the human-computerinteraction domain. Nevertheless actual pattern languages are rare as seemsto be their hands-on use.


3.2.1. Patterns

As already stated, patterns are written descriptions of solutions to problemsthat occur frequently and may be solved in a generalized way. While inventedfor the use in architecture, the concept itself is not domain-specific and may beapplied in other domains as well. The concept of a sole pattern is no rocket-science but a very straightforward approach to documenting know-how.What differentiates patterns from other solution documentations is that they Patterns consider

contextextensively consider the context of the problem, may it be the so called forcesthat influence the problem itself or the detailed discussion of the problem so-lution, which describes the field of physical and social relationships which arerequired to solve the stated problem[. . . ] [AIS77, p.xi]. Apart from that, pat-terns in its original form do not provide a ready-to-use solution that just needsto be inserted as a complete component, but support the pattern user with theadaption of the solution to the current application situation.Despite this very simple approach, patterns present a potential that exceeds Concept potential

5[namely van Welies GUI [Welb], WEB and e-commerce collection [Wela] as well as

35


those of other proprietary documentation forms. Their speaking names allowusers to refer to complex circumstances which just a few words: whenever aproblem occurs, whose solution has found its way into a pattern, just quotingits name is sufficient to make clear to everyone what approach to the problemssolution should be taken. Patterns are also generative in a way that reading andreflecting them actively supports the process of solution creation. Moreoverthey assure the integrity of an application6, as all people working on theircreation can rely on the common basis of the used patterns.Patterns decrease the applications development time as they supersede the

need to design them from scratch: they provide a solid foundation that can bebuilt on. At the same time, they increase the results quality, as contemplatingthe patterns integrates the know-how comprehended within them. Regardingthe documentation of the design process, patterns back up personally-boundknowledge to be ensured7 and also provide a quick and easy way to describe apursued solution.

3.2.2. Language aspect

The potential of patterns strongly increases whenever they are used in a patternPatterns in contextlanguage context. At first sight languages are collections or agglomerations ofpatterns. At closer inspection they are much more: languages emerge withthe relations between the patterns contained herein. As an example for sucha relation, two patterns may be alternative solutions, so the relation is con-trariness or one may be a more general solution that is refined with an other,which represents a hierarchical relation.The relations between patterns fundamentally change the way these patternsLanguages guide their

users are used, increasing the generative character of the whole concept. Startingfrom a single pattern, other related patterns may be considered which againrelate to other patterns. If during an application design process a languageuser follows this guided path through the language they consider various prob-lems and their solutions. During this process the application is progressivelyformed based on the know-how contained in the language, which is appliedwith the situational background of the user. A good language thus activelyguides through the process of application design.One part of the structured form of a language arises from a simple agglom-

eration of patterns, due to a sort of force from the relations within; anotherpart of it needs to be added on purpose by the language creator. Collocatedin such a structure, the patterns form an entity whose whole is more than itsparts: the language.The reason why this entity is called a language lies in an analogy AlexanderDenomination

language has made in The timeless way of building [Ale79]. Starting from mathematical

Borchers HCI collection [Bor01]]6not only in the sense of a software program7diminishing the so-called truck factor

36


languages that consist of language symbols and rules to combine these symbols,he looks at natural languages to find that words represent the symbols andgrammar their combination rules. Beyond that, natural languages include ameaning, which defines which of the possible permutations are making sense.In a pattern language the patterns represent the symbols as well as the rules.The latter are fragmented in the hierarchical structure the patterns define, thesolution approach the patterns represent and in the way the relations need tobe combined. Alexander thus considers pattern languages to be more complexthan natural ones [Ale79, p.185]. An overview of a direct comparison betweennatural and pattern language is given in table 3.1.

Natural language Pattern languageWords PatternsRules of grammar and meaningwhich give connections

Patterns which specify connectionsbetween patterns

Sentences Buildings and places [resp. the ap-plications of the pattern]

Table 3.1.: Comparison between natural and pattern languages [Ale79, p.187]

Alexander however denominates his language as a system, too, which it by Denomination systemdefinition8 is. Other authors, e.g. Frank Buschmann et al. [BMR+96], preferthe system denomination, as one can find discrepancies in the comparison ofpatterns and natural languages. While calling the collection a system may bemore exact regarding these discrepancies this in turn lacks some importantaspects from the language comparison.

3.2.3. Formalization

With the creation of the architectural pattern language, Alexander et al. have Original patternformatalso provided a format for the patterns in their language. The format consist

of several typographically separated sections, which themselves are stylisticallyprose.

Pattern name The name provides a common identifier for the pattern, whichmay be used in personal or formal communication. After the name one,two or three asterisks describe the quality ranking of the pattern by theauthors (more asterisks meaning better quality).

Picture The picture provides an archetypal example of a patterns implemen-tation. In practice it usually allows for a one-look comprehension of thepatterns essence.

8System: a regularly interacting or interdependent group of items forming a unified whole.[MW05]

37


Superordinate context This introduction describes how the current pattern isused by larger patterns, allowing the reader to understand in which largerpattern-context it may be used.

Problem The problem part starts with a short description of the problemsessence and then goes into detail on the empirical background of thepattern and its evidence for validity.

Solution The solution points out a short instruction on what to do to solvethe problem (within the given context).

Subordinate context This paragraph describes which subordinate patterns maybe used to implement the current patterns context and where a usershould go further in their process of design.

The first pattern users in computer science have adapted this formalizationAdaptationsto their needs. Gamma et al. identified only four essential elements, name,problem, solution and consequences, however, they segment and enhance thesewith more sections. This results in 13 pattern elements including e.g. a graph-ical representation of the software classes or sample source code that may beadapted.9 The segmentation of the pattern description is however to a lesserextend a conceptual enhancement than an approach to structure the informa-tion according to the domains needs.Pattern creators in the human-computer interaction domain have writtenHuman-computer

interaction their patterns in various formats of which Sally Fincher has compiled the web-site The pattern gallery [Fin00]. The different formats mainly follow subjectivepreferences of their users and are thus not described in this work. At a work-shop at the CHI 2003, which covered concepts and tools for patterns and itslanguages leaders and participants (including renowned pattern communitymembers) recognized the drawbacks of this diversity and compiled a patternlanguage markup language specification (PLML) including a document typedefinition (DTD)10. The actual DTD may be found in the appendix A.1 onpage 147. The condensed sections of this HCI pattern (language) definition[Fin03] are the following:

Pattern name, aliases and ID The name is used as a common qualifier. Aliasesare included whenever there are several names. The ID is a unique iden-tifier within a single collection.

Illustration An illustration shows an actual real-life use of the pattern. It isnot limited to a static illustration but may also consist of multimedia.

9Cp. [GHJV95, p.3, 6-7]10A Document Type Definition (DTD) is a specific document defining and constraining

definition or set of statements that follow the rules of the Standard Generalized MarkupLanguage (SGML) or of the Extensible Markup Language (XML), a subset of SGML.[. . . ] [sea04]

38


Problem This part describes the actual problem, which is the reason for thepatterns existence.

Context This describes the context in which the pattern may and should beused. It is also reflects its applicability.

Forces This part refers to the compulsions that exist in the environment of theproblem.

Solution The solution delineatesphrased as an instructionwhat needs tobe considered and enforced to solve the problem.

Synopsis This part acts as a summary of the whole pattern, which may beused whenever the whole pattern is too voluminous.

Diagram The diagram outlines the pattern in a graphical, schematic form.

Evidence: example & rationale In the evidence section, known uses of thepattern may be included as examples as well as a rationale on the char-acter of the pattern.

Confidence This section takes up the original star rating by Alexander (seeabove).

Literature References to literature that should be considered in the contextare stated in this part.

Implementation This section holds actual implementation code or fragmentsthereof whenever this is feasible.

Related patterns Patterns within the language that may be used with thecurrent one, are linked to in this part. The relation itself may be one ofthe three following types: an is-a-relation, an is-contained-by-relation ora contains-relation

Author, credits, version and changes This part states authorship, creationdate as well as change management.

To allow for an overview of a whole pattern language, Gamma et al. have Visual representationsintroduced a visual representation of their pattern collection in Design patterns[GHJV95]. It seems to be strongly influenced by software engineering classdiagrams and consists of rectangles representing the patterns as well as directedlines (actually curves with arrows) that represent the relations. An example ofsuch a visualization is given in figure 3.1 on the next page.This visualization has a mathematical equivalent, the directed graph. First Mathematical

definitionused by Borchers in a paper [Bor00b], he refined the definition for his book Apattern approach to interaction design [Bor01]:

39


Entry form Selection menu

Interaction style

Conversational text

Rewarding soundsExplorable interface

Warning sounds

Multiple settings

Cooperating windows

Garden of windows

Zen garden Rich garden

Organized desktop

Single setting

Command control center

Goal oriented areas

Modeless feedback area

Toolbar

Palette

Menubar

Launchpad

Dialog box Clickable symbols

Symbol explanations

Visual symbols

Context sensitive help

Figure 3.1.: Visual representation of the Experiences pattern language [CL96]

40

3.3. Language structures

1. A pattern language is a directed acyclic graph PL = (,R) with nodes = {P1, . . . , Pn} and edges R = {R1, . . . , Rm}.

2. Each node P represents a pattern.3. For two nodes P,Q , we say that P references Q if and only if there

is a directed edge Rx R leading from P to Q.4. The set of edges pointing away from a node P is called its references,

and the set of edges pointing to it is called its context.

5. Each node P is itself a set P = {n, r, i, p, f1 . . . fi, e1 . . . ej , s, d} of aname n, ranking r, illustration i, problem p with forces f1 . . . fi, examplese1 . . . ej , the solution s, and diagram d.

While this definition is considered irrelevant for practical language use bythe author, it may serve as a basis for a programmed language representation.


3.3.1. Patterns agglomeration types

When looking at an agglomeration of patterns it is important to differentiate Collectionsbetween collections and languages as their intended use is usually different.Collections serve as a sort of container of different patterns (normally of anamed domain) that are used in a more reference-oriented manner: A useridentifies a single problem and looks up its solution in the collection. In somecases the found pattern may also refer to another pattern that suits the usersproblem context.A pattern language in contrast should be seen and used as a whole. A Languages

user initiates the process of designing an application and decides to use asuitable pattern language. Obeying the language introduction they start witha more general pattern and work their way through its relations considering anoticeable number of patterns, creating a remarkable part of the applicationsdesign.The delineation of collections from languages in practice is an ambitious task. Continuous degree of

qualityThe visualization of a language may serve as a first indicator: the more relationsexist between patterns and the more hierarchical those are, the more language-like is an agglomeration. In language use, the degree of interconnectedness ofpatterns is directly contingent on the degree a language is generative. Judgingthe latter by only consulting the written patterns (without using them) isconsidered incomplete by the author. The quality of a language, which ismeasured by the degree of its generativeness, needs to be experienced in real-life use and results in continuous rating, not an is or is not a language decision.It is however way easier to classify some agglomerations as collections, e.g.if they do not provide relations at all. Regarding actual pattern languages,

41


scientists and users often discuss controversially whether they would better becalled collections.An overview of indicators that delineate collections from languages is given

in table 3.2. For the sake of completeness, attributes that may be assigned toboth types are also listed.

Collections Languages BothRelations of patternsare not present ofstated

Patterns are hierarchi-cally collocated

Patterns emanate aparticular domain

Relations do not guidea reader/user throughthe system

Reading/using the sys-tem is highly generative

The systems domain isstated and defined

Table 3.2.: Delineation indicators for languages and collections

As already stated in 3.2.2, some authors prefer to call their patterns agglom-erations systems, because they prefer an uncommitted term to evade discussion.This however hinders a clear typing and naming.

3.3.2. Structures

Appending to the physical format of patterns and languages is an intrinsicIntrinsic logicalstructure logical structure that can follow different approaches. In Alexanders original

work, this logical structure is less obvious than the physical format of thepatterns. Being collocated in a book, the consecutive order determines most ofthe format. The intrinsic structure lies within the order in the book: Alexanderet al. have structured the patterns according to their scaleas the bookssubtitle Towns buildings construction indicates. Thus, the physical formatof a language is weak but its virtual structure, which is created by the patternsrelations, can be a lot stronger. This is particularly true for the original patternlanguage as Alexander considers every pattern to have a superordinate contextas well as a subordinate context. This results in every pattern implementingbigger ones as well as being implemented by smaller ones. Thus, theresulting structure is hierarchical.Such an intrinsic language structure effectively simplifies the languages us-

age: it allows the user to find a feasible pattern for the initialization of theirapplication design, eases the navigation through the language and empowersa user to more easily grasp the language as a whole. With this motivation au-thors of application domains different from architecture have felt the need forsuch a structure, too. As the original taxonomy of scale is architecture-specific,differing ones are needed for other domains.In the first published reflections on language structure for human-computerHCI-suitable structure

interaction, Pattern languages in interaction design: structure and organizationby Martijn van Welie and Gerrit C. van der Veer, the authors are following the

42


approach to adopt Alexanders taxonomy of geometry scale to one of problemscale. They state that In Interaction Design there is certainly a scale hier-archy of problems [WV03, p.2-3], as interaction designers begin with gainingbroader insights into the projects general background and end with solvingproblems of individual graphical user interface elements. Following this ap-proach, Welie and van der Veer have come up with different types of patterns,determining four classification types:

Posture type Patterns of this domain describe the general purposes of an ap-plication that are (or will be) realized with it. To provide an exampleapattern may describe the overall approach of e-commerce or personalwebsites.

Experience patterns Classified into the experience type group are patternsthat consider the realization of user goals, e.g. shopping or social contact.

Task patterns Patterns of the task type describe solutions of tangible problemsa user experiences, for example collecting several products in a shoppingbasket.

Action patterns Action type patterns represent solutions that are mostly in-stantiated directly in interaction elements, such as submit order.

This typing or classification of patterns has an immanent direction: designingan application starts with creating (or deducing) a posture, then defining theexperiences, breaking them down to tasks and actions. The top-down approachis best observable in a visualization Welie and van der Veer provide for anOnline shopping centered pattern language. It is reproduced in figure 3.2 onthe next page.The presented concept allows a classification of practically all patterns of Other structures

feasiblepurpose-oriented11 applications but is only one possible solution. This hasbeen identified by the authors themselves and they suggest other classificationsfor example by function, similarity of problem, usability problem or task andexperience from a users perspectivewithout specifying them in detail.The most interesting result of these considerations is that the authors found Differing views on a

languagethat for practical use several kinds of patterns classifications may turn outto be useful [WV03, p.7]. This is why Welie and van der Veer have comeup with the idea of having different views (incorporating the classifications)on an actual pattern language. This idea can be understood as using actualpattern attributes and/or meta properties to create several views of intersectionfree selections. One of this specific suitable views may then be chosen for aparticular purpose. To implement the accessibility of such views, support e.g.by a database-driven software tool is needed. At the time of writing, this seemsnot to be available.11A pattern language with an arty approach for example does not fit into the pattern types.

43


Actionlevel

Tasklevel

Experiencelevel

Paging

Stepping

Sorting

Searching

Shopping cart

Wizard

Good defaults Choices Exit

List builder

Shopping

Teaser menu

Whats new

Informing

Breadcrumbs

Identify

My site

Login

Business goalsCustomer satisfaction

Selling products

Information providing

Sitemap

Getting overview

E-commerce

Product supportsite

Posturelevel

Small corporatesite

Portal

Homepage3-column layout

Personal site

Locating

Productcomparisons

Action buttons

Theme sitesCommunity site

Progressivefiltering

News site

Templates

Playing

Discovering

News letter

Browsing

Guided tour

Poll Forum

Expressing

Figure 3.2.: A partial pattern language for web design (centered around shop-ping), reproduced from [WV03, fig.2]

44

3.4. Enhancements

3.4. Enhancements

3.4.1. Pattern optimization

Although good patterns capture a true and essential part of their problem- Optimization potentialsolution-context, they are not considered perfect. This implicitly becomes clearwhen looking at the asterisk ranking, Alexander et al. have given their pat-terns.12 The optimization of patterns may concern its amelioration, makingits problem or solution description more precise, it may concern the elimina-tion of actual errors as well as concern enhancement, e.g. with known uses orexamples.Regarding the review of single patterns, so-called writers workshops have Procedure: writers

workshopbeen established in the pattern community13. They provide a structured pro-cedure allowing for the optimization of patterns based on the input of othercommunity members. Several reviewers, the authors as well as a moderatorwho coordinates discussion are present during such a workshop. All partici-pants have read and reflected on the content of the patterns description priorto the workshop. The decisive phases of such workshop are:

Reading The author of the pattern reads a part of the patterns description,they consider essential, to the participants.

Summary Two reviewers summarize the description of the whole pattern fromtheir perspective.

Discussion Participants then discuss advantages, disadvantages and finally allother remarks and suggestions regarding the pattern. The author doesnot attend this part and is not addressed directly.

Questions The author may consult the reviewers, to ensure correct under-standing of the reviewers points and ends the workshop with a conclud-ing comment.

These kinds of workshops are in use for the optimization of patterns fromvarious domains, including software engineering as well as human-computerinteraction and are e.g. held at the Pattern languages of programs (PLoP) aswell as at the Conferences on human factors in computing systems (CHI).

3.4.2. Language optimization

Because the quality of a pattern language is highly dependent on the associated Optimize patterns incontextpatterns the optimization of pattern languages directly builds on the optimiza-

tion of single patterns. The latter need to be subjected to ongoing testing12Cp. 3.2.3 on page 3713The procedure has been inferred from poetry and isaccording to [Gra03, p.21]attributed

to Richard Gabriel, a member of the Hillside Group.

45


for their significance. If they do not fit into the overall concept any more orwhen the general framework has changed, they have to be removed from thelanguage. Synchronously, new patterns need to be identified, documented andintegrated into the language, whenever this becomes appropriate. A patternlanguage thus can be a very dynamic construction.In case patterns are removed or added the structure of the pattern language

needs to be altered as a whole, because patterns do stand isolated. For example,the relations of all patterns and the one that is to be removed, need to bechecked14. Likewise, language introductions need to be revised and overviewsneed to be adopted. The most important adjustment however is checking,whether the generative character of the language is still intact or needs to berestored.A method for the optimization of pattern languages cannot be spotted in lit-No method present

erature at the time of research in 2005. The significantly increased complexityof languages in comparison to single patterns anyway conflicts such a method.It is however probable that at least a procedure for the optimization will bedeveloped by the community starting from the writers workshop concept. It isapparent that currently most language optimizations will be done in a practi-cally oriented environment, probably even while the language is in use to makeit suitable for modified project conditions.

3.5. Using pattern languages in human-computerinteraction

3.5.1. Applicability

As the sections above have already made clear, pattern languages are usedwithin the human-computer interaction domain15. This suggests that the con-cept is in general applicable for this area. Nevertheless to ensure a completeconsideration and allow for a better understanding of possible constraints it ismeaningful to check the basis of applicability.As a first indicator for the applicability of pattern languages in the human-Problem are similar

computer interaction domain, problems need to occur in similar forms. This isnecessary so that generalized solutions will be feasible. In HCI this situation isgiven, as the interface between humans and machines consistently causes thesame problems. The technical interface of keyboard and mouse may act as anexample as well as navigation through content presented within a website.As a second step similar solutions for those problems whose character allowsSolutions may be

abstracted the abstraction of the solutions need to exist. This abstrac

a pattern language for the interaction with web-based business intelligence applications

Documents

pattern language contrivance

pattern languages

pattern design

pattern optimization

language optimization

research design

pattern language151

language aspect363