Issuu on Google+

Felix Kaiser

A pattern language for the interaction with web-based

business intelligence applications

A master of science thesis in computer science in media Department of digital media Furtwangen University of Applied Sciences, Germany


Contents at a glance

Preface

9

Acknowledgments

11

I.

13

Research design

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.

13

Research design

1. Basics 1.1. Definition of terms . . . . . . . . . . 1.1.1. Pattern language . . . . . . . 1.1.2. Business intelligence . . . . . 1.1.3. Web-based applications . . . 1.1.4. Human-computer interaction 1.2. Introduction . . . . . . . . . . . . . . 1.2.1. Problem statement . . . . . . 1.2.2. Research question . . . . . . 1.3. Significance . . . . . . . . . . . . . . 1.4. Research objectives . . . . . . . . . . 1.5. Research focus . . . . . . . . . . . . 1.6. Assumptions and premises . . . . . .

. . . . . . . . . . . .

15 15 15 16 16 16 17 17 18 18 19 19 20

2. Research context 2.1. Direct research context . . . . . . . . . . . . . . . . . . . . . . . 2.2. Scientific surroundings . . . . . . . . . . . . . . . . . . . . . . . 2.3. State of research—connectivity & differentiation . . . . . . . .

21 21 21 25

3. Pattern languages for human-computer interaction 3.1. Basics . . . . . . . . . . . . . . . . . . . . . . . 3.1.1. Definitions . . . . . . . . . . . . . . . . 3.1.2. History . . . . . . . . . . . . . . . . . . 3.2. Concept of a pattern language . . . . . . . . . . 3.2.1. Patterns . . . . . . . . . . . . . . . . . . 3.2.2. Language aspect . . . . . . . . . . . . . 3.2.3. Formalization . . . . . . . . . . . . . . . 3.3. Language structures . . . . . . . . . . . . . . . 3.3.1. Patterns agglomeration types . . . . . .

31 31 31 33 35 35 36 37 41 41

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

5


Contents in detail 3.3.2. Structures . . . . . . . . . . . . . . . . . . . . . . 3.4. Enhancements . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Pattern optimization . . . . . . . . . . . . . . . . 3.4.2. Language optimization . . . . . . . . . . . . . . . 3.5. Using pattern languages in human-computer interaction 3.5.1. Applicability . . . . . . . . . . . . . . . . . . . . 3.5.2. Special potential . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

42 45 45 45 46 46 48

4. Business intelligence and its interactions 4.1. The core of business intelligence . . . . . . . . . . . . . . 4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 4.1.2. History . . . . . . . . . . . . . . . . . . . . . . . 4.1.3. The business intelligence concept . . . . . . . . . 4.1.4. Business intelligence applications . . . . . . . . . 4.2. Interacting with business intelligence applications . . . . 4.2.1. Interaction contexts & elicitors . . . . . . . . . . 4.2.2. Typical and comprehensive business intelligence .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

49 49 49 51 53 54 57 57 59

5. Research approach 5.1. Introduction . . . . . . . . . . . . . . 5.2. Methods . . . . . . . . . . . . . . . . 5.2.1. Pattern design . . . . . . . . 5.2.2. Pattern language contrivance 5.3. Practical procedure . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

65 65 65 65 66 68

6. Conclusion 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Further research . . . . . . . . . . . . . . . . . . . . . . . . . .

71 71 71 73

II. The pattern language

75

7. Basics 7.1. Introduction . . . . . . . 7.2. Language structure . . . 7.3. Using the language . . . 7.4. Language substantiation

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

77 77 78 80 81

8. Conceiving information architecture 8.1. Structuring contents . . . . . . 8.1.1. Sign-in page . . . . . . . 8.1.2. Information architecture 8.1.3. User home . . . . . . . . 8.1.4. User salutation . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

83 84 84 84 87 87

6

. . . .

. . . .

. . . .


Contents in detail 8.1.5. Index page . . . . . . . . . . 8.1.6. Dashboard . . . . . . . . . . 8.1.7. Meta application component 8.1.8. Glossary . . . . . . . . . . . . 8.1.9. Help manual . . . . . . . . . 8.1.10. Error page . . . . . . . . . . 8.2. Navigating through contents . . . . . 8.2.1. Navigation . . . . . . . . . . 8.2.2. Split navigation . . . . . . . . 8.2.3. Meta navigation . . . . . . . 8.2.4. Searching information . . . . 8.2.5. Content shortcut . . . . . . . 8.2.6. Related information . . . . . 8.2.7. Personal content shortcut . . 8.2.8. What’s new? . . . . . . . . . 8.2.9. Recently viewed pages . . . . 8.2.10. Breadcrumb navigation . . . 8.2.11. Content preview . . . . . . . 8.2.12. User feedback . . . . . . . . . 8.2.13. Progress bar . . . . . . . . . 8.2.14. Processing indicator . . . . . 8.2.15. Accomplishment indicator . .

. . . . . . . . . . . . . . . . . . . . . .

9. Developing content components 9.1. Modeling contents . . . . . . . . . . . 9.1.1. Content component . . . . . . 9.1.2. Graphical content component . 9.1.3. Textual content component . . 9.1.4. Numerical content component . 9.1.5. Graphic legend . . . . . . . . . 9.1.6. Content module . . . . . . . . 9.1.7. Geographical mapping . . . . . 9.1.8. Information explanation . . . . 9.2. Content layout . . . . . . . . . . . . . 9.2.1. Assigning dimensions to axes in 9.2.2. Balance information volume . . 9.2.3. Information in context . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . spreadsheet . . . . . . . . . . . . . .

10.Designing interactions 10.1. Interacting with content . . . . . . . . . . 10.1.1. Customizing displayed information 10.1.2. Remember customizations . . . . . 10.1.3. Reset to defaults . . . . . . . . . . 10.1.4. Feasible default . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

89 89 90 91 92 92 93 93 94 95 95 97 98 98 99 100 101 102 103 103 104 104

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . reports . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

107 107 107 109 110 111 112 113 114 114 115 115 116 117

. . . . .

119 120 120 122 123 123

. . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

7


Contents in detail 10.1.5. Sorting numerical content components 10.1.6. Selecting time ranges . . . . . . . . . . 10.1.7. Selecting measures . . . . . . . . . . . 10.1.8. Drilling & slicing . . . . . . . . . . . . 10.1.9. Selecting an entity from a list . . . . . 10.1.10.Selecting an entity from a hierarchy . 10.1.11.Selecting a graphic type . . . . . . . . 10.1.12.Problem alert . . . . . . . . . . . . . . 10.1.13.Content feedback . . . . . . . . . . . . 10.1.14.Rating content components . . . . . . 10.1.15.Context-sensitive help . . . . . . . . . 10.1.16.Tooltip . . . . . . . . . . . . . . . . . 10.1.17.Meta information . . . . . . . . . . . . 10.1.18.Function explanation . . . . . . . . . . 10.1.19.Export content component . . . . . . 10.1.20.E-mail content . . . . . . . . . . . . . 10.1.21.Print content . . . . . . . . . . . . . . 10.1.22.Export content to application . . . . . 10.2. Interacting with the application . . . . . . . . 10.2.1. Application-wide preference . . . . . . 10.2.2. Support request . . . . . . . . . . . . 10.2.3. Warning message . . . . . . . . . . . . 10.2.4. Transparent communication . . . . . . 10.2.5. Explain user rights . . . . . . . . . . . 10.2.6. Common parlance . . . . . . . . . . .

III. Appendix

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

124 125 126 128 130 130 131 132 133 134 134 135 136 136 137 138 139 139 140 140 140 142 142 143 143

145

A. Miscellaneous 147 A.1. Pattern language markup language (PLML) DTD . . . . . . . 147 A.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 for the interaction with web-based business intelligence applications. Apart from this challenging objective, the author would appreciate if its readership took delight 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, describes—after explaining some basics— the research context, the concept of a pattern language and business intelligence as well as the approach taken by this study. It concludes with a summary and an 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 patterns and then gives some basic instructions for using the language. Finally, it describes the actual patterns themselves that design the interaction with business intelligence applications. The appendix gives some detail on the author’s 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 and completed with the publication of the thesis in March 2006. Contacting the author The author of this thesis, Felix Kaiser, will happily accept feedback on this document. Remarks, questions and criticism may be sent at mail@felixkaiser.com. This thesis’ website can be found at felixkaiser.com/go/bi-patterns. To learn more about Felix’ background consult section E on page 159.

9


Preface

10


Acknowledgments During the process of conducting this research, the author has experienced support 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 pattern language concept • Prof. Dr. Christoph Zydorek, Furtwangen University of Applied Sciences, adviser of this thesis, who has challenged the author with alien perspectives • FCBi Deutschland, the author’s employer, whose flexibility has opened the time-frame for this research and • the author’s team at FCBi, whose tolerance created the freedom to take advantage 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. Patterns in 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 used to generate an infinite variety of different applications—of the same domain—and whose use will allow the application’s designers and users to generate a balance of uniformity and variety, which makes the application a good one.

1.1.2. Business intelligence This thesis delineates the business intelligence concept and business intelligence applications. See section 4.1 on page 49 for a detailed discussion. Business intelligence (as a concept) is the capability of an enterprise as a whole to support its employees in their business-relevant actions by providing data, information, knowledge or wisdom relevant in this context, extracted from business data. To support this concept and provide the means that allow an enterprise (and its employees) to pursue it, business intelligence applications are implemented: Business intelligence applications are software applications, which support its users in pursuing the business intelligence concept. To do so, they gather, analyze and evaluate relevant data and elevate it to information, knowledge or wisdom in interaction with the enterprise user towards the goal of improving the quality of business actions taken by this user.

1.1.3. Web-based applications The term application in the title of this thesis refers to a software program that is employed by users to solve or support solving problems within a given area. 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 (or by 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 from all 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 by Internet technology via a browser.

1.1.4. Human-computer interaction Human-computer interaction (HCI) is a broad scientific and hands-on domain that is concerned with different aspects of the interaction of one or many human users with computers and computer programs. Hewett et al. have defined HCI in 1992 as follows:

16


1.2. Introduction “Human-computer interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding 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 been highly intensified over the last decade. Therefore, a competitive advantage is vital for businesses to retain profitability and ultimately exist in those markets. While many different concepts and instruments exist that provide a foundation or even claim to be the cure to this problem, the idea of business intelligence (BI) has proved to be an efficient way of coping with it.

Competitive advantage is vital

Whenever a business decides to have the concept of business intelligence implemented in its organization and procedures, its pervasion considering its use becomes crucial for the business’ success. Every employee that should but does not follow the business intelligence concept prevents the company from gaining the competitive advantage to its fullest possible degree. In turn, the use of applications, implementing the BI approach, in part directly depends on the usability—or interaction quality—of the software. Of course, other aspects, as e.g. the employees’ BI knowledge, are interfering with the application’s usage, too. The usability however plays a decisive part as its extensive realization is considered as an absolute basic by the users.

BI depends on its usability

It thus may be said that—to a certain degree—the success of business intelligence within a company is contingent upon the interaction quality of its implementation. As BI applications usually deal with a lot of data and consider extensive correlations, 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 to be documented in a publicly available form. On account of this, creating application concepts means creating them from scratch, only using personal experience—if present. This prevents interaction designers from spending their main efforts on the implementation of the BI idea, which could and should be their main focus. Apart from that practically oriented aspects, a method for the devision and creation of a pattern language does not seem to be available. The process of securing know-how in such a language is thus unsettled.

17

Language creation method


1. Basics

1.2.2. Research question

Support of a pattern language

According to the above stated argumentation the leverage of usability of business intelligence applications would provide a vital support to the idea of business intelligence. As shown, the implementation of this usability depends on the quality or know-how of the interaction designers conceiving it. Those in turn lack support for the recurring tasks of application conception. The existence of a pattern language that deals with this context would provide this support. Such a pattern language would • assure and increase the application’s 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 applications.

1.3. Significance Scientific advancement

Hands-on support

Intended audience

This thesis is intended to meaningfully enhance the field of scientific publications concerning pattern languages and the connected research. By creating and using a methodology for the development of a pattern language, this study hopefully enhances the knowledge in this area and enables others to use this as 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 from the respective opposite side. Regarding the hands-on assistance, the outcomes mainly support interaction designers in conceiving business intelligence applications. As argued in section 1.2.1 on the preceding page, this directly supports the implementation of the BI idea and of course the implementation process. Furthermore, the documentation of the knowledge contained in the BI pattern language builds the currently unavailable basis for future enhancements both in academic and practically oriented areas. As a consequence, the intended audience of this study are mainly people from the pattern language community (both scientists and users) and respectively interaction designers that deal with the concept of BI applications. Whilst 1

See 1.5 on the next page for an explanation why the study is narrowed down on web-based BI applications.

18


1.4. Research objectives the latter’s interest will mainly concern actual pattern language part of this document (beginning at page 77), the pattern language community’s interest probably 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 the interaction with web-based business intelligence applications. Apart from that apparent intention it strives for other subordinate goals:

A BI pattern language 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 settled by a single work. The focus thus needs to be narrowed down to define the validity of the outcomes for a focused area and of course to ensure a reachable goal. The constriction follows the terms used in the title. The pattern language created by this research, is intentionally not restricted in its focus regarding the scope or the level of concreteness of its patterns. The design of the pattern language itself needs to be unrestrained to enable it to fulfill the prerequisites of the other areas. As to the interaction, this study focuses on an end-user clientele, which directly uses the data or information gathered from the business intelligence application for its business means. It does not cover the interaction with BI experts using the application to develop and provide this information or even technical administrators. If a BI application is considered to have a front- and back-end and the respective user interfaces, the latter is not treated. As the interaction possibilities of locally installed and web-based applications differ decisively2 , the patterns found in the pattern language of this study only consider web-based applications. This decision was made by the author based on his personal background and experiences, as few people will start to create 2

The difference emerges in the different underlying technologies as well as the available performance of the whole systems.

19

Pattern language

Interaction

Web-based


1. Basics

Business intelligence

Applications

Not in this work

a locally installed business intelligence software from scratch, whereas creating a 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 available from. The character of the examined business intelligence is mainly a quantitative not a qualitative one, meaning that the information presented is primarily figure- and diagram-based and less textual. Considering the character of the applications, this research deals with, individuality per user and configurability need to be considered. While both should be implemented in a meaningful way, they should not be overdone so that the number of similarities between two users’ applications highly exceeds the number of distinctions. Considering the individuality of single business intelligence reports, those shall not be freely configurable but instead rely on a 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 maximum of around 80 application areas and/or pages or reports. Apart from the above mentioned qualitative delineation, it is also important to state what this work is not: it does not cover the roll-out of business intelligence in a business or the design or planning of such a project. Also it does not explain basic principles of interaction design as these are considered to be well-known by the target audience of interaction designers.

1.6. Assumptions and premises Potentiality of a pattern language

Suboptimal interaction

Market

This research acts on several assumptions that were made when its design was constituted. First of all it assumes that it is possible to formulate the pattern language that is advised by the study. This in turn requires the field of research to have interaction “problems”, which may be generalized. These assumptions are made as a basis for the establishment of this study’s research question and are very probable. It is however still a possible outcome that they may be disproved. Apart from that it is assumed that there are web-based business intelligence applications (which the author can tell from own experience) and the userinteraction with these are suboptimal. In sum this leads to the assumption that there is a “market” for this work 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.

3

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

20


2. Research context Contents 2.1. Direct research context . . . . . . . . . . . . . . . . .

21

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

21

2.3. State of research—connectivity & differentiation .

25

2.1. Direct research context Starting from the title of this thesis, the context comprises of the four fields the work originates from: Pattern languages, business intelligence (BI), humancomputer interaction (HCI) and web-based applications. The focus of this research lies in the intersection of these four domains but has a distinct offset towards pattern languages and business intelligence. This is the case, because the concept of a pattern language both forms the instrument and the outcomes of this research and these cover and consider above all the particularities of (the interaction with) business intelligence applications. Regarding interaction design this study relies on existing foundations and only uses them. The same is true for the technological basis of the conceived applications—the web. Thus, the influences of the fields of HCI and the web are a lot smaller than those of pattern languages and BI. This in turn is the reason for the latter two being described in detail in sections 3 on page 31 and 4 on page 49.

2.2. Scientific surroundings Each of the four stated fields in the context of this thesis again has its own context which may directly influence this work. These influencing domains will be described briefly in this section to illuminate the ambiance of the actual topic and allow for a deeper understanding of the whole field. The strongly interdisciplinary area of human-computer interaction probably spans the most broad and diversified field of all. As stated in a first HCI curriculum recommendation in 1992, its protagonists range from naturally computer scientists over psychologists, sociologists and anthropologists to industrial designers1 and all the people working in between, e.g. HCI student instructors. 1

Cp. [HBC+ 92]

21

Human computer interaction


2. Research context

Business intelligence

As the kernel of HCI is what all these disciplines bring together, this topic can hardly 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 interfaces may be software or hardware interfaces and those again may be differentiated. As an example, different types of software interfaces range from interfaces for operating 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 can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” [Int98]. The implementation of high usability today is considered to be the basis for a “good” interface or the respective application as a whole. In the experience of the author, the realization of high usability, which is often simply referred to as usability without 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 Computing Machinery (ACM), which organizes and sponsors the CHI conferences on human factors in computing systems as well as other specialized speeches and workshops as the MobileHCI conference. Apart from this more theory-oriented environment many practitioners conduct huge amounts of commercial projects that may be settled in the HCI field. The area of business intelligence is less broad but as a whole a lot more confusing as A the term business intelligence is commonly used with different meanings and B other terms are used for more or less the same thing.3 The primary reason for this confusing plurality probably lies in the need, marketing has 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 computer science. Actors in the field of BI primarily consider its application in the context of corporate management. Its applications as a management tool range from operational over tactical to strategical use. BI may be connected as data source or drain to planning systems (such as enterprise resource planning (ERP)), business operating systems (e.g. business process management (BPM) or eventdriven architectures (EDA)); it might as well be integrated into knowledge management systems (e.g. to compare with competitors’ strengths) and many more. Business intelligence is present in a broad range of industries, naturally massproducing manufacturing industries being the blueprint application domain. 2 3

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

22


2.2. Scientific surroundings Considering the size of industries, BI applications can mostly be found but are not limited to larger companies, as cost and effort for implementing and using BI and benefits need to be in a rational proportion. Within enterprises users of BI applications can be found in organizational contexts of accounting, budgeting, financial and management reporting, forecasting, marketing as well as sales. Apart from the industries actually using BI, the topic is given extensive coverage by research and consulting specialists, particularly Gartner4 [Gar] and Meta Group5 [Met], as well as manufacturers of business intelligence software frameworks like Business Objects [Bus], Cognos [Cog] or Oracle [Ora]. Regarding its backbone in information technology, business intelligence applications rely on various data storage, access and manipulation techniques, mainly implemented by data storage artifacts like databases, data warehouses or data marts. The extract, transform & load procedure as well as on-line analytical processing (OLAP) or data mining may be mentioned as exemplary methods. The data storage artifacts may either be part of an out-of-the-box BI software solution or the BI application accesses an underlying multi-purpose database. Regarding the databases themselves, various types are used, ranging from relational to multi-dimensional set-ups. As already stated above, sciences are only marginally connected to the area of business intelligence—it seems that these are very pragmatically consulted whenever this seems appropriate for the solution of a hands-on problem. For example in Jottings from the business intelligence jungle [Sel02], David Selby reports his research for particular BI solutions with the more scientific A programming language 6 (APL) of which the results are re-coded in a more industry-type language and then included in IBM software products. The sciences business intelligence is connected and reverts to are mainly economics, social sciences and structural sciences. Examples of BI-related subjects in science are • behavioral finance in economics, describing principles and empiric findings on human economic decisions, • information democracy in social sciences, considering the social aspects of information made available to d´emos—or a at least a previously unreached wide range of people, or • artificial intelligence in structural sciences, which e.g. has conducted research on pattern recognition used for the devision of actions from data. 4

as BI as a subsidiary of information technology is within core focus of Gartner Recently acquired by Gartner 6 Actually a programming language called A programming language, although originally conceived as Iversion notation by its creator Ken Iverson. 5

23


2. Research context

Architecture

Computer science

The core subject of this thesis, patterns and their languages, do not seem to 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 work and refers to a recurring pattern within data or information that e.g. may be automatically recognized. Regarding the field of architecture the only contact point with this work is the concept of pattern languages which originates from this area. The architectural surroundings thus have hardly any influence. It is nevertheless interesting to examine the feedback pattern languages have received in its original background. The concept is generally discussed controversially: although the Royal institute of British architects lists A pattern language [AIS77] by Christopher Alexander et al. as one of 11 recommended books on (architectural) design and as a design standard [Roy05], other architects consider it overestimated and expose it to criticism7 . It seems that in the past architects have feared a loss of control over their work as the concept empowers their customers, the inhabitants of designing their buildings of high quality themselves. The concept is 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 Alexander’s buildings are few and are said to fail fleshing out his ideas. When it comes to the less architectural but more cosmological or ideological part of his theories, the acceptance or rejection it experiences naturally becomes more intense. This for example became clear in a 1982 debate between Alexander and the post-structuralist Peter Eisenman on Contrasting concepts of harmony in architecture [aut83] which consequently is 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 teaching in architectural contexts. The author was unable to find other, if need be competitive, pattern languages neither for architecture as a whole nor for single subsidiary aspects. However the influence Alexander’s work had and still has on other domains is recognized and appreciated even in architectural context. It may be that his concept has been rejected in architecture because it claims exclusive validity, a fact that users in other domains simply have neglected to ease adoption. The latter is also the reason why most of the criticism in architectural context does not effect the application of pattern languages in human-computer interaction. In software engineering, the field within computer science where pattern languages first gained a broader recognition, the concept has initially been used 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 in several places of the world, called Pattern languages of programs (PLoP)8 that 7 8

Cp. e.g. [Don05] Other PLoP conferences are called ChiliPLoP, EuroPLoP, KoalaPLoP, MensorePLoP, SugarLoafPLoP or VikingPLoP.

24


2.3. State of research—connectivity & differentiation is entirely dedicated to finding and improving software engineering patterns and languages. These conferences also provide sporadic points of contact with the 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 people look at pattern languages: the perception of the pattern language concept has moved from a user-centered to a developer-centered one. The technicallyoriented character and prosaic thinking of those IT practitioners also have resulted 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) that emanates from the SGML/XML area is used by HCI people for the description of a pattern language9 —although it is very far from both architecture and the non-technical way, the inventors of the pattern language concept used for their description. Another example may be the unified modeling language (UML) which is paired with patterns in A UML pattern language [Evi00].

2.3. State of research—connectivity & differentiation With the exception of the World Wide Web part of the Internet, all fields that 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 be in research or practically oriented context. This thesis is based on some of this previous work to that it is meaningful to connect to but also needs to distinguish from some of its antecessors. The domain to which the connection of this work may be considered the most intense is pattern languages in human-computer interaction. In this field there have been many scientific publications in the last five years from the year 2000 to 2005.10 The types of texts published in this area have followed a clear path: they first explained the preliminary unknown concept of the pattern language and at the same time considered its general applicability for HCI purposes. After this question was answered positively, actual pattern languages and their usage were extensively covered, followed by research on the question how pattern languages could be managed, structured and optimized. The latter topic lead to the first serious review process, which criticized the existing HCI pattern languages that were supposed to be most relevant and have been cited the most. This review phase is considered to be the most recent development by the author. To recapitulate: using, structuring, optimizing and discussing pattern languages have been described in detail. 9 10

See 3.2.3 on page 38 A detailed history of the concept of pattern languages in HCI is outlined in section 3.1.2 on page 33.

25

Publications in HCI


2. Research context Creation not covered

Psychology

Semantic information processing

Surprisingly along the described path the actual creation of a pattern language has only been examined very marginally. Although pattern languages had emerged and even the procedure of writing single patterns had been described and discussed there seems no text available that has covered the process of creating such a language. This work, which is aimed at the creation of an actual pattern language, may thus rely on a sound background regarding some important aspects of pattern language usage but cannot fall back on previously gathered knowledge regarding their construction. It has thus been necessary to develop an original research approach, which is described in section 5. In the wider realm of (non-pattern) human-computer interaction, the knowledge 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 disciplines like psychology. From all the findings of this area, the relevant and suitable 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 outlined by requirement definition methods and supported by tacit knowledge that an analyst has gathered against the background of his HCI experience. For the actual process of conceptual design of the user interface, guidelines as well as design methods are at hand and models for the cognitive processes involved are available. Regarding the description of the achieved solution, verbal and visual methods are also accessible. When it comes to testing and optimizing a developed pattern, sophisticated but simple test methods can be used. An overview of design stages and examples for the respective methods available is given 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 extensively considers and integrates the end-users and their demands during requirement, design and implementation phases and even tests whether they were met afterwards, may be mentioned as an example. Two topics in the HCI-related discipline psychology also are of high interest for this thesis: the cognitive processes that A influence the interaction with the application’s interfaces, created byf the pattern language of this work; and B those, which influence the processing of the information presented within the application. The findings of psychology in the field of the cognitive capabilities and limitations of humans regarding the interaction with a computer interface—or more specifically a business intelligence application—have already found its way into HCI. For example, many of the heuristics or rules of thumb that exist for effective interaction design are ultimately psychological findings—may they be a result of scientific psychological experiments or more pragmatic usability tests. It is thus needless to consider them in a psychological context and translate them to HCI. Although this interface interaction includes some degree of human informa-

26


2.3. State of research—connectivity & differentiation

Pattern creation stage Requirement definition

Exemplary HCI methods available • Hierarchical task analysis (HTA), e.g. described in [PRS02] • Volere requirements specification template (on an application level) [Atl04] • Personas for the modeling of users, e.g. [CR03]

Conceptual design • Usability [Nie99]

& interaction guidelines,

e.g.

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

application

Solution description • Use cases for a transactional view, e.g. [Jac04] • Scenarios for a behavioral view, e.g. [CR03] • Wire frames representing application screens/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

Business intelligence

tion processing, the latter needs to be examined in further detail: while for example the simple question of the maximum number of items, a user is cognitively capable to choose from, can be answered with HCI guidelines, no such heuristic is available for the semantic layout of a spreadsheet report showing profit numbers. These more complex issues address the information processing regarding the semantics of the displayed information. In this area, so-called cognitive biases that have been found in psychological research may impact the perception of the actual information. Those biases often are the result of psychological heuristics humans use instead of judging exactly. An example of such bias within rational choice theory is framing 11 , which states that the presentation (frame) of an information may influence its perception. In particular cases, different framings actually lead to diametrical decisions. Other psychological heuristics have similar outcomes. The reasons, as well as the effect of those heuristics and the possibly resulting cognitive biases are well documented. 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 a neutral presentation frame, as only those provide an optimal basis for the conclusions a human user may draw. Nevertheless the need to avoid those effects imperatively requires awareness of their existence. In the non HCI-connected remainder of the business intelligence area—as noted before—less research has been conducted in a scientific surrounding. This results in the knowledge being generally less publicly documented and being more industry-driven: BI know-how can mostly be found in white papers, case studies and professional articles naturally including marketing-oriented parts which need to be cross-checked thoroughly but also hands-on experience that science can hardly offer. Furthermore, practitioners’ books are available, which cover theneed, the purpose and the realization of business intelligence in corporate environments. Fortunately, no more findings from science regarding BI are required for this thesis than those on human information processing. What is needed beyond is a general understanding of business intelligence applications in terms of a typical and comprehensive overview of its capabilities, functions and current characters, as these build the basis for the design of human interaction, which again is the core of this research. The educt of this information is available from 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 this area the author of this work can revert to his experience with the conceptual design of a BI application, which is based on the products of a prominent BI 11

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

28


2.3. State of research—connectivity & differentiation software solutions manufacturer. As outlined in section 2.2 on page 21, a connection of this thesis with the field of architecture outside of pattern languages is not imperative. The study of the pattern language sub area12 , which can be treated without its architectural context, is sufficient. Regarding the connectivity to the architectural pattern languages, extensive research that can be reverted to has already been conducted in the field of HCI.

12

including the feedback the concept has received from architecture

29

Architecture


2. Research context

30


3. Pattern languages for human-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 interaction . . . . . . . . . . . . . . . . . . . . . . . . . . .

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.1—which is meant as a quick introduction—gave a very brief idea of the concept: pattern languages are agglomerations of patterns, which in turn are solution descriptions. A refinement of this short presentation first needs to consider the patterns separately and then the languages, in which they are collocated. The inventors of pattern languages and therefore of the pattern Alexander et al. define a pattern as follows:

31

Pattern definition


3. Pattern languages for human-computer interaction “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 [. . . ].” [AIS77, p.x ]

Language definition

This definition focuses on the recurring occurrence of a problem and its solution and is not restricted to the field of architecture, for which Alexander et al. have developed the concept. At the time of creation, the authors already thought of a pattern as an integral part of a wider framework: the pattern language. Descriptions of the language concept can be found in several works of the architects1 . A significant definition is the following: “We know that it [the pattern language] is a finite system of rules which a person can use to generate an infinite variety of different buildings—all members of a family—and that the use of language will allow the people of a village or a town to generate exactly that 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 be adapted to gain general validity. This generalization results in the following derived definition: A pattern language is a finite system of patterns (as stated before) which may be used to generate an infinite variety of different applications—of the same domain—and whose use will allow the application’s designers and users to generate a balance of uniformity and variety, which makes the application a good one.

HCI pattern language definition

To avoid misinterpretation it is important to differentiate the meaning of the notion language in natural or programming languages from the one in pattern language. As stated by the definition above it should be seen as a system that—for reasons given in the following—is given the name of a language. The given definitions were diversified by various authors that adopted the concept for their purposes and domains. In human-computer-interaction, participants of the CHI meets PLOP: an interaction patterns workshop acquired the following: “An Interaction Pattern Language generates space/time interaction designs that create a system image close to the user’s mental model of the task at hand, to make the human-computer interface as transparent as possible.” [Bor00a, p.10] 1

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

32


3.1. Basics While the workshop attendees considered this to be a definition, the author of this thesis disagrees in that matter, because the text defines what a pattern language does and which goals it should achieve in spite of defining what it actually is.2 Though generalized, the aforementioned definition derived from Alexander’s is still more precise even for the field of HCI. This thesis will thus refrain from using this HCI-based definition and rely on the one generalized from Alexander’s work.

3.1.2. History The concept of a pattern language (and the associated concept of a single pattern) was introduced by the architects Christopher Alexander, Sara Ishikawa and 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 three books, the first The timeless way of building [Ale79] being a theoretical introduction to pattern languages and the last The Oregon experiment [ASA+ 75] a description of a real-life implementation of the theory. The work deals with the design of architecture in a city’s context and gives hands-on support on various levels of architectural considerations: as indicated by the book’s title, they range from a town level down to buildings (and even rooms or room parts) and also handle the construction part. To give an example, the book illustrates that a neighborhood needs to be able to establish an identity [AIS77, p.80] as well as it describes why every balcony needs a minimum depth of six feet [AIS77, p.781] or states how a pillar supports the statics of a construction. The first computer-related discipline that has adopted the pattern language idea was interface design. Ten years after the publication of Alexander’s first book in 1987, Ward Cunningham and Kent Beck made an attempt to use the pattern language idea in a consulting job to design a user interface. They were quite surprised of their success and presented the case in a workshop on the ACM conference on object-oriented programming, systems, languages and applications (OOPSLA) in 1987. In the following years till 1991, the pattern idea has matured in the heads of many software architecture oriented conference attendees, including Erich Gamma and Richard Helm. Then in 1991, both started to compile design patterns into a collection. The same year at the European conference on object-oriented programming (ECOOP), they met with Ralph Johnson and John Vlissides, with whom they published the renowned book Design patterns in 1995 [GHJV95]. While other authors published pattern-oriented books at about the same time3 , this publication constituted the pattern idea in computer science all over the world. 2

This remains true even with Borcher’s more detailed explanation of the definition in his later work, [Bor01, p.38] 3 To name just one: Frank Buschmann et al. with Pattern-oriented software architecture [BMR+ 96].

33

Origin in architecture

Computer science adopts pattern languages

First software engineering publication


3. Pattern languages for human-computer interaction

Foundation of Hillside Group

A pattern language for interaction design

High conference attention

Hands-on publications

Some other attendees of the the ECOOP met in 1993 on the side of a hill “to use patterns in a generative way in the sense that Christopher Alexander uses patterns for urban planning and building architecture” [Por05]. They founded the non-profit Hillside Group, which today is the unofficial steering committee for software patterns and provides a lot of information on patterns at 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 the conference on human factors in computing systems (CHI97) in 1997. There, a workshop called Putting it all together: towards a pattern language for interaction design [BBC+ 98] faced the challenge that human-computer interaction projects had experienced a distinct increase in complexity and diversity. The workshop identified the concept of a pattern language to be a possible solution and discussed a broad variety of application ideas, from creating patterns that represent HCI guidelines to using the original architectural patterns for cyberspace design. As the workshop attendees felt that they “were at the very beginning of the enterprise of understanding the role and utility of pattern languages for interaction design” [BBC+ 98], the outcomes are not more than an overview of the potentialities. In the following years until the turn of the millennium the pattern language topic was widely discussed at conference workshops4 and was pushed forward by a couple of its protagonists. In the year 2000, Jan O. Borchers moderated a CHI meets PLOP: an interaction patterns workshop which compiled a first imperfect definition of an interaction pattern language [Bor00a]. He has also described an actual pattern language, he had used for an interactive music exhibit 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 made clear that they would apply differing focuses. At the CHI’02 a one-day workshop organized by Martijn van Welie, Kevin Mullet and Paul McInerney was dedicated to the patterns topic and provided a forum for sharing “experiences using and writing HCI patterns” [WMM02]. Its outcomes are very practically oriented and reflect that the concept had found its application in non-scientific projects. This is also visible from some of the position papers, the attendees have provided [Wel01]. Also in 2002, Ian Graham put the knowledge he had been gathering over 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 of sites was published by Douglas van Duyne, James Landay and Jason Hong [DLH02b], for which the authors had analyzed 100 “of the highest quality Web sites” and compiled the results into “patterns, principles and processes for crafting a customer-centered web experience” [DLH02a]. Both books were 4

e.g. UPA’99, INTERACT ’99, ChiliPlop ’99

34


3.2. Concept of a pattern language published in and for a primarily non-scientific environment and have thus received 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 van Welie and Gerrit van der Veer have answered the need for an enhanced navigation through pattern languages: they have created a general language structure by transferring Alexander’s scale of architectural geometry to one of problems and came up with a taxonomy of four different pattern types. As this paper deals with the meta content of organizing pattern languages and not with using or creating them, it may be seen as an indicator that the actual concept had arrived 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 interface pattern language? and scrutinized the quality of some of the publicly available pattern languages [TKP04]. They summarize their analysis as “none of the collections5 can be described as mature”. The same year several other authors adapted the pattern languages concept to their domain of interest (in- and outside of HCI) and have also cross-checked the recent work with the original concept. 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-computer interaction domain. Nevertheless actual pattern languages are rare as seems to be their hands-on use.

3.2. Concept of a pattern language 3.2.1. Patterns As already stated, patterns are written descriptions of solutions to problems that occur frequently and may be solved in a generalized way. While invented for the use in architecture, the concept itself is not domain-specific and may be applied in other domains as well. The concept of a sole pattern is no rocketscience but a very straightforward approach to documenting know-how. What differentiates patterns from other solution documentations is that they extensively consider the context of the problem, may it be the so called forces that influence the problem itself or the detailed discussion of the problem solution, which “describes the field of physical and social relationships which are required to solve the stated problem[. . . ]” [AIS77, p.xi]. Apart from that, patterns in its original form do not provide a ready-to-use solution that just needs to be inserted as a complete component, but support the pattern user with the adaption of the solution to the current application situation. Despite this very simple approach, patterns present a potential that exceeds 5

[namely van Welie’s GUI [Welb], WEB and e-commerce collection [Wela] as well as

35

Patterns consider context

Concept potential


3. Pattern languages for human-computer interaction those of other proprietary documentation forms. Their speaking names allow users to refer to complex circumstances which just a few words: whenever a problem occurs, whose solution has found its way into a pattern, just quoting its name is sufficient to make clear to everyone what approach to the problem’s solution should be taken. Patterns are also generative in a way that reading and reflecting them actively supports the process of solution creation. Moreover they assure the integrity of an application6 , as all people working on their creation 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 be built on. At the same time, they increase the result’s quality, as contemplating the patterns integrates the know-how comprehended within them. Regarding the documentation of the design process, patterns back up personally-bound knowledge to be ensured7 and also provide a quick and easy way to describe a pursued solution.

3.2.2. Language aspect Patterns in context

Languages guide their users

Denomination language

The potential of patterns strongly increases whenever they are used in a pattern language context. At first sight languages are collections or agglomerations of patterns. At closer inspection they are much more: languages emerge with the relations between the patterns contained herein. As an example for such a relation, two patterns may be alternative solutions, so the relation is “contrariness” 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 patterns are used, increasing the generative character of the whole concept. Starting from a single pattern, other related patterns may be considered which again relate to other patterns. If during an application design process a language user follows this guided path through the language they consider various problems and their solutions. During this process the application is progressively formed based on the know-how contained in the language, which is applied with the situational background of the user. A good language thus actively guides through the process of application design. One part of the structured form of a language arises from a simple agglomeration of patterns, due to a sort of force from the relations within; another part of it needs to be added on purpose by the language creator. Collocated in such a structure, the patterns form an entity whose whole is more than its parts: the language. The reason why this entity is called a language lies in an analogy Alexander has made in The timeless way of building [Ale79]. Starting from mathematical Borcher’s HCI collection [Bor01]] not only in the sense of a software program 7 diminishing the so-called truck factor 6

36


3.2. Concept of a pattern language languages that consist of language symbols and rules to combine these symbols, he looks at natural languages to find that words represent the symbols and grammar their combination rules. Beyond that, natural languages include a meaning, 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, the solution approach the patterns represent and in the way the relations need to be combined. Alexander thus considers pattern languages to be more complex than natural ones [Ale79, p.185]. An overview of a direct comparison between natural and pattern language is given in table 3.1. Natural language Words Rules of grammar and meaning which give connections Sentences

Pattern language Patterns Patterns which specify connections between patterns Buildings and places [resp. the applications 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 definition8 is. Other authors, e.g. Frank Buschmann et al. [BMR+ 96], prefer the system denomination, as one can find discrepancies in the comparison of patterns and natural languages. While calling the collection a system may be more exact regarding these discrepancies this in turn lacks some important aspects from the language comparison.

Denomination system

3.2.3. Formalization With the creation of the architectural pattern language, Alexander et al. have also provided a format for the patterns in their language. The format consist of several typographically separated sections, which themselves are stylistically prose. Pattern name The name provides a common identifier for the pattern, which may be used in personal or formal communication. After the name one, two or three asterisks describe the quality ranking of the pattern by the authors (more asterisks meaning better quality). Picture The picture provides an archetypal example of a pattern’s implementation. In practice it usually allows for a one-look comprehension of the patterns essence. 8

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

37

Original pattern format


3. Pattern languages for human-computer interaction Superordinate context This introduction describes how the current pattern is used by larger patterns, allowing the reader to understand in which larger pattern-context it may be used. Problem The problem part starts with a short description of the problem’s essence and then goes into detail on the empirical background of the pattern and its evidence for validity. Solution The solution points out a short instruction on what to do to solve the problem (within the given context). Subordinate context This paragraph describes which subordinate patterns may be used to implement the current pattern’s context and where a user should go further in their process of design. Adaptations

Human-computer interaction

The first pattern users in computer science have adapted this formalization to their needs. Gamma et al. identified only four essential elements, name, problem, solution and consequences, however, they segment and enhance these with more sections. This results in 13 pattern elements including e.g. a graphical representation of the software classes or sample source code that may be adapted.9 The segmentation of the pattern description is however to a lesser extend a conceptual enhancement than an approach to structure the information according to the domain’s needs. Pattern creators in the human-computer interaction domain have written their patterns in various formats of which Sally Fincher has compiled the website The pattern gallery [Fin00]. The different formats mainly follow subjective preferences of their users and are thus not described in this work. At a workshop at the CHI 2003, which covered concepts and tools for patterns and its languages leaders and participants (including renowned pattern community members) recognized the drawbacks of this diversity and compiled a pattern language markup language specification (PLML) including a document type definition (DTD)10 . The actual DTD may be found in the appendix A.1 on page 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. Aliases are included whenever there are several names. The ID is a unique identifier within a single collection. Illustration An illustration shows an actual real-life use of the pattern. It is not limited to a static illustration but may also consist of multimedia. 9 10

Cp. [GHJV95, p.3, 6-7] “A Document Type Definition (DTD) is a specific document defining and constraining definition or set of statements that follow the rules of the Standard Generalized Markup Language (SGML) or of the Extensible Markup Language (XML), a subset of SGML. [. . . ] [sea04]

38


3.2. Concept of a pattern language Problem This part describes the actual problem, which is the reason for the pattern’s existence. Context This describes the context in which the pattern may and should be used. It is also reflects its applicability. Forces This part refers to the compulsions that exist in the environment of the problem. Solution The solution delineates—phrased as an instruction—what needs to be considered and enforced to solve the problem. Synopsis This part acts as a summary of the whole pattern, which may be used 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 the pattern may be included as examples as well as a rationale on the character of the pattern. Confidence This section takes up the original star rating by Alexander (see above). Literature References to literature that should be considered in the context are stated in this part. Implementation This section holds actual implementation code or fragments thereof whenever this is feasible. Related patterns Patterns within the language that may be used with the current one, are linked to in this part. The relation itself may be one of the three following types: an is-a-relation, an is-contained-by-relation or a contains-relation Author, credits, version and changes This part states authorship, creation date as well as change management. To allow for an overview of a whole pattern language, Gamma et al. have introduced a visual representation of their pattern collection in Design patterns [GHJV95]. It seems to be strongly influenced by software engineering class diagrams and consists of rectangles representing the patterns as well as directed lines (actually curves with arrows) that represent the relations. An example of such a visualization is given in figure 3.1 on the next page. This visualization has a mathematical equivalent, the directed graph. First used by Borchers in a paper [Bor00b], he refined the definition for his book A pattern approach to interaction design [Bor01]:

39

Visual representations

Mathematical definition


3. Pattern languages for human-computer interaction

Entry form

Selection menu

Interaction style

Conversational text

Warning sounds

Explorable interface

Rich garden

Organized desktop

Palette

Command control center

Garden of windows

Zen garden

Toolbar

Single setting

Multiple settings

Cooperating windows

Rewarding sounds

Goal oriented areas

Launchpad

Modeless feedback area

Menubar

Dialog box

Context sensitive help

Clickable symbols

Symbol explanations

Visual symbols

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 P L = (℘, 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 a name n, ranking r, illustration i, problem p with forces f1 . . . fi , examples e1 . . . ej , the solution s, and diagram d. While this definition is considered irrelevant for practical language use by the author, it may serve as a basis for a programmed language representation.

3.3. Language structures 3.3.1. Patterns agglomeration types When looking at an agglomeration of patterns it is important to differentiate between collections and languages as their intended use is usually different. Collections serve as a sort of container of different patterns (normally of a named domain) that are used in a more reference-oriented manner: A user identifies a single problem and looks up its solution in the collection. In some cases the found pattern may also refer to another pattern that suits the user’s problem context. A pattern language in contrast should be seen and used as a whole. A user initiates the process of designing an application and decides to use a suitable pattern language. Obeying the language introduction they start with a more general pattern and work their way through its relations considering a noticeable number of patterns, creating a remarkable part of the application’s design. The delineation of collections from languages in practice is an ambitious task. The visualization of a language may serve as a first indicator: the more relations exist between patterns and the more hierarchical those are, the more languagelike is an agglomeration. In language use, the degree of interconnectedness of patterns is directly contingent on the degree a language is generative. Judging the latter by only consulting the written patterns (without using them) is considered incomplete by the author. The quality of a language, which is measured by the degree of its generativeness, needs to be experienced in reallife 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

Collections

Languages

Continuous degree of quality


3. Pattern languages for human-computer interaction scientists and users often discuss controversially whether they would better be called 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 to both types are also listed. Collections Relations of patterns are not present of stated Relations do not guide a reader/user through the system

Languages Patterns are hierarchically collocated

Both Patterns emanate particular domain

Reading/using the system is highly generative

The system’s domain is stated and defined

a

Table 3.2.: Delineation indicators for languages and collections As already stated in 3.2.2, some authors prefer to call their patterns agglomerations systems, because they prefer an uncommitted term to evade discussion. This however hinders a clear typing and naming.

3.3.2. Structures Intrinsic logical structure

HCI-suitable structure

Appending to the physical format of patterns and languages is an intrinsic logical structure that can follow different approaches. In Alexander’s original work, this logical structure is less obvious than the physical format of the patterns. Being collocated in a book, the consecutive order determines most of the format. The intrinsic structure lies within the order in the book: Alexander et al. have structured the patterns according to their scale—as the book’s subtitle Towns · buildings · construction indicates. Thus, the physical format of a language is weak but its virtual structure, which is created by the pattern’s relations, can be a lot stronger. This is particularly true for the original pattern language as Alexander considers every pattern to have a superordinate context as well as a subordinate context. This results in every pattern implementing “bigger” ones as well as being implemented by “smaller” ones. Thus, the resulting structure is hierarchical. Such an intrinsic language structure effectively simplifies the language’s usage: it allows the user to find a feasible pattern for the initialization of their application design, eases the “navigation” through the language and empowers a user to more easily grasp the language as a whole. With this motivation authors of application domains different from architecture have felt the need for such 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-computer interaction, Pattern languages in interaction design: structure and organization by Martijn van Welie and Gerrit C. van der Veer, the authors are following the

42


3.3. Language structures approach to adopt Alexander’s taxonomy of geometry scale to one of problem scale. They state that “In Interaction Design there is certainly a ‘scale hierarchy’ of problems” [WV03, p.2-3], as interaction designers begin with gaining broader insights into the project’s general background and end with solving problems of individual graphical user interface elements. Following this approach, 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 application that are (or will be) realized with it. To provide an examplea pattern may describe the overall approach of e-commerce or personal websites. Experience patterns Classified into the experience type group are patterns that consider the realization of user goals, e.g. shopping or social contact. Task patterns Patterns of the task type describe solutions of tangible problems a user experiences, for example collecting several products in a shopping basket. Action patterns Action type patterns represent solutions that are mostly instantiated directly in interaction elements, such as submit order. This typing or classification of patterns has an immanent direction: designing an application starts with creating (or deducing) a posture, then defining the experiences, breaking them down to tasks and actions. The top-down approach is best observable in a visualization Welie and van der Veer provide for an Online shopping centered pattern language. It is reproduced in figure 3.2 on the next page. The presented concept allows a classification of practically all patterns of purpose-oriented11 applications but is only one possible solution. This has been identified by the authors themselves and they suggest other classifications for example by function, similarity of problem, usability problem or task and experience from a user’s perspective—without specifying them in detail. The most interesting result of these considerations is that the authors found that “for practical use several kinds of patterns classifications may turn out to be useful” [WV03, p.7]. This is why Welie and van der Veer have come up with the idea of having different views (incorporating the classifications) on an actual pattern language. This idea can be understood as using actual pattern attributes and/or meta properties to create several views of intersection free selections. One of this specific suitable views may then be chosen for a particular 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 seems not to be available. 11

A pattern language with an arty approach for example does not fit into the pattern types.

43

Other structures feasible

Differing views on a language


3. Pattern languages for human-computer interaction

Selling products

Business goals

Customer satisfaction Information providing

Posture level

E-commerce

Portal

Small corporate site

News site

Personal site Product support site Community site

Theme sites Templates

3-column layout

Experience level

Playing

Homepage

Locating Expressing

Browsing

Discovering

Task level

Poll

Informing

Shopping

Forum

Getting overview Shopping cart

Identify Searching

Guided tour

Product comparisons Teaser menu

News letter

My site Wizard

Sitemap

Progressive filtering

List builder

Breadcrumbs

What’s new

Sorting

Action level

Paging

Good defaults

Choices

Exit

Login

Stepping

Action buttons

Figure 3.2.: A partial pattern language for web design (centered around shopping), 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 problemsolution-context, they are not considered perfect. This implicitly becomes clear when looking at the asterisk ranking, Alexander et al. have given their patterns.12 The optimization of patterns may concern its amelioration, making its problem or solution description more precise, it may concern the elimination of actual errors as well as concern enhancement, e.g. with known uses or examples. Regarding the review of single patterns, so-called writer’s workshops have been established in the pattern community13 . They provide a structured procedure allowing for the optimization of patterns based on the input of other community members. Several reviewers, the authors as well as a moderator who coordinates discussion are present during such a workshop. All participants have read and reflected on the content of the pattern’s description prior to the workshop. The decisive phases of such workshop are:

Optimization potential

Procedure: writer’s workshop

Reading The author of the pattern reads a part of the pattern’s description, they consider essential, to the participants. Summary Two reviewers summarize the description of the whole pattern from their perspective. Discussion Participants then discuss advantages, disadvantages and finally all other remarks and suggestions regarding the pattern. The author does not attend this part and is not addressed directly. Questions The author may consult the reviewers, to ensure correct understanding of the reviewer’s points and ends the workshop with a concluding comment. These kinds of workshops are in use for the optimization of patterns from various domains, including software engineering as well as human-computer interaction and are e.g. held at the Pattern languages of programs (PLoP) as well 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 patterns the optimization of pattern languages directly builds on the optimization of single patterns. The latter need to be subjected to ongoing testing 12 13

Cp. 3.2.3 on page 37 The procedure has been inferred from poetry and is—according to [Gra03, p.21]—attributed to Richard Gabriel, a member of the Hillside Group.

45

Optimize patterns in context


3. Pattern languages for human-computer interaction

No method present

for their significance. If they do not fit into the overall concept any more or when the general framework has changed, they have to be removed from the language. Synchronously, new patterns need to be identified, documented and integrated into the language, whenever this becomes appropriate. A pattern language 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 be checked14 . Likewise, language introductions need to be revised and overviews need to be adopted. The most important adjustment however is checking, whether the generative character of the language is still intact or needs to be restored. A method for the optimization of pattern languages cannot be spotted in literature at the time of research in 2005. The significantly increased complexity of languages in comparison to single patterns anyway conflicts such a method. It is however probable that at least a procedure for the optimization will be developed by the community starting from the writer’s workshop concept. It is apparent that currently most language optimizations will be done in a practically oriented environment, probably even while the language is in use to make it suitable for modified project conditions.

3.5. Using pattern languages in human-computer interaction 3.5.1. Applicability

Problem are similar

Solutions may be abstracted

As the sections above have already made clear, pattern languages are used within the human-computer interaction domain15 . This suggests that the concept is in general applicable for this area. Nevertheless to ensure a complete consideration and allow for a better understanding of possible constraints it is meaningful to check the basis of applicability. As a first indicator for the applicability of pattern languages in the humancomputer interaction domain, problems need to occur in similar forms. This is necessary so that generalized solutions will be feasible. In HCI this situation is given, as the interface between humans and machines consistently causes the same problems. The technical interface of keyboard and mouse may act as an example as well as navigation through content presented within a website. As a second step similar solutions for those problems whose character allows the abstraction of the solutions need to exist. This abstraction process for the most part directly complies with the pattern creation process. The abstrac14

However there should not be too many of them as otherwise the pattern would in most cases not be dispensable 15 To cross-check a definition of HCI and a short description of the field, see 3.1.1 on page 31

46


3.5. Using pattern languages in human-computer interaction tion criterion is also fulfilled by human-computer interaction: in the majority of cases, HCI deals with individual tasks users want to complete. Those are abstracted into a generic scheme that still enables the completion of the differing individual tasks. Another indicator for the fulfillment of this criterion are the common HCI guidelines that accurately represent abstracted and generic recommendations. As a third criterion, one must be able to collocate the found abstracted solutions or patterns in a pattern language. To accomplish this, problems and solutions need to emanate from a confined domain and on the whole reach a broad coverage for this domain. As the focus and borderlines of a language can be decided on prior to building it, this is easily achievable. In conclusion, pattern languages in general are a suitable concept for HCI whenever the application domain is constricted to a stiff definition. As one possible example when looking at the whole field of HCI, such application areas can be obtained by structuring the field by level of abstraction. Using this classification results in the following application areas: Interface design Pattern languages of this area are used to describe and design16 single elements of user interfaces e.g. of a single website page, a software application wizard etc. Patterns both deal with buttons, scrollbars, drop-down menus, progress bars and their layout or the arrangement of those elements on an interface. Jennifer Tidwell has created a pattern collection called “UI patterns and techniques� [Tid]17 , which may act as an example for such a language. Application design In the application design field, pattern languages deal with designing functional parts of software applications, e.g. the text editor of an email client, the process of inserting an image into a document or starting programs via the Windows start menu or OS X dock. Those functions are the elements or patterns, but a language also deals with their relations and how those result in application design. An example for such application design language is Experiences by T. Coram and J. Lee [CL96].18 System design Languages of system design consider the interaction of users with entire systems, e.g. the usage of a personal computer via keyboard, mouse of voice recognition. To provide an example, Jan Borchers’ language for interactive music exhibits (described in [Bor01]) contains such patterns. 16

both in a graphic and non-graphic meaning At the time of writing this collection is not yet but will be published in the book Designing interfaces: patterns for effective interaction design. 18 Experiences is unfortunately uncompleted but nevertheless a good example as it is straightforward and available on the web. 17

47

Suitability for a language

Application domains


3. Pattern languages for human-computer interaction Apart from this generic approach, other application domains can be found, for example, HCI guidelines may be coded in a pattern language or even a pedagogical pattern language may be created that deals with teaching HCI to user interface design students.

3.5.2. Special potential

Securing implicit know-how

Common language

Participatory design

Generative character

For the field of human-computer interaction, pattern languages provide a special potential as they support some of the characteristics and proceedings of the area very positively. Patterns alone (without a language network) already provide a method to document the know-how present in the field of HCI, which because of its qualitative character is normally bound to personal resources. Many concepts in HCI e.g. usability exist mainly as instances in applications but are not extracted as explicit know-how, which becomes easily possible with the help of patterns. People working together in HCI are usually from different disciplines, e.g. concept, design and programming, and thus speak “different languages”. Patterns with their simple but precise form provide a brilliant solution to unify this spoken language and act as a communication basis as indicated by the term Lingua franca 19 . Apart from that, using pattern languages in comparison to other design methods does not require any special tools or preparation. A specialty in comparison to other concept and design methods is the possibility to have actual users integrated into the application design process, as patterns are written in a way users are able to understand. In its original field of architecture, Alexander et al. even have invented the concept for the “users” of their architecture, the inhabitants and not the architects. This resembles the approach of participatory design that integrates actual software users into the design process to enhance its quality. Pattern languages provide a suitable basis for such participatory workshops.20 The most important aspect in the opinion of the author however is the generative character of pattern languages, which intensely supports the conceptual design process, because it adds structure and a procedure to it: a good pattern language allows even an unexperienced designer who is not an expert of the specific application domain to start at the right place and proceed throughout the language creating substantial parts of the application without giving too much thought on this process itself. This aspect is particularly positive for large or complex applications where managing the process of conceptual design becomes very complex in comparison to the design itself.

19 20

Cp. [Eri00] or [Bor00b, p.369] The use of whole languages of course is discouraged without a facilitator experienced in this language, however single pattern may even be used without the presence of such person.

48


4. Business intelligence and its interactions Contents 4.1. The core of business intelligence . . . . . . . . . . .

49

4.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . .

49

4.1.2. History . . . . . . . . . . . . . . . . . . . . . . . . .

51

4.1.3. The business intelligence concept . . . . . . . . . . .

53

4.1.4. Business intelligence applications . . . . . . . . . . .

54

4.2. Interacting with business intelligence applications .

57

4.2.1. Interaction contexts & elicitors . . . . . . . . . . . .

57

4.2.2. Typical and comprehensive business intelligence . . .

59

4.1. The core of business intelligence 4.1.1. Definition Business intelligence (BI) as a term has been used inconsistently in the past and still is today. Evolved within a highly volatile industry-driven field where marketing is more important than clarification of terms, one can find resembling but differing concepts called BI as well as other terms used for the same concept. Industry members in the business intelligence realm agree upon the fact that the name Business intelligence was coined by Gartner Research around the beginning of the 1990s with the decisive contribution of Howard Dresner.1 In their later report Data warehouse, data mining and business intelligence: the hype stops here Dresner et al. define BI as “the enterprise’s ability to access and explore information (contained in a warehouse), analyzing that information, and developing insights and understanding, which leads to improved and informed decision making.” [BDSB96, cited from [SPS04]] This definition in whole is suitable for industry purposes, however it is in the interests of the author to differentiate the concept of BI which will be denoted 1

References report conflicting years of creation. In personal communication, cited in [Uff02], Kevin Cooper, Client Inquiry Analyst of Gartner states that “the term Business Intelligence was created in 1989 and coined by Gartner in that year. Howard Dresner had a hand in the creation of that term, but did not join Gartner until YE 1992, when he drove it into the mainstream.”

49


4. Business intelligence and its interactions with the sole term business intelligence, and its implementation efforts, denoted BI applications in the remainder of this chapter. The concept itself, which at first is completely detached from its implementation is defined as: Business intelligence concept definition

Business intelligence (concept) is the capability of an enterprise as a whole to support its employees in their business-relevant actions by providing data, information, knowledge or wisdom relevant in this context, extracted from business data. To support this concept and provide the means that allow an enterprise (and its employees) to pursue it, business intelligence applications are implemented:

Business intelligence application definition

Business intelligence applications are software applications, which support its users in pursuing the business intelligence concept. To do so, they gather, analyze and evaluate relevant data and elevate it to information, knowledge or wisdom in interaction with the enterprise user towards the goal of improving the quality of business actions taken by this user. For further clarification the two definitions, it is feasible to illustrate some of the terms found within. Foremost it is important to point out that the term intelligence within business intelligence is not used in the more common meaning indicating a mental ability, but in the sense of information or the gathering of the latter.2 3 The denomination business-relevant then indicates that an action needs to influence the common business purpose (to a variable degree). For example, information on the spatial motion of employees within a company of knowledgeworkers, recorded by an access control system, usually is not business-relevant. As a background for the elevation of data, the data-information-knowledgewisdom (DIKW) hierarchy4 is assumed.5 Applied to business intelligence, this model describes an increasing quality of usefulness from data to information, to knowledge and finally to wisdom. Business intelligence applications necessarily only need to provide the lowest stadium as the higher may be achieved by the intellectual capabilities of the human user—nevertheless, the provision of at least the stadia of information and knowledge often are incorporated and of course are appreciated by the enterprises’ employees. To simplify reading, in the remainder the term information is used whenever information, knowledge and wisdom are considered. 2

See the Oxford advanced learner’s dictionary on intelligence. [Cow89] The etymology of the term has not been traced in this study—nevertheless it presumably has evolved in a tradition of military “intelligences”, e.g. U.S. SIGINT or TECHINT. 4 DIKW is often referred to as the information or knowledge pyramid in respect of its decreasing volume. 5 Cp. [Ack89] and [Cle82] 3

50


4.1. The core of business intelligence The definition of a BI application given above is on purpose to a certain degree detached from current practice in the area to allow for an increased lifetime as well as to delineate it from a simple description. As an example some decades ago data storage of BI would have been described to rest upon relational databases, which today are outdated and have been superseded by databases optimized for online analytical processing (OLAP). Nonetheless, to complete the image in this direction, a description of business intelligence would state that both concept and application rely on a data warehouse to store the data, provide access to reports and capabilities to query the data, statistically analyze and forecast data and thus incorporate decision support for its users.6

4.1.2. History Based on the fact that in the realm of business intelligence, similar concepts, ideas and terms with only vague definitions are used inconsistently by many mainly non-scientific actors, thoroughly describing the field’s history is a task almost as hard as defining the term. As the history of the area is not in focus of this thesis but only serves as a means to complete the picture, only an outline of the history is provided below. Nevertheless this outline allows for an understanding of the historical context and trends that “lead” to business intelligence implementations. The above stated differentiation of business intelligence concept and applications can hardly be applied to their history as it is very theoretical—in practice both are strongly interwoven. Concept and supporting information technology in business intelligence have been developed in parallel with user needs, managerial techniques and instruments, technology achievements and naturally costs being the key drivers of its progression. The first publication, which can be considered to build on the foundation of business intelligence, is Ken Iverson’s book A programming language [Ive62], which documented an actual programming language (with hindsight called APL) able to efficiently handle, compute and analyze multi-dimensional data.7 From today’s point of view this can be considered a first and very basic approach in the direction of online analytical processing (OLAP).8 APL since then has been and still is strongly connected to the analytical solution of problems in the BI area. Then in the 1960s and 1970s Artificial intelligence and Neural networks were tested in scientific and industrial environments for knowledge discovery9 . In parallel the capabilities of computers and their software have been used in largescale companies for Management- and Executive information systems (M/EIS) 6

This description is based upon a “definition” given by SearchCRM.com [Sea05]. Cp. [FI78] 8 Cp. [Pen05] 9 Cp. [Sel02, p.191] 7

51

Concept & applications interwoven

APL as inductor

Industry usage


4. Business intelligence and its interactions

Knowledge discovery and OLAP

Integrated commercial products

Overall development

that already have been meant to support decision-making10 and also resulted in commercial products. In 1982 an article in the recognized Harvard Business Review titled The CEO goes on-line states that “Typically, executive information systems (EIS) share the following: a central purpose; a common core of data; two principal methods of use, which are 1) access to the current status and projected trends of the business, and 2) personalized analyses of the available data; and a support organization.”[RT82, abstract] This description already strongly resembles the understanding of business intelligence in 2005. Three years later a system bearing the name business intelligence was developed and installed for the Procter & Gamble Corporation.11 Then in 1989 at a workshop called Knowledge discovery in real databases the term knowledge discovery was coined and “the workshop confirmed that knowledge discovery in databases is an idea whose time has come.” [PS91, p.70] 12 Four years later, E.F. Codd defined a category of database processing, online analytical processing (OLAP) in his seminal tech report Providing OLAP to user-analysts: an IT mandate and presented OLAP capabilities as “incumbent [. . . ] within enterprises of all sizes, to prepare for and to provide [. . . ]”. [CCS93, p.20] During the early 1990s Bill Inmon, widely recognized as the “father of the data warehouse” coined this term with his books on Building. . . [Inm92], Using. . . [IH94] and Managing the data warehouse [IWG97]. In this context in 1997 Jennifer Widom observed a gap between industrial and scientific advances and described Research problems in data warehousing [Wid95] that had been neglected in the past. At about the same time, major industry companies integrated their data warehouse and mining products jumping on the bandwagon. For example, IBM bundled a product called Intelligence miner 13 into their DB2 suite of database products. This process of integration can be observed at the biggest industry players until today in the year 2005. To describe the general development of the BI realm, evolution started in very specialized scientific environments. Out of this niche, results were soon used for corporate purposes but for a long time persisted as proprietary solutions with all their downsides. A strong increase in generated data volume beginning with the even stronger pervasion of business life with computer technology then lead to commercial off-the-shelf products being available. Regarding the usage of business intelligence and linked technologies, an intense shift took place: first because the majority of BI users today are neither scientists nor BI specialists but business domain experts; second because usage has heavily changed: while 10

See [CG74]’s bibliography for an overview on articles describing such uses ranging from 1963 to 1972. 11 Cp. [Hay02] 12 Cp. also [FPSS96, p.39] 13 also implemented in APL during development [Sel02]

52


4.1. The core of business intelligence in the past few top-managers were able to use BI solutions, today BI support within enterprises is often widespread throughout hierarchical levels.14 In many industries, business intelligence in its widest meaning is a standard.

4.1.3. The business intelligence concept As becomes clear from the definition given above, business intelligence is about leveraging the data that is available to an enterprise so that it can and will be used for improving the businesses’ actions. It implies that in the data a company has collected and constantly is collecting, information, knowledge or wisdom hidden at first are contained, which can be extracted and used and that such a use can in turn improve the quality of business actions. This improvement is considered to be of a higher value than the effort required for its acquisition. An example for the effectual use of business intelligence would be the search for the optimal point in time for a product launch. Assuming that product B is going to cannibalize the distribution of an older product A, BI could forecast (based on data of previous sales) at what time the launch of product B would minimize overall losses—and thus maximize profit. A similar result could also be achieved by an experienced product manager, but BI can make this information available to a wider audience within the enterprise. In general, all data or information that is available to an individual enterprise may be considered as a basis for business intelligence and its knowledge discovery. In practice, BI is usually considered to “work” on quantitative financial and sales data; nevertheless there are BI solutions available (and in use) that mine information from textual documents as well. Data source and type however are not decisive for BI. On principle, the character of the information that is relevant for an individual business and that of the information, which is extracted from the data sources, may strongly differ. For example a similar situation as in the example stated above cannot be found in a service company, because usually its business is not product-based. BI implementations thus need to be adapted to individual requirements. Nevertheless, the requirements of distinct industries resemble each other so that business intelligence can be standardized to a certain degree for such verticals. The same is true for the character of source data. As the core of business intelligence, the intelligence 15 part for knowledge discovery, differs from application to application, its implementation strategies also vary according to the contexts in which they are embarked. Whether an actual BI embodiment in a company should use statistical or heuristic methods to discover knowledge is an important decision in this individual project but not decisive for the BI concept as a whole. Nevertheless the currently used 14 15

Cp. information democracy in section 4.1.3 again in the meaning of information gathering

53

General idea

Character of information

Knowledge discovery


4. Business intelligence and its interactions

Information democracy

Link to management instruments

Fundamental rationale for BI

and typical implementation aspects of BI are in scope of this thesis as they determine the design of the interaction. They are thus covered in detail in section 4.2.2 on page 59. Naturally the types of information that actually can be discovered also depend on the character of the data. Usually, business intelligence can only tap its full potential if the information it provides is available to the employees that need to work with it. Business intelligence is thus often called an enabler for corporate information democracy that makes broad information available to a priorly unaware audience.16 For example, preliminarily managerial reports today are made available to sales staff who can now benchmark with their colleagues. Like other concepts in the realm of corporate management that strongly influence the way people work,17 business intelligence usually has strong influences on corporate processes. For this reason, the realization of the concept and the implementation of accompanying applications in a company needs to be carefully planned and executed. According to several authors18 , the most important point in this regard is the integration of the enterprises staff: a sponsor needs to be found and nominated as well as stakeholders and users need to be involved in the project19 . In practice BI implementation projects are often linked to the realization of instruments for corporate management. For example the key performance indicators (KPI) of a balanced scorecard may be used with slight changes for a notification of measured areas that under-perform. This linkage of instrument and application results in a particular constraint: for the employees, BI application and the managerial instrument are indistinguishable—so that success and failure depend on both. As most of the instruments of corporate management furthermore need to have immediate success as otherwise their credibility is lost, BI in such cases becomes mission-critical maybe even for the whole company. The reason most of the texts on business intelligence mention as justification for its use is the need to gain competitive advantage—often in conjunction with the threat of economic globalization. BI in fact is a good way to cope in aggressive markets; however, the author considers the ultimate rationale to be a more prosaic: using BI is one possible means to satisfy a corporate (and concluding human) want for pursuit of profit.

4.1.4. Business intelligence applications General business intelligence scheme

From a panoramic point of view the business intelligence embodiment in its corporate context consists of two parts, the actual BI application and the business processes that may perceive its influences. Intermediary and factual actor 16

Cp. e.g. [VM04, p.1], [BG04, p.2] like customer relationship management 18 Cp. e.g. [HW01, p.56], [GG00, p.115, 150] 19 The process of BI implementation in an enterprise as a project is not discussed in this work as it only marginally influences the BI application and even less the interaction with such an application. 17

54


4.1. The core of business intelligence in between this parts is a corporate user who interacts with the BI application to gather knowledge and then initiates business processes (or changes). A business intelligence application thus represents the means to fulfill the concept’s core and support its users in pursuing it. Describing the business process part of the presented scheme is not focus of this work, even if such a process influences the BI application, as e.g. the use of the managerial instrument balanced scorecard of course reflects in the BI application content and functionality. The technical modules of a BI application however build the main basis for content components and in turn the interaction with them, whose understanding again is vital to optimally design the latter. When discussing BI with employees in an “intelligent business” it is important to notice that those people will hardly differentiate application and processes in their parlance because this distinction does not have any practical meaning to them. Looking at the flow of data, information and knowledge in the presented general scheme, BI applications usually rely on a number of existing transactional databases. These are often geographically spread and may even include external data, e.g. competitive market analyses that are purchased from specialized service companies. The transactional databases are set up and optimized to support mostly operational tasks within the company and focus on a limited set of up-to-date data. Business intelligence applications in contrast require to have a history of data (of usually a few years) and are optimized not for transactions but for analytical purposes. Moreover the format of the data in the multiple sources may differ. For this reasons it is necessary for the BI applications to implement a detached data storage, which when centralized is called data warehouse or if distributed are called data marts. To integrate the data from the transactional databases into the warehouse20 , several steps need to be taken.21 As a first step, the part of the data that shall be integrated needs to be selected in the source database, as seldom all of it is relevant. Then it is to be extracted as a set that can be worked on. The following steps, transformation and cleansing are conducted in the most feasible order and consider the harmonization of data formats and namings and the clearing up of inconsistencies and erroneous information. If the data is preprocessed in such a manner, if may finally be loaded into the warehouse. Once this process is set up, a refreshment of the data is to be executed on a regular basis. Regarding the logical storage in the data warehouse, business intelligence applications with their analytic character also rely on data structures different from those of transactional ones. While the latter use traditional relational databases with two-dimensional table structures, BI analyses often incorporate 20 21

or analogously for the whole process into the data marts Naming and number of steps differ at different authors—however the actual tasks are the same. For example, the extract, transform & load scheme (ETL) usually considers the transform step to implement the data cleansing.

55

Source data integration

Logical data storage


4. Business intelligence and its interactions

Pre-computed figures

Intelligence layer

multiple dimensions. For example an analysis of A products in correlation with B regional markets and C the respective sales volume would be a common question in BI. Because such queries can hardly be executed with high performance in relational databases, BI warehouses rely on multi-dimensional storage, often referred to as data cubes 22 . This difference in data structure and query capabilities is referred to as online analytical processing (OLAP) in comparison to online transactional processing (OLTP) in operational databases. Additionally, BI warehouses often pre-compute figures like aggregations, means or comparisons so that those can be accessed without further calculation. As an example, sales data is often already aggregated for many permutations of product, region and time, so that a query for the total sales of all consumer products in northern Europe of the last quarter can be answered by a simple look-up. Built onto this data storage layer that covers gathering, storing and preprocessing the data is a layer, which is responsible for the actual knowledge discovery. It will be called the intelligence layer throughout this work in the sense that is given in the definitions at the beginning of this chapter. In the intelligence layer various and very differing methods are employed to gather information. They range from classical statistical methods over qualitative mining methods to the accomplishment of scenario-analyses—generally every method capable of creating information that can be justified and is suitable for business-relevant support of the user. For particular purposes it may even be necessary to create new methods.23 While their statistical background and technical implementation are not in the focus of this work, the outputs of this methods in terms of contents are covered in section 4.2.2 on page 59. Examples of the above stated methods, used for knowledge discovery could be • the statistical method of trend extrapolation with exponential smoothing, to forecast sales figures of cell phones for the next quarter, • the qualitative method of text mining 24 to automatically follow and cluster trends in the handset-technology by analyzing media-coverage and enterprise publications, and • the delphi method in scenario analysis to predict the future orientation of the whole industry of mobile devices.

User interface and presentation layer

It is thus the purpose of the intelligence layer to provide the actual content that will be presented in the BI application. This content will then be prepared for presentation and provided with means of interaction by a user interface 22

The cube metaphor factually only is adequate for three-dimensional analyses. As people usually lack an understanding of more than three-dimensional space, examples only present those—nevertheless multi means any number of dimensions greater than two. 23 Cp. [Sel02] for some examples of research conducted to outline new discovery methods. 24 cp. [GG00, p.212]

56


4.2. Interacting with business intelligence applications layer that finally allows an enterprise user to control and communicate with the application. As content types and possible interactions are the basis for the patterns outlined in part II, those are described separately in section 4.2. As a final technical layer there is a presentation layer that operates the display and handles user input etc. This layer is not different for BI applications than for other applications and for example consists of the Windows User Interface [Mic05] for a desktop application or of an Internet browser for a web-based one. To complete the image of business intelligence applications it is necessary to follow the information of BI beyond the final application layer. Having interacted and communicated with the presentation layer, an enterprise user will deploy the knowledge gained from BI in the company’s processes. The impacts of these actions in real business may and most certainly will be measured by other IT systems, e.g. an enterprise resource planning system (ERP). The output of such measuring systems often will be the data source and thus the input of business intelligence applications, therefore creating a loopback. One may thus consider the system to be a closed-loop,25 but in reality it is not closed to 100%: both in BI and the actual business, the information volume of in- and output may change. For example within BI, information may decrease during the data aggregation but increase in the knowledge discovery process; in business processes it is cut whenever an action is not measured and augmented when external data sources are integrated.

Information beyond the application

BI loop is not closed

4.2. Interacting with business intelligence applications 4.2.1. Interaction contexts & elicitors When reading the descriptions of business intelligence concept and applications in the previous sections, it becomes obvious that using BI is vitally different from using for example a word processing application because it ideally builds the direct basis for business-relevant actions. It is thought to be more than a simple tool to get a task done but a way to improve actions with an impact on the actual business itself. For the design of user interactions with BI applications it is thus important to understand the users’ contexts and the elicitors, having an effect on the interaction of users, in order to derive their goals concerning application usage. As a prerequisite for this consideration, it is assumed that business intelligence has been implemented and established in terms of concept and application in the corporate environment of the user. Moreover the user knows the BI application, is able to use it in terms of access authorization and usability as well as has a need for its use. 25

Dan Vesset and Henry Morris, analysts of IDC, e.g. construct a closed-loop decision-centric business intelligence model in a white paper [VM04, p.3].

57

Prerequisites


4. Business intelligence and its interactions

Management

As already outlined in the research context ( 2.2 on page 21), the concept of BI in its holistic approach entails having users from almost every department of the enterprise: management, finance & controlling, marketing & sales, procurement as well as production/service, administration and human resources.26 Users from these different departments naturally strive for differing goals, which are described below. Ultimately those goals are subsets of the enterprises overall objectives, broken down to the respective units. Within the goal descriptions, the term manage is used very often, which shall refer to the acts of planning, organizing, leading, co-ordinating and controlling subjects. The degree of relevancy for individual tasks and the support for each of these activities differ—while e.g. controlling is a common task done within a BI application, leading is something that is hardly directly supported and needs to be done in the social network of an enterprise that is detached from BI. The purpose of the management is to implement the enterprise’s objectives by using its resources while satisfying the stakeholders goals. With their focus on overview and leading without elaborate examination of details, management as a group and process may be comprehensively supported by business intelligence applications and information. BI can provide a sound basis of information for understanding processes, deciding on actions to be taken, planning those and after their implementation control their outcomes. BI may support managers of all but the lowest levels, from top to middle-managers, with strategical, tactical and operational information. In general, management users’ goals are to • strive for the enterprise’s objectives, usually reaching a defined profit increase, and • strive for the personal objectives, connected to business goals.

Marketing & sales

The marketing & sales department’s primary purpose is to sell products and or services (named P/S below) to the buyers of the company. Secondary purposes are the support of sales through marketing and the organization of the P/S distribution. All of these can be supported by business intelligence, resulting in the department’s BI users striving for • managing sales activities, • managing marketing activities, and • managing P/S distribution.

Procurement

In the procurement department, it is primarily important to ensure the provision of the goods that are needed for the accomplishment of the companies actions. The whole process may be supported by BI, resulting in the users’ goals of 26

There are other and differing topologies of departments in literature, however the one presented here is suitable for the inspection of goals regarding BI.

58


4.2. Interacting with business intelligence applications • managing purchasing, and • managing procurement logistics. Primary purpose of the production and/or service department is to create value added with P/S that can be disposed by the marketing & sales department. Whether the actual value-added process can be ameliorated by BI applications depends on the value created: while BI is hardly facilitating a physical manufacturing process, it may come in operation for intangible products a companies produces, e.g. market studies. In both cases, BI becomes deployed on the gateway of the P/S department to others within the enterprise. The P/S department’s users’ goals thus are

Production/service

• managing production in compliance to sales and marketing, and • using business intelligence applications’ information as a basis for the production of intangible assets. Purpose of the administration department (for the purpose of this work including the human resources department) is to efficiently organize human and material resources to support the enterprise in achieving its goals. As this department is providing a layer of support far away from directly reaching the enterprises targets, providing e.g. hygiene factors like office supplies, its potential of using BI is limited. The same is true for other departments, like research & development, which is often somewhat detached from the company’s everyday business and thus usually cannot benefit from everyday BI application usage.27 Of course, these departments and according business actions, which are not in central focus may profit from using BI when information is integrated that is more relevant for their business actions. This however is rarely the case today.

Administration and others

4.2.2. Typical and comprehensive business intelligence To build a basis for the derivation of interaction patterns and their language in part II of this thesis this section examines the different content components of business intelligence applications. To fulfill the need of a language to be comprehensive, it is aspired that the contents described share this nature. In addition contents need to be typical to allow for a generic validity of the language devised. To work towards the comprehensiveness of the described content, this thesis converges the content from three perspectives: first, contents are determined 27

Nevertheless R&D benefits from the information available in the application, for example when observing market developments. Such important developments however will be checked against in bigger intervals and in other contexts than personal BI application usage.

59

Comprehensiveness


4. Business intelligence and its interactions

Request to be typical

Information vs. functional components

Component taxonomy

top-down from theoretically possible component types taken from a devised information taxonomy and second determined bottom-up from practically oriented existing business intelligence application components from the personal experience of the author. Both are then undergone a matching check with a practitioner’s perspective from the various business departments identified relevant in 4.2.1 on page 57. The request for the content components to be typical is addressed by the narrow possibilities of component presentations as outlined below. The limited number of content presentation forms entails limited interaction possibilities so that the latter are essentially typical. As a general distinction of the content of a business intelligence application,28 components may be distinguished by their purpose: while the core components of BI applications are the information contents which aim at—naturally—the information of the user, the application also comprises of functional contents that fulfill the meta purpose of navigation and operation. A pie chart that breaks down profit to products serves as an example for the information content, while the navigational items to get to this chart or the function to save the chart image file to the local machine are functional content. The functional components however depend to a high degree on the information—if there was no pie chart, the function to save it would not be present. Examined from the perspective of an interaction designer, the information components evoke functional component requirements, which in turn provide the interaction layer. As the design of the latter is in focus of this work, interaction patterns are devised from the information contents of business intelligence. While different approaches have been considered for typing these information contents of business intelligence applications,29 the most significant for the determination of interaction possibilities is a typing by presentation form. Such typing leads to the following categories of information components: Numerical information is usually represented in a tabular, spreadsheet manner providing dozens of single (numerical) figures, which are systematically arranged according to an organizing principle indicated by the captions of columns and rows. The character of numerical information is displaying singular, elementary facts30 from which conclusions may and if applicable need to be drawn by a human user. Textual information is displayed as continuous blocks of text organized in natural language. If applicable structural elements like enumerations or visualizations like graphical figures are added. Textual information of quality often includes a sort of narrative that e.g. depicts a line of argument or 28

and other information systems, too Other meaningful typing possibilities could e.g be by degree of interaction or by application structure. 30 not indicating a validity thus including predictions

29

60


4.2. Interacting with business intelligence applications sets out a rationale. Its main focus is thus a presentation of a conceptual connectivity of facts. Graphical information is a visual and pictorial presentation of information of various natures, inconsistently referred to as graphics, charts or diagrams. As a general distinction, they may be discriminated into figurative and abstract ones with the latter being a lot more pervasive in BI context. Within the abstract category of graphical information, this work distinguishes charts, rendering numerical information (see above); and diagrams displaying non-numerical information, like interrelations of objects. Naturally there also exists graphical information that mixes abstract and figurative display, e.g. several bar charts on a geographical map. Mixed information is any information that consists of two or three of the above mentioned information categories in similar shares 31 . Multimedia information is information presented as a combination of several other single media (e.g. the ones above). It is different from the above defined mixed information as it includes a temporal dimension to at least one of the employed single media, e.g. video or audio and integrates those media to a high degree.32 Concerning the second announced perspective, the experience of the author, all contents from the above stated information categories are present in business intelligence applications33 —with the exception of multimedia content which is thus not covered in this thesis34 . The most pervasive content components of the BI applications the author has cognizance of, are reports showing numerical spreadsheet information. Those usually come along with graphical representations of data, whenever this is feasible. While the numerical data shows a lot of detail and allows for the most intense user interaction, the charts usually lack the same elaborateness and show data that is narrowed down to a special detail forming a default view. This originates from two facts: first because showing the same level of detail leads to problems in the visual design of the chart; second because graphical charts are intensionally used to provide a quick overview on a certain topic, e.g. a daily check for the sales volume in comparison with the previous period. 31

Information that e.g. is mainly graphical but has a small textual description, like a bar chart and its detailed legend are assigned to the graphical category in this work. 32 For an extended examination of these foundations from a different perspective, consult the chapter What is new media in [Man01, p.18-55]. 33 as of 2005, when this research was conducted 34 Multimedia information also does not appear in literature. It may nevertheless be used more often in the future as the combination of different media has some advantages over the use of its discrete fragments, e.g. allows for an easier recollection of perceived facts.

61

Practical BI application contents

Informational components


4. Business intelligence and its interactions

Functional components

For the visual display of the charts’ information, a wide range of diagram types are deployed, running from more simple bar, point or pie charts to more complex types like candle-stick or box-plot charts, often in more than one variant. However the more complex charts appear less frequent than the simpler ones, as they require more previous knowledge for comprehension. Accompanying this numerical information are textual contents like customer, product or market information. These are often meant to complement the very limited scope of the spreadsheets with a broader context. If applicable, domain specific expert knowledge may also be provided. As an example, an enterprise that manufacturing medical appliances may want to document surgical procedures to allow its sales representatives a detailed understanding of the needs of their customers—information that is adjacent to but not caught by standard market descriptions. Regarding the functional content in the web-based business intelligence application the author is familiar with, the general navigation is the most apparent one. It naturally answers the purpose of navigating the application to reach, view and interact with the different content components. Depending on the number and importance of the components, it places a list or a complex hierarchy of content elements at the disposal of its users. In some cases it may even be split into several parts representing the hierarchical levels (creating main and sub navigations). As a navigational aid there often exists a additional, detached general navigation, which provides access to meta contents like help, support or contact. Such a navigation will be called meta navigation in this work. Apart from this palpable navigations, a set of visually smaller and less important helper elements are often installed to assist the users in their way through the application: passive elements like introductory texts, explanations and descriptions as well as active elements like tooltips or progress bars. In addition to these clearly navigational components, all personalization elements—if present—also provide means similar to those of navigation: their customization of the application (to whichever degree) often includes or even solely forms ways to circumvent the use of the standard navigational and functional artifacts. For example, links to reports in demand are a popular personalization feature of BI applications. Also attributable to this class are customized settings of reports that may be saved and application-wide settings, like a currency selection. Ultimately, technical functions like the sign-in are also accountable. Besides these clearly informational and clearly functional/navigational components there also exists a third category of components, which within the application is often conceptually separated from the ones described above: overviews containing informational and navigational elements. These often aggregate information of several usually detached reports, —if applicable— process it into a neat diagram and provide a navigational link to the original data. Examples of such overviews are so-called dashboards, which e.g. present

62


4.2. Interacting with business intelligence applications sales variations as speedometers. Once clicked they lead the user to a detailed sales report. As a last check for comprehensiveness, the described content components will be cross-checked with the main requirements of the enterprise departments that are likely to have access. Based on their objectives identified in 4.2.1 on page 57, the following dimensions regarding the support a BI application may provide are checked. In addition suitable BI components are stated. Customization specifies the degree, users of a particular department will need and want to tailor the information to their needs for optimal support. This customization may be executed on several logical levels. For numerical information, common customizations include the selection of displayed entities, spatial or temporal adjustments as well as measuring units. As an example, information in a spreadsheet report could be customized to only show consumer products sold in Zimbabwe in the year 2000 with a measuring unit of acquisition costs. Detailedness indicates how voluminous and in-depth information is displayed and whether there is background information available, which may be consulted to enrich the original information. To give an example, a report with a default view of only a few rows may provide drill-down capabilities from figures of aggregated product groups to a single product. Accuracy refers to the factual exactness of the information displayed, which may differ corresponding to the effort put into data cleansing and transforming (see 4.1.4 on page 54). Its achievement is seldom visible within the actual information, but nevertheless vital for some users. The accuracy of accounts receivable may not be crucial for the work of a sales representative but nevertheless is for an accountant. When examining the management “department� for these dimensions, it is important to state that this includes most of the managers of other departments as well, with their differing job titles including supervisors, directors, department heads etc. All of them share the same need for a quick status-check of the supervised division. Regarding the dimension customization, requirements are relatively low: as management members usually lack the time to customize presented information to their needs, suitable overviews are adapted or built to their request. Likewise, the degree of detailedness is low as information needs to be presented aggregated and compacted. A perfect accuracy of the numerical information is not compulsory as the high level of aggregation usually equalizes imprecisions35 and decisions and actions taken are often not 35

Note that inaccuracies may of course add up in the worst case—nevertheless with common data qualities, errors do not make up considerable amounts in comparison to their level of aggregation.

63

Management


4. Business intelligence and its interactions

Finance & controlling

Marketing & sales

based on accuracy but on direction of the information. Similar is true for textual information. Content components suitable for managers thus are various sorts of overviews e.g. the so-called dashboards, aggregating and compacting information, or graphics. Inappropriate are numerical reports that need to be customized in advance or several pages of continuous text. In the finance & controlling department, customization of the information presented is only marginally required. Standard views usually have been adjusted to this department’s needs already and the analysis requirements are seldom off the beaten track. The requisite detailedness of the information could be classed as “middle”—low detailed aggregation reports e.g. are not sufficient for the financial assessment of the enterprise or its parts; in-depth information is again too explicit. The most valued character of information for finance & controlling however is accuracy, which is a prerequisite for accounting. Suitable components for this department thus are mainly medium aggregated, numerical reports with accurate numbers. Infeasible are e.g. graphical reports. In the marketing & sales unit, customization is a feature definitely appreciated, as marketeers and sales managers usually analyze particular aspects. This originates from the structure, the department often is divided in: responsibilities are placed on employees based on geography or product/service groups. A high degree of information detailedness is also necessary as e.g. sales representatives need to dissect their sales volumes down to single customers. A 100% accuracy of the data however is not vital because BI information usually only supports decisions that base on the personal experience, but is not the single source of information. Naturally, M&S information purposes also do not include accounting.

64


5. Research approach Contents 5.1. Introduction

. . . . . . . . . . . . . . . . . . . . . . .

65

5.2. Methods . . . . . . . . . . . . . . . . . . . . . . . . . .

65

5.2.1. Pattern design . . . . . . . . . . . . . . . . . . . . .

65

5.2.2. Pattern language contrivance . . . . . . . . . . . . .

66

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

68

5.1. Introduction In the preceding chapters the basics for this work as well as the two underlying concepts have been explored, examined and described—all with the ulterior motive of providing a sound basis for the design of a research approach as well as the contrivance of the actual pattern language, which makes up the ultimate objective of this thesis. Having examined the concept of pattern languages, the most decisive outcome regarding this chapter is the lack of an existing, suitable method for the creation of a pattern language in the realm of human-computer interaction. This absence requires the developing and testing of such a method. The description of business intelligence, its content and interactions again is the foundation for designing the interactions themselves, which necessarily needs to be conceived from the content present within the applications. Problems, forces and solutions regarding these interactions construct the core part of individual patterns within the language network. The connection of both, the design of individual patterns and the contrivance of a language organization then builds the outcomes of this work.

5.2. Methods 5.2.1. Pattern design The method used for designing the individual patterns for the language outlined in part II consists of the following four consecutive phases: Exploration describes the process of on the one hand elaborating the core of the business intelligence concept and on the other hand delineating the

65

Results determining the research approach


5. Research approach field. It serves to understand the BI concept as well as the capabilities it provides towards its “users”. Outcomes of this phase are detailed in section 4.1 on page 49. Analysis in a first step identifies possible contents and in a second validates their relevance to conceive typical and comprehensive contents. To do so, contents are examined and contemplated from different complementing perspectives. Conclusions of this steps are described in the remainder of the stated chapter 4 on page 49. Derivation and innovation then characterizes the process of actual interaction design: starting from the contents described, possible interactions are considered, selected and then conceived in detail. As set out in the research focus (see 1.5 on page 19), this work assumes that a reader is familiar with the actions and considerations of interaction design. Thus, the latter are only described when exceptional decisions are made. Documentation finally consists of structuring the conceived interaction designs into a pattern form, writing them down and visualizing them. The findings of this stage form the biggest contingent of part II.

5.2.2. Pattern language contrivance Organizing entities

Bottom-up approach

Top-down approach

As the objective of this thesis is to connect the conceived patterns and form a pattern language, it is necessary to use a structured procedure for its creation. As stated earlier, no such method has been found during the extensive research conducted in the context of this work. To organize entities in a bigger, structured system, two general purposeful approaches of varying directions can be thought of: A making up from detail to entirety and B deriving from entirety to detail. Both approaches are used for the contrivance of this pattern language. The first procedure, often referred to as a bottom-up approach, takes several individual patterns as a starting point. It then analyzes and designs their relations to one another, giving rise to an imaginary network. The section on related patterns, all pattern-formalizations include (cp. 3.2.3 on page 37) heavily assists this materialization. While some of the patterns share strong relations and thus pertain to a certain aspect or topic, other patterns however are more loosely related and delineate from this aspect. In such a way, aggregations or categories of patterns are constructed. On the one hand, this process is an “automated” one seeming to emerge from the patterns, but on the other hand may be controlled by their design and designer. All patterns arranged in their virtual groups as an entirety then only form a certain portion of the complete language—as they may be missing some top-level aspects that have not been considered with this approach’s direction. The second proceeding is top-down, which naturally approaches the organization problem from the opposite direction. It identifies fields of problems of a

66


5.2. Methods business intelligence application as a whole and then solves those in an abstract manner by breaking them down to individual solutions. The latter then can be refined again and again until a necessary concreteness and feasibility are reached. Unlike the bottom-up approach, top-down is not implicitly supported by the patterns, but based on the experience and knowledge of its conductor. However the the grade of incompletion of the approach’s result is similar to that of the bottom-up approach, as some details may not have been considered from the top-down perspective. Based on the natural support for the bottom-up approach, it is considered methodically to use the two approaches in their described succession. After both phases have been completed, a matching and unification of the two resulting problem-solution-networks is required. Even if neither of the two methods deliver complete solutions and their set union does not straighten out this defect, approaching a problem from two opposite perspectives in this manner is considered to deliver comprehensive results by the author.

Combination

If one intends to identify a method for this phase, they would presumably come up with the description trial-and-error. High quality results of the two individual processes however directly result in a smoother and less error-prone combination process. Assuming the existing skills of an experienced designer and the potentiality of a high quality solution, this is the case because the latter materializes from either direction of perspective. As a confession to the complexity of the process, quality assurance and refinement have to be employed. This may even result in an at least partial iteration of the whole process, as with every change of the pattern relations, other patterns are affected.

Refinement & quality assurance

Once the pattern language has been created this way, the only tangible organization principle within the language are the pattern’s relations—all aggregations and groups have remained virtual and are not documented into the pattern language. For its practical usage it is advantageous to have at least one additional organization principle and a respective set of categories giving the language a more solid structure.1 It may occur feasible to derive this principle from the groups created in the bottom-up phase, even though their result has to at least be adapted to the changes made in the combination process. Finally the organization principle needs to be oriented to the actual pattern language users and their needs—the latter are not automatically met by the language creator in the process of language construction. A more methodical approach is thus to focus the language organization on the actual language usage process, into which the language concept then may be optimally integrated.

Language organization

1

Cp. 3.3.2 on page 42

67


5. Research approach

5.3. Practical procedure

Raw material

Emphasis on business intelligence

Alexadrian form

Pattern storage and administration

Workshops & discussion

The practical procedure of creating patterns and their language implemented for this work has been aligned to the above methods as far as possible. To document individual patterns, the author reverts to existing representations of patterns, which then are abstracted. As patterns are in part documented proved solutions, the author falls back on some artifacts of these solutions, originating from two domains: business intelligence applications and interaction design artifacts. The first ones are available as screenshots from the application the author himself has designed2 and from product descriptions, white papers and case studies, the business intelligence industry provides. The latter are of course available from the existing human-computer interfaces the author is aware of as well as from books, papers etc. Complementing these existing solutions are the content and interaction problems identified and described section in 4.2 on page 57 and 4.2.2 on page 59. Some of the patterns found are not restricted to the use in business intelligence applications but provide answers to questions asked in other contexts as well. They are however included into the pattern language, because it otherwise would have stayed inconclusive and incomplete. The emphasis in the design of these more generic patterns yet has been shifted towards its business intelligence relevant character. The form each individual pattern is written in is based on the original Alexandrian form described in section 3.2.3 on page 37 as the author prefers it to the other, more technical formalizations available. It facilitates reading and allows for a more detailed and coherent description of problems and solutions in context. As a drawback it is less easily run over in a practically-oriented surrounding; however, this should not be too disturbing as the single patterns are relatively short. For the creation and administration of the patterns as well as their organization, the author uses electronic mind maps. Every single pattern is represented by a mind map having the branches problem, context, forces, solution and related patterns. Another mind map displays a visual overview of all patterns and parts of their relationships through simple arrow connections. Each pattern is available with a single mouse click from the index map. Apart from that the electronic form allows for an easy re-arrangement of both individual patterns as well as the index and evades the cumbersome handling of paper. During the process of language organization, print-outs of the pattern index as well as individual patterns have been arranged on movable walls. Patterns as well as their structure have then been discussed in workshop-character meetings with both BI and interaction design experts as well as persons new to both fields, to benefit from settled know-how influences as well as to learn from the 2

see appendix E on page 159

68


5.3. Practical procedure novices’ questions.

69


5. Research approach

70


6. Conclusion Contents 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.2. Assessment . . . . . . . . . . . . . . . . . . . . . . . .

71

6.3. Further research . . . . . . . . . . . . . . . . . . . . .

73

6.1. Summary This research has been conducted with the objective of developing a pattern language for the interaction with web-based business intelligence applications. This pattern language has been successfully conceived: more than 60 patterns have been developed and organized in the language context. The author is very confident that the solutions as well as their structuring system, the language, are of a high quality and contribute both to the scientific advancement in the area of pattern languages and the practical requirements of interaction designers in the field of business intelligence. In the course of creation, this thesis has experienced two major succeeding challenges: first, during the phase of exploration and examination of the underlying fields, it has become clear, that the process of creating a pattern language has not been documented in the past. This is the case although researchers as well as practitioners actually have undergone this process—which is proved by the availability of several pattern languages. The need for developing such a pattern language creation method is a direct result of this. As all analyzed prior research has neglected to give evidence on its procedures, this method could not be conceived without an elaborate examination of the focus fields and their contexts. For this reason, it has been unclear for four fifth of the period of research, whether the creation of the pattern language would be successful—which has posed the second challenge. However, as already stated, both challenges have been mastered.

General success

Challenges

6.2. Assessment As premeditated in chapter 1, this section assesses the outcomes of this thesis against the research objectives outlined in section 1.4 on page 19 to evaluate and criticize them. The primary objective of this research has been to provide the stated pattern

71

Language contrivance


6. Conclusion

Interaction & usability enhancement

Testing pattern language creation

Connection of fields

Documentation

Innovation

language. Since it is specified in part II, this objective has been met. Having reached this target, the language’s quality is the next criterion for the success of this work. When comparing it to the concept-specific aspects outlined in sections 3.2, 3.3 and 3.5 (starting from page 35), the language can be classified as comprehensive, connected and generative in the opinion of the author. Naturally, this general evaluation must be complemented with criticism of domain experts providing an objective view. The solutions described in the individual patterns for the most part describe proved solutions of the field, which is the core of the pattern language concept. Nevertheless, they have been complemented with innovative aspects the author has conceived, which have been successfully tested within an industry BI application. The interaction quality and usability of the solutions described in this language’s patterns exceed the usability achieved by other business intelligence applications, the author is aware of. The confidentiality of BI applications however inhibits a detailed benchmarking. Nevertheless, it is supposed that the use of this pattern language enhances the interaction with BI applications conceived therewith. During this research the concept of a pattern language has been tested in detail from the perspective of language contrivance. In this regard, it has proved full suitability for the purpose of interaction design. However, the general formalizations presented (cp. section 3.2.3 on page 37) lack support for a detailed description of the interaction design interface elements. If one intends to let application users (instead of professionals) design interfaces themselves, the employed form of mock-ups is hardly sufficient1 . Contrariwise, users will not cope with the task of interaction design on their own anyway, as they cannot provide the application’s developers with a suitable form of input. With the completion of the pattern language, one may now additionally test the language and its underlying concept in the application creation process. Nevertheless, during its creation, is has already become clear that the generative character of the language vitally supports the process of conceptual design, as it is heavily leading the language user through this procedure. The effort that can be saved in this way can be expected to be a benefit for the implementation of the business intelligence concept. In an overall evaluation, the aspired connection of the spectra of knowledge of pattern languages and business intelligence has been established. While this has been achieved without further constraints on a conceptual level, the differing academic natures of the two fields have strongly complicated the scientific research and the description of the areas. In addition to this concluding documentation, the research progress has been documented with an associated website, allowing first the thesis’ advisers to follow the process and second to achieve potential replicability. Apart from the above examined objectives set out at the beginning of this 1

To provide an example, detailed descriptions of actions on mouse events must be included.

72


6.3. Further research thesis, the author would like to evaluate the inventive ingenuity of this work. Although one part of the patterns contained in this languages has simply been documented as proved solutions and the other probably could have been conceived by an interaction designer experienced in the field of business intelligence, the contrivance of the language creation method and its application for the development of the actual language mark a true merit of invention, which contributes to the advancement of the scientific area.

6.3. Further research The research conducted with this thesis—although self-contained to a high degree—may be meaningfully connected to a number of aspects. Concerning the concept of a pattern language, adjacent research could focus on two important aspects: the enhancement of the actual language as well as the review and amelioration of the creation process. The developed pattern language may be enhanced by using it for actual business intelligence projects and carefully re-including the outcomes of this process. While in the process of creation, the language has already experienced two iterations of refinement in content and organization, such a practical iteration is considered to enormously contribute to its quality. The developed method of pattern language creation may be ameliorated by testing it for languages of other fields with a different number of patterns. As it represents the first documented method, its juvenileness probably calls for extended enhancements until it reaches maturity. Regarding the interaction design this thesis suggests, advancements in technology will surely influence the characters of the patterns. It thus will be necessary to adapt the interactions conceived herein to the recent capabilities of web technology. Most of the fundamental principles the patterns suggest are however unlikely to become completely out-dated, as they are oriented on intuitive handling, not on technological potential. An example of technological influences are the “new” capabilities of the Web 2.0, which has been a “hot topic” in the media when this research was about to be finished.2 The hype is based on Asynchronous JavaScript and XML (AJAX), which is a smart combination of pre-existing technologies.3 Its heavy use results in more desktop-like web applications: a page reload is no longer required to fetch new data from the server and user interactions include direct manipulation, e.g. drag and drop. To enhance the interaction patterns in this work, AJAX could for example be used to provide modeless feedback for tasks, that are modal currently. The pattern Processing indicator (see p.104) could for example be integrated into the “normal” content components and 2

Apart from front page topics in the German computer magazine c’t and the German MIT magazine Technology Review, it has even found its way into mainstream media. 3 The basic techniques used therein actually have been in use for years—admittedly not in this breadth and with the same advertence.

73

Concept of pattern language

Technology advancements


6. Conclusion automatically indicate task completion to the user. While individual aspects of the patterns’ solutions will surely benefit from these richer interactions, the entirety of the pattern language is unlikely to change remarkably.

74


Part II.

The pattern language

75


7. Basics Contents 7.1. Introduction

. . . . . . . . . . . . . . . . . . . . . . .

77

7.2. Language structure . . . . . . . . . . . . . . . . . . .

78

7.3. Using the language . . . . . . . . . . . . . . . . . . .

80

7.4. Language substantiation . . . . . . . . . . . . . . . .

81

7.1. Introduction This pattern language forms the result of research conducted in the context of a master of science thesis. It therefore only is a portion of the complete thesis document—extensive details on the scientific background are provided in the preceding part I. Even if practitioners just wanting to utilize the pattern language do not need to get into all these details, the main concepts underlying the language are a prerequisite for its successful usage. This introduction thus acts as a quick tour to get you started. For the exact and complete information please fall back on the preceding part I. The purpose of this pattern language (designated language from now on) is to support a professional team in planning and implementing a business intelligence (BI) application. To be more precise it considers applications that are technically web-based and provide information in a number of default views— resembling more an intranet than a desktop data-mining application. The focus of the language is to support the process of conceptual design of • the application’s information architecture, • its content characteristics, and • the user-interactions with the components of the application. Apart from its purpose, the ultimate goal of this language is to increase the usability of applications to help business intelligence hit its target. To additionally clarify what this pattern language is not: it does neither cover the principles and heuristics of interaction design, nor visual design, nor the programmatic implementation or the roll-out of business intelligence projects. Excellent literature on these topics is available—consult the bibliography beginning at page 158 for more information.

77

What is this pattern language for?


7. Basics

What are pattern languages?

Are solutions ultimate?

More information & contacting the author

As a consequence being able to resort to a sound knowledge in the aforementioned fields is an advantage for you as a reader. If the opposite is true, you may still expect decent results, as it is one of the core features of the pattern language concept to increase the quality of the derived solutions. The pattern language concept is a method to make solutions for recurring problems accessible. Each of these problem-solution-pairs is described in a socalled pattern. A number of patterns with references from one to the other is called a pattern language. Included in this specific BI language are more than 60 patterns; each of them is around one page long. However if you follow the guidelines given in Using the language ( 7.3 on page 80) you will not read them consecutively but start at a given point and then follow a guided path through the language, which is provided by the patterns’ cross-references. Moreover, reading and contemplating the patterns is considered to accompany the process of application design, putting one little brick of the application onto the other. While each individual pattern depicts a solution that proved successful in an actual industry BI application,1 you should not consider it the definite solution in every detail. Instead, it represents a sound basis for your own examinations of the respective problem and contemplations of the specific solution. It is probable that you need to adapt the solution to your particular situation (and especially to those of your application users). The underlying idea or concept described in a pattern however is solid enough to persist through all of its implementations. In short: using patterns supports, yet not substitutes your reflections. If you want to prove the author’s anticipation of your interest in the scientific background wrong and still want to read more about pattern languages, feel free to consult chapter 3 on page 31. Detailed information on business intelligence and its interactions can be found in chapter 4 on page 49. If you want to comment on the language or individual patterns, you are welcome to do so at mail@felixkaiser.com. Alternatively, you may visit this pattern language’s website at felixkaiser.com/go/bi-patterns.

7.2. Language structure

Pattern form

The patterns described in the following are collocated in a section structure, which is also inherent in the language. To grasp this organization, it is first important to understand the individual patterns. Those consist of five compulsory parts, which naturally include descriptions of the problem and its solution. Quoted in between is a section called context & forces. While the context considers when and in which surroundings the pattern should be applied, the forces describe which constraints it resolves. The remaining two sections effect the integration of the single pattern into the language: the introduction2 describes 1 2

read more about this in E on page 159 or more precisely superordinate context

78


7.2. Language structure from where you have come to the current pattern; the outro3 states to which patterns you should go from here. Optionally, a pattern may be complemented with an interaction design mockup depicting the textual solution. To summarize, patterns consist of 1. an introduction, stating from where this pattern may be reached, 2. a problem description, 3. its context & forces, 4. its core, the solution’s description, 5. an outro, noting where to proceed in the language, and optionally 6. an interaction design mock-up. To simplify apprehension, these sections are delineated typographically, with a visual emphasis on the problem and solution parts. Additionally, Pattern names (79) are started with a capital letter and emphasized as shown. The page on which the respective pattern can be found is included in parentheses. Peek at the pattern Sign-in page (84) to see an example. In addition to this structure of individual patterns, this pattern language organizes its patterns in three chapters, each with two subsections. Each section groups patterns of a specific aspect so that you may access them conveniently even when not in the process of designing an application. The three chapters and their focuses are: Conceiving information architecture considers the overall organization of a business intelligence application in terms of its front-end. Its first subsection provide patterns on structuring contents, for example so-called Index pages (89) that allow for an overview of contents available. The second subsection covers means of navigating through contents, e.g. Navigation (89) or Searching information (95). Developing content components then covers the characters and forms of application content. Its subsection modeling contents supplies patterns for full-page Content components (107) and their smaller relatives Content modules (87). In the following subsection, content layout is observed concerning BI-specific problems. To give an example, it is suggested to provide Information in context (117). Designing interactions finally considers the direct manipulations of the application by its users. This chapter is divided in the subsections interacting with content and application interaction. The first for example provides 3

or subordinate context

79

Pattern organization


7. Basics patterns for Customizing displayed information (120) that are oriented on content. In contrast, the second subsection is oriented on the application as a whole and e.g. describes an interface for a Support request (140). The sequence of the chapters is from more abstract patterns to more tangible ones. Following it in the process of application design thus resembles a topdown approach in terms of interaction design.

7.3. Using the language Where to start?

How to read a pattern?

A way through the language

As outlined in the previous section, using the language means “jumping” from one pattern to another—which naturally requires a starting point. Just like you would start to sign-in to an actual BI application, the pattern Sign-in page (84) is a good starting point to this pattern language.4 As you can see from its description on page (84), being a starting point, Signin page does not provide an introduction.5 Instead it immediately mentions the problem, describes the context and then states the solution. After reading through the pattern, you are advised to implement the pattern immediately in a first draft. Depending on your specific role, this could mean to write down your specific implementation in a concept, to visualize a mock-up or to even create its fully-fledged visual design. When doing so, keep in mind, that the pattern is a proved solution, but not the ultimate one and thus needs to be adapted to your context. If you are used to implement interaction design with a methodical system, feel free to integrate the pattern language concept. It blends well with all methods the author is aware of and may particularly do well when enterprise application users are integrated into the process, for example like it is the case with Goal-directed design 6 . In a next step, scan the outro of the pattern description for references to other patterns. The latter may be delineated into refining or continuative patterns. For the Sign-in page (84) a refinement is to phrase text according to Transparent communication (142). In comparison, a continuative pattern is the User home (87) page, which shall be displayed after successful signin. As you only started your way through the language, you should consider continuing to other patterns first and refine later. Thus pick such a pattern and continue reading. As you will notice, the new pattern will include an introduction, which describes from where it may be reached. In this manner, work your way through the language. Depending on the 4

Ironically, after implementing the pattern, your application’s users hopefully won’t need to sign-in anymore—as this is what the pattern suggests. 5 It is the only initial pattern. Others not include the outro part and are called terminal patterns. 6 Consult About face 2.0—the essentials of interaction design [CR03] for details.

80


7.4. Language substantiation efforts you put into the implementation during the process, this may take from hours to weeks. When you eventually reach one of the rare patterns that have no outro and are terminal, just go one pattern back and choose another continuative path. The patterns are mainly organized in a hierarchical structure but do cross-reference themselves, so there’s no need to note the path you have taken. When you begin to see patterns over and over, pause and review your progress. You may do so by reading through the lists of patterns given at the beginning of each chapter and note which ones you have not come across yet. Your application not necessarily needs to implement all patterns available from this language; however you should at least have considered the integration of every single one of them. If you feel like your application’s implementation is somewhat complete, iterate and refine. If you have not done so yet, now definitely is the time to integrate the application’s users into the design process. When the BI application meets the users’ needs to their satisfaction, you are done. Alternatively you of course may accept your sponsor’s approval, if other acceptance criteria have been agreed upon. As a last step review the whole process and if applicable make changes to your derived solutions as well as enhance the language with new patterns, you have found. If so, please do make your comments available to the author.

When to end?

7.4. Language substantiation The solutions provided by this language’s patterns have all proved successful in an industry project: they emanate from a business intelligence project conducted by the author. In this project, meeting the user’s goals regarding the application’s features has been considered to be just as important as optimal usability by its sponsors. The project covered planning, conceiving, designing, implementing and ameliorating the application over almost two years. During this process, a cross-European team of user advocates has been highly involved into the conceptual and interface design part. Hereby it has been ensured that the content and features, a specialized team of business analysts suggested, have met the needs of the users. The author’s primary function has been to match both and then ensure their implementation. After the application’s launch, the project has received voluminous and excellent feedback, from both the actual users as well as from the enterprise’s management. Naturally, criticism has also been expressed, which were collected and then used for the optimization of the application. At the time of writing, the BI application emerges victorious from an internal competition of applications across Europe and may enjoy a world-wide roll-out within the affiliated group. Notwithstanding such praise, this pattern language is an erroneous work of

81

Industry project

User integration

Success


7. Basics man. It thus needs the collaboration of your intellect to deliver. Conceive!

82


8. Conceiving information architecture Contents 8.1. Structuring contents . . . . . . . . . . . . . . . . . . .

84

8.1.1. Sign-in page . . . . . . . . . . . . . . . . . . . . . . .

84

8.1.2. Information architecture . . . . . . . . . . . . . . . .

84

8.1.3. User home . . . . . . . . . . . . . . . . . . . . . . . .

87

8.1.4. User salutation . . . . . . . . . . . . . . . . . . . . .

87

8.1.5. Index page . . . . . . . . . . . . . . . . . . . . . . .

89

8.1.6. Dashboard . . . . . . . . . . . . . . . . . . . . . . .

89

8.1.7. Meta application component . . . . . . . . . . . . .

90

8.1.8. Glossary . . . . . . . . . . . . . . . . . . . . . . . . .

91

8.1.9. Help manual . . . . . . . . . . . . . . . . . . . . . .

92

8.1.10. Error page

. . . . . . . . . . . . . . . . . . . . . . .

92

8.2. Navigating through contents . . . . . . . . . . . . . .

93

8.2.1. Navigation . . . . . . . . . . . . . . . . . . . . . . .

93

8.2.2. Split navigation . . . . . . . . . . . . . . . . . . . . .

94

8.2.3. Meta navigation . . . . . . . . . . . . . . . . . . . .

95

8.2.4. Searching information . . . . . . . . . . . . . . . . .

95

8.2.5. Content shortcut . . . . . . . . . . . . . . . . . . . .

97

8.2.6. Related information . . . . . . . . . . . . . . . . . .

98

8.2.7. Personal content shortcut . . . . . . . . . . . . . . .

98

8.2.8. What’s new? . . . . . . . . . . . . . . . . . . . . . .

99

8.2.9. Recently viewed pages . . . . . . . . . . . . . . . . . 100 8.2.10. Breadcrumb navigation . . . . . . . . . . . . . . . . 101 8.2.11. Content preview . . . . . . . . . . . . . . . . . . . . 102 8.2.12. User feedback . . . . . . . . . . . . . . . . . . . . . . 103 8.2.13. Progress bar . . . . . . . . . . . . . . . . . . . . . . 103 8.2.14. Processing indicator . . . . . . . . . . . . . . . . . . 104 8.2.15. Accomplishment indicator . . . . . . . . . . . . . . . 104

83


8. Conceiving information architecture Chapter overview Figure 8.1 on the facing page provides an introductory overview of all patterns described in this chapter. The single patterns are depicted as blue boxes, whereas their relations are displayed as directed edges, targeted at the patterns stated in their outro. The chapter’s initial pattern is highlighted. Relations to patterns of other chapters are also included. Those foreign patterns are presented as gray boxes. While the graph provides an overview of patterns and their relations, you should rely on the written patterns for a guidance through the language.

8.1. Structuring contents 8.1.1. Sign-in page This pattern is initial—there is no superordinate context. Problem

A business intelligence application user needs to be identified to access information. In most cases information provided in a business intelligence application is confidential and not openly available, even not for all users within an enterprise. Moreover volume and character of information displayed are dependent on the individual position of a user. To provide this security but also for accountability, legal and other reasons, every user of a business intelligence application must be authenticated and checked for authorization. Therefore:

Solution

If possible, automatically sign the user in to the business intelligence application, e.g. with a single sign-on (SSO) relayed by the operating system. As a fallback solution and for particular purposes1 provide a Sign-in page, which allows the user to authenticate themselves and the application to authorize their usage. As the sign-in page makes up the first contact to a potential user, welcome the user and phrase the page’s text (including error messages) very politely and according to Transparent communication (142). To absorb annoyances, questions and concerns, provide means to let the user issue a Support request (140) and contact a person directly (e.g. at an enterprise’s help desk). Once the user is authorized and has been authenticated, proceed to the User home (87). However, the first thing you should consider now is Information architecture (84).

8.1.2. Information architecture You have created a Sign-in page (84) as the initial application component and now need to organize the applications’ contents. 1

e.g. training or administration

84


8.1. Structuring contents

Figure 8.1.: Visualization of this chapter’s patterns 85


8. Conceiving information architecture Problem

Contents of a business intelligence application need to be organized in a way enabling a user to successfully access them. The many and voluminous potential Content components (107) of a business intelligence application that is to be conceived can only be used successfully2 when they are organized. Implementing such a structure is on the one hand necessary for the user to be able to work with the information provided and on the other hand vital for the long-term success of the application’s technical implementation. Organizing contents in this respect includes the contrivance of means to find and access them conveniently. To organize contents, one or more organization principles should be considered. These are finally dependent on the individual business intelligence application but in many cases can be similar to one or several of the following: Similarity of aspects Contents are grouped whenever they illumine similar aspects of information, for example all graphics, spreadsheets and articles considering the sales of the enterprise. Similarity of users Contents are combined whenever they are the preferred elements of certain user groups. For example, all staff of the marketing find “their” information in a special area. Similarity of type Aggregations are made based on the content type, for example all graphics are compiled in one area, all spreadsheets in another. In either case, the taxonomy should employ a preferably even distribution of content to groups. Avoid more than seven items in a group to allow for an optimal perception. In practice, the organization of contents should optimally be developed in face-to-face workshops with the actual users, for example as outlined in the process of goal-directed design as recommended in the seminal book About face 2.0 [CR03]. Yet the ultimate objective of organizing contents is providing an organization that is intuitive to the users—regardless of what other principles the supervisors, programmers, designers etc. prefer for whatever reason. Therefore:

Solution

Conceive and document an Information architecture that defines a structure of contents. Make sure that the resulting organization is according with the users’ mental models of the provided information. Use a systematical approach for conceiving Information architecture that is heavily influenced by the actual system’s users. To substantiate this abstract concept, all patterns in the remainder of this chapter Conceiving information architecture may be used. To start, provide 2

“Successfully” in this context concerns the success of business actions taken based on the information provided.

86


8.1. Structuring contents a User home (87) which acts as the user’s starting point for the application (where applicable preceded by a Sign-in page (84)). Use Navigation (93) as a central means to find and access contents in the Information architecture as well as alternative ways, for example Content shortcuts (97).

8.1.3. User home You have created the Sign in (84) page and now need a starting point for the use of the application that is displayed thereafter. The user needs an entry point to the business intelligence application’s information and a place to come back to, whenever they got lost.

Problem

Without a point of origin, the big amount of information contained in any business intelligence application remains unusable for any user: they need a single starting point to access information. Moreover, it is a technical requirement of a web-based application to display a start page and “wait” for user input. Beyond this natural requirements, a user will feel uncomfortable if they do not have a “home” they know and may return to whenever they got lost in the depth of the application’s information. Giving the user such a home provides them with the safety that whatever they do and wherever they go, they know a “safe place” to rest. Therefore: Provide a special page as a starting point for the application. Make its design and main content singular enabling the user to recognize its uniqueness.

Solution

To further communicate the feeling of personal ownership heavily use Customizing displayed information (120) for the page, so that the user may set it up according to their requirements. Prominently display a User salutation (87) to enforce personalization. Integrate the User home at root level in the Navigation (93) hierarchy. If there is special content suitable and available for the User home make it a Dashboard (89) to display those; if not aggregate content from beneath with an Index page (89). Figure 8.2 on the next page provides an interaction design mock-up of this pattern with Dashboard (89) characteristics.

Interaction design

8.1.4. User salutation You want to indicate personalization of the User home (87). Users cannot tell who is currently signed-in to the business intelligence application.

87

Problem


8. Conceiving information architecture Page header Good morning John Doe

Sales development

Geographical overview

in 1,000 EUR

Italy

Hydraulics

Last business day Daily average this year

781 612

Quarter to date compared to business plan Sales QTD

49,203

Business plan (smoothed)

47,770

Previous quarter

53,646

0 -6

Year to date comparisons Business plan

458,591

Previous year

515,002

Industry average

Total Europe

Year-to-date goal

Consumer products

Sales volumes

100%

Module: geographical mapping

+3 +6 [%]

Header incl. Navigation User salutation Module incl. level indicator, speedometer and mini bar chart

68%

Customization functionality

Sales YTD 472,349 + 3%

- 8%

-

+ 4%

0% France: 10% growth, under sales objective

John‘s favorites Sales performance Overall sales performance: customized to my sales regions Comparison to last year‘s sales (monthly) Product launches New product launches (YTD) in comparison to previous year Comparison to last year‘s sales (monthly) Profit forecast

Module: Personal content shortcut

Your favorite „Top 10 in sales“ has been deleted, as the report is no longer available (click to dismiss).

Page footer

Figure 8.2.: User home mock-up with Dashboard characteristics

In particular with single sign-in (see Sign-in page (84), users cannot tell from the application interface who is currently signed-in to the application. They may also be unaware of the fact that the application has identified them and shows them personal content, which if applicable may not be available to other users at all. Identifying the current user is also important for training and demo purposes. Therefore: Solution

Provide a consistently positioned interface element that indicates which user is signed-in to the application. Display the user’s real name3 and additionally welcome them with a polite phrase. Integrate the Application-wide preferences (140) into this element.

Interaction design

Figure 8.3 provides an interaction design mock-up of this pattern in the context of Navigation (93). Product performance

Sales performance

Product launches

Good morning John Doe Edit your preferences

Profit forecast Salutation with real name of user

Area index Button to access Application-wide Overall sales performance preferences Monthly sales performance Tooltip explaining the button’s function Sales regions Temporal comparisons

Figure 8.3.: User salutation mock-up

3

and ensure those are unique

88


8.1. Structuring contents

8.1.5. Index page You have created a User home (87) and the Information architecture (84) resulting in a gap between starting point and the actual contents. You have created a Navigation (93) and if applicable refined it with a Split navigation (94). In the gap between the application’s starting point and the actual contents, overviews of content beneath are needed for navigational purposes.

Problem

Whenever there are more Content components (107) than may directly be displayed on the User home (87), those cannot be easily accessed by the user. Naturally, Navigation (93) provides direct access to these components, but names of content components may not be sufficient for a user to recognize and find the information they require. As a consequence, the user does not necessarily know where to navigate to and needs at least one level of overview in his navigational path. Some users moreover are less stringent in their navigation and like to browse contents instead of strictly navigating to what they need—this behavior is not encouraged by standard navigation. Additionally, curiosity and explorative behavior shall be promoted as it increases application usage, supporting the business intelligence concept. Therefore: Provide pages that aggregate content components beneath by providing an index. Display descriptions of the individual components and make them accessible from this page. Throughout the whole application, design all Index pages consistently to provide an optimally recognizable overview for the user.

Solution

Display Content previews (102) (maybe enhanced with short Information explanations (114)) for the Content components (107) available below. In the Navigation (93), visually distinguish Index pages from Content components (107) to allow the user to recognize and benefit from them. If it is meaningful to directly display aggregated information of the Content components beneath, provide a smaller Dashboard (89) that summarizes the indexed pages. Figure 8.4 on the next page provides an interaction design mock-up of this pattern.

8.1.6. Dashboard You have created several Content modules (87) and want to integrate them. You want to give an overview of important information on the User home (87) or on an Index page (89)

89

Interaction design


8. Conceiving information architecture Page header Sales performance indicators Dashboard element

Dashboard element

Dashboard element

Header incl. Navigation, User salutation etc. Dashboard header Dashboard element, e.g. a speedometer Index header

Sales performance reports Comparison to last year Content preview

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur scelerisque. Aliquam posuere mi a nulla. Sed pretium. Ut in arcu. Vivamus sed neque.

Overall sales performance sales regions Content preview

See details

Profit forecast Content preview

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur scelerisque. Aliquam posuere mi a nulla. Sed pretium. Ut in arcu. Vivamus sed neque. Lorem ipsum dolor sit amet, See details

Last year‘s sales (monthly) Content preview

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur scelerisque. Aliquam posuere mi a nulla. Sed pretium. Ut in arcu. Vivamus sed neque. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. mauris ultricies feugiat. See details

Component description Link to component

Product launches Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur scelerisque. Aliquam posuere mi a nulla.

See details

Content preview

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur scelerisque. Aliquam posuere mi a n. Quisque elit orci, molestie at, sodales vel, condimentum eget, nunc. Maecenas a urna. Aenean id tortor. Mauris sit amet nisl id leo fermentum . See details

Page footer

Figure 8.4.: Index page mock-up Problem

Frequently checking several figures from various areas is time-consuming as all relevant content components need to be viewed consecutively. Some users of the business intelligence application will want to check on several key indicators without going into too much detail. This is especially true for members of the management levels, who should not need to access complex spreadsheets. They usually only check on indicators and then delegate the actual detailed analysis and clearance of the problem. An example for such aggregated indications are the key performance indicators of the balanced scorecard approach. Accessing such single indicators in the depth of information is possible but potentially generates high excise. Therefore:

Solution

Provide one or several pages aggregating figures that are frequently checked by the users. Visualize the information presented to allow for a faster recognition using graphical Content modules (113). Link the aggregated information to the actual source information for quick access whenever a further analysis is needed. If needs of different user groups differ vitally, either supply several adapted Dashboards or use customization to let users personalize the page. Populate the Dashboard with Content modules (113). If applicable, smaller Dashboards may also be elements on Index pages (89).

Interaction design

Figure 8.2 on page 88 provides an interaction design mock-up of the User home (87) pattern with Dashboard characteristics.

8.1.7. Meta application component You have created the Information architecture (84) and acknowledge that some contents do not fit into its organization.

90


8.1. Structuring contents Apart from the informational Content components (107) a business intelligence application also needs to inform the user of topics concerning the application itself.

Problem

The most substantial part of a business intelligence application beyond doubt is the business-relevant information, which is provided in Content components (107) and Content modules (87). However, there is a different kind of information, the user wants the application to provide in order to assist them in using it, e.g. a Help manual (92). Therefore: Provide pages detached from the actual informational Content components (107) that hold meta information, concerning the application itself. Visually differentiate these pages from others for easy user recognition.

Solution

Integrate the Meta application components into the application using a Meta navigation (95). Compare the concept to Meta information (136), which holds information “meta� to Content components (107). Often required Meta application components are Sign-in page (84), Glossary (91), Help manual (92), Support request (140) as well as Error pages (92) and Application-wide preferences (140).

8.1.8. Glossary Your are employing Common parlance (143) throughout the application, e.g. in Information explanations (114) and want to provide a place to look up terms and definitions used therein. You provided Tooltips (135) for individual terms and want to link them to a more extensive explanation. Not all users of the BI application are proficient in the terms used within the application and their definition.

Problem

Within a business intelligence application a lot of terms, names, captions etc. are used in a very strict meaning that has to be understood in detail to correctly interpret its information. However users may not share this knowledge with the application supervisors or simply not remember it and thus need to be able to look it up. Therefore: Provide a Glossary including all terms and their definitions as a Meta application component (90). In this Glossary, clarify definitions with striking examples from the real world of the application’s users. To make the Glossary accessible from every page, display a consistently positioned link in the Meta navigation (95). Ensure that Common parlance is used throughout the Glossary and Transparent communication (142) is employed. For explanations that go beyond the capabilities of textual descriptions provide personal assistance using Support request (140).

91

Solution


8. Conceiving information architecture

8.1.9. Help manual You have acknowledged the concept of of Meta application components (90) and want to provide such with a help manual. You implemented a Glossary (91) but need to provide more detailed explanations on the usage of the application. Problem

Some users will need help in using the application that goes beyond what is or can be provided alongside the information or the application functions themselves. Business intelligence applications provide complex information in complex relations that require some effort even when explained face-to-face. Ideally, a user already has all this knowledge prior to accessing the application. However this can neither be expected in all areas of information nor from all users. Whenever necessary premises are not met, elaborate explanations are required which cannot be given alongside the actual information of function in the business intelligence application. Even with Tooltips (135), Information explanations (114) and Function explanations (136) the available space is too limited. Besides, explaining e.g. the concept behind an information display is not the primary focus of the application and should thus be presented uncoupled to maintain a due proportion of effort. A complete and correct understanding of the information provided however is crucial for the users, as its use is business-relevant. Therefore:

Solution

Provide an online application manual whose explanations provide far more detail, than is available in the business intelligence application itself. Uncouple the manual visually and open it in a new window4 , so that it may be viewed concurrently. In the manual on the one hand explain what information is presented in the application; on the other hand show how the application may be used. Apart from all these basics, make the manual a business-supporting document, e.g. by providing sample cases, solved with the help of the application. Keep examples simple, yet powerful, so that updating the application does not require a complete revision. In the manual use Transparent communication (142) and Common parlance (143). Make a Support request (140) available in case the user requires personal assistance.

8.1.10. Error page You want to substantiate the pattern Meta application components (90). Problem

No application is error-free. 4

and take care of pop-up blockers

92


8.2. Navigating through contents Regardless of the technical quality of their implementation, business intelligence applications will run into situations where the normal front-end cannot be displayed, because an error has occurred being so severe that it cannot be handled by the application. In these situations a user’s vexation can be anticipated. Therefore: Provide an error page politely explaining that a non-recoverable error has occurred. Apologize to the user and provide a compensation, e.g. have a supervisor answer their information requirements on the phone. Provide the user with hints on how to react and recover (e.g. re-sign-in).

Solution

Let the user issue a Support request (140) which automatically includes the error message. Use Transparent communication (142) and Common parlance (143) in the error description.

8.2. Navigating through contents 8.2.1. Navigation You have created an Information architecture (84) and want to allow the user navigating through this architecture. Information architecture (84) needs to be substantiated with interface elements in the business intelligence application to allow the users to successfully identify and access Content components (107).

Problem

The organization conceived with Information architecture (84) presents a conceptual means of access to individual contents. This concept now needs to be instantiated with an interface element allowing the user to fetch the information they require for their business actions. Therefore: Provide a visually accentuated, omnipresent interface element, a Navigation, which visually presents the Information architecture (84) and allows the user to find and access Content components (107). In this navigation, highlight the currently selected path for recognition. If a high number of Content components (107) requires more than two levels of hierarchy in the Navigation, it may be feasible to use a Split navigation (94), which resides in two detached screen areas. At meta levels of Navigation, for example at points where navigation has been split, provide Index pages (89) to aggregate Content components (107) available beneath. One general Navigation, however is not sufficient for all users, as it only follows a single mental model. Alternative navigational elements may follow other

93

Solution


8. Conceiving information architecture possible models. Those should be supplied by e.g implementing Searching information (95) or Content shortcuts (97). Apart from the Navigation acting as a means to find and access information, it is also necessary to give a user orientation of where they have navigated to or potentially will go to. This may be accomplished with a Breadcrumb navigation (101) and Content previews (102). Whenever a user initiates processes that do not provide immediate results, integrate User feedback (103). Meta application components (90) should not be made accessible from the general Navigation, but from the Meta navigation (95). Figure 8.5 provides an interaction design mock-up of this pattern.

Interaction design

Sales performance

Sales performance

Good morning John Doe

Product launches

Highlighted main application area

Profit forecast

Area index Overall sales performance Monthly sales performance Sales regions Temporal comparisons Geographical comparisons

Area index Per month Per quarter Per year Per decade

Area Index page Content component Numerical content comp. Highlighted navigation area Highlighted Graphical content component

Figure 8.5.: Navigation mock-up

8.2.2. Split navigation You have conceived an Information architecture (84) embodied with a Navigation (93), but the number of Content components (107) renders it visually cluttered and makes it less usable than desired. Problem

Providing all accessible information from one single Navigation (93) interface element diminishes its usability, when a high number of Content components (107) requires Navigation (93) to consist of more than two hierarchical levels. Information architecture (84) organizes the available Content components (107) into groups and subgroups. If the number of Content components (107) results in many groups, who in turn require more than two hierarchical levels, this makes the visual and interaction design of the Navigation (93) interface element difficult. As a result it may not be as usable as required or may even render content untraceable. Furthermore, a Navigation (93) not including interim levels of aggregation (e.g. Index pages (89)), expects all users to exactly know what information to look for and where to find it. This naturally is not the case. If however, a

94


8.2. Navigating through contents user’s process of navigation was segmented into several steps associated with individual interface elements, this would improve. Therefore: Split Navigation (93) into several interface elements that follow the group or hierarchical structure of Information architecture (84). In most cases do not use more than two discrete content Navigations (93)5 , as otherwise these make user interaction more complex. Emphasize the connection of Split navigations with visual design and with connecting captions by repeating the last common navigational item.

Solution

Insert Index pages (89) to provide an overview of which contents are available beneath—at least on the split point of Navigation (93).

8.2.3. Meta navigation You have created Meta application components (90) like a Glossary (91) and want to make those accessible from every page. Some contents of a business intelligence application only have an auxiliary character and thus cannot be meaningfully integrated into the standard Navigation (93).

Problem

Following the information-semantic-based organization of Information architecture (84), standard Navigation (93) includes all Content components (107), providing the information part of business intelligence—however there are further Meta application components (90) that do not blend into this structure harmoniously. Those in addition are of application-wide importance, so that they should be accessible from every page. Therefore: Provide a specialized kind of Navigation (93), the Meta navigation, which exclusively provides access to Meta application components (90). Position it unobtrusively but findable on every page at a consistent position.

Solution

Compare this pattern to Meta information (136), which provides information “meta” to informational content.

8.2.4. Searching information You have implemented Navigation (93) and other navigational patterns but want to provide alternative ways of finding and accessing information. Standard Navigation (93) and its relatives provide access to the Content components (107) of the application by browsing. However, users 5

in comparison to e.g. the Meta navigation (95), which should not be counted

95

Problem


8. Conceiving information architecture who exactly know what they are looking for, but not where to find it, are not supported. Independent of the quality of the implemented Information architecture (84), there are situations when users will prefer searching functionality to standard Navigation (93) to find and access information: • The organizational principle of Information architecture (84) does not allow access to the artifact a user is looking for. As an example, a user wants all information on a specific product, but the organization principle of Navigation (93) are enterprise departments like production, marketing, sales etc. • A user knows exactly what information to access but not where to find it in the Information architecture (84) or cannot grasp its mental model. • A user wants faster access to a specific information than by browsing the navigational paths. For these reasons, searching functionality is a meaningful navigation supplement for all users—if the quality of results is high, it may even supersede standard navigation for some users. Therefore: Solution

Provide advanced search functionality that takes BI particularities into account. As successfully searching the actual information itself is hardly possible semantically, make Searching information heavily rely on Meta information (136). Apart from that, search in captions, legends, entities and measures in all Graphical (109) and Numerical content components (111). Search Textual content components (110) with traditional methods. When presenting results, enrich them with additional information, for example content type or application area, to support other mental models of information organization.6 Allow the user to enhance their search entering additional information to narrow down back-end efforts as far as possible and to get best results. In an effort of Transparent communication (142) ensure the user is aware of capabilities and caveats of the function. Provide Content previews (102) for the search results. Use Function explanations (136) to make the user understand how they may improve search results. Ensure that Meta information (136) is available as a basis for search technology.

Interaction design

Figure 8.6 on the facing page provides an interaction design mock-up of this pattern. 6

It may even be sensible to state understandably what search algorithms/methods have been

96


8.2. Navigating through contents Search

Element header Function explanation

Find the following phrase

Find

This is font size 10px

This is font size 11px

or select a phrase from your search history Advanced search Find the following items Report names Report descriptions Measures Entities (e.g. customer names)

Search the following areas Sales performance Product launches Profit forecast

8 elements found

This is font size 12px Expandable/collapsible advanced search

This is font size 14px

This is font size 16px

Search constrictions

Result header

Sales performance

Result area

Overall sales performance profit regions Comparison to last year‘s sales (monthly)

Profit

This is font size 8px

Overall sales performance: customized to my sales regions Spreadsheet with bar-chart: Comparison to last year‘s sales (monthly) Details monthly sales of the YTD in comparison to the previous year. forecast Customization allows narrowing down to Comparison to invidual last yearproducts

Individual result with relevancy indicator Content preview for selected result (on rollover)

Overall sales performance sales regions Sales performance: customized to my sales regions Last year‘s sales (monthly) 2 more results in this area

Figure 8.6.: Searching information mock-up

8.2.5. Content shortcut You have created a Navigation (93) based on the application’s Information architecture (84) but acknowledge that it represents a single mental model of organization. Navigation (84) does not reflect all feasible content access organizations, the users’ mental models may provide. Additionally it is too stiff and generates high excise for some special navigational tasks.

Problem

A single Navigation does a good job in representing a common compromise of a mental model to access content components. However, other mental models do exists that are feasible as well and should be followed. These will allow users not so familiar or comfortable with the common model to more efficiently navigate through the application. Additionally, for some tasks the standard navigation generates high excise, while alternative solutions can reduce this. Therefore: Provide a list of shortcuts to Content components (107) that can be used independently from standard Navigation (93). Whenever links may used.

97

Solution


8. Conceiving information architecture become invalid, provide an appropriate handling or a user notification. Substantiate the concept of Content shortcuts with Related information (98), Personal content shortcuts (98), What’s new (99) or Recently viewed pages (100). Provide Warning messages (142) for error handling. Interaction design

Figure 8.7 on the next page provides an interaction design mock-up for the specialized Personal content shortcut (98).

8.2.6. Related information You have created a Navigation (93) but want to provide alternative ways of content access by substantiating the concept of Content shortcuts (97). Problem

The user cannot identify information related to the one they are currently viewing. Whenever there is a strong relation between the currently viewed Content component (107) and another one, accessing this other component would usually mark a benefit for the user: viewing BI information in context contributes to understanding the bigger picture and thus augments the quality of actions derived. Navigation (93) alone does provide some hints on correlation with its structure7 ; it however fails to point out stronger relations between individual components on the same level or from completely different navigational paths (e.g. antipoles). Additionally, users cannot be expected to have an understanding of the application’s content as a whole and thus are unlikely able to find all relevant topics for their analysis. Therefore:

Solution

Provide a Content shortcut (97) interface element with every appropriate Content component (107) that links to related information within the application. Enrich each shortcut with a description stating the relation’s relevance as those are often so complex that the user may not be aware of them. This pattern is terminal—there is no subordinate context.

Interaction design

Figure 8.7 on the facing page provides an interaction design mock-up for the similar Personal content shortcut (98).

8.2.7. Personal content shortcut You have created a Navigation (93) but want to provide alternative ways of content access by substantiating the concept of Content shortcuts (97). You have provided functionality for Customizing displayed information 7

For example, Content components (107) from the same main navigational area naturally correlate regarding the organization principle; cp. Information architecture (84).

98


8.2. Navigating through contents (120) and want the user to be able to access their customized components easily. Accessing frequently used content components through standard navigation generates excise.

Problem

Users of business intelligence applications are usually responsible for defined aspects of distinct business departments. On account of this, they access the very same Content components (107) frequently, for example on a daily basis. Using the standard Navigation (93) for this purpose generates high excise, which the users are unlikely to accept. Similar is true for users who have used functions for Customizing displayed information (120) to adapt information display to their needs—such customized contents will probably also be accessed very often. Therefore: Provide an interface element allowing a user to save shortcuts to the currently viewed Content component (107) (while Remembering customizations (122)). Complement it with another element that displays all saved shortcuts. Place the first element consistently on every Content component (107), the latter for example on the User home (87). Provide simple functionality for structuring several shortcuts a user may save.

Solution

Error handling, as recommended in the more general Content shortcut (97), is particularly important for this pattern, as side-effects of linked components that have changed are more complex. If for example a spreadsheet has been customized to display a single product only, it has to be considered what actions need to be taken, when this product is no longer available. Figure 8.7 provides an interaction design mock-up of this pattern. John‘s favorites Sales performance Overall sales performance: customized to my sales regions Comparison to last year‘s sales (monthly) Product launches New product launches (YTD) in comparison to previous year Comparison to last year‘s sales (monthly) Profit forecast Your favorite „Top 10 in sales“ has been deleted, as the report is no longer available (click to dismiss).

Interaction design

Element header Function explanation

This is font size 8px

This is font size 10px

This is font size 11px

This is font size 12px

Category Shortcut

This is font size 14px

This is font size 16px

Remove shortcut Warning message

Figure 8.7.: Personal content shortcut mock-up

8.2.8. What’s new? You have created a Navigation (93) but want to provide alternative ways of content access by substantiating the concept of Content shortcuts (97).

99


8. Conceiving information architecture Problem

There is no way for a user to take notice of when new content or functionality has been added to the application which in the worst case prevents them from using it. Business intelligence applications are seldom static: they usually will be amended or enhanced with new content or functionality at some time. However, the mere addition will not let the application’s users benefit from the enhancements—simply because they are unaware of them. The supervisors and ultimately the enterprise as a whole, will however want to enforce usage to benefit from the effects of the enhancements on the business. Additionally, it is impossible for the application supervisors to call the users’ attention to a particular information, for example when the enterprise’s management wants all users to focus on the achievement of the year’s profit goal. Therefore:

Solution

Provide a Content shortcut (97) interface element on the User home (87) or on a Dashboard (89), which links to new or featured Content components (107). Enrich the links with a short description, so that the user may get an idea whether the enhancement is useful for them. Additionally, prepare a special, linked page that can be used to explain the new functionality in more detail. Automatically fill the element with new content. Nevertheless, provide the capability to let a supervisor complement featured enhancements manually. This pattern is terminal—there is no subordinate context.

Interaction design

Figure 8.7 on the preceding page provides an interaction design mock-up for the similar Personal content shortcut (98).

8.2.9. Recently viewed pages You have created a Navigation (93) but want to provide alternative ways of content access by substantiating the concept of Content shortcuts (97). Problem

If a user is constantly switching between two or a small number of content components, using the normal navigation generates a lot of excise. Using the standard Navigation (93) is not in all cases the most usable form of navigating through a business intelligence application. If a user for example frequently compares two Content components (107) placed deep in the hierarchy, this generates high excise: accessing them alternately requires the full navigational process each time. Having a shortcut to lately visited pages substantially eliminates this excise. Apart from that, it would also provide an enhanced orientation8 to the user of what has been their path and give them a comforting security of being able to go one or several steps back in their exploration process. 8

compared to Breadcrumb navigation (101)

100


8.2. Navigating through contents Therefore: Provide a Content shortcut (97) interface element on all pages with links to last visited Content components (107). List at least three of the last visited pages with the newest being on top to exemplify the function. More than five links are unlikely needed as well as harder to grasp for the user.

Solution

This pattern is terminal—there is no subordinate context. Figure 8.8 provides an interaction design mock-up of this pattern. Recently viewed pages Overall sales performance Product launches New product launches Comparison to last year‘s sales (monthly) Profit forecast

Interaction design

Element header

This is font size 8px

This is font size 10px

Page name (newest)

This is font size 11px

This is font size 12px

This is font size 14px

Page name (oldest)

This is font size 16px

Figure 8.8.: Recently viewed pages mock-up

8.2.10. Breadcrumb navigation You have created a Navigation (93) but want to provide additional user orientation. Viewing a Content component (107) a user may not remember what navigational path they have taken to this point. They feel uncomfortable and cannot go back the way they had come.

Problem

Whenever a user employs standard Navigation (93) to get to and view an individual Content component (107), they may naturally forget, which way they have taken. This effect is increased as the Navigation (93) does not provide the same level of environmental change in comparison to moving through the real world. The interface element may assist with a visual highlighting, but in non-trivial Information architectures (84) not all items can be seen at a glance. With drop-down Navigation (93) highlighting even disappears. Real-life-navigation includes the possibility to go back and turn to another direction—yet this is hardly possible with standard navigation interfaces. Users however feel more comfortable, if they have an understanding and feeling for where they are and how they can go back to where they came from. Such an orientation would also allow them to remember their position and come back later. Therefore: Provide a textual indicator of the navigational path taken by the user,

101

Solution


8. Conceiving information architecture leaving Breadcrumbs of all visited pages in the Navigation (93) hierarchy. Link every crumb to its respective page, acting as a navigational item as well. Of course, Remember customizations (122) on the linked pages.

8.2.11. Content preview You have created navigational elements as Content shortcuts (97) or Index pages (89) to assist the user in their navigational tasks and help them orient and want to further enforce this. You have implemented functions for Customizing displayed information (120) and want to help the user with judging their options. You have implemented Searching information (95) and want to give the user more information to evaluate the results. Problem

For a new or unfrequent user, navigating through a business intelligence application or using Customizing displayed information (120) is trial and error, because they do not know what expects them after clicking links. An enormous amount of information is present in a business intelligence application. Navigation supports finding the right one, but this is exhausting for new or infrequent users as no previews are available. The same is true for Customizing displayed information (120)—a user usually cannot predict which effects their configuration will have—and the overview of Searching information (95) result set. Therefore:

Solution

Provide Content previews whenever the user is to decide to select one of several choices, may they regard Navigation (93) or Customizing displayed information (93). Keep them visually as simple as possible but preserve the very determining character of the specific information. Compare this pattern to Information in context (117), which suggests a similar concept.

Interaction design

Figure 8.9 provides an interaction design mock-up of this pattern. Sales performance per region and country YTD

Content preview as used on an Index page

Shows sales volume, sold items and profit per region and country for the year to date. May be narrowed down to individual products and product groups.

This is font size 10px

This is font size 11px

Graphic showing actual contents as similar as feasible See details

Figure 8.9.: Content preview mock-up

102

This is font size 8px

This is font size 12px

This is font size 14

This is font size


8.2. Navigating through contents

8.2.12. User feedback You have created a Navigation (93) or Customizing displayed information (120) and want to provide feedback for tasks that do not provide immediate results. If an action does not provide immediate feedback on its completion the user cannot judge its duration which makes them feel uncomfortable.

Problem

On the Internet immediate feedback to an action taken by a user is often not provided without special effort of the application designers. The most widely used browser, Microsoft Internet Explorer, furthermore provides very poor feedback on the technical part of application access. Therefore: Whenever an action launched by a user is known to take a longer time, that they might expect from their experience with the remainder of the application, provide visual feedback that an action launched by the user has been started.

Solution

If it is technically possible, provide a Progress bar (103) to indicate duration. If the processing time cannot be judged, at least provide a Processing indicator (104) that is technically connected to the completion of the task.

8.2.13. Progress bar You want to substantiate User feedback (103), in particular after Customizing displayed information (120). A user is unable to judge the processing of an action they have launched due to the black box character of a business intelligence application.

Problem

Users naturally tend to get nervous and impatient when they launch an action and neither can decide whether it has been started nor are able to estimate its queue time. While the latter can be judged for real-life actions by visible indications or from experience, the complex implementation of a business intelligence application which is a black box for the user totally prevents this. Therefore: Provide a Progress bar as a visual indication on the process duration and its current degree of completion. Enrich it with every available and meaningful information, for example the estimated time of arrival, the number of processed items in proportion to the total amount, etc. Use a consistent visual design for all Progress bars. If progress or processing time cannot be calculated, as a fallback provide a Processing indicator (104).

103

Solution


8. Conceiving information architecture

8.2.14. Processing indicator You want to substantiate User feedback (103), in particular after Customizing displayed information (120). Problem

The user cannot decide whether an action they have launched is (still) processing. In business intelligence applications, some complex user requests may require anomalously long processing times—yet there are no comparative values from which the remaining time could be estimated. This may particularly be the case for database requests that are the result of the user Customizing displayed information (120). Those are often singular queries. However, if no indication is given at all, a user will feel uncomfortable, because they cannot judge whether their request has been started. They will also feel uncomfortable when they cannot decide whether the task is still running. Unfortunately a Progress bar (103) cannot be provided as the task duration cannot be specified for technical reasons. Therefore:

Solution

Provide an interface element indicating that the task has been started and is still running. State that the action has been taken but its duration cannot be estimated. Technically connect the widget to the actual task.9 Make this Processing indicator visually distinguishable from the Progress bar (103) to not mislead the user. Provide every available additional information that may help the user cope with his impatience. For example, describe how long the task may take at the utmost. Name individual phases of the task and mark their completion if possible. Use Transparent communication (142) in all texts to further the user’s confidence in the application.

8.2.15. Accomplishment indicator You want to substantiate User feedback (103), in particular after Customizing displayed information (120). Problem

A user may not be able to immediately recognize whether an action they requested has been accomplished. Many actions taken by a user in a business intelligence application are complex, both in their back-end implications as well as in the resulting information display, presented to the user. Nevertheless, implemented changes are not necessarily apparent, so that a user may not be able to judge immediately whether something has changed at all. 9

Do not use fake indicators as as soon they have once misled the user, they cannot trust the Processing indicator anymore.

104


8.2. Navigating through contents Additionally, the complexity of changes e.g. made by Customizing displayed information (120) and a long processing time may make a user forget what they have requested. Moreover the application must inform the user of errors that occurred while processing their request. Therefore: Provide an Accomplishment indicator at a consistent position that textually announces the accomplishment of the most recent action. Textually repeat the actual action name or a description. This pattern is terminal—there is no subordinate context.

105

Solution


8. Conceiving information architecture

106


9. Developing content components Contents 9.1. Modeling contents . . . . . . . . . . . . . . . . . . . . 107 9.1.1. Content component . . . . . . . . . . . . . . . . . . 107 9.1.2. Graphical content component . . . . . . . . . . . . . 109 9.1.3. Textual content component . . . . . . . . . . . . . . 110 9.1.4. Numerical content component . . . . . . . . . . . . . 111 9.1.5. Graphic legend . . . . . . . . . . . . . . . . . . . . . 112 9.1.6. Content module

. . . . . . . . . . . . . . . . . . . . 113

9.1.7. Geographical mapping . . . . . . . . . . . . . . . . . 114 9.1.8. Information explanation . . . . . . . . . . . . . . . . 114 9.2. Content layout . . . . . . . . . . . . . . . . . . . . . . 115 9.2.1. Assigning dimensions to axes in spreadsheet reports

115

9.2.2. Balance information volume . . . . . . . . . . . . . . 116 9.2.3. Information in context . . . . . . . . . . . . . . . . . 117

Chapter overview Figure 9.1 on the next page provides an introductory overview of all patterns described in this chapter. The single patterns are depicted as blue boxes, whereas their relations are displayed as directed edges, targeted at the patterns stated in their outro. The chapter’s initial pattern is highlighted. Relations to patterns of other chapters are also included. Those foreign patterns are presented as gray boxes. While the graph provides an overview of patterns and their relations, you should rely on the written patterns for a guidance through the language.

9.1. Modeling contents 9.1.1. Content component You have created the application’s Information architecture (84) and want to include the actual information contents into the application. You have created means of Navigation (93) linking to content that is not present yet. Business intelligence application users are no specialists for creating BI information, but for using it.

107

Problem


9. Developing content components

Figure 9.1.: Visualization of this chapter’s patterns 108


9.1. Modeling contents An enterprise cannot expect its employees to design and create the information that should be presented in a business intelligence application for themselves, since they are business domain experts, not business intelligence experts. Instead information needs to be prepared by BI specialists, for example the application’s supervisors. In accordance with Information architecture (84), they will identify user questions and provide the necessary information to answer them (as far as possible). The majority of users usually are inexperienced in requesting the information they require directly from the data warehouse creating everything from scratch. The reason for this on the one hand lies in the lack of “technical” BI knowledge but on the other is also based on the inability to identify possible paths to the required answers. Additionally, providing an information basis that then may be customized always prevents the intimidation of users.1 It may even be necessary to provide a feasible mental model for the users to grasp the situation and interrelations. Therefore: Provide precast information artifacts or Content components that illumine particular business aspects, required by the application’s users. As they form the primary and most important contents of the application let them take up as much screen space as possible—arrange other interface elements around them. Provide consistent visual design for the information displayed.

Solution

Contingent on the actual form of information presentation, provide Graphical (109), Numerical (111) or Textual content components (110). Enrich those with an Information explanation (114) and provide Contextsensitive help (134). If several components shall be displayed on a page (e.g. on a Dashboard (89)), use the smaller Content modules (87). Make sure to Balance information volume (116) on all components. If possible, show Information in context (117). Allow the user to Export content components (137) and provide Contextsensitive help (134) for this functionality. Figures 9.2 on the following page and 9.3 on page 112 provide interaction design mock-ups for two specializations of this pattern: graphical and numerical content components.

Interaction design

9.1.2. Graphical content component You want to provide Content components (107) with mainly graphical character. Some aspects of business intelligence information are most intuitively understood as a graphic. 1

Cp. [CR03, p.221]

109

Problem


9. Developing content components Graphical representations of information without dispute have advantages over numerical or textual ones: for example they can be perceived and understood much faster or provide insights that would have been easily overlooked in a spreadsheet. Naturally there are also drawbacks, as for example this strength may also bias viewers.2 As their benefits can be brought out especially in a fast-paced business context, graphics should be made available whenever appropriate. Therefore: Solution

Provide a Content component (107) with one or several graphics that illumine the respective content’s aspect. Conceive a group of possible graphic types and ensure consistency in their application and visual design to allow for a quicker perception by the users. Use a Graphic legend (112) to explain the component’s elements. Link every Graphical content component to its respective Numerical (111) one to allow users to check on the details. Enrich it with an Information explanation (114). When singular facts shall be presented, consider the use of Content modules (87) instead. Allow the users to Export content components (137). Figure 9.2 provides an interaction design mock-up of this pattern.

Interaction design

Page header Sales performance per region and country YTD Italy

Lombardy

[EUR]

Spreadsheet view

[pcs.]

264 K (+21%)

[EUR]

Export functions

Context 930 K

217 K

Main chart

1,520 (+19%) 1,280

40 K

Sales volume

Last year

Context chart 217 K

32 K (-20% )

Profit [EUR]

Legend

Sold items

Global sales

Current region’s sales

Description Current year (over plan)

Current year (under minimum)

Current year (under plan)

Header incl. Navigation, User salutation etc. Function explanation Customizing displayed information Export content components Link to spreadsheet

This bar chart shows sales volume, sold items and profit per region and country for the year to date. Global sales are provided as a context to compare sales to overall volume.

Meta information

Graphic legend Information explanation Meta info. (collapsed)

Page footer

Figure 9.2.: Graphical content component mock-up

9.1.3. Textual content component You want to provide Content components (107) with mainly textual character. 2

A very well-founded comparison can be found in the book The Visual Display of Quantitative Information[Tuf01]

110


9.1. Modeling contents Some BI information aspects can only be set out by the narrative form of continuous text.

Problem

While traditionally most of the information in business intelligence applications is of numerical type, this form lacks the capability to describe coherences and more complex circumstances. Detailed information, describing a conceptual connectivity of facts and comprehensive rationales, can only be presented in continuous text. Therefore: Provide Content components (107) with continuous text in the style of articles. If needed enhance them with figures, tables, enumerations etc.

Solution

Allow the users to Export content components (137), with the possibility to edit and re-use text as well as maintaining the original layout.

9.1.4. Numerical content component You want to provide Content components (107) with numerical character. Numerical information is the content-basis of a BI application. The design of those spreadsheets and related types of information however is complex.

Problem

Most of the information in business intelligence applications is of numerical character. While singular spreadsheets can easily be conceived and designed, providing a consistent structure and design throughout an entire BI application is a more complex task: a detailed understanding of the content’s parts and functional capabilities is a necessity to optimally design its interface to the user. Therefore: Provide Content components (107) with numerical information in the form of spreadsheets. When developing them, keep patterns mentioned in the following in mind.

Solution

Obey Assigning dimensions to axes in spreadsheet reports (115). Link the component to the respective Graphical content component (109) if such is available. When relatively simple spreadsheets are presented, consider the use of Content modules (87). To customize the display order, use Sorting numerical content components (124). Allow the users to Export content components (137). Figure 9.3 on the next page provides an interaction design mock-up of this pattern.

111

Interaction design


9. Developing content components Page header Sales performance per region and country YTD Italy

Chart view Sales volume [EUR] Last year (smoothed)

Profit [EUR] Growth

Last year (smoothed)

Abruzzo

203,114

289,555

43%

34,868

30,569

-12%

1,387

1,353

-2%

Aosta Valley

220,846

230,521

4%

43,772

31,386

-28%

1,098

1,317

20%

Apulia

210,178

235,389

12%

47,014

31,618

-33%

1,310

1,759

34%

Basilicata

250,528

240,932

-4%

43,994

37,981

-14%

1,243

1,608

29%

Calabria

257,034

294,461

15%

43,180

34,372

-20%

1,249

1,387

11%

Campania

251,314

256,293

2%

44,649

33,616

-25%

1,111

1,621

46%

Emilia-Romagna

242,633

298,413

23%

40,088

34,078

-15%

1,049

1,283

22%

Friuli Venezia Giulia

226,021

277,334

23%

42,102

30,070

-29%

1,065

1,506

41%

Latium

196,885

301,856

53%

44,102

35,945

-18%

1,233

1,349

9%

Liguria

237,358

222,581

-6%

40,633

34,435

-15%

1,301

1,392

7%

217,000

264,000

22%

40,000

32,000

-20%

1,280

1,520

19%

2,512,911 2,911,335

16%

464,402

366,070

-21%

13,326

16,095

21%

Lombardy Total

YTD

Export functions

Sold items [pcs.]

Profit

Meta information

YTD

Growth

Last year (smoothed)

YTD

Growth

Description This spreadsheet shows sales volume, sold items and profit for all regions of the selected country for the year to date.

Header incl. Navigation, User salutation etc. Function explanation Customizing displayed information Export content components Link to chart view Spreadsheet

Meta info. (collapsed) Information explanation

Page footer

Figure 9.3.: Numerical content component mock-up

9.1.5. Graphic legend You have created Graphical content components (109) and want to ensure users are able to fully understand them. Problem

Graphical information cannot provide enough detail to allow the user to completely understand its backgrounds. Graphical information is a very suitable means to display e.g. time-dependent progressions or to give a quick overview. However, it lacks explanations how the values it depicts have been calculated or which contexts they have evolved from. This is the case as the amount of space within a Graphical content component (109) is restricted, so that captions need to be extracted and displayed isolated. Additionally, graphics tend to become visually cluttered, if too much information is contained. Apart from that, automatically created graphics do not reach the quality of those manually adjusted and laid out, which makes considerate integration of legends impossible. Additionally, explanations and descriptions of the explained information’s background can only be conveyed in continuous text. Therefore:

Solution

Provide a legend holding captions for dimensions and symbols contained as well as explanations of calculation methods and backgrounds of the information presented. Compare the similar-purpose patterns Information explanations (114) and Context-sensitive help (134) for other Content components (107).

Interaction design

A basic Graphic legend is included in figure 9.2 on page 110.

112


9.1. Modeling contents

9.1.6. Content module You have created a Dashboard (89) or an Index page (89) and want to populate it. The sovereign posture of Content components (107) does not allow presenting several components at the same time to provide an overview.

Problem

As described in the patterns Dashboard (89) and Index page (89), users do not need to access detailed information all the time—instead, some of them prefer to view several key indicators on an aggregation level. Content components (107) however cannot provide such an overview: as they have been designed to provide information as detailed and complete as possible, their sheer size inhibits a side by side positioning. Therefore: Provide information display elements that let users view their preferred aggregated information in terms of key indicators. Visualize those as far as feasible. Make them no bigger than a quarter of full-screen space, so that they may be positioned side by side and on top of each other in a grid layout. In their visual design, emphasize their module character, for example by providing a common header and a module frame.

Solution

Enrich the modules with Function explanations (136). Provide the modules with means that allow Customizing displayed information (120) and Remember customizations (122). For spatial information, employ Geographical mapping (114). Figure 9.4 provides an interaction design mock-up of this pattern. Note that it only represents a fragment of possible visualizations as those are ultimately dependent on the displayed indicators. As an example, mini tables with top and flop lists are also imaginable. Sales development

in 1,000 EUR

Italy

Function explanation Hydraulics

Last business day Daily average this year

781 612

Quarter to date compared to business plan Sales QTD

49,203

Business plan (smoothed)

47,770

Previous quarter

53,646

Year to date comparisons Business plan

458,591

Previous year

515,002

Industry average

-

0 -6

Year-to-date goal 100%

Speedometer shows sales development Colors indicate accepted values and warnings

+3 +6 [%]

Level indicator

68%

Shows attainment of goals, color indicating the current progress

Sales YTD 472,349

Mini bar chart

+ 3% - 8% + 4%

0%

Figure 9.4.: Sample Content module mock-up

113

Interaction design


9. Developing content components

9.1.7. Geographical mapping Pattern description You have created a Dashboard (89), for example on the User home (87) and want to show problem indicators for numerical information based on geography. Numerical information that bases on spatial distribution, e.g. geographic regions, is very common in business intelligence applications. To provide an example, sales force is usually organized in regional structures, resulting in a single sales representative or a team accounting for sales volumes in this area. Without distinction, such information is stored with the “other” business intelligence information in the database and is thus as a default displayed in a numerical spreadsheet. It is assumed that most users’ mental models however are based on a visual representation of geographic regions, usually a simple map. Moreover, an overview on several regions can hardly be obtained from a spreadsheet report. The latter also cannot provide for a quick indicator of how regions are doing. Therefore: Problem

Spreadsheet reports do not follow the user’s mental model, if geographically distributed information is displayed.

Solution

Display information based on spatial distribution in a geographic visualization of this distribution, e.g. on a simple map. Design this visualization as an interactive graphic and use Context sensitive help (134) to explain how to use the element. Use functionality for Customizing displayed information (120) to let the users adapt the display to their needs. To explain the function and contents of the interface element as a whole, use Information explanations (114) and Function explanations (136); for its parts use Tooltips (135).

Interaction design

Figure 9.5 on the facing page provides an interaction design mock-up of this pattern.

9.1.8. Information explanation You have created Content components (107) or Content modules (87) and want to explain them. You have created Index pages (89) and want to describe aggregated contents. Problem

Information available from business intelligence applications is complex and needs context for comprehension. Many Content components (107) in BI applications present complex correlations so that they cannot be grasped from the actual contents themselves. This is especially true for spreadsheets, where it is nearly impossible to deter-

114


9.2. Content layout Geographical overview Total Europe

Consumer products

Sales volumes

Element header Function explanation Measure customization Division customization Country customization

Geographic map, changing to country and regional view Chart overlay, showing indicator values

France: 10% growth, under sales objective

Tooltip, showing numerals for indicators, linked to resp. country and ultimately spreadsheet

Figure 9.5.: Geographical mapping mock-up mine their meaning for sure, when not even a headline is provided. However, it is of enormous importance that all information in BI applications is correctly understood. Therefore: Provide an interface element explaining the aspects a Content component (107) or module (87) presents as well as its context. Display it integrated with the actual content, except when it is used as a description of aggregated content on an Index page (89).

Solution

Use Common parlance (143) and Transparent communication (142) throughout all explanations. Compare the similar pattern Function explanation (136). A short Information explanation is included in figure 9.2 on page 110.

Interaction design

9.2. Content layout 9.2.1. Assigning dimensions to axes in spreadsheet reports You have created Numerical content components (111). Inconsistent dimensions in Numerical content components (111) require users to adjust to every display anew. Different Numerical content components (111) tend to have recurring

115

Problem


9. Developing content components (or similar) dimensions displayed across their axes. As in practice reports are often designed by different application supervisors, assigning dimensions to axes may be done inconsistently. Some reports may even require assignments based on their orientation (e.g. when the time dimension is a lot longer and is thus displayed vertically). Therefore: Solution

Compile a list of possible report dimensions and define their default axes, paying attention to their semantics. For example, time is usually considered to be a linear, horizontal progression, while top and flop lists are oriented vertically. Compile priorities for these dimensions so that whenever two dimensions are to be on the same axis (as defined above), the one of higher priority can be identified. This pattern is terminal—there is no subordinate context.

9.2.2. Balance information volume You have created several Content components (107) providing means for Customizing displayed information (120). Problem

A business intelligence application becomes cluttered when information is distributed unevenly. The complex interconnections of the components of a business intelligence application make it hard to find a sustainable balance, which distributes contents evenly across the application. Without a balance, however the application will become cluttered and disordered, which lowers its usability and ultimately the perception of the information contained therein. The stated imbalance may e.g. concern the number of items in the Navigation (93), as well as the amount of information displayed on a single page. While at first sight no connection of both is apparent, they actually do have an influence on each other: the more information is contained within a single Content component (107) (or analogous module (87)), the smaller the number of elements in the Navigation (93). A similar dependence occurs concerning the number of customizations. In most cases a high number of customization possibilities leads to fewer information displays of lesser volume. To provide an example, a Numerical content component (111) may show manufacturing as well as sales numbers of an enterprise’s products without customization. If you use Selecting an entity from a list (130) to include a filter for single products, the display will become a lot smaller. You may further decrease its volume by splitting it up into separate spreadsheets displaying sales and manufacturing numbers and placing them in two different Navigation (93) areas—sales and production. In practice, this becomes even more complex as feasible solutions are dependent on the semantics

116


9.2. Content layout of information: in the given example, you may not split sales and manufacturing numbers if these need to be compared. Therefore: Balance the displayed information throughout the whole application. Vary its distribution with the parameters A volume of information display, B number of customizations and C number of navigational items. Prioritize your considerations in the given sequence: first, decide which information needs to be presented at a glance on one page, then determine necessary customizations and finally define the respective navigational items. Try to balance information so that individual Content components (107) take up one screen maximum.

Solution

Design functions for Customizing displayed information (120) and Navigation (93) according to the results of your considerations.

9.2.3. Information in context You have created several Content components (107) and want to ensure their correct understanding. Users cannot judge business-relevant (and thus critical) information comprehensively without context.

Problem

The information available from business intelligence applications necessarily and always is biased in some way. This bias e.g. emerges from the simple selection of facts displayed and those ignored. Presenting information as a part of a bigger context, however can prevent some of the biases and thus is an adequate way to decrease (but not completely avoid) them. While the context may seldom be presented in its entirety, even a short textual hint to remind users of its existence will yield better results than when they are not aware of it. Therefore: Provide the users with descriptions of the bigger picture surrounding the currently displayed Content component (107), depending on the component type. While the actual context naturally is contingent on the information, some examples can be given: Regarding Numerical content components (111) context may be provided by displaying interrelated measures, e.g. sales volumes as an enhancement to profits. Browsing along the time-axis may be simplified to allow for easy comparisons. Absolute values may be amended with percentages to show proportions in Tooltips (135). Additionally benchmarks from other enterprises in the industry may be supplied. Similar contexts may be given for Graphical content components (109). In Textual content components (110), background information and context may easily be given in the course of continuous text. To particularly

117

Solution


9. Developing content components highlight context, a short paragraph at the start of every article may be included. Use Common parlance (143) and in particular Transparent communication (142) when describing contexts. Providing Meta information (136) is another means of substantiating this pattern. Interaction design

Information in context is depicted in figure 9.2 on page 110.

118


10. Designing interactions Contents 10.1. Interacting with content . . . . . . . . . . . . . . . . 120 10.1.1. Customizing displayed information . . . . . . . . . . 120 10.1.2. Remember customizations . . . . . . . . . . . . . . . 122 10.1.3. Reset to defaults . . . . . . . . . . . . . . . . . . . . 123 10.1.4. Feasible default . . . . . . . . . . . . . . . . . . . . . 123 10.1.5. Sorting numerical content components . . . . . . . . 124 10.1.6. Selecting time ranges . . . . . . . . . . . . . . . . . . 125 10.1.7. Selecting measures . . . . . . . . . . . . . . . . . . . 126 10.1.8. Drilling & slicing . . . . . . . . . . . . . . . . . . . . 128 10.1.9. Selecting an entity from a list . . . . . . . . . . . . . 130 10.1.10.Selecting an entity from a hierarchy . . . . . . . . . 130 10.1.11.Selecting a graphic type . . . . . . . . . . . . . . . . 131 10.1.12.Problem alert . . . . . . . . . . . . . . . . . . . . . . 132 10.1.13.Content feedback . . . . . . . . . . . . . . . . . . . . 133 10.1.14.Rating content components . . . . . . . . . . . . . . 134 10.1.15.Context-sensitive help . . . . . . . . . . . . . . . . . 134 10.1.16.Tooltip . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.1.17.Meta information . . . . . . . . . . . . . . . . . . . . 136 10.1.18.Function explanation . . . . . . . . . . . . . . . . . . 136 10.1.19.Export content component . . . . . . . . . . . . . . 137 10.1.20.E-mail content . . . . . . . . . . . . . . . . . . . . . 138 10.1.21.Print content . . . . . . . . . . . . . . . . . . . . . . 139 10.1.22.Export content to application . . . . . . . . . . . . . 139 10.2. Interacting with the application . . . . . . . . . . . . 140 10.2.1. Application-wide preference . . . . . . . . . . . . . . 140 10.2.2. Support request

. . . . . . . . . . . . . . . . . . . . 140

10.2.3. Warning message . . . . . . . . . . . . . . . . . . . . 142 10.2.4. Transparent communication . . . . . . . . . . . . . . 142 10.2.5. Explain user rights . . . . . . . . . . . . . . . . . . . 143 10.2.6. Common parlance . . . . . . . . . . . . . . . . . . . 143

119


10. Designing interactions Chapter overview Figure 10.1 on the next page provides an introductory overview of all patterns described in this chapter. The single patterns are depicted as blue boxes, whereas their relations are displayed as directed edges, targeted at the patterns stated in their outro. The chapter’s initial pattern is highlighted. Relations to patterns of other chapters are also included. Those foreign patterns are presented as gray boxes. While the graph provides an overview of patterns and their relations, you should rely on the written patterns for a guidance through the language.

10.1. Interacting with content 10.1.1. Customizing displayed information Your application supplies various Content components (107) with standard presentations, but users request having other views as well and you want to find a remedy. Problem

Information may be presented in several feasible manners but only a single one can be presented as a default. Users, however want to access other views on information, too. According to Balance information volume (116), a single information display shall not take up more than one screen—however the analysis requirements of users demand to have illumined more than single aspects. Users thus need to be provided with functionality to identify, select and access the information of these other aspects. Examining information artifacts from different perspectives and comparing them, often is a major step towards a complete understanding and thus towards better decision making. Therefore:

Solution

Provide interface controls allowing the customization of the information displayed, so that it may be configured according to the user’s needs. In the best case, integrate these controls into the actual information; if the screen then becomes cluttered, at least visually group all customization functionality outside of information display. Provide a Feasible default (123) for the initial display, oriented on the needs of the target group. If several defaults are feasible choose the one with the widest acceptance. Whenever a user has used Customizing displayed information to adapt the presentation to their requirements, automatically Remember user customizations (122)—the fact that they have made the effort is a clear indicator that they want to have information displayed in the “new” manner next time. Nevertheless, always provide undo functionality by integrating Reset to defaults (123) with the customization controls. To substantiate customization semantically, several patterns are available:

120


10.1. Interacting with content

Figure 10.1.: Visualization of this chapter’s patterns 121


10. Designing interactions • Sorting numerical content components (124) describes interface elements that allow a re-ordering of spreadsheets, for example sorting product sales by sales growth. • Selecting time ranges (125) lets a user choose the temporal basis of a report, e.g. the first quarter of 2006. • Selecting measures (126) concerns the customization of measures to display in the information, e.g. profit instead of sales. • Drilling & slicing (128) describes the interface elements for the slicing and drilling functionality in on-line analytical processing (OLAP) cubes.1 • Selecting an entity from a list (130) changes the artifacts a report displays, e.g. products instead of customers. It shall be employed when a maximum of 49 items to choose from is available. • Selecting an entity from a hierarchy (130) also changes the artifacts displayed, but shall be used whenever more than 49 items are available and those are organized in a complex hierarchy, for example an enterprise’s product hierarchy. • Selecting a graphic type (131) changes the diagram type of Graphical content components (109), e.g. a bar chart instead of a line chart. To indicate constraints, warnings or errors concerning customization, display a Warning message (142). In order to allow users to solely access content in case of trouble, provide Problem alerts (132). If the customization will not provide immediate results, integrate User feedback (103). Customizations that are not bound to Content components (107) can be accomplished with Application-wide preferences (140).

10.1.2. Remember customizations You have implemented functionality for Customizing displayed information (120) and want to deliver the users from re-doing customizations with every access. Problem

Users accessing functionality for Customizing displayed information (120) in mosts cases require this customization for their work with the information. They, however need to re-do it every time they access the respective Content component (107), which generates excise. As outlined in Customizing information display (120), users want to access different perspectives of the displayed information. Whenever they make 1

In case you are unfamiliar with this functionality in regards on data access, consult [CD97, p.4] for an introduction.

122


10.1. Interacting with content the effort to configure such a differing view, they in most cases want to have this customization remembered: first because their requirements on the perspective will probably be the same or very similar during their next visit; second because they will feel more comfortable with this, as it is a natural behavior2 . Therefore: Automatically remember settings employed by Customizing displayed information (120) and always recall this configuration prior to information display. Visually indicate that the user is viewing a customized display that can be reset to its Feasible defaults (123).

Solution

Supply Reset to defaults (123) to enable the user to delete saved settings. Let the user create a Personal content shortcut (98) to quickly access customized information displays, whose customizations are remembered.

10.1.3. Reset to defaults You have implemented functionality for Customizing displayed information (120) and Remember customizations (122) but want to provide a means to restore the initial information display. When a user has used Customizing displayed information (120) they cannot get back to the initial display.

Problem

Customizations employed by a user shall generally be considered superior to the default view (implemented by Feasible defaults (123)) and thus need to be remembered. A user may feel the need to get back to the original view of information, e.g. for comparison with other reports or as a common basis for analysis together with another user. Therefore: Integrate an interface control into the interface elements for Customizing displayed information (120) that resets the current presentation to its Feasible defaults (123). Disable it, when no customization has been employed and visualize this.

Solution

When this function is initiated, restore Feasible defaults (123).

10.1.4. Feasible default You have defined Content components (107) and need to provide an initial display status. You want to implement Reset to defaults (123) and need to define this default. Displaying Content component (107) demands for an initial status of 2

Consider the opposite in real life: you put a knife on the kitchen counter to use it, but every time you leave and come back to the room, it is back in the drawer.

123

Problem


10. Designing interactions the element. Additionally having the possibilities of Customizing displayed information (84) requires a default to come back to. The complex information available from business intelligence applications almost always may be presented from different perspectives effectuating slight or vital changes concerning possible conclusions. Naturally, at least one default view has to be chosen by the application’s supervisors, which reflects most users’ requirements regarding the presentation. As this standard view may reflect the “usual” perspective on the facts, it should also be possible to come back to it anytime. As giving the user the power of Customizing displayed information (84) also enables them to mess it up—it is thus feasible to make the user able to reset the display to the standard. Therefore: Solution

Provide a Feasible default for every display of a Content component (107). Ensure that this view is technically always available. Starting from this Feasible default, a user may use functions for Customizing displayed information (84) to adapt the display to their needs.

10.1.5. Sorting numerical content components You want to substantiate Customizing displayed information (120) and let users determine the sequence of elements displayed. Problem

The information displayed in a spreadsheet report represents a (default) order which the user wants to customize to better fit his needs. Whenever Numerical content components (111) are displayed, a default arrangement of information is included resulting in a particular sequence of information. According to Feasible defaults (123) it should meet the needs of most users in most cases. Sometimes however, having another sequence would better meet the user’s objectives. Therefore:

Solution

Provide interface elements for changing the order of rows or columns of the displayed information. Integrate it with the actual information display and make it apply changes without further affirmation. Provide a clear visual indicator for the existence of a sequence, its ordering principle, direction and its subject. Integrate it into the caption of the sorted dimension. Provide a Feasible default (123) for the order of the display, oriented on the needs of the target group. If several defaults are feasible choose the one with the widest acceptance. The fact that a user has made the effort to change the sequence is a clear indicator, that for this action, the application should Remember customizations (122). To provide a sort of undo, also supply Reset to defaults (123).

124


10.1. Interacting with content Figure 10.2 provides an interaction design mock-up of this pattern. Sales volume [EUR]

Profit [EUR]

Region

Last year (smoothed)

YTD

Growth

Abruzzo

203,114

289,555

43%

Aosta Valley

220,846

230,521

4%

Apulia

210,178

235,389

12%

Basilicata

250,528

240,932

- 4%

Calabria Campania

257.034

294.461

15%

Sales volume [EUR] 251.314

256.293

2%

Last year (smoothed) 242.633

298.413 YTD

Growth 23%

Friuli Venezia Giulia Latium

226.021 196,885

277.334 301,856

23% 53%

Abruzzo Latium

196.885 203,114

301.856 289,555

53% 43%

Emilia-Romagna Liguria

237.358 242,633

222.581 298,413

-23% 6%

217.000 226,021

264.000 277,334

22% 23%

2.512.911 217.000 2.911.335 264.000

16% 22%

Region Emilia-Romagna

Friuli Venezia Giulia Lombardy Lombardy Total Calabria

Interaction design

257.034

294.461

15%

Aosta Valley

220.846

230.521

4%

Campania

251.314

256.293

2%

240.932

-4%

Unsorted column, click to sort ascending Ascending sorted column, click to reverse sorting

Profit [EUR]

Descending sorted column, after double-click

Figure 10.2.: Sorting numerical content components mock-up 210.178 235.389 12%

Apulia

10.1.6. Selecting time ranges Basilicata 250.528 YouLiguria want

237.358 222.581 -6% Customizing displayed

to substantiate information (120) to let Totalconfigure what time range 2.512.911a 2.911.335 16% a user Content component (107) is based on. Users need to change the temporal basis of a Content component (107) for their analysis purposes, yet it is complex to provide interactions for potential selections. Most of the Numerical (111) or Graphical content components (109) available from business intelligence applications include a temporal dimension, which initially is displayed with a Feasible default (123), e.g. the last month. Users however cannot rely on this default for their analysis purposes— they need to be able to customize the time range displayed. While the semantical selection is relatively straightforward, its interaction design experiences complex constraints: • Time ranges heavily vary in their scope per report: they may span from some days to some years with their borders being Sales volume [EUR] Profit set [EUR]at “natural” calendar items like full months or at individual dates. Region Last year (smoothed) YTD Growth Latium

196.885

301.856

53%

Emilia-Romagna

242.633

298.413

23%

• Some selections made may not be feasible for the information the report Abruzzo 203.114 289.555 43% presents. The data for this period may even not be available. Veneziafrom Giulia static time 226.021 •Friuli Apart ranges, 277.334 there also 23% exist logical ones, e.g. previous Lombardy 217.000 264.000 22% month or month-to-date the user wants to select. Calabria

257.034

294.461

15%

Apulia

210.178

235.389

12%

Aosta Valley

220.846

230.521

4%

Campania

251.314

256.293

2%

Basilicata

250.528

240.932

-4%

Liguria

237.358

222.581

-6%

2.512.911 2.911.335

16%

Total

125

Problem


10. Designing interactions • Business-specific definitions of temporal items, e.g. differing calendar and accounting years, further complicate display and selection. Taking all these constraints into account will result in a complex interface design. Therefore: Solution

For the interface design of Selecting time ranges rely on the most widely accepted basis: a usual calendar. Thus, provide a calendar interface control as a basis for all interaction and enhance it with the particular functions needed for the Content component (107) displayed. If the usability of the control should get poor, consider breaking up the analysis capabilities in several reports obeying Balance information volume (116). If two time spans shall be compared, provide a double calendar interface for the two selections. In either case, do not automatically apply settings on every click. Instead, provide an apply button to let the users comfortably configure their time spans. Enrich the interface with Function explanations (136) to explain its behavior.

Interaction design

Figures 10.3 and 10.4 on the facing page provide interaction design mock-ups for the two characters of this pattern. Select a time range to display 2005 Q1

Jan Feb Mar Q2

Apr May Jun

Q3

Jul

Oct Nov Dec

CW

M

T

W

T

F

S

S

5

1

1

2

3

4

5

6

Aug Sep Q4

6

7

8

9

10

11

12

13

7

14

15

16

17

18

19

20

8

21

22

23

24

25

26

27

9

28

1

2

3

4

5

6

to

17.02.2005

Free time range From

17.02.2005

Apply range

Current year, selects full year Function explanation Next year Selects full quarter Selects full month Selects all Sundays from displayed month Selects full week Selects a single day (currently selected)

Free time range selection (synchronized with calendar) Date entry for start date End date Applies selected range to displayed information

Figure 10.3.: Selecting time ranges mock-up: single time range selection

10.1.7. Selecting measures You want to substantiate Customizing displayed information (120) to let a user configure what measures are displayed. Problem

Users have varying requirements for the measures displayed in Numeri-

126


10.1. Interacting with content Compare time ranges A and B A

Second calendar for comparisons B

2005

2006

Q1

Jan Feb Mar Q2

Apr May Jun

Q1

Jan Feb Mar Q2

Apr May Jun

Q3

Jul

Aug Sep Q4

Oct Nov Dec

Q3

Jul

Aug Sep Q4

Oct Nov Dec

CW

M 27

T 28

F 31

S 2

CW

M 27

T 28

F 31

53

W 29

T 30

S 1

13

W 29

T 30

S 1

S 2

1

3

4

5

6

7

8

9

14

3

4

5

6

7

8

9

2

10

11

12

13

14

15

16

15

10

11

12

13

14

15

16

3

17

18

19

20

21

22

23

16

17

18

19

20

21

22

23

4

24

25

26

27

28

29

30

17

24

25

26

27

28

29

30

5

31

1

2

3

4

5

6

18

1

2

3

4

5

6

7

to

31.03.2005

to

30.06.2006

Free time range A From

01.01.2005

Smooth values

Last available data (assuming today is 13th April 2006) Arrow indicates continuing selection

Free time range B From

01.04.2006

Compare ranges

Smoothes out differing range lengths Applies selected comparison ranges

Figure 10.4.: Selecting time ranges mock-up: dual time range selection for comparison purposes cal (111) and Graphical content components (109) according to their responsibilities in a business.3 Most Numerical content components (111) in business intelligence applications rely on one or more measures as semantic units of numerals.4 Examples for such measures are more general terms like profit or sales volume but may also include very detailed differentiations, e.g. price averages in- or excluding free samples. The last example makes clear that different conclusions may be drawn from the displays, varying with different measures selected. It is thus a must for BI application users to compare the measures. Therefore: Provide a control for changing the measure(s) of a Content component (107). If the measure only occurs once in the component, integrate it into the information display; otherwise integrate it with the functions for Customizing displayed information (120). According to the number of measures available, structure them in a flat list or into categories. However, keep a hierarchy as flat as possible. If the control’s list is hierarchical, provide a visual indicator on A the element which is currently selected, as well as B the path that has been taken to this element in the hierarchy. If there are many items in the list of measures and users are known to often use only a handful of these, extract the more probable ones to a special place at the top of the list. Ensure that all measures listed are defined in the Glossary (91) and ex3

While e.g. a finance controller will show more interest in profit, a sales person mainly considers sales volume. 4 sometimes complemented with a currency, cp. Application-wide preference (140)

127

Solution


10. Designing interactions plained in the Help manual (92). Naturally, they should be phrased according to Common parlance (143).

10.1.8. Drilling & slicing You want to substantiate Customizing displayed information (120) and let users view varying aspects of information. Problem

Accessing and viewing information from multi-dimensional data sources needs detailed understanding of its logical model, which cannot be expected from the users. The cube data model that is the technical foundation of many information displays in business intelligence applications opens up a great deal of possible views on information contained therein. The number is naturally diminished, as not all perspectives are feasible for the the users—still there are many meaningful views to choose from. Off-the-shelf business intelligence products often allow and require users to compile their information display from scratch and thus heavily overextend novice and intermediate users. Both groups manage their information requirements more successfully, when they have limited customization functionality connected to a default view. Even advanced users will appreciate simpler functionality when the information presented is sufficient. The standard drilling and slicing access procedures for multi-dimensional data should thus be simplified as far as possible. Therefore:

Solution

Provide interface controls that allow drilling and slicing, but hide their complexity to the user. For exclusive slicing, see the outro for suitable patterns. Regarding drilling always provide a combination with slicing, so that a drill-down on an item automatically slices to its sub-elements. See the mock-ups for an example. The suggested simplification allows users to easily understand the outcomes of their interactions, as most of them consider them to be intuitive. Support the remaining learning process with dynamic Tooltips (135), which explain the functions by using real data names. For exclusive slicing, consider Selecting time ranges (125), Selecting measures (126), Selecting an entity from a list (130) as well as Selecting an entity from a hierarchy (130).

Interaction design

Figures 10.5 on the next page and 10.6 on the facing page provide interaction design mock-ups of two states of this pattern. Exclusive slicing is included in the first figure for comparison purposes only.

128


10.1. Interacting with content

Sales volume

Slicing: selects a single measure from the resp. OLAP cube, for example sales volume or profit Sales volume [EUR] Last year

Current Y

Growth

France

2,018,344

3,317,846

64%

Germany

3,331,957

1,683,452

- 49%

Ireland

1,783,286

2,180,503

22%

Italy

2,512,911

2,911,335

16%

Spain

1,557,919

2,754,891

77%

3,545,594

3,321,281

- 6%

14,750,011

16,169,308

10%

United Kingdom Total

Drill-down and slice to Italy‘s regions

Dimmed visual design for maximum readibility of spreadsheet table `` Drills down to regions and slices to Italy, resulting in second display

Figure 10.5.: Drilling & slicing mock-up: initial display, before drill-down & slicing

Sales volume [EUR] Last year

Current Y

Growth

Abruzzo

203,114

289,555

43%

Aosta Valley

220,846

230,521

4%

Apulia

210,178

235,389

12%

Basilicata

250,528

240,932

- 4%

Calabria

257,034

294,461

15%

Campania

251,314

256,293

2%

Emilia-Romagna

242,633

298,413

23%

Friuli Venezia Giulia

226,021

277,334

23%

Latium

196,885

301,856

53%

Liguria

237,358

222,581

- 6%

Lombardy

217,000

264,000

22%

2,512,911 2,911,335

16%

Total

Drilled-down display with Italy’s regions

Drills up to countries and cancels slicing to Italy, again resulting in the first display

Drill-up to countries (including total Italy)

Figure 10.6.: Drilling & slicing mock-up: resulting display, after drill-down & slicing

129


10. Designing interactions

10.1.9. Selecting an entity from a list You want to substantiate Customizing displayed information (120) to let a user configure, what entities a Content component (107) is based on. Problem

The varying business backgrounds of users require them to analyze different aspects. The Feasible default (123) view, however only displays one of these aspects. Some Numerical (111) or Graphical content components (109) in business intelligence applications are meaningful for several entities. For example, a sales report could aggregate sales volumes on individual product, product group or enterprise division level. All perspectives display different entities; only one of those displays is feasible at the same time. The user thus needs an interface to select the appropriate entity from a list. The number of items to choose from, however may differ heavily and thus influences the interface for selection. Therefore:

Solution

Provide an interface control to select a single entity from a menu, when in total there are no more than seven groups with a maximum of seven items each available to choose from. Provide a menu similar to a dropdown control, with at maximum one additional opening menu. Visually highlight the path to the currently selected item. If users are likely to use a small number of items over and again, provide the current user’s three most commonly used items at the top of the list. Compare the alternative Selecting an entity from a hierarchy (130).

Interaction design

Figure 10.7 provides an interaction design mock-up of this pattern. Net trade sales Italian list price Pocket margin European list price Eaches Trade sales Viable spec factors

Dropdown expands/collapses selection menu Most commonly used items Indicates path to currently selected item (dimmed) Standard trade sales Net trade sales Net trade sales enh. List-price sales

Currently selected item

Figure 10.7.: Selecting an entity from a list mock-up

10.1.10. Selecting an entity from a hierarchy You want to substantiate Customizing displayed information (120) to let a user configure what entities a Content component (107) is based on. Problem

Selecting a single item from hundreds of elements generally is not usable

130


10.1. Interacting with content with Selecting an entity from a list (130). For some applications of Customizing displayed information (120), a single item needs to be selected out of a list of sometimes several hundreds of items. Choosing a single product from the product hierarchy of a highly diversified enterprise is an example. While the same result is accomplished by Selecting an entity from a list (130), its interface is not suitable for the increased number of items. This is the case, as the forked display of opening menus is not usable for a lot of items and hierarchical levels. Furthermore, browsing the hierarchy (e.g. going back and forth) generates high excise. Additionally, all items need to be included into the page initially, which may increase page loading time heavily. Therefore: Provide a specialized interface for the selection of an entity from a hierarchy, when more than a maximum of 7 groups with 7 items total are available. Provide it with multiple selection lists representing the respective hierarchy levels and holding their items. Dynamically fill the selection list. If necessary, reload the selection lists on selection to decrease overall loading time.5 Provide an apply button, that is dimmed until the selection is feasible and technically sufficient for information display. Open the interface in a new browser window and provide a cancel button that closes the window. Provide a search function to support users who are unaware where in the hierarchy the item they look for is positioned.

Solution

Enrich the interface with Function explanations (136) to explain its behavior. Figure 10.8 on the following page provides an interaction design mock-up of this pattern.

Interaction design

10.1.11. Selecting a graphic type You want to substantiate Customizing displayed information (120) to let a user configure which graphic type the Graphical content component (109) is based on. Users may prefer different types of graphics, e.g. a pie chart to a bar chart in their analysis. Different types of graphs illuminate distinctive aspects of the information displayed: for example a bar chart with e.g. three bars lets a viewer easily grasp the absolute values of all bars, but cannot give an impression of the proportions of the bars—the opposite is true for stacked bar charts. The actual figures beneath the information however do not change. Users thus will want 5

This can be technically implemented with HTML <iframes>. You could also only reload on every third selection by including three levels of navigation items into each page.

131

Problem


10. Designing interactions Function explanation

Select from the enterprise hierarchy (from left to right)

Business to consumer

Cooling solutions

All

Business to business

Elastic semifinished

Flow measurement

Professional services

Electric machinery

Fluid pumps

Name of hierarchical level Last clicked item, filled list of product groups with item All selected

Maintenance and repair

Energy conversion

Hydropower

Hydraulics

Liquids

Selectable list items

Storage facilities

Supplies

Division (required)

Product line (required)

Product group

Product category Select a product group

Empty list as no selection in superordinate list (dimmed)

Turbines

Search in item lists

Apply selection

Cancel

Find the following item Hydr 2 items found Hydraulics (product line) Hydropower (product group)

Click a found item to show it in the above list, then apply selection

Find

Scrollbar with automatic scrolling on selection Applies selected item(s) to information display Expands/collapses search Searches for an item in hierarchy List of items found Shows and selects item in selection list above

Figure 10.8.: Selecting an entity from a hierarchy mock-up to change the graph type to illumine such differing aspects of information. One should keep in mind that the graph type may also bias users towards an erroneous interpretation, so that a preselection of meaningful types has to be done. Therefore: Solution

Provide an interface control that lets the user select and activate different graph types for the currently displayed Graphical content component (109). Provide a visual overview of the feasible graph types, including the current one for comparison. Textually state, if some types have not been included to avoid biasing or because they are unsuitable. Display possible graph types as Content previews (102), as similar to the actual display as meaningful. Integrate Information explanations (114) stating which aspects a graph type will illuminate.

10.1.12. Problem alert You want to substantiate Customizing displayed information (120) and inform users about issues. Problem

Some users of business intelligence applications frequently need to check that certain values are in a defined rangeâ&#x20AC;&#x201D;apart from that, they will seldom access the application for other purposes. Accessing the application over and over just to check on a single or a very

132


10.1. Interacting with content limited number of values naturally is generating high excise. Users will thus prefer to be informed automatically, if a specific value it out of range. While some ranges may be defined by the application’s supervisors (e.g. for displays in Dashboards (89)), solely relying on the supervisors for all alerts means incorrectly shifting the responsibility, as only the very personal experience of each user can determine the correct borders. Therefore: Provide an interface control to let a user set up an alert for a specific value in a Numerical content component (111). Let them select a value, then provide an interface to let them configure what change shall be monitored. For each alert, let the user decide when they would like to get informed (e.g. immediately or in a daily wrap-up) and how often (e.g. every time, once a day). Also make them select the medium of information, e.g. email or SMS text message. Link the actual alert to the application content, so that details may easily be examined. If enterprise policies and security concerns allow it, attach the actual Content component (107) as a PDF. From the second of consecutive alerts on, provide a link to de-active alerts until the next time, the condition will not be met and then is met again.

Solution

Automatically Remember customizations (122).

10.1.13. Content feedback You have created several Content components (107) and want users to be able to collaborate on them. Business intelligence applications are per se anti-social environments where Problem users cannot discuss content components and share insights. Information presented in a business intelligence application must often be contemplated by its human users—however, the results of this process cannot be submitted back to the application and may thus be lost for the community of users. BI applications are anti-social places where information is solely “consumed”. Social interactions even in a very basic form however decrease this loss of knowledge and at the same time increase the felt social quality of the application. Therefore: Provide an interface control that allows users to give feedback on the Content components (107) displayed. In a very basic form, users should just be able to leave short posts; in more advanced forms, provide full bulletin board capabilities. Display the users’ feedback near the actual content.

133

Solution


10. Designing interactions Other ways of increasing the application’s social quality are described in Rating content components (134) or Support request (140).

10.1.14. Rating content components You have created several Content components (107) and want to measure their quality. Problem

A BI application user has no possibility to give feedback to the administrators on the quality of the information presented. Content components of business intelligence applications are usually provided by a party6 whose work in providing information naturally is somewhat detached from the actual users. Because of this, a simple feedback on specific Content components (107) is appreciated by both users and supervisors. While there often is and certainly should be an off-line feedback process involving criticism of the information provided, this process often cannot include all users and is not anonymous. Giving and receiving ratings also is enormously important when deploying a new application or new content to determine which areas to ameliorate—in particular when efforts need to be focused and prioritized. Therefore:

Solution

Provide a rating interface that allows the user to rate individual Content components (107). Use a common rating scale to allow for a comparison of all elements. Of course encourage the user to further detail their rating with an additional comment, but don’t force them to. Getting simple feedback is better than getting none. Keep the rating scale very simple; maybe even only “good” and “bad” are sufficient. The decision of the user to employ the function, already is a strong indicator that their rating is important. A more complex rating scale however may be considered when the ratings shall be used for marketing purposes. To be able to personally react to their rating, an identification of the user is needed. However, provide optional anonymity. This pattern is terminal—there is no subordinate context.

10.1.15. Context-sensitive help Your application provides Content components (107), modules (87) as well as connected functionality which you want to explain. Problem

Content components (107) and their smaller relatives Content mod6

May it be an individual supervisor/administrator or a whole department.

134


10.1. Interacting with content ules (87) offer complex information and interactions that can not always be understood intuitively. Caused by the semantic complexity of the information presented in business intelligence applications, previous knowledge or a respective business background are premises for their correct understanding. Even with these met, the breadth of information implicates that a single user will probably need help with at least some of the applicationâ&#x20AC;&#x2122;s contents. This is particularly true for new or infrequent users. However, looking up all their questions in the Help manual (92) is to circuitous for the usersâ&#x20AC;&#x201D;this potentially leads to users acting based on information they may have misunderstand. It is thus ultimately in the interest of the enterprise to have help available with very simple and direct access. Therefore: Provide interface elements that provide context-sensitive help, directly attached to individual Content modules (87) or functions. As a default, hide the actual help information from the interface, but let the user access it conveniently, e.g. with a simple mouse roll-over. Supply application-wide visual indications on where context-sensitive help is available.

Solution

To substantiate this concept, provide Function explanations (136) for more complex artifacts, or more simple Tooltips (135), e.g. to explain single buttons. To give a bigger picture of the information displayed, provide Meta information (136). Compare the similar pattern Information explanation (114).

10.1.16. Tooltip You want to substantiate Context-sensitive help (134) and need to provide simple and short help texts. A single user interface action or term needs explanation.

Problem

As explained in Context-sensitive help (134) it is sensible to provide direct explanations with interface actions as well as simple informations, e.g. the function of a button or the definition of a particular term. When showing those in the interface it is important that they are not to obtrusive. Therefore: Provide short explanations of functions or simple facts in a Tooltip element, just big enough to hold at least one sentence of text. Show and hide it on mouse roll-over and mouse-out. Make the Tooltips available consistently, e.g. for all clickable buttons in the interface. For Tooltips in text provide a visual indication of availability, for example a dashed underline. If the explanation is longer than one sentence, use Function explanations

135

Solution


10. Designing interactions (136) instead. Use Common parlance (143) and Transparent communication (142) in the explanation.

10.1.17. Meta information You want to substantiate Context-sensitive help (134) with additional information as well as substantiate Information in context (117). You implemented Searching information (95) and provide the technically requisite information. Problem

In some cases, the information presented in business intelligence applications does not speak for itself: it is not sufficient to provide a complete picture. Especially Numerical (111) and Graphical content components (109) in business intelligence applications are unable to reveal their bigger context. A spreadsheet for example may hardly be understood without its short descriptive name. Other aspects of information, for example its technical quality, cannot be inferred from the information at all. Understanding the backgrounds and incorporating them into the process of drawing conclusions may however be vital for the quality of the resulting business actions. Similar to this effect on human users are the impacts on the application itself: Searching information (95) for example can only produce high-quality results if information on Content components (107) is available in addition to the content itself. Therefore:

Solution

Provide meta information to every Content component (107) that is fully accessible for the application and in part for the user. Make the user-relevant part of the Meta information directly accessible from the information itself via a consistently placed interface element. Consider to present Meta information at least on the information source (physical, temporal and semantical) and on the information quality (correctness, completeness and relevancy). Always include the current application status as well as a creation time stamp of the content displayed for reference purposes. Employ Transparent communication (142) for all Meta information, particularly regarding quality. Compare the related patterns Information in context (117) and Searching information (95).

10.1.18. Function explanation You want to substantiate the concept of Context-sensitive help (134) regarding the functionality of the application. Problem

The name or graphical symbol of a functional interface control alone will

136


10.1. Interacting with content not necessarily be enough information for the user to understand and judge the actual result of its actions. The partly complex functionality, for example for Customizing displayed information (120), associated with its intricate information result in interfaces that cannot always be self-explanatory. Users thus cannot use the functions intuitively, even if this has been striven for with high effort. Using trial and error is not an option for the user as neither the response times of complex requests are low enough nor their business background does supply them with this time. Visually blending functionality and explanation however requires screen space that is terse in business intelligence applications, whose primary focus after all is presenting information. Therefore: Provide Function explanations as a substantiation of Context-sensitiveSolution help (134) explaining in depth and oriented on the actual information what a function does. Regarding their implementation, rely on layers holding the description, if it is no longer than around 20 sentences; if it is more voluminous, reserve screen space that is expandable on user interaction (and normally is collapsed). Link terms in the explanation to the Glossary (91), if they are available. Use Common parlance (143) in the explanations. Whenever the explanation is as short as one sentence, use a Tooltip (135) instead. Figure 10.9 provides an interaction design mock-up of this pattern.

Consumer products

Sales volumes

Help This element shows different measuresâ&#x20AC;&#x2DC; values for a specific division in a specific region. Rollover a bar to display its details including numerals. Click a region to view it in detail. You may drill down from Europe over a country to an individual region. Click again to see the respective spreadsheet.

Interaction design

Icon indicating availability of explanation, mouse-over shows explanation, mouse-out hides it after 5s Toggle pin to keep explanation open Explanation

Figure 10.9.: Function explanation mock-up

10.1.19. Export content component You have created several Content components (107) and want to enable the users to use them detached from the application. Users cannot access the business intelligence application wherever they want and thus need to have access to its information detached from the application.

137

Problem


10. Designing interactions Naturally, the information available from business intelligence applications is not only required in the context of application usageâ&#x20AC;&#x201D;it is thought to be used in every relevant business context. An obvious example is the discussion of a BI applicationâ&#x20AC;&#x2122;s information in a live staff meeting. Apart from that, the information manipulation capabilities of a web-based application are limited so that users will want to use local applications for further analysis. The most prominent example for such an application surely is Microsoft Excel.7 Therefore: Solution

Provide functionality that enables a user to Export content components from the application for independent use in various forms. Use a consistent control and position for the functions. Remember the users textually that information may be confidentially. Prepare Content components (107) for export as outlined in Print content (139) and Export to application (139). Also enable the user to E-mail content (138) to others. Enrich the functions with a Function explanation (136). If rules can be stated concerning who is allowed to view the information, Explain user rights (143). Include Meta information (136) when exporting, especially an export time stamp.

10.1.20. E-mail content You want to substantiate Export content component (137) and permit the communication of contents to others. Problem

Users want to supply colleagues with copies of Content components (107) to accompany their communication. In normal business context, it is unlikely that users solely view and contemplate a Content component (107) on their own. Instead, they will want to be able to quickly share the information with co-workers or even are obliged to communicate problems in their reporting path. They could use Exporting content to application (139) and then e-mail the file received, however launching the application is a detour. Therefore:

Solution

Provide an interface control that lets users directly E-mail content from the application. Let the user choose which of the available Export content component (137) formats to send via e-mail. For security reasons log every e-mail sent and mention this to the user. Do however not restrict the sending as such restrictions may always be bypassedâ&#x20AC;&#x201D;if the content is sent by the application it at least can be traced. Clarify the operation of the element with a Function explanation (136). 7

Excel export capability is a market-must for BI applications no matter how sophisticated they might be.

138


10.1. Interacting with content If the recipient is known to the application, check their right to access the content and mention the results to the user (cp. Explain user rights (143)).

10.1.21. Print content You want to substantiate Export content component (137) and permit the user to create hard copies. Viewing the business intelligence application in the application is not suitable for all business purposes; sometimes users want to take away a hard copy.

Problem

There are several situations, where users prefer a print-out to the actual information on-screen. Apart from the obvious example of taking a hard copy into a meeting, users may also want to compare a number of paper copies, which is just not possible on-screen, due to its limited surface area. Numerous other applications can be conceived. Therefore: Provide print functionality for all information available from the application. Prepare a special display of information for print-out: strip everything that is irrelevant like for example the Navigation (93).8

Solution

Supply the control with a Function explanation (136).

10.1.22. Export content to application You want to substantiate Export content component (137) and permit the user to process content outside of the application. The capabilities of the business intelligence application towards advanced information editing are very limited. Additionally, users cannot work off-line with the BI applicationâ&#x20AC;&#x2122;s information.

Problem

Due to the limited interaction possibilities of the web, manipulation capabilities of web-based business intelligence applications are restricted as well. Users however are accustomed to the functionality and interaction quality of desktop applications and thus want to use those for manipulation. As a second constraint, web-based applications by their very nature cannot be accessed off-line. Users however will want to access specific information even when not connected, for example on a business trip. Therefore: Provide an interface control allowing users to export Content components (107) from the BI application to desktop software applications like for example Microsoft Excel. As an export format at least provide a very 8

However, as already stated include Meta information (136).

139

Solution


10. Designing interactions basic one, that most software applications understand and can import.9 If a corporate standard may be consulted for widely-installed software, provide these formats in addition. Technically provide the file for download, not for opening. Integrate the information’s Meta information (136) in the export, especially an export time stamp.

10.2. Interacting with the application 10.2.1. Application-wide preference You want to substantiate Meta application components (90) in terms of application settings. You have integrated means of Customizing displayed information (120) but observe that some settings are not bound to individual Content components (107). Problem

Some preferences of the user concern the application as a whole and thus cannot be accessed and saved within individual Content components (107). In most BI applications there are some settings that effect the entire system, for example the selection of the currency all numerics shall be displayed in, or other locale settings. In addition to this technical necessity, employing their own preferences lets the users adopt the application as their own. While such application-wide settings may in some cases be set when viewing a Content component (107), they however should be accessible detached from individual contents for reasons of consistency. Anyhow. application-wide settings do not have an intuitive place to be stored and accessed as content customizations. Therefore:

Solution

Provide a special page that holds and lets the user set his preferences regarding application-wide settings. Name the link and function “preferences”. When an application-wide preference is changed often (e.g. the currency), make it additionally available on every page. Integrate this page into the Meta navigation (95) or the User salutation (87).

10.2.2. Support request You have created several application components, for example Error pages (92), which may cause a user’s wish to contact support. 9

A good basis are comma-separated-value-files (CSV) for Numerical (111), JPG-files for Graphical (109) and RTF or HTML for Textual content components (110).

140


10.2. Interacting with the application In case of problems, users need to be able to contact the business intelligence application administrator.

Problem

Regardless of the quality of usability and implementation of a business intelligence application, issues will still be raised where users require support. Requesting such should be possible from anywhere in the application where a problem may occur, even when an alternative off-line support process is established; especially as the latter will seldom be available twenty-four-seven. Additionally, managing support completely off-line (e.g. via telephone) requires higher effort and budget. Therefore: Provide an interface element at a consistent position on every page, which allows users to request support. Depending on the efforts taken for supporting users, provide one of the following methods, the first being a must: â&#x20AC;˘ E-mail support: provide a support form where the user may enter a problem. The request will then be answered via e-mail. As an alternative provide a standard e-mail link to the system. â&#x20AC;˘ Text-chat: let the user enter a text-based live chat with a member of the support staff. â&#x20AC;˘ Audio/video-chat: let the user have an audio/video-conference with a support staff (VoIP browser-based or application-based, e.g. Skype). If more than one way to contact support is available, let the user choose. Only provide methods that are currently available.10 Automatically identify the user and add his contact information to the respective forms. Let them however change the information in case this is required.11 Whenever technically possible, open the Support request in a separate window to allow the user to still see the original page. To endorse high quality support (and in some cases make requests controllable at all), use an issue tracking system for incidents.12 For users wishing direct personal contact, provide additional contact information including the supervisor/analyst responsible for the currently presented Content component (107). From this page link to the Glossary (91) as well as to the Help manual (92) to reduce request volume. Use Transparent communication (142) and Common parlance (143) on the page as well as in personal support. If the request could not be sent, provide an Warning message (142). 10

For example do not provide live chat, when support staff or a slot is not available. e.g. for a sales representative without access to corporate e-mail 12 A proved solution e.g. is the free Request Tracker from Best Practical. 11

141

Solution


10. Designing interactions

10.2.3. Warning message You have implemented functions for Customizing displayed information (120) or to Export content components (137) and want to catch errors. Problem

A message needs to be communicated to the business intelligence application user that should be considered top priority. As a result of user interaction, it may become necessary to display a warning message to the user, for example when their efforts Customizing displayed information (120) have not been fruitful. Additionally, a problem with the application as a whole, e.g. missing technical access to the data warehouse, must be communicated to the users. In both cases, this information has top priority for the user, so that it should be perceived immediately. Therefore:

Solution

Provide a interface element that visually informs the user of an unexpected situation they should be aware of. Position this element visually striking so that the user must become aware of it. Find a consistent position for the element that may be repeated on every page of the application— this allows the user to learn where to find warnings and watch out for them. Use Transparent communication (142) in the actual message. While this element catches errors that can be recovered, Error pages (92) shall be employed for fatal ones.

10.2.4. Transparent communication Throughout the application, you have included textual introductions, explanations and other messages. Problem

Inaccurate information in business intelligence applications may directly influence the business actions of its users. All information that is available from business intelligence applications is considered to be used for business purposes. It is thus of enormous importance that it is correct and complete to the highest possible degree. While this is obvious for the actual information of Content components (107) and in this area is a question of “data quality”, the same is true for the communication part of user interactions: if the BI application does not openly address all (even potential) issues to the users, the results may be disastrous. Therefore:

Solution

In all communication between the application and the user, describe all aspects as openly and transparently as possible to promote correct and complete understanding. This will additionally gain the users’ confidence.

142


10.2. Interacting with the application When communicating very complex issues with potentially major impacts, integrate the possibility to Request support (140). Compare the similar patterns Explain user rights (143) and Common parlance (143).

10.2.5. Explain user rights You have acknowledged the concept of Transparent communication (142) and want to substantiate it regarding user rights. You have implemented functions to Export content components (137) and want to clarify who is allowed to see them. Different users may have different rights to view information and access functionality, yet they are unaware of that and thus cannot understand certain behaviors of the application.

Problem

The rights of the applicationâ&#x20AC;&#x2122;s users may vary heavily concerning the information they may view as well as the functionality they may access. However, this differentiation is implicit and not communicated by the application. As a result, users who collaborate with colleagues having different rights, will encounter inconsistencies in their communication. Therefore: Provide a description of the current userâ&#x20AC;&#x2122;s rights in regards of content and functionality integrated into their Application-wide preferences (140). This will create a general awareness of the existence of such differing rights. Also state rights a user does not hold and let them issue a Support request (140) to demand a change.13

Solution

This pattern is terminalâ&#x20AC;&#x201D;there is no subordinate context.

10.2.6. Common parlance Throughout the application, you have included textual introductions, explanations and other messages. Users must be able to consistently interpret the semantic artifacts of Content components (107).

Problem

Every individual concerned with the business intelligence application uses different words and phrases for the same artifacts. A correct understanding of business intelligence information is crucial for the success of its users, as the impact of decisions based on misinterpreted information may be tremendous. Therefore: Ensure that within the business intelligence application all (relevant) terms are used unequivocally. Ensure that this is not only conducted within 13

Obviously user rights will not be changed on simple request. It is however in the interest of an enterprise to provide its employees with all information raising their quality of work.

143

Solution


10. Designing interactions captions but also within the data or information itself. This is especially important for business-relevant terms, like the measures or dimensions used. Provide a Glossary (91) that explains terms and their definitions.

144


Part III.

Appendix

145


A. Miscellaneous A.1. Pattern language markup language (PLML) DTD The following pattern language markup language document type definition was compiled by a workshop at CHI 2003 [Fin03]. PLML v1.1 <!ELEMENT pattern (name?, alias*, illustration?, problem?, context?, forces?, solution?, synopsis?, diagram?, evidence?, confidence?, literature?, implementation?, related-patterns?, pattern-link*, management?)> <!ATTLIST pattern patternID CDATA #REQUIRED> <!ELEMENT name (#PCDATA)> <!ELEMENT alias (#PCDATA)> <!ELEMENT illustration ANY> <!ELEMENT problem (#PCDATA)> <!ELEMENT context ANY> <!ELEMENT forces ANY> <!ELEMENT solution ANY> <!ELEMENT synopsis (#PCDATA)> <!ELEMENT diagram ANY> <!ELEMENT evidence (example*, rationale?)> <!ELEMENT example ANY> <!ELEMENT rationale ANY> <!ELEMENT confidence (#PCDATA)> <!ELEMENT literature ANY> <!ELEMENT implementation ANY> <!ELEMENT related-patterns ANY> <!ELEMENT pattern-link EMPTY> <!ATTLIST pattern-link type CDATA #REQUIRED patternID CDATA #REQUIRED collection CDATA #REQUIRED label CDATA #REQUIRED > <!ELEMENT management (author?, credits?, creation-date?, last-modified?, revision-number?)> <!ELEMENT author (#PCDATA)>

147


A. Miscellaneous <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT

credits (#PCDATA)> creation-date (#PCDATA)> last-modified (#PCDATA)> revision-number (#PCDATA)>

A.2. Use of graphical icons Some of the icons used in the pattern mock-ups are taken from the Eclipse project. They are licensed under the Eclipse Public License (Version 1.0). For more information consult eclipse.org.

148


B. List of Figures 3.1. Visual representation of the Experiences pattern language [CL96] 40 3.2. A partial pattern language for web design (centered around shopping), reproduced from [WV03, fig.2] . . . . . . . . . . . . . . . 44 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9.

Visualization of this chapter’s patterns . . . . . . . . . User home mock-up with Dashboard characteristics User salutation mock-up . . . . . . . . . . . . . . . Index page mock-up . . . . . . . . . . . . . . . . . . Navigation mock-up . . . . . . . . . . . . . . . . . . Searching information mock-up . . . . . . . . . . Personal content shortcut mock-up . . . . . . . Recently viewed pages mock-up . . . . . . . . . . Content preview mock-up . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. 85 . 88 . 88 . 90 . 94 . 97 . 99 . 101 . 102

9.1. 9.2. 9.3. 9.4. 9.5.

Visualization of this chapter’s patterns . . . . Graphical content component mock-up Numerical content component mock-up Sample Content module mock-up . . . . . Geographical mapping mock-up . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

108 110 112 113 115

10.1. Visualization of this chapter’s patterns . . . . . . . . . . . . . . 10.2. Sorting numerical content components mock-up . . . . 10.3. Selecting time ranges mock-up: single time range selection 10.4. Selecting time ranges mock-up: dual time range selection for comparison purposes . . . . . . . . . . . . . . . . . . . . . . 10.5. Drilling & slicing mock-up: initial display, before drill-down & slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6. Drilling & slicing mock-up: resulting display, after drilldown & slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7. Selecting an entity from a list mock-up . . . . . . . . . 10.8. Selecting an entity from a hierarchy mock-up . . . . . 10.9. Function explanation mock-up . . . . . . . . . . . . . . . .

121 125 126

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

127 129 129 130 132 137

149


B. List of Figures

150


C. List of Tables 2.1. Stages of pattern creation and respective HCI exemplary methods 27 3.1. Comparison between natural and pattern languages [Ale79, p.187] 37 3.2. Delineation indicators for languages and collections . . . . . . . 42

151


C. List of Tables

152


D. Bibliography [Ack89]

Ackoff, Russell L.: From data to wisdom. In: Journal of Applied Systems Analysis 16 (1989), S. 3–9 50

[AIS77]

Alexander, Christopher ; Ishikawa, Sara ; Silverstein, Murray: A pattern language: towns, buildings, construction. Oxford University Press, 1977 24, 32, 33, 35

[Ale79]

Alexander, Christopher: The timeless way of building. Oxford University Press, 1979 32, 33, 36, 37, 151

[ASA+ 75] Alexander, Christopher ; Silverstein, Murray ; Angel, Shlomo ; Ishikawa, Sara ; Abrams, Denny: The oregon experiment. Oxford University Press, 1975 32, 33 [Atl04]

Atlantic Systems Guild: Volere requirements specification template. www.volere.co.uk/template.pdf. 2004. – Edition 10.1 27

[aut83]

author, Unkown: Contrasting concepts of harmony in architecture. In: Lotus international 40 (1983), S. 60–68. – cited from www.katarxis3.com/Alexander_Eisenman_Debate.htm 24

[BBC+ 98] Bayle, Elisabeth ; Bellamy, Rachel ; Casaday, George ; Erickson, Thomas ; Fincher, Sally ; Grinter, Beki ; Gross, Ben ; Lehder, Diane ; Marmolin, Hans ; Moore, Brian ; Potts, Colin ; Skousen, Grant ; Thomas, John: Putting it all together: towards a pattern language for interaction design: a CHI 97 workshop. In: SIGCHI Bull. 30 (1998), Nr. 1, S. 17–23. – ISSN 0736– 6906 34 [BBF98]

Bless, Herbert ; Betsch, Tilmann ; Franzen, Axel: Framing the framing effect: the impact of context cues on solutions to the ’asian disease’ problem. In: European journal of social psychology 28 (1998), S. 287–291 28

[BDSB96] Brethenoux, Erick ; Dresner, Howard J. ; Strange, Kevin H. ; Block, Jonathan. Data warehouse, data mining and business intelligence: the hype stops here. Gartner Research. October 1996 49 [BG04]

Bill Gassman, Alan H. T.: Business intelligence: emergence and convergence. 2004 ( AV-23-4336). – Forschungsbericht 54

153


D. Bibliography [BMR+ 96] Buschmann, Frank ; Meunier, Regine ; Rohnert, Hans ; Sommerlad, Peter ; Stal, Michael: Pattern-oriented software architecture. John Wiley & Sons, 1996 33, 37 [Bor00a]

Borchers, Jan: CHI meets PLOP: an interaction patterns workshop. In: SIGCHI Bulletin 32 (2000), January, S. 4 32, 34

[Bor00b]

Borchers, Jan: A pattern approach to interaction design. (2000), S. 10 34, 39, 48

[Bor01]

Borchers, Jan: A pattern approach to interaction design. John Wiley & Sons, 2001 33, 36, 39, 47

[BT01]

Borchers, Jan O. ; Thomas, John C.: Patterns: what’s in it for HCI? (2001), S. 2 34

[Bus]

Business Objects corporate website. www.businessobjects.com/. – Accessed 10/17/2005 23

[CCS93]

Codd, E.F. ; Codd, S.B. ; Salley, C.T.: Providing OLAP to user-analysts: an IT mandate / E.F. Codd Associates. 1993. – Forschungsbericht 52

[CD97]

Chaudhuri, Surajit ; Dayal, Umeshwar: An overview of data warehousing and OLAP technology. In: SIGMOD Rec. 26 (1997), Nr. 1, S. 65–74. – ISSN 0163–5808 122

[CG74]

Carlson, John G. H. ; Gilman, Richard: Management information/decision systems using APL. In: APL ’74: Proceedings of the sixth international conference on APL. New York, NY, USA : ACM Press, 1974, S. 65–78 52

[CL96]

Coram, Todd ; Lee, Jim. Experiences – a pattern language for user interface design. www.maplefish.com/todd/papers/ Experiences.html. prob. 1996 40, 47, 149

[Cle82]

Cleveland, H.: Information as resource. In: The Futurist (1982), S. 34–39 50

[Cog]

Cognos corporate website. www.cognos.com. – Accessed 10/17/2005 23

[Cow89]

Cowie, A. P. (Hrsg.): Oxford advance learner’s dictionary of current English. 4. Oxford University Press, 1989 50

[CR03]

Cooper, Alan ; Reimann, Robert: About face 2.0 - the essentials of interaction design. Wiley Publishing, Inc., 2003 27, 80, 86, 109

154


D. Bibliography [DLH02a] van Duyne, Douglas K. ; Landay, James ; Hong., Jason I.: The design of sites - book website. www.designofsites.com. July 2002. – Accessed 08/18/2005 34 [DLH02b] van Duyne, Douglas K. ; Landay, James ; Hong., Jason I.: The design of sites: patterns, principles, and processes for crafting a customer-centered web experience. Bd. http://www.designofsites.com. 1st. Addison Wesley Professional, July 2002 34 [Don05]

Donath, Dirk: Christopher Alexander, seine Theorien und Bauten. www.uni-weimar.de/~donath/c-alexander98/ ca98-html.htm. 2005. – Accesse 09/29/2005 24

[Eri00]

Erickson, Thomas: Lingua francas for design: sacred places and pattern languages. (2000), S. 357–368 48

[Evi00]

Evitts, Paul: A UML pattern language. New Riders Publishing, 2000. – ISBN 1-57870-118-X 25

[FI78]

Falkoff, Adin D. ; Iverson, Kenneth E.: The evolution of APL. In: HOPL-1: The first ACM SIGPLAN conference on History of programming languages. New York, NY, USA : ACM Press, 1978, S. 47–57 51

[Fin00]

Fincher, Sally: The pattern gallery. www.cs.kent.ac.uk/ people/staff/saf/patterns/gallery.html. August 2000. – Accessed 08/29/2005 38

[Fin03]

Fincher, Sally: CHI 2003 workshop report: perspectives on HCI patterns: concepts and tools (introducing PLML). In: Interfaces Bd. 56. British HCI group, 2003, S. 26–28 38, 147

[FPSS96]

Fayyad, Usama ; Piatetsky-Shapiro, Gregory ; Smyth, Padhraic: From data mining to knowledge discovery in databases. In: AI magazine 17 (1996), Nr. 3, S. 37–54 52

[Gar]

Gartner corporate website. 10/17/2005 23

[GG00]

Grothe, Martin ; Gentsch, Peter: Business intelligence: aus Informationen Wettbewerbsvorteile gewinnen. Addison-Wesley, 2000 54, 56

www.gartner.com. –

Accessed

[GHJV95] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: Design patterns. Addison-Wesley Professional, January 1995 33, 38, 39

155


D. Bibliography [Gra03]

Graham, Ian: A pattern language for web usability. Pearson Education, 2003 ( 0201788888) 34, 45

[Hay02]

Hayes, Frank. The story so far. www.computerworld.com/ April databasetopics/data/story/0,10801,70102,00.html. 2002 52

[HBC+ 92] Hewett, Thomas ; Baecker, Ronald ; Card, Stuart ; Carey, Tom ; Gasen, Jean ; Mantei, Marilyn ; Perlman, Gary ; Strong, Gary ; Verplank, William ; Hefley, Bill (Hrsg.): ACM SIGCHI curricula for human-computer interaction. The Association for Computing Machinery, 1992 17, 21 [Hil05]

Hillside Group: Hillside patterns library. hillside.net/ patterns/. August 2005. – Accessed 08/12/2004 10:50 34

[HW01]

Kap. Der Prozess des Data Mining im Marketing In: Hippner, Hajo ; Wilde, Klaus D.: Handbuch Data Mining im Marketing - Knowledge Discovery in Marketing Databases. Vieweg Verlag, 2001, S. 21–91 54

[IH94]

Inmon, W. H. ; Hackathorn, Richard D.: Using the data warehouse. Somerset, NJ, USA : Wiley-QED Publishing, 1994. – ISBN 0–471–05966–8 52

[Inm92]

Inmon, W. H.: Building the data warehouse. Wellesley, MA, USA : QED Information Sciences, Inc., 1992. – ISBN 0–89435–404–3 52

[Int98]

International Organization for Standardization (ISO): Ergonomic requirements for office work with visual display terminals (VDTs) – Part 11: Guidance on usability. 1. International Organization for Standardization (ISO), 1998 ( ISO 9241-11) 22

[Ive62]

Iverson, Kenneth E.: A programming language. John Wiley & Sons, 1962 51

[IWG97]

Inmon, W. H. ; Welch, J. D. ; Glassey, Katherine L.: Managing the data warehouse. New York, NY, USA : John Wiley & Sons, Inc., 1997. – ISBN 0–471–16310–4 52

[Jac04]

Jacobson, Ivar: Aspect-oriented software development with use cases. Addison-Wesley Professional, 2004 27

[Man01]

Manovich, Lev ; Malina, Roger F. (Hrsg.): The Language of New Media. The MIT Press, 2001 61

[Met]

Meta Group corporate website. www.metagroup.com. – Accessed 10/17/2005 23

156


D. Bibliography [Mic05]

Microsoft Corporation: Windows user interface description. msdn.microsoft.com/library/default.asp?url=/library/ en-us/winui/winui/windowsuserinterface/windowui.asp. 2005. – Accessed 11/16/2005 57

[MW05]

Merriam-Webster: Merriam-Webster online dictionary. www. m-w.com. 2005. – Accessed 08/24/2005 37

[Nie99]

Nielsen, Jakob ; Weiss, Steve (Hrsg.): Designing web usability. 1. New Riders Publishing, 1999 27

[Ora]

Oracle BI website. www.oracle.com/solutions/business_ intelligence/index.html. – Accessed 10/17/2005 23

[Pen05]

Pendse, Nigel: The origins of today’s OLAP products. January 2005. – Accessed 11/16/2005 51

[Por05]

Portland pattern repository’s wiki contributors: History of patterns. c2.com/cgi/wiki?HistoryOfPatterns. August 2005. – Accessed 08/10/05, 17:46 34

[PRS02]

Preece, Jennifer ; Rogers, Yvonne ; Sharp, Helen: Interaction Design. Wiley Publishing, Inc., January 2002 27

[PS91]

Piatetsky-Shapiro, Gregory: Knowledge discovery in real databases: a report on the IJCAI-89 workshop. In: AI magazine 11 (1991), January, Nr. 5, S. 68–70 52

[Roy05]

Royal institute of British architects: British architectural library. www.architecture.com/go/Architecture/Reference/ Library_1020.html. September 2005. – Accessed 09/29/2005 24

[RT82]

Rockart, John F. ; Treacy, Michael E.: The CEO goes on-line. In: Harvard Business Review (1982), January 52

[Rub94]

Rubin, Jeffrey: Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. Wiley Publishing, Inc., 1994 27

[sea04]

searchWebServices.com Definitions: Definition of ”Document type definition (DTD)”. searchwebservices.techtarget. com/sDefinition/0,290660,sid26_gci213918,00.html. April 2004. – Accessed 08/29/2005 38

[Sea05]

SearchCRM.com. Business intelligence definition. searchcrm.techtarget.com/sDefinition/0,290660,sid11_ gci213571,00.html. August 2005 51

157


D. Bibliography [Sel02]

Selby, David: Jottings from the business intelligence jungle. In: APL ’02: Proceedings of the 2002 conference on APL. New York, NY, USA : ACM Press, 2002. – ISBN 1–58113–577–7, S. 190–197 23, 51, 52, 56

[SPS04]

SPSS Inc. Getting Smart About ROI. http://www.spss.com/ registration/premium/AskQuestions03.cfm?id=1%&country= US. 2004 49

[Tid]

Tidwell, Jenifer. UI patterns and techniques. time-tripper. com/uipatterns 47

[TKP04]

Todd, E. ; Kemp, E. ; Philips, C.: What makes a good user interface pattern language? (2004), January, S. 10 35

[Tuf01]

Tufte, Edward R.: The Visual Display of Quantitative Information. 2. Graphics Press, May 2001 110

[Uff02]

van Ufford, Deborah Q. Business intelligence - the www.few.vu.nl/onderwijs/stage/werkstuk/ umbrella term. werkstukken/werkstuk-quarles.doc. November 2002 49

[VM04]

Vesset, Dan ; Morris, Henry D.: Why consider oracle for business intelligence? / IDC. 2004. – Forschungsbericht 54, 57

[Wela]

van Welie, Martijn: GUI design patterns. patterns/. – Accessed 08/18/2005 35

www.welie.com/

[Welb]

van Welie, Martijn: Web design patterns. patterns/. – Accessed 08/18/2005 35

www.welie.com/

[Wel01]

van Welie, Martijn: CHI2002 patterns workshop - position papers. www.welie.com/patterns/chi2002-workshop/. 2001. – Accessed 08/18/2005 34

[Wid95]

Widom, Jennifer: Research problems in data warehousing. In: CIKM ’95: Proceedings of the fourth international conference on Information and knowledge management. New York, NY, USA : ACM Press, 1995. – ISBN 0–89791–812–6, S. 25–30 52

[WMM02] van Welie, Martijn ; Mullet, Kevin ; McInerney, Paul. The CHI 2002 patterns workshop. www.welie.com/patterns/ chi2002-workshop/index.html. 2002 34 [WV03]

158

van Welie, Martijn ; van der Veer, Gerrit C.: Pattern languages in interaction design: structure and organization. (2003) 35, 43, 44, 149


E. About the author Felix Kaiser has been designing for the Internet since his days in school back in 1997. After finishing his studies in computer science in media in 2003 at Furtwangen University of Applied Sciences, Germany, he has been working as a project manager, conducting complex online projects until today. His first professional station has been Pixelpark, Hamburg, where he experienced the last days of the dot-com boom. He then changed to FCBi, Hamburg, an international agency network, and has been managing various e-business projects ever since. Together with his team, he pitched for and won a business intelligence project in 2004, that had been tendered by Ethicon Endo-Surgery (EES), a member of the Johnson & Johnson group of companies. Felix has then worked in close collaboration with the EES team for more than a year on site, both coordinating and managing the project as well as conceiving and testing the interaction design. After the launch of the applicationâ&#x20AC;&#x201D;which had received excellent feedback from the organizationâ&#x20AC;&#x201D;he has intermittently continued supporting the project until today. Felix has been an advocate of usability ever since he had learned to press CTRL-ALT-DEL to log-in to Windows NT. Apart from computer science, he also enjoys challenging the usability of everyday things. Apart from traveling, experiencing foreign cultures and various sports, his personal interests are new media, technology as well as the socialization of the Internet. With this thesis, Felix strives for a masterâ&#x20AC;&#x2122;s degree in computer science in media.

159


c 2005, 2006 Felix Kaiser, Hamburg, Germany No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted by applicable law, without the prior written permission by its author. See the preface on page 9 for information about how to contact the author. Trademarks used in this document are the property of their respective owners.


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