Context Knowledge

Context Knowledge

Supporting Designers’ Information Search in the Early Design Phases

MUHAMMAD IKHWAN JAMBAK

Context Knowledge Supporting Designers’ Information Search in the Early Design Phases

Muhammad Ikhwan JAMBAK Faculty of Industrial Design Engineering

Delft University of Technology

Context Knowledge Supporting Designers’ Information Search in the Early Design Phases

Proefschrift

ter verkrijging van de graad van doctor aan de Technische Universiteit Delft, op gezag van de Rector Magnificus prof. dr. ir. J.T. Fokkema, voorzitter van het College voor Promoties, in het openbaar te verdedigen op donderdag 10 mei 2007 om 15.00 uur door

Muhammad Ikhwan JAMBAK

Master of Engineering (Mechanical) Universiti Teknologi Malaysia geboren te Palembang, Indonesië

Dit proefschrift is goedgekeurd door de promotor: Prof. dr. P. Badke-Schaub Toegevoegd promotor: Dr. J.S.M. Vergeest

Samenstelling promotiecommissie: Rector Magnificus Prof. dr. P. Badke-Schaub Dr. J.S.M. Vergeest Prof. dr. H. Jaakkola Prof. Prof. Prof. Prof. Prof.

dr. Y. Kiyoki dr. ir. M. Aksit dr. P.P.M. Hekkert dr. P.J. Stappers ir. D. van Eijk

Context Knowledge:

voorzitter Technische Universiteit Delft, promotor Technische Universiteit Delft, toegevoegd promotor Tampere University of Technology, Pori, Finland Keio University, Japan Universiteit Twente Technische Universiteit Delft Technische Universiteit Delft Technische Universiteit Delft, reservelid


ISBN 978-90-5155-033-7 A PhD dissertation at Delft University of Technology Copyright © 2007 by Muhammad Ikhwan JAMBAK E-mail: [email protected] ; [email protected]

Cover Front:

Back:

”Castle Mount”, a ”copyleft” fractal image created by and with permission of Dr. Sven Geier (California Institute of Technology/NASA) Each of the ”cells” looks like uniquely independent but they are connected to their neighbours. One who sees these relationships will have an association or interpretation ”Context Knowledge” created using ”Another Matrix” screensaver software and ”Dome of Rock”, Jerusalem, Palestine, photographed by Buyung Agusdinata

To my mother and the memory of my father, my brothers, my beloved wife and sons

Semoga

amanah

ini

mengumpulkan

kita

di

Jannah...

Acknowledgements

In the Name of God, the Most Beneficent, the Most Merciful The author wishes to thank: Prof. Dr. Petra Badke-Schaub for promoting this PhD research work, and for her non-intrusive and constructive comments and critiques. The author almost always has a big smile on his face whenever he leaves Petra’s office. It was not only because of the lively discussion, but also sometimes because of the way Petra gives her critiques; the author was able to accept these easily and laugh at his own stupidity. Vielen Dank ! Dr. Joris S. M. Vergeest, for his daily supervision, encouragement, and personal help. While lifting the scientific standard, he also gave the author a very large space for creativity and freedom to choose. ”It is your research, not mine, and it is your responsibility; I leave it to you!” is such a sentence the author often heard after argumentative talk that ended up with no consensus between him and the author. Hartstikke bedankt! All committee members for their expertise which enriched the quality of this final thesis. Their comments, suggestions, and corrections are invaluable. Dr. Prabhu V. Kandachar, the Design Engineering department head, for his administrative involvement which allowed the author to smoothly work on the project until the end. Dr. ir. Rudi. M. F. Stouffs, the chairman of Design Informatics Faculty of Architecture, TU Delft; Prof. Dr. Riichiro Mizoguchi from the Institute of Scientific and Industrial Research, Osaka University; Dr. Rob Dekkers from the faculty of Technology, Policy and Management TU Delft; Prof. Dr. Tetsuo Tomiyama from Mechanical Engineering, TU Delft; and dr. Henry. H. C. M. Christiaans and dr. ir. Regine. W. Vroom for their help in the early stage where the author made the i

ii

ACKNOWLEDGEMENTS

foundation of this research. Some of them were also involved during the system evaluation and acted as shadow committee members of the thesis draft. Iraas Korver and Erland Bakkers from Fabrique; Erik Woldring from NewProducts; Edwin van Vianen, Ramon van de Ven, and Michael de Regt from Philips Design; Guus Ranke from Philips Applied Technologies; Jasper van Kuijk from section applied ergonomic and design; and Wilfred van der Vegte, for giving their expertise or allowing their experts to evaluate the CDIRS. Farid Wajdi, Hatami Nugraha, Gea O. F. Parikesit, and Muhammad Reza Akil for their involvement in the design cases development. Special thanks to Hatami for helping the author to process the data from the investigation context from the D1 experiment. Many thanks to Zulfikar Dharmawan who helped the author conceptualize the proposed system. Remko van der Lugt and Froukje Sleeswijk-Visser for the reading material and pictures of ’Contexmapping.’ Credit goes to Dr. Sven Geier, Buyung Agusdinata, Richard Zoontjes and family, and Mrs. Nizmah ’Teteh’ Agustjik for supplying and allowing pictures to be used for this thesis. Mrs. Diane Butterman-Dorey and Mrs. Courtney Dougall for their proofreading on the draft. Their efforts have made this thesis more readable. Miss Kristin K¨ oppe, Dr. Stella B¨ oß, Miss Hilal Taymaz, Mrs. Tanja Jokinen, and Mr. Hitoshi Komoto for translating the summary of this thesis. Colleagues in the Design Engineering (DE) department and Computer Aided Design Engineering (CADE) group for their cooperation. The author is indebted to Jouke Verlinden for his involvement during the implementation of CDIRS. Special thanks to Tjamme Wiegers, who with him, the author did not feel alone in raising his children in a less religious society and enjoyed the inter-faith discussion. Tjamme gave the necessary Desys Project data along with nice discussions, while many other readings were also collected from him. The draft of this thesis was carefully examined by him. Also, a special thanks goes to Dr. Raluca Dumitrescu who, together with the author, faced almost all technical and administrative problems regarding their research and to survive in Holland. The technical and administrative problems themselves would not have been solved easily without the assistance from the computer administrators Marco Bolleboom and Adrie Kooijman, and the department secretaries, Astrid Bijkerk, Marijke Timmerman, and Hanneke Sosef. The help and private communication from former staff members, dr. ir. Peter de Jager and Jeroen Pulles, are very much appreciated. Thanks also go to Evren Akar, Dr. Alexander Shevchenko, Zhishan Wang, and Huaxin Wang for being such nice officemates. Genuine thanks are expressed to prof. dr. Imre Horváth, the head of CADE; although in many respects the author did not agree with him, the author would not neglect his influence in helping the author to reach this current stage.

iii Ir. Aad Bremer, the former Design Engineering department head and Mrs. Agnes de Haan, the P&O advisor to the author’s research group for keeping the author on the track when the working environment was not appropriate to do a good research. Thank you for the trust, and thank you for the encouragement. Without their trust and encouragement, most probably the author already gave up and quit like some other PhD students and staffs. Alvast hartelijk bedankt! Dr. Ery Djunaedy and his family. Without their help, the author never would have gone to Holland. Due to the economic disaster across Southeast Asia, it was almost impossible for the author who was doing his master’s thesis to buy an airline ticket for the interview in Delft. None of his friends or relatives were able or willing to help, or did not trust the author’s ability to pay them back if something went wrong. (Indeed, if something went wrong, the author will never able to pay back the loan with the normal salary in Indonesia for his whole life!). Ery sent a long email of encouragement and called to discuss any possibilities for solving the problem in his office at the National University of Singapore. The author could not find him at his office (he had already left to be with his wife in Bandung, Indonesia, who was expecting their second baby), but the author found a paid ticket with the author’s name on it for the interview. After having presentation and a three days of full Dutch coffee interviews with all ICA group members in Delft, the author was accepted for the PhD position, but sadly also had to accept a clausal: ”no ticket reimbursement if accepted or full reimbursement if rejected.” –Fortunately, no other PhD candidates after the author will have to accept this condition anymore– The Djuenady’s were very happy with this news and never asked about the payback. Months later, the author finished his master’s degree, and was facing the same problem of how to buy a ticket to start his PhD research in Delft. Again, Ery bought a ticket for the author - the one whom he called ’akhi ’ (my dear brother) - with his credit card, while the first one was not paid yet. If God has His Arsy (throne), then the Arsy must be shaken by the Djunaedys’ demonstration of a brotherhood. Jazakallahu khairan katsiran! Dr. Yogi A. Erlangga for being the LATEXguru in this thesis preparation, and for introducing the gentleness and the beauty of the Salafy school. The Raam family, the Nugraha family, Mr. Helman Muhammad and family, the Jacobs family, the Supriyanto family, the Parikesit family, Bang Syamsudin and other Indonesian and Muslim communities in Delft, Rotterdam, Den Haag, and Amsterdam whose names the author cannot include. Para (tidak lagi) bujangan such as Oki, Hatami, Rusdha, Gea, Rizki ’Kiki Gis’, Sanny, Ari ’Pai ’ Nugroho, Ari Nurman, Said (benernya sih: Irfan), Ary ’Datuk ’, Andi, Ican, Nandra (Nganu), and Noval (baca: Nopal ) for being such nice anakanak to the author. The Abdurrahman Kadir family, all other relatives and friends especially Eko Ihsanto, Syamsul Bahri, Santi ’Ode’ Soekanto, Wisnu ’Kadz ’ Pramudya and all their family, who make the settlement of the author’s family in Indonesia goes

iv

ACKNOWLEDGEMENTS

smoothly. Mas Bambang I. Soemarwoto and Natalia R. ’Ceu Iya’ Mustafa, the author’s only cousins in Holland, and their daughter Karina ’Ayin’ P. H. Soemarwoto for their hospitality toward author whenever he feels homesick. Marbiah Abubakar-Jambak, the author’s mother, Muhammad Ihsan ’Kak Ican’ Jambak and Muhammad ’Irfan ’Papang’ Jambak, the author’s brothers and their families (’Yuk Mila’ Tirawasni, Dek Nurhasanah Wuri Utami, Inayah, Ikrom, Irham, Balqis, and Nuha) for their love, continuously praying, supporting, and encouraging. At the most, the author and his family is indebted to Kak Ican as he has been the backbone to the Jambaks, especially after the past of the beloved father Ahmad Jambak. The author also hopes Papang will finish his PhD soon and together with the author will be able to payback the sacrifice of Kak Ican, the one who support the author and Papang to reach this stage. Mo kaseh Kak, kalu idak kerno toubouk-tu, kamek beduo dak pacak jadi mak ini. The author hopes this thesis could fulfil the effort of the Jambaks to promote the value of education and knowledge in the riches-oriented society of number 30 of world’s most corrupt countries (source: Transparency International, 2006). The hopes and prays also go to ’Nelly’ Nawal Abdurrahman, the author’s sister in law and her family in Japan, who is struggling to finish her PhD. Ganbatte kudasai ! ’Afifah ’Iffah’ Azzahra’ Abdurrahman, the author’s soulmate and lifelong partner, for being his lovely wife, taking care of his sons –his walking hearts– and for trusting him completely although sometimes this trust was tearful and painful for her. No matter how far and high the author must go to achieve, she is always better than him because of the above reasons. Without her role in all of this, it is inconceivable for the author to believe he could have finished this research. Ahmad Asadillah ’Asad ’ Abdurrahman Hasan, Ahmad Abdurrahiem ’Ahmad ’ Salim Fiddaroini, and Ahmad Abdulhaq ’Abduh’ Mutawakkil –the most beautiful and joyful gifts in the author’s life. They deserve the author’s sincere thanks for, because of them, he refused to give up and fought any and all obstacles. The author hopes this piece of work will be a good foundation and source of encouragement and inspiration for their better life. To conclude this acknowledgement, the author would like to make an apology to his mothers, his brothers, his wife, and his sons for their tears and suffering caused by the commitment of the author to this research work, especially his absence for the last two years. The author wishes to be able to compensate for his absence, either in the future or otherwise, hopefully, this commitment may cause a better reunion in the next life. Muhammad Ikhwan Jambak Delft, 04 April 2007

Contents

Acknowledgements

i

1 Introduction: Getting into the Context

1 1 5

1.1 1.2 1.3 1.4

1.5 1.6 1.7

Data, Information and Knowledge in Design Process . . . . . . . . Data, Information and Knowledge Handling in Early Design Phases Using State-of-the-Art Search Engines for Supporting the Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Problem Statement and Research Questions . . . . . . . . . . . . . 1.4.1 Knowledge-Generating Point of View . . . . . . . . . . . . 1.4.2 Artifact-Generating Point of View . . . . . . . . . . . . . . Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research Approach and Basic Definitions . . . . . . . . . . . . . . Thesis Context and Overview . . . . . . . . . . . . . . . . . . . . .

2 The Chaos of Context: A meaning reconstruction survey 2.1 2.2 2.3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Context in the Dictionary . . . . . . . . . . . . . . . . . . . . . . . Context in Various Disciplines and Applications . . . . . . . . . . 2.3.1 Context in Ubiquitous and Pervasive Computing . . . . . . Context Categorization, Handling and Use in Ubiquitous and Pervasive Computing . . . . . . . . . . . . . 2.3.2 Context in Information Science, Information Retrieval, Web Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Context in Information Science . . . . . . . . . . . . . . . . Context in an Information Retrieval and Web Search . . . 2.3.3 Context in Design . . . . . . . . . . . . . . . . . . . . . . . Context in Architecture/Building and Urban Design . . . . v

8 10 10 11 12 12 14 15 15 16 19 19 22 25 26 27 28 29

vi

CONTENTS

Context in Software Design . . . . . . . . . . . . . . . Context in Consumer Product/Industrial Design . . . Context in Mechanical and Other Engineering Design Shape Context in Product Modeling . . . . . . . . . .

. . . .

. . . .

. . . .

31 34 40 42

2.4

Summarizing Remarks on ”Context” . . . . . . . . . . . . . . . . .

44

2.5

Context in this Thesis: Problem Statement Revisited . . . . . . . .

46

2.6

Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . .

48

3 The Study of Context Knowledge in Design Practice1

49

3.1

Introduction

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

49

3.2

Introduction to the Desys Project . . . . . . . . . . . . . . . . . .

50

3.3

The Relevance of the Context Study and D1 Experiment

51

3.4

Indicating the Existence of Context in the Design Process . . . . . 3.4.1 Indicating the Existence of Context by the Emergence of New Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . f-file Analysis and Discussion . . . . . . . . . . . . . . . . . 3.4.2 Indicating The Existence of The Context By Answering-Time Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results and Discussion . . . . . . . . . . . . . . . . . . . .

54 54 54 58 58 58

3.5

The Role of Context in Communication . . . . . . . . . . . . . . . Terminologies, Definitions, and Analysis . . . . . . . . . . . Results and Discussion . . . . . . . . . . . . . . . . . . . .

60 60 62

3.6

Proposed Formalism . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Design Process Formalism . . . . . . . . . . . . . . . . . . . 3.6.2 Context Knowledge Formalism . . . . . . . . . . . . . . . .

64 64 65

3.7


65

. . . . .

4 System Conceptualization

53

67

4.1

Introduction

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

67

4.2

System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

4.3

User Validation and Addition . . . . . . . . . . . . . . . . . . . . .

72

4.4

Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

4.5

Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

4.6

Context Management . . . . . . . . . . . . . . . . . . . . . . . . .

77

4.7

Information Design . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

4.8


82

1 adopted

from Jambak and Vergeest [2004]

vii

CONTENTS

5 The Contextual Design Information Retrieval System 5.1 5.2 5.3 5.4 5.5 5.6

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Specification . . . . . . . . . . . . . . . . . . . . . . . . . System and Interface Requirements Specification . . . . . . . . Web-based Contextual Design Information Retrieval System . . System Database . . . . . . . . . . . . . . . . . . . . . . . . . . Profile Management . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Login system and User Profile Modules . . . . . . . . . 5.6.2 Project Module . . . . . . . . . . . . . . . . . . . . . . . Project Profile . . . . . . . . . . . . . . . . . . . . . . . 5.7 Dialogue Management . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Search Module . . . . . . . . . . . . . . . . . . . . . . . Search Engine Utilization . . . . . . . . . . . . . . . . . History and Bookmark . . . . . . . . . . . . . . . . . . User’s Embedded Documents . . . . . . . . . . . . . . . 5.8 Context Management . . . . . . . . . . . . . . . . . . . . . . . 5.8.1 Context Editor . . . . . . . . . . . . . . . . . . . . . . . 5.8.2 Context Visualization . . . . . . . . . . . . . . . . . . . 5.8.3 Context Search and Copy . . . . . . . . . . . . . . . . . 5.9 Structured modules list . . . . . . . . . . . . . . . . . . . . . . 5.10 Modules Interaction . . . . . . . . . . . . . . . . . . . . . . . . 5.10.1 User Profile, Project Profile and Search Interaction . . 5.10.2 Project Creator, Search and Context Editor Interaction 5.11 Concluding Remark . . . . . . . . . . . . . . . . . . . . . . . .

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

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

83 83 84 84 85 86 88 88 88 88 89 89 90 92 95 98 98 100 103 104 104 106 106 108

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

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

111 111 111 112 112 116 117 118 119 119 120 121 123

6 System Life-Cycle Illustration and Evaluation 6.1 6.2

6.3

Introduction . . . . . . . . . . . . . . . . . . . . . . . System Life-Cycle Illustration2 . . . . . . . . . . . . . 6.2.1 The Design Assignments . . . . . . . . . . . . 6.2.2 Context Building . . . . . . . . . . . . . . . . . 6.2.3 Context Use . . . . . . . . . . . . . . . . . . . System Evaluation . . . . . . . . . . . . . . . . . . . . 6.3.1 Evaluation Strategies and Methods . . . . . . . 6.3.2 Evaluation Results . . . . . . . . . . . . . . . . Experts’ Profile . . . . . . . . . . . . . . . . . Experts’ Opinions on Existing Search Engines Experts’ Opinions on Future Search Engines . Expert Opinions of CDIRS . . . . . . . . . . .

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

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

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

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

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

2 This illustration is built-up partly from the observation of several participants who volunteered to simulate the same assignments as mentioned in this chapter with and without using CDIRS. Some pictures used in this illustration have already been appeared in chapter 5.

viii

CONTENTS

6.4

6.3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7 Conclusions and Future Work 7.1 7.2

7.3

129 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.2.1 History: short-term memories . . . . . . . . . . . . . . . . . 130 7.2.2 Bookmarking: Long-term memories and design process capturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 7.2.3 File inclusion: Building low-level context . . . . . . . . . . 131 7.2.4 Context Editor: Building and modifying contexts . . . . . 131 7.2.5 Context Visualization: Making explicit context visible . . . 132 7.2.6 Copy Context: Making sharable contexts transferable . . . 132 7.2.7 Search Personalization and Compartmentalization . . . . . 132 7.2.8 Implementable Contexts . . . . . . . . . . . . . . . . . . . . 132 7.2.9 CDIRS as Knowledge Elicitation and a Transfer Mean . . . 132 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.3.1 Limitation of the Project . . . . . . . . . . . . . . . . . . . 133 7.3.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . 133

Bibliography

135

Summary

145

Samenvatting3

149

Inhaltsangabe4

153

Yhteenveto5

157

Matome6

161

¨ 7 Ozet

163

Ringkasan8

167

Committee Members’ Profile

171

Vitae

173

3 Summary

in Dutch in German 5 Summary in Finnish 6 Summary in Japanese 7 Summary in Turkish 8 Summary in Indonesian and written in Jawi/old Malay. This ancient Indonesian and Malaysian script was disappeared from Indonesian society during the Nederlandsche Oost-Indische occupation, while it has still been taught and used limitedly in Malaysia nowadays. 4 Summary

CONTENTS

ix

Appendix A –f-file Session 19

175

Appendix B – f-file Session 2

183

Appendix C –CDIRS Documentation

191

Appendix D –Expert Questionnaire Form

199

9 complete

sessions documentation in van Breemen, 1996

Chapter 1

Introduction: Getting into the Context

”The mere formulation of a problem is often far more essential than its solution, which may be merely a matter of mathematical or experimental skill. To raise new questions, new possibilities, to regard old problems from a new angle requires creative imagination and marks real advances in science.” - Albert Einstein

1.1

Data, Information and Knowledge in Design Process

The design process has been formalized, described and interpreted in many ways [Cross, 1995; French, 1998; Hyde, 1989; Pahl and Beitz, 1995; Roozenburg and Eekels, 1995], and has ended up with different representations of design process diagrams. Furthermore, a comprehensive look at the design process can be found in Braha and Maimon [1997] work. All of these descriptions can be simplified and described as a series of activities including analysis, synthesis, representation/simulation, evaluation, and decision, as shown in Figure 1.1. First, based on need, motivation or the specific design task, the designer(s) researches the problem area and analyzes it. The designer(s) then synthesizes all of the necessary information in order to produce (some alternative) problem solutions candidates. These problem solutions candidates will then be simulated or represented in a CAD system or a simple pencil sketch and will then be evaluated before a decision can be made. Certainly, large amounts of data, information and knowledge are involved throughout the design process [Court, 1997; Rodgers et al., 2001]. 1

2

INTRODUCTION: GETTING INTO THE CONTEXT

1.1

Factually, a design process can be seen as an activity designed to transform the available data, information, knowledge and expertise to construct a map from an expressed solution need [Lang et al., 2002].

Figure 1.1: Basic design cycle [Roozenburg and Eekels, 1995]

While the definitions of data, information, knowledge and their relationships remain debatable [see Court, 1997; Eckert et al., 2005; Groff and Jones, 2003; Maier et al., 2005; McMahon et al., 2004; Morroni, 2006; Stenmark, 2002; Tuomi, 1999; Wang and Ariguzo, 2004], traditionally, ”data” is understood as raw facts. For instance, material properties are just a list of a number of physical facts about such materials. Meanwhile, ”information” gives them meaning by connecting these pieces of data to certain topics. In this case, the information about design material might allow the designer to choose which material is suitable for the alternative solution, but will not disclose the separate number that appears in each of the physical properties of the material. ”Knowledge” is created when information is observed by the designer and recorded by his memory through a mental activity. Furthermore, knowledge adds information to the understanding and capability of the owner of that knowledge and places them in a state of knowing that guides actions, whereas data and information simply inform or even confuse. For that reason, designers can be defined as information processing systems in

1.1

DATA, INFORMATION AND KNOWLEDGE IN DESIGN PROCESS

3

order to solve design problems or to find ideas, as illustrated in Figure 1.2. Therefore, the result of a design project depends very much on the initial know-ledge and expertise of the designer(s) and also on the information obtained during the design process by any means of information retrieval. The initial knowledge or information is referred to as any knowledge or information that a designer has before he starts to retrieve necessary information. Expertise is regarded as the capability of converting a designer’s knowledge into actions in a specific area. These components are interrelated and influence each other. For example, knowledge and expertise do not only differ in their capacity to initiate search terms in an information retrieval process, but they also differ in their capacity to judge and utilize the information search results. Conversely, if the quality of incoming information is higher, it will positively influence the designers’ ability in the design decision-making and problem-solving areas while also reflecting the level of the designer’s expertise.

Figure 1.2: Designer as an information processing system. Adapted from [Wiegeraad, 1999]

Unfortunately, the amount of data, knowledge and information to be handled by designers is often too large, broad and unmanageable to be implemented into a well-structured system. As a result, although data, information and knowledge are abundantly available and surround the designer, getting access to the correct and necessary knowledge or information for a particular design process is not always an easy task [Cave and Noble, 1986; Lang et al., 2002]. The challenge of the above issue does not only come from the size, types and difficulties in utilizing the data, information and knowledge from various locations, domains and disciplines (as shown in Figure 1.3) but also through the ambiguity between connections/relationships, sequences, and keywords. Because

4


1.1

of this deficit, in many cases, designers often do not complete a great deal of informational research [Rouse and Cody, 1989], preferring instead to use information they already possess [Court, 1997]. As a result, informal communication with a nearby colleague is often preferred over a systematic search through literature, patent databases and so forth. This situation merely leads to the risk of making wrong decisions and overlooking new possibilities concepts. In addition, this situation also results in many designs being generated without the benefit of existing information in the design environment. In the end, this could degrade the quality of the design and/or unnecessarily lengthen the design process.

(a) Information sources

(b) Information types

Figure 1.3: Information Sources and Types [Wiegeraad, 1999]

For an expert or experienced designer, it is relatively easy to understand the context of such data, information or knowledge to be accessed and applied and to predict the consequences of such actions in each design state. This kind of understanding is defined as knowledge about knowledge and termed by Hori [1997],

DATA, INFORMATION AND KNOWLEDGE HANDLING IN EARLY DESIGN PHASES

1.2

5

Clarkson and Hamilton [2000], as ”meta-knowledge”. For the purpose of this research, meta-knowledge in this thesis is more specified knowledge about context, and therefore is termed as ”context-knowledge” and technically defined in chapter 2. For instance, this includes putting into practice which keywords are to be used to access the internet, which experts need to be contacted and consulted, which drawings needs to be learned, what practices would be best to adopt, etc. The concept of ”context” itself is being explored in many research fields, such as artificial intelligent [Akman and Surav, 1996; Buvaˇc et al., 1995], know-ledge management [Schwotzer, 2002], natural language processing [Brézillon, 1999b], and information seeking [Kari and Savolainen, 2007]. The term ”context” is widely used but does not enjoy a consensus on its meaning. However, generally speaking, it has to do with knowledge or information relationships. Indeed, Schwotzer said that knowledge never stands on its own; it is always embedded in a context. In this thesis, the concept and term ”context” is explored and discussed from many angles. Furthermore, context knowledge terminology is introduced, referring to a subset of all knowledge that identifies the context of specific knowledge or information. There are other reasons to immerse this context knowledge in the design environment besides its important role in design processes, as described in the above case. First of all, a design project is necessarily executed by a group of designers, so it is very important that they have the same goals in mind. Although they could have the same sources, they may not have access to the same data, information or knowledge. Second, the knowledge transfer from experienced designers to novice designers can be speeded up if the context knowledge is visible or easily available. Third, since most knowledge is in the designers’ minds, most design companies frequently suffer from knowledge loss if a designer leaves the company.

1.2

Data, Information and Knowledge Handling in Early Design Phases

A design process can be described according to its phases and the outcomes of each phase, as shown in Figure 1.4. The process starts with a need or design brief. The first design activity is to analyze the problem or clarify the task. The output of this activity is a statement of the problem or a design specification. In the conceptual design phase, one or more alternative solutions or concepts are developed; one or more of them are selected and taken to the next phase. According to the results obtained in the embodiment phase, necessary feedback is provided in order to re-analyze or rebuild a new concept. After the necessary iterative modifications, a concept is chosen and detailed in the detail design phase, as some output, such as working drawings, production planning, etc., will be produced. The early phases of design refer to the analysis and conceptual phase. Unlike the other phases, these phases are characterized by ill-defined problems. They involve describing the real problem, the possible solutions, and the methods re-

6

1.2


Task

Need

Clarification Analysis of Problem

Specification Conceptual design Selected concepts

Statement of Problem

Conceptual Design

Feedback

Embodiment design Preliminary design Detail design

Selected Schemes

Embodiment of the Schemes

Finished design Production planning Product

(a) Product development phases [Pahl and Beitz, 1995]

Detailing

Working Drawings, etc

(b) Conceptual design phases [French, 1998]

Figure 1.4: Two interpretation of design phases

quired to obtain the solution, in many cases, cannot be completely validated. Therefore, design methods suggest to avoid premature commitment to a design problem solution, but rather iteratively and gradually propose design concepts, specifications, functions, and alternative solutions, and evaluate them as soon as possible [Austin et al., 2001; Hatamura, 2006; Jin and Chusilp, 2006; Ozkaya and Akin, 2006; Qin et al., 2003; Segers et al., 2005]. In order to identify the need, to generate or search ideas or concepts, to look up alternative solutions, or to define specifications and functions, designers generally use divergent approaches which involve the suspension of judgments. Meanwhile, designers use convergent approaches to evaluate or select those alternative solutions, which involves the imposition of value judgments [Cross, 1995; Liu and Bligh, 2003; Roozenburg and Eekels, 1995; Thompson, 2005], as illustrated in Figure 1.5. The iterative process and the divergent-convergent approaches mentioned above are also true for the information search process during the design process. Based on personal understanding and knowledge capacity, one can initiate a search that is believed to contain useful information. In the divergent approach, some of this information are seemingly irrelevant but could lead to alternative or new ideas or could trigger a new search term [Jambak et al., 2005; Snoek et al., 1995]. Otherwise, designers must refine the search term that is believed to be closer to his or her design informational needs. When useful information is retrieved, designers

DATA, INFORMATION AND KNOWLEDGE HANDLING IN EARLY DESIGN PHASES

1.2

7

Needs

Divergent

Convergent

Exploration

Specification (requierments)

Identification

Concept design

Generation and evaluation ideas

Solution

Level of solution abstraction

(a) adapted from [Liu and Bligh, 2003]

(b) adapted from [Thompson, 2005]

Figure 1.5: Divergent-convergent approaches

might want to complete a convergent approach by detailing the results with a new search, as can be seen in Figure 1.6. During this iterative process, designers gradually structure the connections among the incoming information and build knowledge by setting connections between one query to another. The situation illustrated in Figure 1.6 actually occurs in both human to human and human to non-human interactions. For the first interaction that is human to human, a designer to expert discussion or a brain-storming session in ad design team can be used as an example. A designer can direct a question towards an expert in order to find a solution or a problem based on his personal understanding of the design task or problem. The first question may be vague for the expert, but he or she can answer the question or decide to gain further understanding by further questioning the designer. The more frequently the two parties exchange questions and answers, the faster both of them will reach a state of understanding, where the designer can ask very specific questions and the expert can more easily understand the question and therefore give his expertise to the designer. Obviously, the information search process on the internet can be taken as an example of a human to non-human interaction, illustrated in Figure 1.6. However, a designer reading a book can also be an example of this interaction. Moreover, it can be taken as an example of a divergent approach, where an idea possibly comes to the designer’s mind, although he or she reads a book that did not have a direct link to his or her design project. When this happens, he or she can begin to shape the idea with the convergent approach by finding more specific data in more specific resources, for example, a design handbook, a material properties handbook, etc. A number of remarks can be derived from the above examples. First of all, there are two differences on how the designer and information resources interact with each other. In the case where sources are human, such as an expert or other

8

1.3


Yes

Search

Search results

Evaluation

Relevant Yes

No

Refine search term

Inspire new idea

No

Yes New search term No Finish Yes

Detailing

No

Figure 1.6: The information search model

design team members, both parties gradually develop common understanding (a)1 . Therefore, they can share this understanding (b). They can also validate the ”need” for each party (c). For instance, the expert can validate a designer’s question to determine whether it is reflecting his or her informational need or not, and the designer can discuss with the expert whether the answer from him or her is something he or she really needs or not. Meanwhile, the designer has to develop his or her own understanding in human to non-human interactions (d).

1.3

Using State-of-the-Art Search Engines for Supporting the Design Process

Today, the enormous growth of web sites has opened up opportunities for designers to retrieve a broad variety of design information, such as potential markets, existing competitors, materials, processes, etc. Designers use a search engine in order to retrieve this information from the internet. These search engines do offer not only better algorithms, but also technology advancements that potentially help designers to gain necessary information. These advancements include automatic bookmarking, history, audio and video searches and playback, image searches, e-book searches, and communication means. The automatic bookmarking and history provide services where a user of an internet search engine does not have to bookmark any of the checked search results 1 Although the problems of communication between experts and non-experts are known, see [Eppler, 2004; Stonehouse and Pemberton, 1999], but that is a research field by itself

USING STATE-OF-THE-ART SEARCH ENGINES FOR SUPPORTING THE DESIGN

1.3

PROCESS

(a) Automatic bookmarking and history

(b) Audio search and playback

(c) Video search and playback

(d) Image search

(e) e-Book search

(f) Communication means

9

Figure 1.7: The popular search engines and their features

and can keep them in the historical search. This advancement keeps the search process and the results in one environment. Without this advancement, a user must bookmark a search result using the internet browser. It is also possible

10


1.4

to search an audio or video file on the internet and play it inside of the search engine. While some of these multimedia files are restricted by copyright, some of them may be freely downloaded. Images or static pictures may now be searched and downloaded from a search engine. Search engines are able to not only search information that is in different formats (i.e., text, postscript, Microsoft ™ office) or different languages, but are also able to go through an electronic book. Some of these search engines provide various communication services, such as email, messenger, and audio/video conferencing. These advanced features for popular search engines are shown in Figure 1.7. At this moment, the notion of ”relevance” is still at the center of information retrieval research [Baeza-Yates and Ribeiro-Neto, 1999]. Therefore, algorithmic approaches have been fighting to improve search engines. It is fair to say that some of these search engines significantly improve their query methods and techniques, bringing their degree of relevance closer to the actual ”information need”. Their confidence in their search results can be seen by their offers to give only the top web page in their ranking that is returned in a query (For example, the ”I’m feeling lucky” service offered through www.google.com). Despite the increase of users’ (including designers) satisfaction in available search engines, their applicability in the field of design still has room for improvement. Companies are still looking for improved tools to assist the designer in retrieving information where the internet as a source of information is increasingly important.

1.4

Problem Statement and Research Questions

In order to better articulate the problem statement and research questions of this research work, it is necessary to briefly introduce the philosophical fundamentals of research in design, and the research-design relationship (for more detail and further readings: [Braha and Maimon, 1997; Fallman, 2003; Stappers, 2005]). Although both of research and design share their similarities, and each of them is essential to the other –research is essential to design, and viz versa–, they differ in their aim [Stappers, 2005], and therefore an activity can be subject to one of them based on its orientation. Fallman [2003] simplifies the discourse into two categories: knowledge-generating design-oriented research and artifactgenerating research-oriented design. Both of these categories are used to articulate the problem statement and research questions of this research work.

1.4.1

Knowledge-Generating Point of View

This research wanted to gain knowledge of how ”context” can give the opportunity to solve problems to gather knowledge, store and represent knowledge, and to manage it, and to reduce the risk of brain drain that often happens when a designer leaves a company. In order to do so, some research questions have emerged including the following:

1.4

PROBLEM STATEMENT AND RESEARCH QUESTIONS

11

• What is the concept of context? • How to use or handle context?

1.4.2

Artifact-Generating Point of View

The existing search engines assume that a supplied search term is a mature fix, and accurate information is needed. At the early phases of design, the design problem is ill-defined, the concept is vague, and possible solutions are unevaluated; therefore, the most likely informational need is also vague. At this point, designers are actually defining and validating the information need. Consequently, in order to define an accurate ”information need”, designers should complete information searches iteratively while his or her mind evolves from abstract to concrete, from partial understanding to comprehensive understanding of the design task, needs, problems, and possible solutions. On the contrary, most of the search engines treat an information search in a single query process. Subsequently, designers use search engines repeatedly, but the connection between one search term and others, and how they are being grouped into a topic, is only structured in the designer’s mind. Usually, the connection between information or knowledge sources, as illustrated in Figure 1.2 and 1.3(a), are structured implicitly in the designer’s mind. Not many available search engines enable the user to personalize the search process. Google ™ and Yahoo ™ are two that do allow their users to personalize their own search processes, as can be seen in Figure 1.7(a). However, for the design information management purpose, it would be more helpful if could also compartmentalize their search processes based on their design projects, because each design project had its own unique information search. Furthermore, while other search engines are still not concerned about retaining a search history, the features from the two popular search engines mentioned above give users the opportunity to capture the design process and the designer-thinking evolution. However, this feature will come closer to the nature of the design if the users have room to use their judgment instead of automatically storing all search terms supplied or search results clicked. By assuming that every search result is a product of the designer’s thinking, the prospect of capturing the judged search terms will open up possibilities of capturing designers’ thinking paths in each design project. The effort towards knowledge utilization in design practice remains feeble and is still attempting to answer three big questions, namely, how to gather knowledge, how to store and represent knowledge, and how to manage it. The risk of losing knowledge that often happens when a designer leave a company can be reduced if knowledge products, which can be both the process and results of an information search, can be stored.

12


1.6

From the above statements, some research questions have arisen, including the following: 1. How can search engines better fit the design process enabling designers greater benefit from them? These benefits include: (a) The ability to support the iterative process (b) The ability to allow designers to connect the search process with other designers’ external information or knowledge sources, as well as allow designers the ability to build a context knowledge of each information search process 2. How can search engines create an information connection or context-knowledge that is explicit to the designer’s mind? 3. If it can be made explicit, how can it be visualized? 4. Can this context-knowledge (reflecting the designer’s thinking path, processes and results of an information search) be stored? 5. How can a search engine personalize and compartmentalize the search process?

1.5

Hypothesis

In order to decompose the problem statement and answer the research question, hypotheses have been created and clarified during this study. They include: • If the search terms of a search process, using an internet search engine, can be connected, then there is the possibility of making an internet search process more towards the nature of the designer. It is then possible to represent the context. • If a search is supported by a representation of the context of the information request, the probability of obtaining the right response is increased. The explicit creation of contexts and their adaptation and extension during the design process is the key to effective information retrieval and managing the available information and knowledge.

1.6

Research Approach and Basic Definitions

The problem of this research was approached from two angles. Firstly, a literature study to understand the concept of context from various domains and applications. Secondly, an empirical study of a design project. In the empirical study, data from previous investigations on conceptual design tools were studied. From

1.6

RESEARCH APPROACH AND BASIC DEFINITIONS

13

these two approaches, a general formalism on the design process and context were developed. Thereafter, a system to assist context building and manipulation during the information search process within a design process has been conceptualized and implemented. Furthermore, the implemented system has been used as a proof-of-concept of the design practice and has been evaluated by experts. A software system called ”Web-based Contextual Design Information Retrieval System” has been developed and implemented for the purpose of this research. This system aims at helping designers collect information related to their design projects. Thus, the software name must be read as ”contextual designinformation” rather than ”contextual-design information”. ”Contextual design” is a methodology used especially in software design that deals with issues of data gathering, driving and managing the design, team and organization contexts [Beyer and Holtzblatt, 1998]. It is an approach to designing products that comes directly from the designer’s understanding of how the customer works [Beyer and Holtzblatt, 1999]. However, in a broader sense, this system is aimed at helping designers during the execution of a design project to retrieve design-related information, or, in short, ”design information” contextually, regardless of any design methodologies or approaches. It is also necessary to clarify the use of the phrase ”information retrieval system” rather than ”data retrieval system”, although in design processes, both of these types of systems could allow designers to share the same necessitate. According to Baeza-Yates and Ribeiro-Neto [1999], the ”data retrieval system” is aimed at retrieving all items which satisfy clearly defined conditions such as, for instance, a relational algebraic expression that conveys the constraint that must be satisfied by items in the answer set. Furthermore, data retrieval, while providing a solution for the user of a database system, does not solve the problem of retrieving information about a subject or topic. The ”data retrieval system” could be very useful to designers when they are seeking specific engineering data during the design process as a part of the whole design-related information retrieval system. However, not all necessary design information can be specific and constrained into an informational need expression, especially in the early phases of design. In contrast, with an ”information retrieval system” the user’s informational need is translated into a query, which is a set of words which convey the semantics, and then the ”information retrieval system” will ’interpret’ the contents of the information items into a collection and rank them according to their degree of relevance. In many cases, the effectiveness of an information retrieval system is judged according to its precision, or the number of relevant items within the entire number of items retrieved [Saracevic, 1975; Strzalkowski et al., 1997; Xu and Croft, 2000]. In fact, the primary goal of most available information retrieval systems is to retrieve information which is ”relevant” to a user query while retrieving as few ”non-relevant” information items as possible [Baeza-Yates and Ribeiro-Neto, 1999]. However, in design, ”irrelevant” information in a query process may fit or be useful in a certain design context (see Section 1.2). This is the fundamental

14


1.7

reason why the software title ”contextual” that comes from ”context” is chosen, despite using ”relevance” before the ”design information” phrase. Last, but not least, the term ”web-based” needs to be clarified because, generally speaking, a web-based or internet system is a perfect match as an information retrieval system, since the user of an internet system has to specify his informational need as a search term (keywords, phrases or a combination of them) that will be executed in search engines in order to collect the intended information. In return, the search engine will collect lists of websites and rank them based on their degree of relevance. Considering this fact, one can say that every information search process occurs in an ”information retrieval system”. Nevertheless, the term ”web-based” refers to a more specific source among other informational sources in a design environment which can involve experts, books, drawings, charts, local computer files, notes, etc.

1.7

Thesis Context and Overview

This thesis is constructed as follows: Chapter 2 (The Chaos of Context) intensively look at the concept of ”context” in various domains and application. At the end, the term ”context” for this thesis is defined, as well as the term of ”context knowledge”. Chapter 3 (Study on Context Knowledge in Design Practice) reports the study on the indication of existential context knowledge during a conceptual design. Chapter 4 (System Conceptualization) introduces the conceptualization and architectural work of an information retrieval system that gains the benefit of context knowledge, based on the findings of chapter 2 and chapter 3. Chapter 5 (The Contextual Design Information Retrieval System) reports the implementation of a user interface that builds on the existing web search technology and operates in conjunction with a common internet search engine. Chapter 6 (System Life-Cycle Illustration and Evaluation) presents the illustration of how the system can assist designers in developing context knowledge during the informational search completed in the early phases of design. Chapter 7 (Conclusions and Future Work ) closes the thesis with a summary and discussion of the presented research topics and hypotheses clarifications, and concludes with some suggestions for future research.

Chapter 2

The Chaos of Context: A meaning reconstruction survey

”The skill of writing is to create a context in which other people can think.” - Edwin Schlossberg

2.1

Introduction

This chapter aims at clarifying the ”context” terminology that is widely used in many domains and applications. In 1999 alone, an internet search using the keyword ”context” retrieved more than 440.000 documents [Brézillon, 1999b]. At the end of 2006, about 244.000.000 documents were listed in the search results using that same keyword. Since the word is ill-defined and used in many domain specifics with such an ad hoc manner, it somehow creates a chaotic situation that is difficult for those who want to understand it. The strategy of this survey is to start from a dictionary survey, where the root and the common use of the word ”context” can be found. The root and the common understanding are used to draw the meanings from representative specific domains, along with a common concept of those domains. This survey also emphasizes how context has been treated and used in each domain and application. To reconstruct the meaning of ”context”, this survey work not only tries to find a consensus of meaning or concept of ”context”, but also attempts to present the understanding of ”context” from various points of view for domains and applications. Therefore, it can be understood by readers from different domains or applications. At the end of this chapter, three definitions of ”context” and ”context knowledge” for the purpose of this research work are presented. 15

16

THE CHAOS OF CONTEXT: A MEANING RECONSTRUCTION SURVEY

2.2

Context in the Dictionary

2.2

The Barnhart dictionary of etymology [Barnhart, 1988] suggests that the word ”context” as a noun has been used since before 1425 and is borrowed from the Latin word contextus and the past participle of contexere. However, context, in the sense of surrounding parts of a text, was first recorded around 1568. Furthermore, the Oxford Latin dictionary [Glare, 1982] reveals the meaning of the root ”context” as follows: 1. contex¯ o [CON +- TEXO], as an adjective, has the following meanings: (a) to join weaving or otherwise closely linking (e.q. to make by weaving, joining, etc., together) (b)

• to connect, link (word) • to compose, assemble (speech, writing) by linking together

(c) to bring into close association, combine, link ( e.g. to make continuous, join) 2. Contex¯e [CONTEXTVS +- E] is an adverb and means in close combination; in a connected or coherent manner 3. contextim [NEXT +- IM] is an adverb and means in a continuous or uninterrupted manner 4. Contextus [past participle of CONTEXO] as an adjective has the following meanings: (a) closely joined, interwoven (b) connected, coherent (c) continuous, uninterrupted, unbroken 5. Contextus [CONTEXO +- TVS] has several meanings. They include the following: (a) the action of weaving or otherwise joining together (b) the state of being joined, (e.g. logical connection, coherent) (c) an ordered scheme, plan, course (d) the manner in which a thing is made or constructed, structure (e) the state of being uninterrupted, (e.g.,a continuous series or grouping together) (f) a whole made-up numerous part, complex

2.2

CONTEXT IN THE DICTIONARY

17

For the time being, the above explanation for the root of ’context’ will be left as it is, and will again be referred to for the absorption of English or adoption in different fields of research. In order to check the common understanding of the word ’context’, three well-known dictionaries have been chosen for the survey. They include Webster’s New International Dictionary [Gove, 1981], The Oxford English Dictionary, Second Edition [Murray et al., 1989], and The American Heritage Illustrated Encyclopedic Dictionary [DeVinne, 1987]. According to [Gove, 1981], ’context’ is defined as: 1. the weaving together of words in a language 2. the part or parts of a written or spoken passage preceding or following a particular word or group of words and so intimately associated with them as to throw light upon their meaning 3. the interrelated conditions in which something exists or occurs 4.

• coherent in discourse • = contexture

5. things or conditions that serve to date or characterize an article(as a primitive artifact): surroundings 6. the fleshy part of the pileus of a mushroom or other pileate fungus as distinguished from hymenium Meanwhile, [Murray et al., 1989] defines ’context’ as: 1. the weaving together of words and sentences; the construction of speech, literary composition 2. the connected structure of a writing or composition; a continuous text or composition with parts duly connected. 3. the connection or coherence between the parts of a discourse 4.

• the whole structure of a connected passage regarding its bearing upon any of the parts which constitute it; the parts which immediately precede or follow any particular passage or ’text’ and determine its meaning •

– transferred (e.g. ”We carry on with us, from day to day, the whole moral context of the day gone by”.) – figured (e.g. ”It is literally impossible, without consulting the context of the building, to say whether the cups have been added.)

• in this context: in this connection 5. = contexture

18


2.2

[DeVinne, 1987] defines context as: 1. the part of a written or spoken statement that surrounds a particular word or passage and can clarify its meaning 2. the circumstances in which something occurs or exists; the background or setting From these three dictionaries, the meaning of context can be combined into the following definitions: 1. the weaving together of words and sentences 2. the part or parts of a written or spoken statement that surround a particular word or passage and can clarify its meaning 3. the connection or coherence between the parts of a discourse 4. in connection with 5. contexture 6. background or setting and interrelated condition in which something exists or occurs 7. the fleshy part of the pileus of a mushroom or other pileate fungus as distinguished from hymenium The item number 1 can be removed because this definition overlaps with the definitions of sentence and paragraph. The item number 7 can also be removed from the list because this definition is not only too isolated from the other definitions, but also has no connection with the Latin root form. Item 2 and item 3 can be combined because a verbal interchange of ideas or discourses certainly involve some spoken statements. Furthermore, although the meaning of item 5 can have the same meaning as context (e.g., This text is lying in this contexture; Is there anything in the intention and contexture of these ten passages to warrant so grave a departure from the common meaning of the words?), it can also have a different meaning which can be categorized into the derivative word of context. Therefore, it is proposed that this item also be removed from the above list. From this dictionary survey, it can be concluded that the use of ”context” includes the following: 1. the part or parts of a written or spoken statement that surround a particular word or passage and can clarify its meaning; it also covers the interconnection and coherence of those parts 2. in connection with

2.3

CONTEXT IN VARIOUS DISCIPLINES AND APPLICATIONS

19

3. background or setting and interrelated condition in which something exists or occurs For the rest of this chapter, these three definitions are referred as the daily common understanding of context.

2.3

Context in Various Disciplines and Applications

Context has been exploited in many research domains [Brézillon, 1999a,b; Guha, 1991; Serafini and Giunchiglia, 2002]. However, this word has been extended in many directions and is generally not well-defined. ”Context” then becomes some sort of ”conceptual garbage can” [Akman, 2000], since the word ”context” is used daily and everyone supposedly knows its meaning without a clear definition. Otherwise, one will give an ad hoc definition to delineate the particular meaning from one’s own point of view [Akman and Surav, 1996; Bazire and Brézillon, 2005]. The following subsections will explore the notion of ”context” and how it is used in different discipline. It is a realistic expectation that there is no consensus among the disciplines related to the many aspects of ”context”. In fact, the common meanings found in the dictionary survey have apparently been used in confusing ways or have been extended exclusively towards a particular discipline which ends up creating new meanings. On the contrary, there is still a question as to whether a unified theory of ”context” can be realized [Buvaˇc and Kameyama, 1998]. However, after the dictionary survey, the exploration of various disciplines and applications is the logical departure point in search of the understanding of ”context”.

2.3.1

Context in Ubiquitous and Pervasive Computing

The mobile lifestyle is now supported by many types of ubiquitous electronic devices that are present everywhere. Pervasive computing is the new research application moving towards increasing ubiquitous and wireless connected computing devices in an environment. This area of research not only covers existing wireless mobile devices, such as mobile phones or laptop computers, but also any device that can be embedded in an object and can communicate through the interconnected network, creating a completely connected, intuitive, and effortless portable that is constantly available in such environments. Consequently, to reach these goals in this research area, this domain of research must deal with humancomputer interaction problems. The use of context is important in interactive applications, but on the contrary, it has been noticed that human capabilities use implicit situational information (or context) to increase their conversational bandwidth, does not transfer well in human-computer interactions [Dey and Abowd, 1999; Dourish, 2004].

20


2.3

According to [Dey, 2001] and [Crowley et al., 2002], the definition of ”context” in the field of pervasive computing was first introduced by Schilit and Theimer in 1994. [Schilit and Theimer, 1994] argued that computation no longer occurred at a single location in a single environment. For this reason, the information on a location enabled users to query and use nearby devices, while also enabling software to track a moving object (the changes object over time) and adapt according to the 1) location of use and 2) the collection of people and objects. ”Context”, according to them, refers to a location, people and an object’s identity, as well as the changes in the objects. [Dey, 2001; Dey and Abowd, 1999] and [Crowley et al., 2002] stated that after [Schilit and Theimer, 1994], similar definitions have been proposed with some other elements included, such as time, focus of intent, environmental elements (temperature, season, etc.), and user’s physical, social, and emotional states. Context is also defined as the environment, situations, and subsets of physical and conceptual states of interest for a particular entity. The above definitions are too technical and too domain-specific, since all of them seem too far from the common meaning that can be found in the dictionary. Furthermore, [Dey and Abowd, 1999] and [Dey, 2001] said that the above definitions are either too general or specific. Therefore, they proposed a new definition which seems to be the standard in this domain. According to http://citeseer.ist.psu.edu/, these two papers have been cited a total of 132 times since their appearance and have become the central issue for HumanComputer Interaction journal, special issue (volume 16, number 2, 3, & 4, 2001). As they stated, ”context” is defined as: any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. This definition of ”context” (or often confused as ”context information”; see: [Shafer et al., 2001] and [Khedr and Karmouch, 2005]) is converse to the item 3 of the common meaning of ”context”. In the third meaning of ”context” in the dictionary, the ”situation” is used to explain something that interchanges between two subjects. For instance, the information interchanges, by the above definition, the information is used to characterize (explain) the situation. In addition, according to [Winograd, 2001], this definition is still too general, since it uses open-ended phrases, such as ”any information” and ”characterize.” From the facts given above, it is clear that in this domain, the definition of context, and the important elements that are comprised within context, still remain debatable. To implement such concepts of context, researchers face a trade-off between the scope of their context and the possibility of the implementation. It is not easy to include the social and emotional context of the user, but at the same time, if they reduce the scope of context, the system then only partially supports the context and merely turns to a listed-preserved users’ expectations system.

2.3


Input

Output

(a) Traditional ”black box” application

Explicit Input

21

Explicit Output

(b) Context-aware application

Figure 2.1: Context is everything but the explicit input and output [Lieberman and Selker, 2000]

This way, the implemented system can become intrusive and annoying when the users’ intentions and expectations are not listed or wrongly defined beforehand by the system designers/developers. Researchers in this domain dispute the definition of context, not only because of their different views on approaches, but also because the nature of the system will support the context. The system could purely used the input and output of the computation system point of view to implement the context. Figure 2.1 shows that Lieberman and Selker [2000] used the shifting of computation point of view from traditional ”black box” application to context-aware application to define context as everything but explicit input and output. The implementation of a context concept in a pocket PC, shown in Figure 2.2 could give two different views of how the context possibly be implemented. First of all, although it is complex, it is quite easy to define the context of loading information that is stored along with a map in the pocket PC. The system will load the connected information, such as a restaurant’s name, nearby gas stations, or public transports that are near the point of location using a global positioning system (GPS). Here, in this system, the contextual information is loaded according to the change of the ”location”. For the second possibility, which is rather difficult, is to define the context that enables one to automatically switch off the user’s home electric equipment using this pocket PC when the user goes to sleep. A simple assumption that the user will go to bed after midnight could turn to disaster if the user is working late to prepare for a very important meeting in the morning. More examples of this kind of ”intelligent” context application are elaborated in [Khedr and Karmouch, 2005]. The above pocket PC application examples show that the ”situation” happening in a ”context”, which is lead the necessity to define the situation in order to understand the context. The first pocket PC application example shows that the

22


2.3

Figure 2.2: The implementation of context concept in pocket PCs

situational information is loaded according to where the location is situated on the map. In the second example, the context (must) tried to define the situation in which the contextual action must be done. Regarding to their definition, Dey and Abowd [1999] and Dey [2001] include the term ”situation” in their definition, but unfortunately, give less attention to describing the notion of situation. McCullough [2001] defined ”situation” as abilities connected with a setting. If this definition is combined with the third common meaning of ”context”, or ”setting conditions in which something exists or occurs” then it can understood that situations point out the context in which something exists or occurs. Meanwhile, [Greenberg, 2001] noticed that the dynamic nature of context is defined by situated action. However, situated action is easily confused by the institutionalized (and often simplistic) social norms that are often used to predict and prescribe all actions. The example of making the assumption that all people will sleep after midnight is an instance where institutionalized and simplistic social norms can wrongly define a situation. Context Categorization, Handling and Use in Ubiquitous and Pervasive Computing Looking at the fact that the definition of context is far from reaching a consensus in this domain, viewing how plausibly researchers treat, handle and use the context

2.3


23

will be much more worthy to note. First of all, the dispute can be abstracted to the level of conception rather than a more complex application level. Second, as [Gu et al., 2005] said, by classifying various contexts and knowing their characteristics, it is possible to perform a context reasoning where perhaps a context conflict can be solved. Dourish [2004], made a categorization based on the view of researchers of when they handle context. Based on these categories, he then made a general assumption. Dourish said that the context representations were inspired by the social science that falls into three major categorizations: positivist, phenomenological, and critical theories; only positivist and phenomenological theories are relevant to context. While positivist theories are derived from the rational, empirical, and scientific tradition and, therefore, are often objective and quantitative in nature, the phenomenological theories are subjective and qualitative in orientation. In summary, positivist and phenomenological theories are not compatible. However, many researchers attempt to derive positivist responses to phenomenological arguments, for instance, when trying to encode and represent the context. From this point of view, such definitions of ”context” can be generalized into four assumptions, including the following: • context is a form of information • context is delineable • context is stable • context and activities can be separated. Dourish argued that context as a representational problem with the four listed principles above can model the sociological critiques but not the context itself. He proposed an alternative view which does not use the sociological approach. Instead of considering context as a representational problem, he considers it as an interactional problem. Instead of raising the question of ”what is context and how can it be encoded”, he questioned ”how and why, in the course of their interactions, do people achieve and maintain a mutual understanding of the context for their actions?” Those four assumptions listed above have been altered into the following assumptions: • contextuality is a relational property held between objects or activities • the scope of contextual features is defined dynamically • context is occasioned property • context arising from the activity (or content) cannot be separated

24


2.3

With this assumption, Dourish altered the conception of ”context” from something that describes a setting to something that people do and formed an engagement of those settings. This conception, although slightly different from what Dey and Abowd [1999] and Dey [2001] proposed, still opposes the common meanings listed in the dictionary. The item 3 common meaning of the word ”context” would give a setting, for example, of why somebody would do this or that. However, with Dourish’s conception, it will be understood that somebody does this or that because of a certain context. Moreover, Dourish claimed that users would be allowed to negotiate and evolve systems of practice and meaning in the course of their interaction with information systems, or what he called ”embodied interaction”. Crowley et al. [2002] categorized context into a user’s and system’s context. They refer to the ”user”, using common computer science terms, as human agents. The context of which such systems should be aware is that of one or more users. In most cases, users are driven by one or more goals which can be parallel or switched from one to another. However, interacting with the system is not considered to be the goal of the user. In fact, when they use the system to archive their goals, it should be invisible to users. Crowley [2002] proposed definitions of state, task, and activity for this model. A state is defined as using combinations of predicate (or their negation) expressions, which are functions of properties observed in the world. Actions are represented by connected states in the universe. While at any instant in time, the universe is a state called a current state, a goal state is a state where the user brings the universe to another state, requiring a sequence of actions. The association between the current state and the goal state is a task. A set of current tasks define the user’s activity, some others can be referred to as background tasks. A system’s context is composed of this model plus a model of its internal context. This composition then provides the means to observe and interpret the observations. Gu et al. [2005] classify context into two main categories: direct and indirect context. A context is classified as a direct context when it is directly acquired or obtained from an internal or external context provider. Meanwhile, indirect context is derived by interpreting direct context through context reasoning. Direct context can be classified into sensed context if it is required from physical sensors; a direct context is classified as a defined context if it is defined by the user. Chalmers et al. [2004] identify the use of context or contextual information into six categories as follows: • contextual sensing, where the context is sensed, and information describes the current context • contextual augmentation, where the context is associated with data • contextual resource discovery • context triggered actions

2.3


25

• context mediation, where context is used to modify services • context aware presentation

2.3.2

Context in Information Science, Information Retrieval, Web Search

Figure 2.3: Information retrieval process [J¨ arvelin and Wilson, 2003]

One could argue that information science, information retrieval, and information searches on the internet have one purpose, namely, to utilize the information. At the most basic level, information science should include information and data base theories, library science, documentation, information management, information processing, geographical information, etc., and should concern gathering/collecting, retrieving, storing and manipulating recorded information. Most studies conducted in these fields have been used by other more specific and applicable research domains, such as information retrieval and internet searches. Information retrieval concerns information-seeking based on the users’ informational needs and puts the issue of how to gather the relevant information, while reducing nonrelevant information in an information query, as the central focus of the research in this field. A web search or information search on the internet using a search engine is a kind of internet version of the original information retrieval system, but characterized by broader and less-structured systems. It is

26


2.3

believed that context can play a role in creating better information manipulation and allowing the user to focus on a certain topic in order to avoid an information overflow. The topics division in this subsection might not satisfy everybody. For instance, there are many arguments for separating information seeking (belonging to library and information science) from information retrieval on the basis of a philosophical foundation or conversely including the knowledge aspects into these disciplines [J¨ arvelin and Wilson, 2003; Kuhlthau, 2005]. However, beside not having the nature of this literary study deeply involved in this debate, these terminologies are interrelated, as shown in Figure 2.3 of the information retrieval process. Context in Information Science According to Theodorakis et al. [2002], ”context” in information modeling is a higher level of a conceptual entity that describes a group of conceptual entities from a particular standpoint, while the conceptual entities described can also be a context by themselves. In this terminology, a context is recognized or distinguished by views or versions. For example, an information base is a context because the designer’s viewpoint is influenced by the particular needs. View schemas of an object-oriented database are also a context because they are according to the view of the creator. Workspace, where the objects are created and manipulated, is a context because the created objects are viewed according to the involved individual. Conversely, Motschig-Pitrik [2000] said that the information expression on conceptual entities that are relative to context have some criteria, including viewpoint, topic (information items must be relevant to one or more topics), focus (by ignoring the irrelevant issues in a situation), (restricted) access, varying degrees of evidence (to describe situation) and time slots for viewing an entity in the instance of time. Both the works of Motschig-Pitrik [2000] and Theodorakis et al. [2002] share the same goal, namely, to allow partial information on conceptual entities to be viewed from different viewpoints and different situations, thus allowing the decomposition of an information base into possible overlapping subsets, called ”context”, as seen in Figure 2.4. They also share the same central claim, that objects can have different names (more then one) or even zero names in order to handle synonymous, homonymous and anonymous objects. Using almost the same idea, Akaishi and Spyratos [2004]; Akaishi et al. [2005] defines context as the organization of manageable subsets of the contents of an information base. If objects are contents of an information base, described by descriptors, and referred to as a certain context by references, then formally, a context is a set of triple forms: (descriptors, objects, references). With this formalism, as long as the objects are identifiable, then the objects can belong to any context, which is almost the same concept as claimed by the two studies described above.

2.3


27

Figure 2.4: Context in the information base [Theodorakis et al., 2002]

The ”context” of this field of research is too domain-specific and differs somewhat from common understandings. However, it can be understood as a ”channel of communication” between system developers, users and systems so that their viewpoints are transparent and clear to others. By showing these viewpoints as partial information or subsets of an information base’s contents, it will allow the user to personalize the collection or speed up the search for desired objects. The description of context criteria and notions, such as ”relevant”, ”focus”, ”situation” and ”viewpoint” from the research mentioned above, are very useful in recognizing or sensing an existing ”context”. Some of these notions are discussed in the field of information science, but perhaps for the purpose of this literature study, it would be better to discuss it in the next subsection. Another important fact found in this ”context”, meaning reconstruction, is that context can be nested; in another words, a context can explain or be made from another context. Context in an Information Retrieval and Web Search Riloff and Hollaar [1992] divided information retrieval into two branches. The first is described as the query-based retrieval task where the user formulates a query by specifying the topic of interest and typing it into the retrieval system. In return, the system will produce a ranked list of potentially relevant documents where the top item is considered the most relevant. The second branch concerns a single query that will interest one or more people during a period of time–a kind of static informational need. The sub-branches include categorization, routing and filtering. Categorization automatically labels the information based on a set of predefined categories. Routing systems automatically route information, based on users’ profiles or interests, to the corresponding user. A filtering system only passes the appropriate information on to the user. For a web search, Dumais

28


2.3

et al. [2001] proposed another branch, which combines search results and category structures. Information retrieval communities remain focused on improving indexing and retrieval algorithms to provide ”objectively” relevant results given in an isolated query. However, more and more intentions have been put in ”context”, which is a kind of information communicated by the user to the system in order to allow the system to better respond to the user’s informational needs [Anick and Vaithyanathan, 1997; Budzik et al., 2001]. This information communication bandwidth between user and system could be increased by improving a user’s experience with the accessed information. One example of this is [Kiyoki et al., 1994] which define context as user’s impression and the content of the information. In order to extract the appropriate information according to the user’s impression and the information contents, a method called mathematical model of meaning (MMM) realizes the semantic associative search by giving context words. This way, users use their own words for representing impression and information contents for information retrieval, and do not need to know how the information of retrieval candidates are characterized in database. Kari and Savolainen [2007] define context as all those things which are not an inherent part of information phenomena, but which nevertheless bear some relation to these. One fundamental attribute of context in information seeking is referred to as time [Savolainen, 2006], and then the concept of ”situation” in information seeking emerged. Dourish et al. [1993] refers to context as a set of practices for retrieving and evaluating information. These experiences and practices could guide the information interpretation, because interpretation must be interpreted and decided by users when retrieved and could lead to the understanding of what is ”relevant”. Saracevic [1975] divides relevance into three categories, as depicted in Figure 2.5. Topical relevance is easy to implement, as judgment is decided by predefined categories. The other two are difficult to implement without strong support from artificial intelligence and psychology. Motivational relevance is difficult to implement because it should sense user motivation and relate this sense to the user information seeking process. Interpretational relevance is more difficult because it must consider all context properties, such as situations, focus, time instances, and the user.

2.3.3

Context in Design

The ”context” jargon has also been widely used in design domains. But, as the design itself is not a monolithic discipline, the context terminology may vary for each design sub-domain. In the next subsection, ”context” use will be discussed from an architectural/building and urban design, software design, industrial/consumer product design, and mechanical engineering design points of view. It is assumed that these four design sub-domains will represent the differing emphases and common senses of the design domain. Furthermore, with the exception of software

2.3


29

Figure 2.5: Relevance [Saracevic, 1975]

design, the other three technical areas are very much assisted by computer-aided design. There has been a paradigm shift in computer-aided design from being just a drawing tool to a design representation in which is involved some aspect of design, including the ’design context’. For this reason, this survey will include one of these design contexts, the ”shape context”. Context in Architecture/Building and Urban Design Looking for the meaning of ”context” in architecture and urban design sources can be considered difficult, not only because this word has been widely used among researchers and practitioners of this domain without a clear definition, but also because a lot of new context-related idioms have emerged. In this survey, the definition of context was not found in any architecture dictionary, such as [Hoshino, 1978] and [Burden, 2002]. The most probable reason behind this is that the term ”context” is assumed to be understood. In fact, most of these definitions are understood as the meaning of item 2 and item 3 of the common meaning of ”context”. For instance, ”historical context” can be interpreted by one who does not have an architectural background, simply as an architectural or urban connection with a historical background, or the architecture of a building that is set and interrelated with a historical background. The fact that ”context” is ill-defined and left to be interpreted by the reader creates a mess of context-related idioms that have been found in [de Jong and van der Voordt, 2002; Franklin, 1998; Stellingwerff, 2005; Talen, 2006; Unwin,

30


2.3

Figure 2.6: Fitting, responding, and mediating an architecture to its surroundings [Burden, 2002]

2003; Warren et al., 1998] and many others architecture reading sources, possibly leaving readers confused. The approach that has been used to reconstruct the meaning of context in this sub-design domain explores the meaning of ”contextual” and ”contextualism”, as these two terminologies are well- defined derivatives of context terminologies in [Burden, 2002]. The meaning of “contextual” is any doctrine emphasizing the importance of the context in establishing the meaning of terms, such as the setting into which a building is placed, its site, its natural environment or its neighborhood. Meanwhile, contextualism is defined as an approach to urban planning (1960-1970) that considers the city in its totality, and the view that the experiences of a city are greater than the sum of its parts; all architecture must fit into, respond to, and mediate its surroundings. From those two definitions, ”context” obviously plays a role in establishing the relationship between an object of architectural or urban design work (which has primary basic architecture elements, i.e., the ground, space, gravity, light and time [Unwin, 2003]) and its surroundings, while it also becomes a frame of reference to totally harmonize these relationships. Therefore, once a design features a location or place, it has a material context (spatial, ecological, or technical), a social context (historic or historical, cultural, or political), and a practical context (organizational, operational, or intersubjective ) [Franklin, 1998] and [de Jong and van Duin, 2002]. Since these contexts are changing, a designer should anticipate the future of a context. One way to do so is to write down information via physical or digital means and translate the design ideas and sketches into a socalled ”virtual context” that allows designers to ’foresee’ what may come in the future [Stellingwerff, 2005].

2.3


(a) Dome of Rock, Palestine

(b) Royal Mosque Kotobaru, Riau, Indonesia

(c) Al Azhar, Cairo, Egypt

(d) Blue Mosque, Istanbul, Turkey

31

Figure 2.7: Islamic architecture, (source: private documentations)

As quoted in [Stellingwerff, 2005], Ranulph Glanville said ’Design is (like) a conversation’. The designer and user or owner are communicating the architectural work or artifacts through the contexts. A designer puts all of the components and concepts of his or her architectural work into contexts [de Jong and Rosemann, 2002], while the user or owner interprets the architecture using the context [Mácˇel, 2002]. The designer can scale the intensity of the context in his architectural work, while the user can distinguish the architectural work on its contextual scale. Figure 2.7 shows that Islamic architecture shares common senses but differs in material and social context scales. Context in Software Design The term ”context” appeared in the software design domain not long ago. Perry [1994], mentioned ”context” as something that needed to be considered during the building of software, including architectural (size, product type, product approach, and level of process maturity), organizational and social contexts. This understanding is closer to item 3 of the common understanding of ”context”, and establishes that the software development process is set and interrelated with such conditions. In the same year, Holtzblatt introduced the idiom of ”contex-

32


(a) Flow Model

(b) Affinity diagram

(c) Consolidated flow model

(d) Storyboard

2.3

Figure 2.8: Contextual design methodology [Beyer and Holtzblatt, 1998]

tual technique” in software design in [Holtzblatt, 1994]. Along with Beyer, she then gradually developed a software design methodology of so-called ”contextual design” which is now widely used. ”Contextual design” deals with the issues of data gathering, driving design, and managing the team and organization context [Beyer and Holtzblatt, 1998]. It is an approach of designing products directly from a designer’s understanding of how the customer works [Beyer and Holtzblatt, 1999]. Although the term context is not well-defined, this methodology aims at the results of such software development and is set in the user’s context (not only requirements, but also culture, policy and vision). It seems that Holtzblatt and Beyer combined some known techniques in software design and other techniques from design science in their user-centered software design methodology, as can be seen in Figure 2.8. Affinity diagrams and storyboard are two well-known techniques that allow the user to express his or her experiences and wishes for a product, and analyze the results respectively. Later on, more specific context definitions in this domain are found by Evans [2004]. In the introduction of the concept, Evans described how important context is among developers, users and experts and how difficult it can be to represent and share. A context is defined as the setting in which a word or statement ap-

2.3


33

Figure 2.9: Navigation map [Evans, 2004]

pears that determines its meaning. Several contexts are bound to give a clear and shared understanding of what is consistent and what can independently develop for teams members. The relationship and their model between certain bound contexts involved in a project are represented in a context map depicted in Figure 2.9. In this case, Evans not only adopted the ”context” terminology from the common English understanding, but also directly from the Latin understanding, namely, the state of being joined, (e.g. logical connection) of contextus. Context in Human-Centered Software Design The International Organization for Standardization (ISO) provides guidance on human-centered design activities throughout the life cycle of computer-based interactive systems known as ISO13407-1999 [ISO13407, 1999]. One factor that is emphasized in this standard is usability and to what extent a product (software) can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use [ISO9241-11, 1998]. Related to this, ISO9241-11 defines the context of use, user, and task respectively. The ”context of use” is defined in ISO9241-11 as users, tasks, and equipment (hardware, software and materials) and the physical and social environments in which a product is used. Meanwhile, ISO/IEC FDIS 9126-1 (”Software product quality - Part 1: Quality model”) proposes a software quality model [Bevan, 2000] and defines usability as the capability of the software product to be understood, learned, used and attractive to the user under specified conditions. The use of use under specified conditions phrase makes it clear that quality is not an absolute property, but depends on the context of use [Bevan, 1999].

34


2.3

From those two related definitions, the meaning of ”context” in ”context of use” terminology refers to item 3 of the common understanding of ”context”, thus can be interpreted as an interrelated condition in which the quality of software can be measured. However, the definition in ISO9241-11 is considered an ambiguous definition, since it mixes up the actors (users and equipments), factors (tasks), and conditions (physical and social environments). Otherwise, this definition tends to explicitly emphasize that the quality of software can only be measured when actors, factors and conditions are placed together as a whole in one setting. Context in Consumer Product/Industrial Design The two approaches listed above have been used in order to reconstruct the meaning of ”context” in two branches of design. In this subsection, in order the understanding of ”context” in this field, a theory called degree of product-user relationships was developed and proposed. This theory was adopted from product levels description in [Hekkert and van Dijk, 2001] and theory of entity-relationship from [Chen, 1976, 2002] Degree of Product-user Relationship In the first degree, the product is understood as an artifact. It is merely the shape, materials, form, colors, aesthetics, list of functions and other quantifiable characteristics. In the second degree of the relationship, a product is related to a user by how the user experiences (uses, feels, sees, and judges) and understands it, or how the product affects the user (i.e. lifts the user’s prestige, gives the user comfort or pushes the user to think). Finally, at the third degree of the productuser relationship, the second degree user-product relationship is put, fitted and derived into a certain related list of facts, for example, as social, economical, political, environmental, cultural, etc., as depicted in Figure 2.10. By adopting the basic theory of entity-relationship, the user-product relationship degrees mentioned above can be described mathematically. Initially, the product itself (no relationship with the user or first degree of relationship) is symbolized in the following formula: f : P i → Ai

(2.1)

A product (P ) can be seen as an entity, which has several attributes (A), such as shape, form, material, aesthetics, and so on, and can therefore be detailed in the following formula: f : P i → A i 1 X A i 2 . . . X A in

(2.2)

where X denotes the Cartesian product. The users or human beings–which are not easily mathematically described– can be seen by all factors (B ) as making decisions, judgements, using senses,

2.3


35

Second degree First degree

Third degree Figure 2.10: Degree of product-user relationship

positions, etc., using cultural backgrounds, religious or faith backgrounds, tacit knowledge, political views, hobbies, understandings, experiences, etc. In a simple formula, the user is a function of these factors. f : Ui → Bi

(2.3)

f : Ui → Bi1 X Bi2 . . . X Bin

(2.4)

Furthermore, the product-user relationship as such (the second degree of relationship) or ri for a particular product with a particular user (U ) is a cartesian product of a product’s attributes and user’s human factors that describe a unique user-product relationship, such as ”LIKE”, ”DISLIKE”, and ”COMFORT”, as an element of a set of relationships R. ri ⊂ A X B

(2.5)

R = {r1 , r2 , . . . , rn }

(2.6)

Where

An R or set of all particular relationships between a specific user and a specific product will describe the user’s experiences with a particular product. It seems

36


2.3

R will allow the user to have the product (to use it again in the future) or not. However, there are factors (C ) outside of this relationship that can not only change or influence the user’s decisions or experiences with a particular product as mentioned above, but can also change or influence the product development and thus, the product’s attributes. These factors are time sensitive and can change from time-to-time. Therefore, these factors are a function of time C → C(t). If c1 , c1 , . . . cn , are the selected factors of time t that can potentially influence the product, the user and their relationships, then ct1 , ct2 , . . . ctn ⊂ C

(2.7)

At the end, the third degree product-user relationship (E ) can be described as E = {R, cti }

(2.8)

”Context” in a Successful Product Development

Figure 2.11: Over the wall production steps [Rembold et al., 1993]

Traditionally, product development is understood as consisting of several isolated activities. With this old-fashioned understanding, product development is seen as an ”over-the-wall” transformation, as illustrated in Figure 2.11. Therefore, by these means, design is often simply a plan for an object to be built later, leaving designers to believe that their role only produces objects [Mitchell, 2001]. In the early 1990’s, this view radically changed to include more integrated product development [Jambak, 2000]. However, –refer to a successful product development– although now more and more designers develop a product more integrally, but many designers’ visions are still disconnected from the users’ needs, which is in contrast to the fact that design is central to the human experience [Hekkert et al., 2000; Heskett, 2003; Hummels and Overbeeke, 2000; Mattelmäki, 2005; van Rompay et al., 2005]. This common mistake (which becomes a common design failure) will be taken as a starting point to reconstruct the meaning of ”context” in product development in the field of consumer product/industrial design. The

2.3


37

common understanding of ”context” and the proposed degree of user-product relationship theory will be used as a means for this purpose. Mitchell [2001] claims that designers often pay more attention to the style of design rather than responding to the actual context in which the design will be situated. Paradoxically, it is also definitely beyond a designer’s ability to anticipate and respond to all complexities of context. Hummels and Overbeeke [2000] and Mattelm¨ aki [2005] proposed shifting the design from creating products, improving usability and addressing ergonomic problems to experiences. Here, Hummels and Overbeeke [2000] proposed ”context for experience” as possibilities for a user to do things, gain knowledge and be affected in some way, depending on the intentions of the user and the situation in which the event occurred. To this point, ”context” can be easily understood as a set of conditions (item 3 of the common understanding of ”context”) about which a designer should be concerned during the design process or conditions with which he or she should be connected and aware. From the user-product relationship degree point of view, they are suggesting moving from the first degree (isolated product concern) to the second degree (where the user-product relationships are included). However, the presentation of some terms, such as ”experience”, ”use”, and ”possibilities” in the ”context for experience” needs further clarification. Before that, the term ”context”, as defined by industrial designers, will first be discussed. Hekkert and van Dijk [2001] and Sleeswijk Visser et al. [2005] define ”context” as all (implicit and explicit) factors selected and combined by designers that influence the experience of product use. This definition promotes the ”context for experience” from the second degree to the third degree of user-product relationship, bringing in interactions with other possible factors that could influence the original ”context for experience” when a product is used. Although this definition does not explicitly mention conditions, backgrounds, and settings, the term ”experience” implicitly contains those three meanings. Therefore, one could say that this definition is close to item 3 of the common understanding of ”context”. Theoretically, the above definition of ”context” is adequate enough to explain the user, product, and the (in a very broad sense) environment as it fits the generalization of the third degree of a user-product relationship. However, this definition makes the ”context” unlimited, as depicted in Figure 2.12. Since the definition of this context is unlimited, it is then beyond the ability of a designer to handle it and is known as the paradox mentioned by Mitchell [2001]. Moreover, this definition of context overlaps with the design notion itself if design is understood as compromising the whole factor of design in a balanced and comprehensive way. Glock [2001] distinguishes between the contexts and the collection of requirements and design factors by invoking these collections with certain contexts, such as context of use, context of production, and context of maintenance. In other words, context is an understanding-enriched collection of requirements and design factors. Unlike the traditional design solution, the selection of design factors is driven by a design problem, and context factors are not obviously related to the

38


2.3

Figure 2.12: Onionskin and layer models of context [Stappers and Sleeswijk Visser, 2006]

problem domain but rather the commitment of a strategy [Hekkert and van Dijk, 2001]. These two statements impose at least three implications in understanding the meaning of ”context”. First, there is the intention of designers to select certain design factors in order to invoke certain contexts. Second, there is an interconnected judgement process involving a factor selection. Third, one should predict or be sure (rationally or intuitively) of their predictable expectations when a selection has been made. Unlike human-centered software design domains that clearly state that context is not the property of a product but rather a tool to measure the usability of a product, from this literature study it can be conclude that industrial designers do not have that position (for example, see: [Hekkert and van Dijk, 2001; Hummels and Overbeeke, 2000]). However, measuring and simulating these contexts (e.g. context for experiences or context of use) as properties of a product is difficult. In fact, current design support software packages do not yet cover modeling and forecasting product use that make designers anticipate various use circumstances in order to develop a successful product [van der Vegte and Horváth, 2002]. Nevertheless, if designers use their intentions of invoking a certain context, then later judge their position and boundaries of the intended context as a setting of product development, this context will most likely play a big role as a factor in successful product development. Using an example, when a team of designers has chosen, based on their judgment, certain ”possible experiences” that the users might have for their imminent product, they can use this shared understanding in product development. This understanding acts as a reference when they choose certain requirements and when they define design problems, and acts as a boundary to certain solutions previously proposed. This understanding might also act as an ”interpreter” to avoid ambiguity in communication (i.e. during the brain-storming session).

2.3


(a) Process and involvement

(b) Data collection techniques

(c) Preparatory diagram

(d) Data analyze

39

Figure 2.13: Contextmapping methodology, (source: [Sleeswijk Visser et al., 2005] and private documentation)

Sleeswijk Visser et al. [2005] introduced a method to collect and represent possible users’ experiences called ”contextmapping”. This method was motivated by the fact that many designers face difficulties in designing (or re-designing) a product based on just numbers and graphs provided by R&D and marketing departments. Designers receive few clues of what users really expect of such products. Contextmapping comprises methodology in collecting information that influences a user’s experience with such products and a means of communicating this information among design team members (which can be educated designers, engineers, marketers, managers, etc.), contextually depicted in Figure 2.13. This concept brings an enormous potential contribution to the design sciences, especially to the user-centered design and design for experience. Nevertheless, this approach operates on the paradox mentioned by Dourish [2004], as they combine the positivist and phenomenological theories. During the observation or data collection, the positivist rationale is used in actions such as objectivity, individual uniqueness, and the reduction of complexity. However, during analysis, the phenomenological rationale, such as subjectivity and qualitatively, are used, especially when the results of the observation being analyzed are overwhelming. This way, the context might be recognized or indicated, but reducing the objectivity during the analysis, might lead one to question the end results.

40


2.3

Context in Mechanical and Other Engineering Design Gomes et al. [2001] classified design as routine and non-routine. A design is classified as routine when all of the needed knowledge for the mapping process is available to the designer; in other words, it is an instance of known designs. Meanwhile, a non-routine design is classified when some of the knowledge for the mapping process is missing. A subclass of this non-routine classification is an innovative design, whereas the lack of knowledge is located in the structural space. Otherwise, if the knowledge is missing in all spaces, it is called creative design. When innovative design gives new values to the design variables that are not commonly used in previous designs, the creative design extends the known design space by creating a new class of artifacts. Unlike the industrial design, described in the previous section, that can most likely be classified into innovative or creative designs, mechanical and other engineering designs heavily reuse the knowledge from previous design activities and can be classified as routine, or a partially innovative design. Over 60% of the mechanical-design activity in industries reuse existing mechanical designs [Bardasz and Zeid, 1992]. Mechanical and other engineering designs can also be seen as an activity of intensive manipulation of knowledge that forms from the establishment of complex associative relations, such as functional and topological, among different design object or entities for each considerated problem [Dentsoras, 2005]. Therefore, storing the design cases generated while solving design problems, and retrieving those applicable for new design problems context in a knowledge base (a machine-readable resource for the dissemination of information) or knowledge management system (integral knowledge base that includes resources, documents, people and skills), is of paramount importance [Bardasz and Zeid, 1992]. Furthermore, Bardasz and Zeid [1992] argued that in most cases, it is more effective to modify the design process and create a mechanical artifact, rather than modify the mechanical artifact itself. Many types and approaches of knowledge-based or knowledge management systems have been proposed to store or retrieve design knowledge, i.e. knowledge indexing [Ahmed, 2005]. However, Bardasz and Zeid [1992]; Clarkson and Hamilton [2000]; Dentsoras [2005] argued that storing and retrieving knowledge is not as easy as doing the same to information. Some problems that can be listed include the following: it is not always easy to form and structure knowledge, since it is usually expressed dynamically and is complicated; it is not easy to capture the design process; it is not easy to verbalize human knowledge; it is not easy to make a generalization and at the same time distinguish each case or event individually in order to make knowledge storing efficient as well applying retrieved knowledge. The understanding of the meaning of ”context” in this area will be approached from the mechanical/engineering knowledge utilization problems mentioned above. According to Clarkson and Hamilton [2000], although knowledge has been systemized in a well-structured way, those systems still cannot do what an expert can do, namely, understand which piece of knowledge may be applied and pre-

2.3


41

dict the likely consequences of applying particular knowledge. Above this stored knowledge, there is a knowledge about knowledge, referred to as meta-knowledge. This meta-knowledge, in a broader sense, plays a role in eliciting knowledge from other sources, including human experts, textbooks, work files, and previous cases. In their proposed system, retrieved knowledge describes the specific method to be used to perform a task, and coupled with the meta-knowledge, describes the ”context”. At this point, ”context” can be understood as a condition or setting where pieces of specific knowledge can be applied with a predictable consequence. Referring to the three common understandings of ”context” in the dictionary, it can be argued that this understanding is closer to the third meaning. However, as meta-knowledge actually plays a ”context” role, namely, connects pieces of knowledge, it can also be understood as ”context” from the latin root contextus, meaning ”action of weaving or joining together.”

(a) Contexts

(b) Contexts Relationship (- - - -: relationship)

Figure 2.14: Contexts and their relationships [Bardasz and Zeid, 1992]

Bardasz and Zeid [1992] proposed the use of a memory model to store and retrieve mechanical design knowledge, based on certain accessible contexts, which is analogically designed to solve problems. A context comprises events that correspond to design plans for mechanical artifacts, for example, product context, assemblies context, (mechanical) component context, and recurring engineering context, as depicted in Figure 2.14. From this fact, it can be argued that the meaning of ”context” is a division of knowledge, allowing a user of that knowledge to focus on a particular mechanical design plan while retrieving the best-case scenario for his design problem, and store cases of solved design problems efficiently. This understanding seems a bit far from the common understanding found in the dictionary. However, this understanding is close to some definitions of the latin root contextus, including the followings:

42


2.3

1. joining together 2. the state of being joined, (e.g. logical connection, coherent) 3. an ordered plan 4. constructed or structured 5. a whole made up of numerous parts and complexes There are two claims from Bardasz and Zeid [1992] work which are interesting to be reviewed. First, they claim that these contexts can determine a minimally relevant set of featured types to describe an event. Fundamentally, a context can be recognized when there is a relationship. However, since mechanical and engineering design problems are established from relationships among different design objects or entities, such as features, shapes and assemblies, these pieces of the relationship might hinder the focus of such design plans. Reducing or minimizing the relevance makes such contexts and focuses or goals of such plans easier to identify. Bardasz and Zeid [1992] also claimed that this memory model grows with the designer when more and more design problems are presented and solved. As this memory model can be seen at a higher level of context, it can be said that context also grows when knowledge grows. Shape Context in Product Modeling Shape is of primary concern in product modeling. For companies, the shape of their products reflects their brand and vision. One example of this is the automotive domain. Although they gradually keep changing their product shape –to show their customers that they are innovative and technologically high-ended– they still keep the new shape in context of their brand. Figure 2.15 shows the different types of shapes and series of products that are contextually linked to the producer’s brand and specific series. A radical change would set their brand at risk. In this case, a shape context can be understood as a limitation of shape changing to keep a tight relationship between a user or customer [Vergeest and Jambak, 2007]. Therefore, the meaning of ”context” in this context can be understood as a setting or background where a particular shape could exist; this is closer to the third common meaning listed in the dictionaries. However, for each change in shape or modification that refers to a certain product brand, it can be said that these tasks are in connection with a certain brand image. Hence, it can also be stated that this kind of context refers to the second common understanding in the dictionaries. Another understanding of ’context’ in this domain is a creation or control over the shape in product modeling. In order to effectively control the shape, one must have the proper shape context in place [Dumitrescu et al., 2005]. In this case, context functions as the cancellation (or hiding) of degrees–of–freedom parameters that are not relevant to the current modeling task [Vergeest, 2001].

2.3


43

Series Models ↓

Figure 2.15: Series of models of BMW products, www.bmw.com

Conversely, according to Vergeest [2001], context can be understood as the set of parameters that are relevant to the current modeling task. He also defined parameter as anything that can be changed or controlled by the designer in order to perform his or her task. This could include a numerical variable or a profile curve. Meanwhile, a task is defined as the creation or modification of a shape. This definition of ”context” also applies to the first definition above (for instance, in the case of BMW products) if the set of parameters are understood as something limiting shape modification and the term ”relevant” is according to the products’s brand-customer relationship. Vergeest [2001] and Dumitrescu [2007] characterized shape context as the following: • shape context relates to degrees of freedom, or parameters, or shape handles. In general, it is connected to those aspects that can (or need to) be changed • shape context is dynamic; it depends on time to determine whether a particular shape aspect is or is not relevant; therefore, it cannot be assumed that shape context is static • shape context is related to the current design intent. As far as shape is concerned, design intent can be circumscribed as the set of shapes that would satisfy the constraints It can be concluded that a shape context is a finite collection of shape variation procedures where each shape variation procedure is governed by a multicomponent parameter and can be formalized by its implications to the shape

44


2.4

3

domain 2R . A shape context C, C = {M1 , ..., Mn }, is a set of mappings, n ≥ 0, where each mapping takes the form 3

3

Mi : (2R × Pi ) −→ 2R

(2.9)

where Pi , called the parameter domain of Mi , can be any set. Mi transforms a shape S into a different (or possibly the same) shape S 0 , depending on the parameter value p ∈ Pi . For a given shape S ⊂ R3 , the set Ii (S) = {Mi (S, p) | p ∈ Pi } is called the image of S through Mi . Ii (S) is a family of shapes, possiblly including S itself. The union of all images through S Mi , denoted as R(S) is the range of the shape context relative to S: R(S) = i=1,n Ii (S). In order to describe a process that takes place during a finite time interval, time dependency must be taken into account and the shape context equation must be generalized into the following: C(t) =

[

Mi

(2.10)

i=K(t)

where t ∈ [t0 , t1 ] denotes the time interval considered and K(t) ⊆ {1, . . . , n} is a selection function from n indices. The set {M1 , . . . , Mn } contains all mappings that occur in context C(t) for at least one value t ∈ [t0 , t1 ]. To summarize, for any t in a time interval [t0 , t1 ], C(t) specifies zero or more ‘active’ mappings; each mapping specifies a shape, or a ‘space’ of shape variations, controlled by a (multi–component) parameter.

2.4

Summarizing Remarks on ”Context”

After collecting the definitions of context from three popular English dictionaries, this survey suggests three common understandings of ”context” in daily life. Prior to doing this, a study on Latin words, from where the English word ”context” was borrowed, have been studied. The three daily common understandings of ”context” have been suggested considering the Latin words and these understandings have been used to reconstruct the meaning of ”context” in various domains and applications. Not surprisingly, a consensus on ”context” has not been found. Even in some areas of research, the understanding of this word has been sharply polarized. Moreover, the definition of this word has been extended with an ad hoc definition for the purpose of a specific study, research, or application. What is a surprising finding in this study is that the word ”context” can be used very flexibly in each domain and can still be accepted as a true definition, even if it is very much the opposite from not only other domains or applications but also from the daily common understanding. Two examples that can be drawn here are from pervasive computing and mechanical engineering design domains. In one common understanding, ”context” explains why something happens or why an object does a certain activity; ”context” more or less defines a situation.

2.4

SUMMARIZING REMARKS ON ”CONTEXT”

45

However, in pervasive computing, ”context” is an object or activity explaining a situation where, based on this situation, computers can do a certain task. In this case (or in context of this research domain), an object or activity becomes contextual information as an input for a computation process. In daily life, people can find the application of this ”opposite” concept in an automatic door. The door will open or not according to the results of such computation processes where the input of this process is the identified object (a person) standing before the door. It is widely accepted that context is about relationships. The more relationships that are included, the more a context is clearly understood. However, in mechanical or engineering design, where a component is defined by feature relationships, an assembly is defined by component relationships, and a product is defined by assembly component relationships, a context can be defined by reducing these relationships until it is clear to the user on what certain design task or plan he or she can focus. Although this is opposite other domains in defining a context, without reducing relationships, a context in mechanical and engineering designs might not be easily recognized. In the same spirit, reducing the properties of ”context” has also been enacted in order to realize the implementation of context-aware application systems in pervasive computing. In general, the existence of context can be recognized or defined by recognizing or defining its properties: relevance, focus, situations and other heritage tasks. Relevance is defined by judgement and produces a list of relevant contents. To focus on a certain context, one must be aware of or sensitive about goals, motivation and current issues. An object can be said to leave a context when its focus is changing. A situation describes a context and thus defines a context. Inspired by the human capability to handle contexts, studies have different attitudes, strategies, and representations of context, for instance, the human capability to understand an incomplete, implicit, or ambiguous sentence. Humans are also able to understand a goal or meaning without being verbally instructed, and of course, are capable of interpreting words, situations, conditions or phenomena. From this literature study, it can be generalized that there are two attitudes and two strategies of researchers towards ”context”. Some researchers, in order to understand and utilize context, tend to describe the properties of context. Understanding what the mechanisms are and how are they run processes is a kind of challenge. For instance, what is relevance? How have judgments been made to satisfy relevance? How does one sense a focus when a user or system can come or leave a focus? How does one describe a situation in such a context, or viz versa? What is the boundary of context? And so on. It can be speculated that these attitudes are very much influenced by the research in the field of artificial intelligence (that, in fact, is one of the first research domains concerned about context) and end up in a strategy of creating an intelligent context, which tends to replace or artifice human capabilities to make a judgement, or sense a focus, situation, or interpretation. Huge challenges must still be overcome in order to formulate and describe a context in a complete

46


2.5

portrayal. Other groups of researchers recognize the phenomena of existing context and tend to facilitate utilizing the context. This way, they face less difficulties in describing a context. This attitude is deployed in the strategy assisting users (that could be a human being) to develop (or recognize) and utilize context, including acting as a human-computer (or system) channel of communication. The next section will describe context and the strategy in utilizing context in this thesis.

2.5

Context in this Thesis: Problem Statement Revisited

As described in chapter 1, it is well-known that designers face many problems in conceptual design due to characteristics of ill-defined design problems and vague design concepts. This problem also affects the formulation of designer’s informational needs into information queries because the informational need is ill-defined as well. Analogically, how designers use internet search engines during this design phase is like a man in a dark tunnel searching for a light. Although such algorithm improvements and better predefine categories are good, it would be in the best interest of designers to help designers who have already found the light, namely those who know what to find. What is important in helping designers during this search in the dark tunnel include the following: • Assistance in recording and connecting every step he or she made in order to find the light. Designers need assistance connecting each single isolated search process using an existing search engine. • Assistance in tracing every step he or she made to revise or reevaluate his or her previous judgements. Designers need assistance in recording every query he or she made in order to revisit judgments. • Assistance in marking each connected step of his or her endeavor to find the light. Designers need to group these queries so that he or she can recognize his or her focus and any attempt in finding a design solution, concept, or idea. • Assistance in recording the experience of walking in the dark tunnel. Designers need to personalize their information search processes and systematically construct them according to their design projects. From this literature study, three definitions of context that plausibly to support designers in situation described in four items above were made. Following each of these context definitions, are the reformulated problem definitions. Furthermore, based on these three definitions, ”context knowledge” is defined.

2.5

CONTEXT IN THIS THESIS: PROBLEM STATEMENT REVISITED

47

Context definition 1. • Context includes interconnected search term(s) and relevant results in information search processes using internet search engines. • Context is a record of (interconnected) search term(s) and relevant results according to users’ design projects. Problem definition 1. • How to personalize internet information search processes? • How to compartmentalize these processes according to design projects? • How to connect these isolated queries? • How to record (bookmark) both search term(s) and relevant results Context definition 2. Facts: Design knowledge and information are not limited to only the internet. This knowledge or information may come from experts, books, patents, brain-storming notes, design tasks, design sketches, etc. Designers use multi-resource knowledge and information for specific design tasks and design problem-solving cases. Therefore, although designers have abundant knowledge and information resources, it is necessary to bring these applications together to solve a specific design problem. In daily life, a designer will search for information on the internet, print it, and put it in a design project folder, along with other notes, photocopies, drawings, sketches, etc. Therefore, context is interconnected search terms, relevant results, and other user’s (digital) documents in a specific focus. Problem definition 2. How does one include user’s (digital) documents into a search process?

48


2.6

Context definition 3. Facts: Information search processes are inclusive in a design process. Therefore, the capability and expertise of designers influence significant factors of good informational needs. Keeping or recording information search processes will open opportunities to keep or store designers’ knowledge that traditionally was difficult to do because of the difficulties verbalizing designers’ knowledge from their mind. In daily life, especially in collaboration design projects, designers need to share their understanding with others. How can they can exchange their information search results at the same level of understanding? Therefore, context is interconnected with search terms, relevant results, and other user’s (digital) documents that explicitly and visible to other designers and transferable. Problem definition 3. How to make a defined context transferable? Context Knowledge definition. From the three context definitions above, the then context-knowledge can be defined as: • Knowledge of knowing interrelated (information) search processes • Knowledge about interrelated knowledge and information sources and how to retrieve them for a specific purpose.

2.6

Concluding Remarks

This literature study reported the reconstruction the meaning of ”context”. Different approaches have been used to introduce the concept of ”context” in each domain. For the industrial design domain, where this research project attempts to support the designers, the concept of ”context” was introduced using the degree of product-user relationship theory. At the end of this meaning reconstruction, summarizing remarks have been made and the problem statement, defined in the chapter 1, has been revisited, where the understanding of ”context” derived from this literature study is central to reformulating the problem definition. From this literature study, approaches to recognize or to indicate the ”context” were found. One of these approaches, that is indicating the existence of context by the change of ”focus” was used during the empirical study of context knowledge in design practice and reported in next chapter. The proposed context definitions for this thesis, are detailed and implemented in chapter 4.

Chapter 3

The Study of Context Knowledge in Design Practice1

”Your theory is crazy, but it’s not crazy enough to be true.” Niels Bohr

3.1

Introduction

In chapter 2, the definition and the concept of ”context” in many research fields has been studied. In order to ensure that the upcoming system can be helpful and useful for the designer, a study on the data of an experiment that reflects the practice of product engineering design has been completed. The assumption is that if the ”context” in design practice can be understood, there is a greater chance of having a helpful and useful support system closer to the nature of the design process. For this purpose, data from the so-called D1 experiment of the Desys project [van Breemen, 1996] were used in this study. This chapter reports the results of that study. Desys was a research project conducted at the Faculty of Industrial Design Engineering at the Delft University of Technology. It investigated the role of information in the early phase of the product development process [van Breemen, 1996]. The Desys project aimed at developing tools that supported conceptual design activities. In order to have a computerized conceptual supporting tool, the requirements of such a computer system were gathered through an empirical observation of the design process. 1 adopted

from Jambak and Vergeest [2004]

49

THE STUDY OF CONTEXT KNOWLEDGE IN DESIGN PRACTICE1

50

3.2

In section 3.2, the Desys project D1 experiment, will be described. Following this, the relevance of the context research study is analyzed in Section 3.3. Section 3.4 reports on how the contexts are indicated and the way they are being treated. Section 3.5 reports the role of context in communication during the informational transaction. After learned these phenomena, the design process and context knowledge has been formalize in section 3.6. The conclusions are drawn in section 3.7.

3.2

Introduction to the Desys Project

As part of the Desys project, the D1 experiment aimed at studying information handling provided by means of design support and then identifying any opportunities to do so. This experiment, as depicted in figure 3.1 [Knoop, 1997], was based on a conceptual design task given to a designer. The designer S performing the design process P was located in an observation room with audio and video equipment facilities, where he was assisted by an experimenter E1 who was seated at the same table. E1 played the role of an expert in providing pertinent information. Meanwhile, E2 , observed both S and E1 , in a separate room and controlling the audio and video equipment. Both experimenters, E1 and E2 , observed the requests, answers and results, and also noted the activities of S. However, since E1 had to answer questions from S, his observational activities were considered as incomplete. And therefore in this case, E2 had a more complete observation.

Figure 3.1: Structure of D1 Experiment

The task that was chosen for the experiment reflected an industrial problem,

3.3

THE RELEVANCE OF THE CONTEXT STUDY AND D1 EXPERIMENT

51

addressing a mixture of generating a concept together with the technical specifications in both the mechanical and electrical domain. For this experiment, the subject (S ) had to design a bicycle lighting system that would power the light bulb even when the bicycle speed was low or the bicycle was standing still for a short period of time. Subject had to generate a brief description of the concept how it fulfilled the requirements. E1 and E2 made real time notes on an observation list as shown in figure 3.1. This list contains the start and end of the task, observed activities, requests, answers, and results that were represented by their time, description and indication. At the end of each session, E1 and E2 made a first version of their transcript by combining their notes and, if necessary, observing the video and audio recordings. This transcript file, called f-file (see: 1), was structured as follows: • File identification • Header • Start time of the task • Transcription of the events • End time of the task In this research, two sample f-files from session 1 and 2 of the D1 experiment have been studied (see: appendix). f-file 1 Session 1 13:08:25 a[]0 activity (start_of_assignment;;) # the activities are renamed to studying the assignment 13:09:40 a[1]1 activity ("studying the assignment"; marking the assignment on page 1) 13:12:35 a[1]1 activity ("studying the assignment"; marking the assignment on page 2) # the activity is renamed to making notes on the assignment 13:13:00 a[1]1 activity ("making notes on the assignment"; making notes about the requirements; 42) # sample 1 # the request following this activity indicates an information # collection, the activity is therefore placed before the ri[]1 and # its time is changed to that of ri[]1, the description is shortened 13:13:30 a[1]3 activity ("collecting technical information"; collecting information on the technical environmen 13:13:30 ri[]1 request (what are the different types of rear-wheels on which the generator has to fit, how are integrated in their environment, how does the internal of the hub look like such as chain gear-case, overcoat guard, pedal brake, calliper brake and drum brake) # end sample 1 # this activity which occurs more than once is named sketching rear # axle area 13:15:00 a[1]4 activity ("sketching rear axle area"; sketching; 42 centre) # this answer comes when s is in an activity that is another than the # one in which the request was raised 13:15:30 ii[1]1 answer information sheet ’hub’; 1)

3.3

The Relevance of the Context Study and D1 Experiment

To draw the relevance between this research and the Desys experiment, a situation design studio is illustrated. Suppose there is a designer doing his design task,

52


3.3

along with an expert who can give any answer needed, sitting side by side. In the middle of the design process, the designer asks the expert a question: ”What is the radius?” It would be no surprise if the expert could understand the question and answer it correctly. First of all, it is common in human communication that people able to understand a question without having it complete. The second reason is that the expert has been following the designer’s work since the beginning of the project. Therefore, the expert knew to what radius the designer was referring. If the designer had asked other experts that had the same level of expertise but had not followed the design process, it is likely that the expert would have asked for additional information on the question; for instance, ”To what radius are you referring? Is it the radius of the wheels or the chain-wheels?” As already mentioned in chapter 1, for a human to human designer-information provider relationship, this kind of example where both parties gradually develop a context does exist. But it is still a challenge to make, computers doing the same thing. It is not the intention of this study to get involved in a controversial issue of human versus computer or of who could or should handle knowledge utilization during a design process. However, computers are already involved in aiding designers in other aspects of design. Therefore, it is possible for a computer to play a role in supporting the designer in utilizing knowledge during a design process. However, there are still many obstacles and difficulties in developing a suitable knowledge utilization support system using a computer. Some reasons for this include the lack of computer capabilities over human capabilities. Humans can easily integrate different kinds and pieces of knowledge from different domains. In contrast, computers need a clear information classification and certain rules in order to integrate it. For example, a designer can unconsciously use pure geometric knowledge and consider aesthetics and other knowledge while making a design model. Humans can also easily process incomplete informational input to produce an expected result, but it is difficult for a computer to produce the correct results without having complete and exact input. Referring back to the design sub-process, it is common for the designer to jump from one sub-process to another or deal with more than one process at a time. A designer can gain a better understanding of a problem while he or she is trying to solve a design issue. Designers may have to choose two or more alternatives to solve a design problem. Quite the opposite, it is certainly very difficult to deploy all of these capabilities with only a computer. From the above illustration,it can be understood that a context has been transferred or shared among the designer and the knowledge provider. The knowledge provider uses context in order to retrieve the necessary information for the user. The user will then interpret or transform the information into his or her own knowledge. The Data of f-file and video in the D1 experiment recorded the question-answer session in an earlier phase of the design process between a designer and an information provider. Furthermore, the experiment also recorded how the designer jumped from one problem or topic to another. It almost perfectly represented how an actual system support can handle such situations during

3.4

INDICATING THE EXISTENCE OF CONTEXT IN THE DESIGN PROCESS

53

the design process. It is now a challenge to understand and formulate it. A system that aims at helping the designer in the same situation will be significantly beneficial from this formulation.

3.4

Indicating the Existence of Context in the Design Process

Only if there is enough initial knowledge one can manipulate data [Ullman, 2001]. This condition also applies to the situation where one must gather additional knowledge or retrieve information. The initial knowledge should be sufficient to have queries to the knowledge or information from the provider in order to receive relevant information. During the iteration process of searching for/receiving information, the context should become more and more clear, as illustrated in figure 3.2.

t = t0

Initial Knowledge context

t = ti

Accumulated Knowledge context

t = t(i

+ x)

Accumulated Knowledge context

Figure 3.2: Knowledge growth and information exchange

54

3.4.1


3.4

Indicating the Existence of Context by the Emergence of New Issues

The emergence of new issues can indicate the growth of context, assuming that the designer’s knowledge is growing when he/she receives the incoming knowledge or information from the information provider. As shown in figure 3.2, if the context is the subset of the accumulated knowledge, the capability to identify the necessary knowledge also increases. From this study, it can be expected to find new design issues during the design process. Method The data from the transcript file (f-file) was read sequentially and divided into blocks. Each block was defined as lines from the f-file transcript within a ”sample” and lines from before the project started. Within this block, every issue found was extracted. An issue could be noticed by keywords or terms of information requested by the designer, dialogues between the designer and expert, and documents studied by the designer. At the end of each block, the most dominating issue tackled by the designer was what is referred to as as a designer’s ”focus” in that particular stage. However, when a designer tackles all issues equally, then the focus will not be seen. When a new issue appeared, it was tagged as ”new”. In addition, when new issues were inherited from the previous connected terminology, a tag ”sub” was included at its next appearance. Furthermore, when two issues had a connection to each other, a ”connect” tag was given. In order to indicate the context, an example of the f-file analysis method can be seen below. f-file Analysis and Discussion After studying the design requirements, the designer requested some information (tagged as six initial issues at time 13:13:30), see: f-file session 1. This can be regarded as a starting point of the context-knowledge growth. Every new issue arising from the starting point until the end of the design assignment was noticed within five minute time intervals, as shown in figure 3.3. New issues were frequently noticed during the first 15 minute period, where the highest number (14) occurred in the period between minutes 10 and 20. There were no new issues between minutes 35 and 45, minutes 65 and 100, or after minute 125 until the end of the design assignment. Figure 3.4 shows the accumulation of new issues from the beginning until the end of the design process.

3.4


55

Figure 3.3: New design issues

Figure 3.4: Total new design issues

This study confirms that the designer has the initial contextual knowledge needed as he/she can make some informational requests. This analysis shows that an issue might influence new knowledge/information discoveries. In the periods where there were no new issues, it was observed that the designer was busy with elaboration or was dealing with previous issues. Indeed, it can be concluded that at the end of the design assignment when the idea/concept was practically concrete, no new issues arose.

56


f-files 13:08:25 start of assignment # the activities are renamed to studying the assignment 13:09:40 a[1]1 activity (”studying the assignment”; marking the assignment on page 1) 13:12:35 a[1]1 activity (”studying the assignment”; marking the assignment on page 2) # the activity is renamed to making notes on the assignment 13:13:00 a[1]1 activity (”making notes on the assignment”; making notes about the requirements; 42) # sample 1 # the request following this activity indicates an information # collection, the activity is therefore placed before the ri[1] and # its time is changed to that of ri[1], the description is shortened 13:13:30 a[3]1 activity (”collecting technical information”; collecting information on the technical environment) 13:13:30 ri[1] request (what are the different types of rear-wheels on which the generator has to fit, how are they integrated in their environment, how does the internal of the hub look like such as chain gear-case, overcoat guard, pedal brake, calliper brake and drum brake) # end sample 1 # this activity which occurs more than once is named sketching rear # axle area 13:15:00 a[4]1 activity (”sketching rear axle area”; sketching;42 centre) # this answer comes when s is in an activity that is another than the # one in which the request was raised 13:15:30 ii[1]1 answer (information sheet ’hub’; 1) # s goes back to a[3] this activity swap is inserted 13:15:45 a[3]2 activity (”collecting technical information”)

Analysis 1st block Issues: a. Rear-wheels b. Generator c. Environment d. Hub e. Chain,new: gear-case f. Overcoat guard g. Pedal brake h. Caliper brake i. Drum brake Focus: Environment

2nd block Issues: a. Hub, New: Five speed gear, cup, turning and non-turning part, construct outside, driving cup b. Drum brake c. Rear-wheels, New: diameter d. New: Axle e. New: Inertia Focus: Hub

3.4

3.4


13:15:45 ri[2] request (does the bicycle has a drum brake) 13:15:45 ii[2] answer (a drum brake and a five speed gear hub) 13:15:45 a[1]2 activity (”making notes on the assignment”;writing down these data; 42) 13:16:00 a[3]3 activity (”collecting technical information”;reading sheet ’hub’; 1) 13:16:25 a[1]3 activity (”studying the assignment”; reading theassignment) 13:16:35 a[1]3 activity (”studying the assignment”; reading theassignment) # this answer comes when s is in an activity that is another than the # one in which the request was raised 13:16:40 ii[1]2 answer (the rear wheel has a diameter of 26 or 28inch; 42) # the request following this activity indicates s is investing the # drive aspects a[7]1 is placed in front of ri[3] and time is changed # accordingly also the name into investigate how to drive the # generator 13:17:00 a[7]1 activity (”investigate how to drive the generator”;looking for a turning and non turning part nearthe hub; 42) 13:17:00 ri[3] request (is it allowed to change the cup around thehub) 13:17:00 ii[3] answer (no it is not allowed to change the cup) # sample 2 13:18:30 a[7]1 activity (”investigate how to drive the generator”;considering an alternative outside axle) 13:18:45 io[1] result (the use of inertia is not a reasonablealternative) 13:19:30 ri[4] request (is it allowed to construct outside the hub,on the axle or on the driving cup) 13:19:30 ii[4] answer (yes it is allowed to construct outside thehub) # end sample 2

57


58

13:20:00 io[2] result (i continue with this solution that is,outside the hub) 13:20:25 a[4]2 activity (”sketching rear axle area”; sketchingrear axle section; 42 bottom) 13:22:00 a[4]2 activity (”sketching rear axle area”; markingeventual position in red; 42) # a[10]1 belongs to the start of an investigation of loaction, the # name is changed 13:23:20 a[10]1 activity (”investigate the locations”; get new page43) # sample 3 # both activities following are the same 13:23:30 a[10]1 activity (”investigate the locations”) 13:23:30 a[10]1 activity (”investigate the locations”; write downrequirements for location: must not hinder and mustnot get damaged; 43 top) 13:24:00 ri[5] request (construction of current availablegenerators: types, power, torque, number ofrevolutions) # end sample 3

3.4.2

3.4

3nd block Issues: a. Hub b. Axle c. New: position d. New: location e. Location, New: hinder, damage f. Generator, New: Construction, types, power, torque, revolution

Indicating The Existence of The Context By Answering-Time

The setting of the D1 experiment, as described in figure 3.1, gives opportunities to the expert (E1 ) to develop his/her context during the design process, since the expert is within the scope of the process. Our assumption, since the expert was the only knowledge/information provider that could develop the context while others (books, physical models, pictures, sheets,etc.) could not, was that the expert must more quickly provide knowledge/information to the designer. Method This method using the difference between the time the designer received an answer and the time when he or she asked (or looked) for information. From each type of answering delay time and answering delivery the indication of the existing of context can be found. Results and Discussion Figure 3.5 shows the results of the study. Books imply the longest delay time while oral replies needed the shortest amount of time. To allow the results to be more clearly understood, the frequency distribution of the above results is shown

3.5


59

in figure 3.6 . Most oral communications gave answers in less than one minute; nineteen examples were directly supplied by the knowledge/information provider.

Figure 3.5: Answering time per channel of communication

Figure 3.6: Frequency of distribution of answering-time

This study confirms the important role of context while gathering knowledge or retrieving information between the designer and the information provider.

60


3.5

The Role of Context in Communication

3.5

In addition to the results of the study as described in subsection 3.4.2, a study of the role of context between the communication of the designer and knowledge/information provider was conducted. The hypothesis that will be tested is that ”every question asked an information provider can be and needs to be accompanied by context(s). A richer context gives the information provider a better chance of providing a correct and relevant answer at the right time.” The questions made by the designer (subject) in session 1 and 2 of the D1 experiment have been analyzed. This analysis aimed at figuring out the relationship between the questions asked by the subject and the context surrounding the question-answer process. Therefore, this analysis focused on the following points: 1. Concreteness of the question 2. Relevance of the question At the beginning of this analysis, the expectations formulated were as follows: 1. There will be some cases found where the questions are not concrete or implicit, or may be incomplete questions that the information provider can still understand. 2. There will be some cases where the question is related to previous questions. 3. There will be some cases where contextual transfers/dialogues occur within the question-answer process. Terminologies, Definitions, and Analysis Some terminologies were introduced for the analysis; they are described as follows: 1. The subject is a designer who is asking questions to the expert (information provider) 2. The observer is the one who observes the transcript file (f-file) 3. Time is the time stamped in the protocol when a question is asked 4. Concreteness of questions determines whether the question is explicit; it is explicit if the observer can understand it without referring to previous questions and answers. ”Y” means the question is explicit and ”N” means the question is implicit. 5. The channel of communication refers to the question or context transacted between the subject and the information provider. ”S” means the question and/or context was literally transacted. ”T” means the question or context

3.5

THE ROLE OF CONTEXT IN COMMUNICATION

61

was transacted via a written text. The question may have been transacted literally but the context was transacted via a text. In the D1 protocol, session 2, time 14:29:00, for example, the subject asked the question ”Does this formula give the effective voltage?” In this case, it is assumed that the subject was showing a written formula to the information provider. ”P” means the question or context was transacted via a picture/drawing sheet. ”O” means the question or context was transacted via a physical object. 6. Was the question related to a previous question? ”Y” indicates the observer assumed that the question had a relationship with the question-answer process or request activities. 7. Did the question relate to an earlier question? ”Y” was marked if the question was related to an earlier question or request activity. 8. Was confirmation needed? ”Y” was marked if the information provider asked the subject to confirm his/her understanding of the question or to redirect his/her context. 9. Were context word(s) needed? ”Y” was marked if the question contained one or more words that could point to previous question-answer processes or request activities. The procedure of this analysis is as follows: 1. The observer should read the f-file sequentially 2. The observer has to find the question to the activity ”request” of the f-file 3. The observer must notice the time stamp when the request happens 4. Requests not in a question form should be excluded from the table but should be recorded because they may be involved in building the context 5. The observer should check the question to determine whether he/she can understand the question without further specification. 6. The observer should observe how the question is transacted, whether literally or in need of an explanation or additional information using texts, pictures or physical objects. 7. The observer should determine whether the question has a relationship to previous request and answer activities from the f-file 8. The observer should determine whether the question has a relationship with earlier questions and not all request and answer activities 9. The observer should determine whether the answer activity related to the request activity and whether it was in a question form or not

62


3.5

10. The observer should determine whether the question contained one or more words that related to other request or answer activities of the f-file Results and Discussion From the results below, most of the questions can be considered explicit. In session one, none of the eleven questions were implicit. Only two out of twentytwo were implicit in session two. All implicit questions were related to the previous questions. On the contrary, not all of the explicit questions had a relationship with the previous questions. These results show us that an implicit question occurs if the question has a strong relationship with previous questions. For instance, in session two, at 14:35:05, the question ”Are they equally expensive?” is not explicit to the observer. However, after the observer sees the previous request at 14:33:40 concerning the current existing batteries, it is clear to the observer that the question should be as follows: ”Are these existing batteries equally expensive?” Here, it can be seen that the information provider already had a context; therefore, it is not a problem to understand the implicit or incomplete question. Both sessions one and two show that most of the questions have a relationship with the previous question or request activities. Indeed, most of the questions have a relationship with earlier questions or request activities. These results show that the context has been developed during the question-answer process and even during the design process as a whole. Few questions have no relationship between the entire request-answer process or the earlier question or request. These results give the indication that a new context has been built. On the other hand, questions at 14:51:30, 14:51:30 and 15:00:00 of session two, have a relationship with the previous request-answer process but have nothing to do with the earlier question. This could be an indication of a subject shift back to the specific focus of the design problem that he or she previously left. The results also show that most questions contain word(s) that can point to the previous request-answer process or request activities. All of the questions that contain a context word(s) have a relationship with the previous request-answer process or request activity. In most cases, the context transfer uses speech as a channel of communication. The questions are explained literally during the dialogue between the subject and the information provider. However, it happens twice that the contexts are transferred via (or refer to) a physical object. At one time they are transferred using a text. Other evidence found in these results indicated that in most cases, the initiative of context building comes from the subject who asks the question, but the context could also be requested by the information provider in order to deliver an answer. In this case, the information provider will reply to a question from the subject with another question. In other words, confirmation is needed by the information provider in order to have the correct context. The results of this analysis are consistent with some of the expectations. Some

3.5

Y Y Y Y Y

S S O S S S S S S S S O S S S S S S S S S S P T S S S S S S S

Y

Y

Y

Y Y Y Y Y

Y Y Y Y Y

Y Y Y Y Y Y Y Y

Y Y Y

Y Y Y

Y Y Y

Y Y Y Y Y

Y Y Y Y

Y Y Y Y Y Y Y Y Y Y

Y Y Y Y Y

Context need words

Y

Confirmation need

Channel of communication

Concretness of questions Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

Question related to very earlier questions/actions

13:15:45 13:19:30 13:26:00 13:56:30 14:00:30 14:02:00 14:06:00 14:07:30 14:48:30 14:58:30 15:40:00 13:35:00 13:36:00 13:42:20 13:47:40 13:51:00 13:51:00 13:55:00 13:58:50 14:04:05 14:07:50 14:12:00 14:23:40 14:26:30 14:29:00 14:35:05 14:39:40 14:43:50 14:51:30 14:51:40 15:00:00 15:00:00

Question related to previous questions/actions

Session 2

Session 1

Time Elapsed (t)

THE ROLE OF CONTEXT IN COMMUNICATION

Y

Y Y

Y Y

Y Y Y Y

Y Y Y

63

64


3.6

cases were found where the information provider managed to understand the implicit question. This study also found that most of the questions have a relationship to previous question-answer processes or request activities that give an indication that a specific/local context has been developed. Here also can be found some possible channels of communication that transferred the context. However, it is not possible to use this analysis to measure the quality of the answers due to the absence of feedback from the subject regarding incoming data/information from the information provider. Another reason is that these question-answer processes occurred as a part of the design process where the results of the design process itself are also progressing.

3.6

Proposed Formalism

Guided by the results of this study, a formalism of the design process and context knowledge have been proposed. This formalism is used as the foundation of the development of a knowledge-gathering and information-retrieving support tool to be used during product design.

3.6.1

Design Process Formalism

The design process will be denoted as D. This process begins at tstart and ends at tend . In this process, the designer(s), denoted as S, is creating models M(t) that can be changed from time to time until the end of the design process at tend . The knowledge providers R, such as databases, books, experts, etc., provide a set of items of information J = {dj1 , dj2 , dj3 ...djm } at T J = {tj1 , tj2 , tj3 ...tjm }, where di is an information item provided by R at time tji . If all received information items dj1 , dj2 , dj3 ...djm ∈ Jand I include the set of all information, then: J ⊂ I. In order to received the necessary information, S must produce and pass Q = {q1 , q2 , q3 . . . q m } at T Q = {tq1 , tq2 , tq3 ...tqm } to R, where qi is a query item passed by S to R at time tqi . Therefore, the design process D can be described as follows: D = (S, R, M(t) , tstart , tend , J, Q, T J , T Q ) It can be assumed that before t = t start , the designer S has accumulated pieces i of knowledge k1i , k2i , k3i ...km in a set of initial knowledge Ki . Tacit knowledge, such as designer experience and/or any knowledge that he or she previously had t = t start are included in this initial knowledge. All of these pieces of knowledge are i denoted as k1i , k2i , k3i ...km and are members ofKi . It can also be assumed that all of the received information items of J can be interpreted or transformed into knowledge by the designer in process P . Therefore, the process P , can be seen as mapping I from K; thus: P : I → K, i.e., if P (djm ) = Km . If all incoming information in J can be transformed into knowledge and it can be assumed that nothing was lost during the process and that it can all be

3.7

CONCLUDING REMARKS

65

stored, then this knowledge is accumulated in the designer’s set of accumulated a knowledge Ka (t) as pieces of knowledge that are denoted as k1a , k2a , k3a ...km . The accumulated knowledge (Ka ) at time t can then be expressed as follows: Ka (t) = Ki ∪ P djm , tjm ≤ t m=1,n

The accumulated knowledge Ka (t) is a union of the initial knowledge and the knowledge from the interpretation or transformation process of all received information items. At the beginning of the design process, Ka (tstart ) = Ki because there is yet no interpretation or transformation from information to knowledge. At the end of the process, where t = tend , the knowledge accumulated at the completion of D can be seen as: P (J) = Ka (tend ) As a note, if K is a set of all knowledge, then Ki ⊂ Kas well as Ka (t) ⊂ K.

3.6.2

Context Knowledge Formalism

Context knowledge is a subset of all knowledge accumulated by the user and has been or will be transferred or shared to the knowledge provider (which is not necessarily a human knowledge provider). Therefore, at time t, the context knowledge Kc (t) can be expressed as Kc (t) ⊂ Ka (t). However, in order to share the context knowledge, the user S must express it as understandable information to the knowledge provider R. Let E represent a process to express the knowledge into a set of context information C. If dc1 , dc2 , dc3 ...dcm are pieces of information deducted from Kc in a process of E(Kc ), then dc1 , dc2 , dc3 ...dcm ∈ C. Therefore, it is also true that dc1 , dc2 , dc3 ...dcm ∈ I. It is true that the designer can express his/her initial knowledge Ki into a set of information V that contains informational pieces dv1 , dv2 , dv3 ...dvm in a E(Ki ) process. Therefore, for a query qm that is passed by the designer S at time tjm < tqm ≤ t, a set of additional context information Cm can be delivered along with this query, where Cm ⊂ {V ∪ J}and dci ∈ Cm : dci related to qm .

3.7

Concluding Remarks

The results of this study have provided indications and evidence of the existence of context during the design process. The evidence shows the important roles of two types of context. The first type of context, which is increasing along with the growth of accumulated knowledge, is very important in the knowledge and information transaction. The second type of context is very helpful for communication between the designer and the knowledge/information provider. Although both of them are important, for the purpose od this research work, this study focuses on

66


3.7

the first type of context. For this reason, a formalism of the design process and context knowledge has been provided. The study of the Desys project is very important because it can reflect the conditions of finding information during the design process through an ”intelligent” agent acting as an expert, in which the intelligent agent knows the context hidden in questions. It is extremely difficult to understand and make a generalization of how the designer and expert in this study can develop and share a common understanding in their communication. Nevertheless, this kind of context shows that the informational resource (the expert) can give a correct answer in a relatively short period of time for an incomplete question asked by the designer. The study also describes that each designer has his/her own information searching path that depends on their tacit knowledge. This study suggest that although the subjects had the same level of education, for each design problem and knowledge source, every designer has his/her own way of finding a design solution. They have their own questions to be answered. If the knowledge source is passive and only reacts to the designer’s questions, then it can be said that every answer is based on the designer’s question formulation. In other words, every question is an actual reflection or representation of a designer’s knowledge. It can also be seen that each answer from the knowledge source will trigger another question and/or another idea. It could then be said that every answer received will encourage designers to have a better formulation of information need. Formalism of the design process and context knowledge have been made. These formalisms will be used as a guide to conceptualize a system in chapter 4 and pilot the implementation of a proof-of-concept system in chapter 5.

Chapter 4

System Conceptualization

”The art of simplicity is a puzzle of complexity.” - Doug Horton

4.1

Introduction

The question-answer activities between the designer and the expert in chapter 3 is in a sense analogous to the web information search through a search engine. The internet user will supply a search term that could be a keyword, a phrase or a combination of keywords/phrases. In response, the search engine will give a list of related web pages, if any. These search results are based on the supplied search terms accordingly, with the most relevant page appearing first due to the search algorithm. However, unlike the process between the designer and the expert, the process between the user and the search engine has a very short life-cycle. As depicted in figure 4.1, the process between the user and the search engine ends when the search engine gives its response, namely a list of web pages.

Web pages

User

Search Engine Search terms

Figure 4.1: Web information search life-cycle

67

68

SYSTEM CONCEPTUALIZATION

4.1

By means of the question-answer analogy, it is assumed that designers use the search engines repetitively. For a design problem, they might look for information on the internet throughout a search engine using more than one supplied search term. There are two main logical reasons why designers complete an iterative information search process. First of all, since the design concept during the early phases of design is vague and incomplete, the query might evolve by query reformulation. Or, the designer could initiate a number of searches just to generate ideas. The second reason is the nature of the design process where a designer could jump from one sub-design problem to another. A sub-design problem often needs more than one informational source or type, e.g., the geometry, material properties, aesthetics, and manufacturing. In order to support designers in building, retrieving and sharing such contexts, a system has been built. This chapter will describe the concept of the web-based Contextual Design Information Retrieval System. This system conceptualization is based on the literature survey of chapter 2 and the findings in the study of chapter 3. If every question that is supplied to the knowledge source is a reflection of a designer’s knowledge, then it is important that such a web information search system not only record the search results, but more importantly, the search terms. Because the combination of the ’right’ search terms and the ’relevant’ search results and their relationship is a kind of knowledge, storing this information will take one step further in answering the question of how to share the (design) knowledge. Prior to this fact, it would useful if the track of the search terms could be seen (at least during the search activity) historically, so that the designer’s cognitive thought processes could be mapped. So far, some search engines have provided the possibility of keeping the search terms and the search results once, as previously mentioned in 1.3. Despite the fact that this state-of-the-art web information retrieval system is very useful and helpful in general, it needs further efforts to comply with informational processing in design projects. First of all, it should not only be personalized (every user has their own search and search results) but must also segregate this search activity into a compartmentalized design project. Second, it should give designers the space needed to decide which search results are relevant. The above-mentioned search engines will keep the clicked search results in a history database, even though they are not always relevant. Third, as mentioned in chapter 3, when designers focus on a design problem, they might use more than one search term in order to find relevant information for problem solutions or ideas. Consequently, the system that aims at helping the designer should also manage the relationship among the associative search terms when defined as a context. In practice, designers print out the relevant search results and put them into a design project folder, where other documents, such as drawing sketches, brainstorming reports, meeting reports, etc., are also included. It would be good if these associative documents, along with the search terms and the relevant search results, could be stored contextually in a better way. Hypothetically, this would make it easier for the designer to access this information.

4.2

INTRODUCTION

69

Projects

has [1:m] Contexts has [1:m]

has [1:m]

Keywords

URLs

(a) Context

has [1:m]

Documents

(b) Context granularity

Figure 4.2: Basic concept of the information search ’context’

The basic concept of a hierarchical context based on theory and findings described in chapter 3 and the definitions in 2.5 is shown in figure 4.2. The relationship between a search term (keyword) with a list of relevant search results and user’s attached documents is shown at a very low level of context. A group of interrelated search terms that represent the designer’s focus on a particular design problem is referred to as ”context”. A project contains a list of contexts and individual search terms. The original of this idea of ”context” not only to encourage designers to find relevant information, but also allows them to make this kind of knowledge transferable. Since designers often work in groups, it is good if they can share information contextually. An additional reason is that design companies often suffer from a loss of knowledge when a designer leaves the company and takes their gained knowledge with them. This chapter is aimed at briefly overviewing the implemented prototype system concept. Section 4.2 gives the overview of the system, while section 4.3 and section 4.4 describe the search information personalization. The core of the system, namely project, search, and context management modules, are described in separate sections. There are many ways and methods to describe the concepts and architectural styles of this system which are dependant on original purposes. Nonetheless, it should be clear, simple, and easy to implement these into a system artifact. The most important parts of an architectural concept of a software system are entities, data flow, processes, data storage and the relationship between data entities. To show these parts of the system, the implemented prototype in this research is described by data-flow diagrams and an entity relationship diagram. The Gane-Sarson’s data flow diagram notations have been chosen to standardize the notations of the chosen description method.

70


4.2

System Overview

4.2

The system is designed to interface between the user and the search engine, so that the state of question-answer sessions in chapter 3 can be situated as shown in figure 4.3. The user gives his search terms to the search engine directly, and the search terms will be passed through the system. In return, the search engine will give the search results for every search term received from the system to the user via the system, but the user will have a chance to manage them contextually.

User

Contextual Information

UserID Project Profile User Profile

CDIRS

Search Results

User’s Data

Search Term

User’s Search Term

Search Engine

Figure 4.3: System overview

In order to manage this search activity and its results, the user of the system must create his/her own user and design project profiles. The user must invest some time in the beginning to create these profiles. The user will then only supply his user identification (userID) to log on to the system and load the stored projects or begin a new (web information search for a design) project. The system also allows the user to embed his relevant data, such as digital drawings or sketches, office files or media files, to a search term.

4.3

SYSTEM OVERVIEW

71

As shown in figure 4.4, each user will have their own account and will complete the design information search on the internet through a search engine for a specific design project. Every new user will be added to the users’ database and will be verified with their supplied userID and password each time they log on to the system. This unique userID will be used to identify the owner of the projects that are stored in the project profile database. Therefore, every single internet search activity is dedicated to a specific project and a particular designer. In this way, it is then possible for the user to include his/her own data for a specific information context (from the internet search activities) of his specific design project. Instead of using the conventional way of finding information from the internet where users only have bookmarks of search results with no context, the return user of this system can retrieve a project where the search terms and the relevant results are bookmarked and the user’s own files are attached within a context.

Search Engine


Search Results

Contextual Information User’s Data

Do Project Existing Project(s)

Search Term Project Profile

Edited Project Project Owner

Project Profile

New Project(s)

User UserID User Profile

User validation and addition

Saved User Verified UserID

Figure 4.4: User’s search activity management

Users

72


4.3

User Validation and Addition

4.4

A userID allows the user to access the system database and do a search for a particular design project. The user validation screen is the gate to the system; hence, the user must supply his/her userID and password. The system will make a query to find a matching combination of a userID and password in the user profile database. Once the system finds the match combination, it will allow the verified user to go to the project menu and and update the user log in the session database. If the userID and password entered is incorrect, the system will provide a userID and password exclamation. A registered user can try with another combination. Meanwhile, a non-registered user can sign up as a new user by creating a new userID, password, and detail profiles. A log will be updated every session subsequent to a successful login. Figure 4.5 shows the user validation and addition process. Logged User

Login

Project Owner

Verified UserID

Session

Users Saved User

UserID

User Profile

Register New User

User

Figure 4.5: User validation and addition

4.4

Project

After finding the match of the supplied userID and password through the validation query, the system will retrieve a list of the user’s available projects, if any. The system will notify the user of the last project that was completed before the last successful logout. By selecting one of the available projects, the user can then begin an internet search as depicted in figure 5.4. In this way, the user can

4.5

SEARCH

73

continue any terminated information search activities without forgetting valuable search terms and results. Like a design activity as a whole, part of the information search activity is to have a search term as a representation of the designer’s brain work that is too valuable to be lost. Some conventional search engines do not keep the search term because they are designed to have a very short life-cycle, as described in section 4.1. Others do keep these search terms, however, they are not managed into separate project folders and are less meaningful to the user and less likely to be put into a context. To start a new project, users can create their own new project or participate in another user’s shared project. When a user starts a new project, he or she should supply project profile data, such as a project name and a project identification (projectID). With the exception of the projectID, if necessary, the stored project profile can be edited. It is important to supply the design requirements along with other project profile data. Design requirements often become information search objects during the early stages of a design, allowing the design results to meet their requirements. According to the developed theory in chapter 3 the designer has actual initial knowledge. This system allows a designer to input possible and potential search terms while supplying a project profile data. These search terms will appear when the designer completes information search activities. In practice, a design project is often done by a group of designers. They could be divided into smaller groups and then come together with the best design or idea, or divide the project into smaller and more specific works. Whatever project working style has been chosen, in general, there will be a brain-storming phase and progress meeting for the project. Therefore, the system should also allow the user to join a project (created by another user). Every user of a joint project will have his/her own information search, but at the same time, it will be possible to keep the search activities within a project and share the search results among users of a particular design team. Only the owner of a project has authority to make any changes in the project profile. After saving the new project profile or selecting one of the available projects, a user can begin a search. More details about this will be described in section 4.5. After obtaining the necessary information, the user can then manage these individual search terms into contexts. Further details on this context management will be explained in section 4.6.

4.5

Search

A “Do-search” play role is a core function of this system, where the user can search information with a dedicated conventional search engine in a web-browser. However, this system also offers an added value that complies with the design process. The term ’dedicated’ means that the system should not do any “metasearching” or use more than one search engine in a query, because this can violate the terms of service for some search engines. However, the system should work for

74

4.5


Search Engine


Search Results

Do Search Selected Project

Requirements New Project(s)

Project Profile

Stored Search Term

New Requirements

Keywords Create New Own Project

Initial Search Term Edited Project

Project Owner

Saved Search Term

Existing Project(s)

Project Profile

User validation and addition

Edit Project Profile


Manage Context(s)

Context ID Search Term

User User’s Data

Figure 4.6: Project

most search engines and should be able to embed any search engine in general. Any search engine company can benefit by adopting this system. The search engine should not be manipulated, thus avoiding any jurisdiction risks that could be interpreted as cracking such search engines. They should remain as they are, with all of their original search results and other features and advertisements. As can be seen in figure 4.7, when a user selects one of the available projects,

4.5

SEARCH

75

the system will recall the search function. The system will initialize a search engine by sending the user’s search term. In the case of a new project, when the user saves the project profile, any initial search terms that represent the user’s initial knowledge will be stored in a keywords database and loaded in the search function. Once the user selects these stored search terms, they will be sent to the search engine. In response, the search engine will send a list of search results to the “show results” process. From the list of these search results, users will then select any relevant results and bookmark them. More details about the bookmarking process will be described in section 4.5. On the contrary, the user might not find any relevant information from the search process. In this case, there will be no bookmarking process, unless the user decides to do so, as opposed to some existing search engine history features that record every clicked search result. The user will not only have a list of bookmarked URLs, but may also want to embed his or her supportive files for each relevant search term. These files will then be stored in a ”documents” database and always associated with a particular search term. If a user has more than one individual search term, he/she might want to build a context by associating the search terms in a context management. This context management function is the same as was mentioned in section 4.4. Bookmark A search engine will rank the search results based on their algorithm from the most relevant to the least. The existing search engines are judged by the their users based on their ”guess”. The closer the guess is to what the users expect, the better the acknowledgment they will get, although there are some ”nasty” search engines that give any party who pays more the highest ranking. Furthermore, some popular search engines, who have great confidence in their algorithm, will provide a sorted list of search results. For instance, only the first ten search results, or possibly only the first, will be displayed. The limitation of search results offered by search engines sounds good to the user because it helps the user avoid the ”noise” of said search. However, there are at least two arguments to counter why this is not always the best scenario in a design situation. First, since the search terms are actually the manifestation of the user’s knowledge of what should be searched, it is possible that at the very early stages of design where the concept is vague, the search terms might not be correct. It could be because there is a limitation of knowledge about what is to be searched, or perhaps because of the formulation of the search term. The wrong formulation might put the ”relevant” search results lower on the sorted list and hinder the user from finding it. Second, when designers work out the design problem, they might use two different approaches at once: divergence and convergence. This limitation may help in the convergence approach, as opposed to divergence. In conclusion, this system will allow the user to judge which search results

76

4.5


Manage Context(s)

Saved Search Term

Bookmarks

Search Engine

User’s Search Term New Bookmark

Do Bookmark New Search Term

Keywords

Stored Search Term

Search Results

Selected URLs

Show Results

Initialize Search Engine

List of URLs

Search Term

User

User’s Data

Selected Project

Embed User’s Data Linked Document

Project Profile Documents

Figure 4.7: Completing a Search

are relevant and also allow them to rely on the original search engine’s rank. As depicted in figure 4.8, the search results are shown in the “show results” process and will be selected by the user. When the user decides to bookmark a selected search result, the system will verify the existence of the search term. If the system

4.6

CONTEXT MANAGEMENT

77

finds one, it will go through the bookmarking verification process. If not, it will trigger a pre-store process to ensure that the correct search results are given and that the associated search terms are stored correctly. For the existing search term, the system will directly store the selected search result if it cannot find one during the verification process, and only on the condition that the user wants to store it. Keywords

Existing Search Term

New Search Term Associated Search Term

Bookmarks

New Bookmark Existing Bookmarks

Verify Existing Search Term

Check Existing Bookmark

Selected URLs

Show Results

Figure 4.8: Bookmark

4.6

Context Management

Lists of individual search terms are stored during the iterative search process. These search terms represent the necessary information needed for design problemsolving. When the information is needed, the user can execute the search term through the search engine. Meanwhile, the bookmarked URLs represent the selected relevant information of such search results. However, these individual search terms and their contents (search results, bookmarked relevant URLs, and embedded files) do not represent the user’s focus, as mentioned in chapter 3. The context management function allows the user to build such contexts from stored individual search terms, as shown in figure 4.9. The user can build a context with at least two associated search terms. To build a context, a user needs to supply a contextID and then add all appropriate search terms from the search activity. This process reflects the proposed theory in chapter 3 that the knowledge about context is cultivated along with the growth of incoming information that is relevant. It is quite possible that the user will complete the

78

4.6


search process first and then group all individual search terms according to their contexts. Do Search Edit Context

Edited Contextual

Edited Context Chosen Contextual

Building Context

Saved Search Term

Contextual

Linked Search Term

Context ID

Selected Contextual Saved Context ID

User


Chosen Context

Contexts

Selected Context

Context Visualization

Visualize Context

Figure 4.9: Context management

Since a search term could appear in two or more different contexts, the linked search terms of a distinctive context and the information about the context itself are stored in different data storages. The information about the context, such as context name and explanation, are stored in a ”context” database, while the associated search terms are stored in a ”contextual” database. For example, in the bicycle design case, the term ”material” could appear in a ”bicycle frame” context. It could also possibly appear in another part of the bicycle, such as ”chain”. If necessary, the user may want to edit or delete a context. Through the editing

4.7

INFORMATION DESIGN

79

context process, users can edit the context information or remove an associated search term. Given that a context should contain more then one search term, users must delete a context if there are only two search terms and one of them is out of context, or they must alternatively add a new one and then remove the unneeded search term. To provide an adequate representation of a context, the system will visualize a context in a 2-D representation, rather than a simple list or tree view. A selected context will appear and interconnect with its associated search terms. Each search term will then interconnect with its URLs and files in a 2-D representation. These interconnections are represented by lines from a context to the search term and from a search term to the URLs and files.

4.7

Information Design

From the above data flow diagrams, a concept of the database for the system implementation has been derived, as shown in figure 4.10. Subsequently, the following entities have been created. They are: users, sessions, projects, requirements, keywords, bookmarks, documents, contexts, and contextual files. In order to personalize the search, a ”users” entity has been introduced. This entity allows a unique user to have dedicated search activities. Within the ”users” entity, the ”user id” attribute plays the role of the primary key. For some search engines, the user id value is bonded with the provided user’s email address. Together with the ”user password” attribute, the ”user id” attribute is used in the user verification process. The ”user id” attribute also acts as a foreign key to the ”sessions” entity which will tell the user the time of the last login and what the last project was. This way, the user will know which uncompleted search activities can be continued. With the purpose of segregating search activities into a compartmentalized design project where the user can have many projects, the ”projects” entity was created. Each design project will be notified by the primary key of this entity, namely the ”project id”. More information, such as project name and project description, can be stored in the ”project name” and ”project desc” attributes. Moreover, design requirements information is important for design information searches because often the information gathering is began from finding more information than design requirements demand. Since there are frequently more than one design requirement, a ”requirements” entity was created with the ”project id” playing the role as the foreign key. Meanwhile, the value of one integer ”sharing project” attribute is used to notify the user if he/she wants to share particular design project information with others or not. If the value is ”yes”, true or ”1”, then other users can find search activity information, such as search terms, contexts, and embedded files, within the project. In addition, in anticipation of a project being accessed by another user (for instance, in the case of a design project that has been done by a group of designers)the ”owner” attribute was added. If

80


4.8

the value of ”user id” is the same as the value of ”owner”, then the user is the creator of the project. This user has authority to change any of the values of the attributes or even delete the data. The complexity of this information design occurs because of three reasons. First, the user’s core activity, namely the information search activity, is a repetitive process that should be recognized by a particular project. Since a user may have more than one project and a project can belong to more than one user, the ”works” entity can be used to recognize an active project of a users-projects many-to-many relationship. The attributes of this entity are used to recognize search terms and contexts of a particular project. They act as a foreign key for the ”keywords” and ”contexts” entities below. In addition, this ”works” entity ensures that the search results of a project exclusively belong to a user, even in a joined project. The second complexity this information design addresses is that the system should recognize a search term as individual and unique for a certain context of a certain project. The ”keyword id” is introduced to anticipate the search terms text similarity stored in the ”keyword” attribute. A different user might have the same search terms in different contexts and different projects. A search term for a particular context might have different purposes, i.e. different lists of URLs or different supportive files. Therefore, each search term must be unique. Every query will be stored within the ”keywords” entity, while their results will be stored in the ”bookmarks” entity because one search term may be relevant to more than one search result. The ”url description” is used to put verbal contexts to a relevant search result. The supportive file that will be linked with the query will be stored in the ”documents” entity. Because the documents that will be attached are different in type and have a different way of being loaded, the type will be stored in the ”doc type” attribute in order to make the content easier to load within a ”doc content” attribute. The third complexity can be described by the following example. Two different and separate bicycle design projects have contexts within the so-called ”bicycle frame” and ”bicycle wheel” contexts. Within each of these contexts, there is a search term ”stainless steel” with very different search results. This complexity will increase when these bicycle projects are executed by a group of independent designers of different design teams. Therefore, although the contexts and keywords are recognized by ”works”, each of the ”contexts” and ”keywords” entities have a ”context id” and ”keyword id” correspondingly to handle the similarities. In this fashion, a context including all search terms and their search results can be transferred to a different project and a different user. Because a search term can appear in two or more different contexts, the content of a context listed in search terms is stored in a separate entity called “contextual” to allow for duplication.

4.8

INFORMATION DESIGN

projects

users PK

user_id user_name user_password

sessions PK,FK1

user_id

81

PK

project_id project_name project_desc sharing_project Owner

works PK,FK1 PK,FK2

requirements

project_id user_id

last_login last_project

bookmarks

FK1 project_id requirement

url url_description FK1 keyword_id contexts PK

keywords

context_id PK

context_name context_description FK1 project_id FK1 user_id

keyword_id

keyword FK1 project_id FK1 user_id

documents

contextual

FK1 context_id FK2 keyword_id

doc_name doc_type doc_description doc_content FK1 keyword_id

Figure 4.10: The information model

82


4.8

Concluding Remarks

4.8

The definition of ”context” from chapter 2, have been used in this system conceptualization. Although the system conceptualized in this chapter is generic enough so that the user does not necessarily have to be a designer, it complies to the design process because of four reasons. First of all, it can do a repetitive search process for a design project. Regarding this repetitive search process, the implementation of the ”users” and ”projects” entities give the possibility of having a personalized and compartmentalized search activity. Implementing these entities also makes it possible to implement the concept of ”history”, where the user can stop the search activity and come back again to the exact point where he/she left off. Second, during this iteration process, every associative search term, with the search results, can be connected in a context. Therefore, the designer can jump from one design focus to another without losing the context. The third and fourth reasons are that this system supports both the uniqueness of the designer and the possibility of a joint project. Each designer can have his or her own search terms and search results, even in a joint project. However, even though every design team member will has his or her own search, and therefore his or her own context, he or she is still able to share with each other. This system is aimed at helping the designer build the above-defined ”context”. Each context itself can grow and trigger a new search, which is also supported by this system. However, the system does not automatically produce or generate any search term or initial knowledge. They are very much dependant on designer experience, understanding and knowledge that differentiate between the expert and the novice designer as well as each individual user. However, as the findings in chapter 3 indicate, every designer has their own way or path to find the right information that can be accommodated in this system and also shared. Therefore, theoretically, the novice can gain advantages from the expert by using this system. Additionally, this system proposes a new approach on how to minimize vanishing knowledge when a (senior) designer leaves a design company. The pilot implementation of the proof-of-concept system for this thesis is reported in the next chapter.

Chapter 5

The Contextual Design Information Retrieval System

”Search is the user’s lifeline for mastering complex websites. The best designs offer a simple search box on the home page and play down advanced search and scoping.” - Jakob Nielsen

5.1

Introduction

This chapter is aimed at reporting the implementation of the system conceptualized in chapter 4. The ultimate goal of this chapter is to answer the following sub-research questions: 1. How to personalize a search engine 2. How to track an information search path 3. How to create a sort list that separates relevant results from the search results 4. How to embed the user’s document into a search term 5. How to assist the user in building a context 6. How to visualize this context 7. How to transfer the context 83

84

THE CONTEXTUAL DESIGN INFORMATION RETRIEVAL SYSTEM

5.3

Since this chapter will detail the implemented prototype system, this chapter will be constructed using the software engineering report style. It begins with the user specification, system and interface requirements specifications,and a database, followed by the details of the system. While describing the implemented system, each of the sections will construct ideas to address each of the sub-research questions listed above. The first sub-research question will be addressed in section 5.6 and section 5.7. The second, third and fourth will be explored in section 5.7. Section 5.8 will concentrate on sub-research questions numbers 5, 6, and 7.

5.2

User Specification

The users of this system are designers who have minimum experience using internet search engines. It is assumed that the users need to complete one or more iterative information searches on the internet, and need to manage the results and the information search processes in a constructive way. It is also assumed that the users will complete individual or collaborative design projects. The users might be willing to use the results and the processes of the informational search in other projects or share this information with other users.

5.3

System and Interface Requirements Specification

From the system’s conceptualization, literature study, and the results of the context knowledge study in conceptual design, the specific implemented system is as follows: 1. The implemented system is built on existing web search technology and operates in conjunction with a common internet search engine. The idea of this work is not to develop a new search engine. Instead of replacing existing advanced search engines, this system will amplify them to fit the nature of the designers, as well as their projects and purposes. As a prototype, the implemented system will utilize a browser technology component and a popular search engine that supports the chosen programming language. 2. The implemented system will support the user in building representations of one or many contexts, where each context is a structured set of keywords that contains Uniform Resource Locators (URLs), pictures, and supportive files, such as office application documents and media files. With the phenomena of design in practice, design problems needing to be solved or design ideas needing to be elaborated may occur in an iterative information search process using more than one search term. Each of these keywords may show one or more URLs as a result of the particular search. Each of the search terms may also be supported by the user’s existing local computer files, such as office documents, pictures, and media files.

5.4WEB-BASED CONTEXTUAL DESIGN INFORMATION RETRIEVAL SYSTEM

85

3. This system will provide an overview of all available contexts in a particular design project and also provide the graphical presentation of any contexts. One way to make the context explicit is to represent it in a graphical representation. 4. This system enables the editing of any context; keywords can be included or deleted, and local or newly retrieved documents can be associated with keywords. 5. This system encourages the designer to search for information from a context selected from existing sources rather than from keywords or stored bookmarks. 6. This system encourages the designer to spend more time and effort on enriching existing contexts and/or creating new ones. 7. This system enables the copying of contexts from preceding and/or shared projects. It also enables the copying of entire projects (as a starting point of a similar design or a redesign). 8. This system enables the designer to make his/her project sharable with other designers. From the system requirements specified above, a list of interface requirements is drawn: 1. The search application interface should contain a common search engine. 2. The search application interface should allow users to see the list of all queries that have been given by the search engine and show the results. 3. This system should allow designers to decide for themselves the relevance of each result. 4. This system should allow the designers to decide for themselves which keywords are within a context. The user should be able to edit the context itself in terms of adding or removing relevant keywords. 5. This system should allow designers to find and attach their local supportive files onto a particular context.

5.4

Web-based Contextual Design Information Retrieval System

A prototype system has been implemented using a Visual Basic and Java programming language. The system offers the possibility of managing the queries

86


5.5

and results in a structured way. It also presents the possibility of supporting the designer in building a representation of one or more search contexts. Another key aspect of this system is the possibility of archiving contexts and reusing them in new design projects, thus accelerating the information search process. Figure 5.1 gives the overview of the architecture of the implemented system that consists of profile management, dialogue management and context management, while relying on an existing search engine. The next section will describe the implementation of the information design conceptualized in chapter 4, followed by sections that describe the details of each part of the implemented system.

Figure 5.1: Web-based Contextual Information Retrieval Architecture

5.5

System Database

The MSAccess database management system has been chosen to implement this information design. The numbers on the tables that have been created are as much an entity in information design as any other component, but some details to the attributes have been added. The users and project tables play a key role in determining how to personalize the search process. The combination of the primary keys from these two tables is to ensure that each information search process carried out on the internet is unique. Since the relationship between

5.6

SYSTEM DATABASE

87

these two tables is many-to-many, where a user can have many projects and a project can belong to many users (for example, when they are developing the design project together), a table called ”works”, shown in figure 5.2, is a kind of index allowing the query to be unique and expectantly faster. Likewise, with other relationships in this database, many difficulties arise because of the manyto-many relationships. For example, an information search in a project can have many search terms (located in table ”keywords”) and contexts, while a search term might appear in more than one context. Similar to this, a bookmarked search result and a user’s embedded document might appear in more than one search term.

Figure 5.2: Implemented database

Because of the above facts and what has been discussed in 4.7, in order to personalize an information search process, the system should not only uniquely identify who is the user, and in what project design he is now working, but should also identify each of the supplied search terms. The possibility of duplicating search results and user-embedded documents in an information search process should be a trade-off with the need for unique identification.

88


5.6

Profile Management

5.6

The profile management maintains the data of the users as well as their (design) project data. Therefore, the information search process in this system will always associate with a particular (design) project that belongs to an individual user (designer) through dialogue management. In this way, the system can be personalized in accordance with the chosen search engine. In other words, each user will have his/her own design projects and each of the projects will have an individual information search process. This profile management controls the login system, user, and project profile modules.

5.6.1

Login system and User Profile Modules

In order to use this system, the user must log onto the system. If the user uses the system for the first time and has not become a registered user, he or she must sign up first. When a user first registers, a user profile will be created. The user should then provide a self-chosen user identification (ID) and password. Other contact details, such as affiliation and email addresses, may also be provided by the user. Each time the user logs onto the system, the system will seek to match the userID and password combination from the stored user profiles in the system’s database.

5.6.2

Project Module

This module is central to the implemented system. This module is divided into sub-modules where the user can see what design projects have been done, and the collaborative design projects in which the user is participating. Here the designer can also create a new project, edit a project profile, complete internet searches for such projects, create and manage the contexts of a particular project and find and copy useful contexts from other projects. In this module, a user will be provided with two kinds of project lists as shown in Figure 5.3. On the left hand side, the user will find a list of any design projects that he created before (as an individual or a team leader). On the right hand side is the list of projects in which the user is participating, if any. To begin a search process, users will select a project from the list and execute it. Project Profile To manage the information search activities based on a project and to integrate the information search process and its results with other project documents, the users can create an information search project as same as his or her design project’s naming system. When a user creates a project, the user can type in any initial keyword for that project in the menu shown in Figure 5.4. The initial keyword or combination of keywords or sentences are any keywords that appear

5.7

DIALOGUE MANAGEMENT

89

Figure 5.3: Project menu

in the users’ mind before they actually begin the information search process. The user may also decide whether or not to share the information search contexts of a project. When a project is created, the project profile will be stored in the project database. This profile can be maintained using the project profile sub-module. The information about a project, such as project goals, project requirements, and types of products, will be maintained.

5.7

Dialogue Management

The dialogue management actually interfaces the users with the existing search engine and keeps the queries and results tractable. The other role of the dialogue management is to connect the users’ supportive files to the appropriate search queries.

5.7.1

Search Module

This module is at the core of the implementation system. In this module, an existing search engine is utilized. The user will use the search engine as usual. Any of the features available from the search engine will be available to the user. In addition, this module will capture the query text (keywords, combination of keywords, or sentences) and write it into a “history” memory before it is passed to the search engine running on the internet browser. When necessary, the text in the memory can be passed to the search engine. In return, the search engine will display a list of URLs as a result of the passed query. The memory will be flushed whenever the module is closed. Instead of going to the location of the

90


5.7

Figure 5.4: Project profile

clicked URL, a pop-up window will appear to show the internet site. It is then the decision of the user to determine the relevance of the site. If the user decides to keep the chosen internet site, both the query text and the URL text will be stored in the “Keywords” and “Bookmarks” tables. Whenever a query text is loaded from the database, it will be passed on to the search engine. In addition, all lists of internet sites, bookmarked URLs, pictures, and documents will be loaded. This process is shown in figure 5.5 and details of this module process will be described in the next sub-sections. Search Engine Utilization To utilize a search engine, a web browser component and text box must be placed in a visual basic form. Whenever the search module is executed, this form will be loaded and will call the web browser component. The empty web browser component will be initiated by a chosen search engine web address and then locked

5.7

DIALOGUE MANAGEMENT

91

Figure 5.5: Search module process

to avoid a direct search through the search engine. The search term typed by the user in the textbox will be taken as a search argument value. After encoding this search argument into a form that is accepted by the chosen search engine, a complete URL that contains the search engine address and search argument will be composed. This URL will be called by the activated web browser by using the ”Navigate2” method. In return, a list of search results will be shown by the web browser. The general algorithm of this process can be seen in algorithm 5.1 and the example of the search engine utilization subroutine is shown in code 5.1. Algorithm 5.1 search engine utilization Load the form Initiated the web browser with search engine address Initiate text-box with null value Read the text-box value Encode the value Compose a complete URL Call the URL with "Navigate2"method

Unlike using the search engine directly, this system will not redirect the web browser to the clicked search result, but rather will load a pop-up window called the result browser window that consists of a web browser. The user can still see all of the listed search results while checking a clicked search result. After checking

92


5.7

the search results in the result browser window, the user can decide to bookmark the result or not. More details about bookmarking activities will be described in the next sub-section. Sub StartGoogleSearch(searchString) Dim url As String, searchArgs As String searchArgs = Replace(Trim(searchString), " ", "+") ’compose complete url url = "http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=" + searchArgs ’for yahoo ’url = "http://search.yahoo.com/search?p=" + searchArgs + "&prssweb=Search&ei=UTF-8&fr=FP-tab-web-t400&x=wrt" ’navigate to the page! WebBrowser1.Navigate2 url Exit_StartGoogleSearch: Exit Sub Err_StartGoogleSearch: MsgBox Err.Description Resume Exit_StartGoogleSearch End Sub

Code 5.1: Search engine utilization subroutine

A requisite of the system conceptualization in chapter 4 is that the implemented system should represent the search engine as it is and should allow the user to see and use all available features that belong to the search engine and web browser. In other words, the embedded search engine’s features must be available for use. In order to differentiate between the click on a search result that triggers the loading of the result browser window and other clicks that enable the use of a search engine’s features, an ”intelligent” check procedure has been added. Only a double click on a URL listed in the search results will trigger a result browser window to appear;otherwise, it will be considered an action of the search engine or web browser. Details on this procedure are shown in code 5.2. History and Bookmark As already briefly mentioned in section 5.7.1, the search terms written in the text box are not only passed to the search engine, but also have been sent to a temporary history list as shown in figure 5.6. This temporary memory is used to catch user’s “trial-and-error” and “mind jump” from one topic to another, as a tool for the user to keep track of his/her searches. If these right, relevant, “wrong” or “irrelevant” search terms should be revisited, the user can again select the term and the system will pass the information to the search engine to again search for results. Technically, each time the search module sends the search term text from the text box to the search engine, it sends this text to a listbox as well. A double-click on one of these listed search terms will activate the search engine to search for information on the internet and present the search results based on the clicked

5.7

DIALOGUE MANAGEMENT

93

Private Sub WebBrowser1_BeforeNavigate2(ByVal pDisp As Object, url As Variant, Flags As Variant, TargetFrameName As Variant, PostData As Variant, Headers As Variant, Cancel As Boolean) On Error Resume Next If InStr(url, "google.com") = 0 Or InStr(url, "google.com/url") > 0 Then ’for yahoo ’If InStr(url, "yahoo.com") = 0 Or InStr(url, "yahoo.com/url") > 0 Then Cancel = True ’open secondary browser ResultBrowserForm.Show ResultBrowserForm.WebBrowser1.Navigate2 url URLtext = url ’checking the URL Dim KeywordIDCheckRs As New Recordset Dim FindKeywordIDArgument As String FindKeywordIDArgument = "SELECT * FROM keywords WHERE user_id = ’" & WorkRs!user_id & "’ AND project_id = ’" & WorkRs!project_id & "’ AND keyword = ’" & Keywordtext & "’" KeywordIDCheckRs.Open FindKeywordIDArgument, cdirsdb, adOpenStatic, adLockOptimistic If KeywordIDCheckRs.RecordCount > 0 Then Dim BookmarkCheck As New Recordset Dim FindBookmarkArgument As String FindBookmarkArgument = "SELECT * FROM bookmarks WHERE keyword_id= ’" & KeywordIDCheckRs!keyword_id & "’" & " AND " + "url = ’" & URLtext & "’" BookmarkCheck.Open FindBookmarkArgument, cdirsdb, adOpenStatic, adLockOptimistic If BookmarkCheck.RecordCount > 0 Then BookmarkTrigger = True End If BookmarkCheck.Close End If KeywordIDCheckRs.Close End If End Sub

Code 5.2: Result browser window

text. Since these search terms listed in the listbox are represented as “short memory” in this information search process, they will be cleared whenever the search module is closed. Contrastingly, the bookmark system is a representation of a “long term” memory. When the user bookmarks one of the search results, it means he/she affirms that the bookmarked search result is relevant to the design process, and therefore both the search term and selected search result need to be stored in the system database as an intellectual asset. Before showing the selected URL, the system will first check if the search term has been previously stored. The system will only store the search term once, when the first URL from a particular query is bookmarked. If the search term does exist in the database, the system will then check to see if the URL has been stored before as a particular associated search term. If so, then the system will only show the result and will not complete a pre-store process. Otherwise, only a pre-store process for a URL, or for both the search term and URL, will be executed when the user clicks the ”bookmark”

94


5.7

Figure 5.6: Captured and saved keywords

button. In the pre-store process, the system will access the “keywords” and “bookmark” tables of the CDIRS database and collect sets of records called recordsets from those two tables by executing Sequel Query Language (SQL) commands. The system will then do a quick seek to find the search term. If the search term does not exist, then the system will create a unique identification (ID) for the search term and for the URL, or the system will only create an ID for the non-existing URL. The system will then start a data store process to write the search term ID, search term text, URL ID, and URL text to the recordset. By using the data transaction methods, the system will only physically transfer the data to the database if there is no error and the process can be completed; otherwise it will cancel the transaction. After a successful transaction, the recordset will be closed and the memory will be released. By following this procedure, the system can keep the data integrity in the physical database. When a bookmark has been successfully created, the search term will be displayed in a combo box (a list box that only displays a single item at the first item index). Only the latest stored search term will be displayed in the combo box, while all relevant URLs will be displayed in a list box as shown in figure 5.6. Every time that a URL from the list is clicked, the information (web site) will be displayed in a pop-up window screen.

5.7

DIALOGUE MANAGEMENT

95

Each one of the stored search terms in the combo box is linked with the search results, the list of bookmarked URLs and the list of a user’s relevant documents, such as electronic pictures/drawings, MS Office files, and multimedia files. Once the user selects the combo box and chooses another search term, the search engine will update the search results based on the chosen search term and a list of bookmarked relevant URLs from the particular displayed search term will be shown. The user’s embedded files will then be listed on a multi-tab pad as can be seen in figure 5.6. Essentially, every stored search term builds a very low context definition, namely, a connection between a search term, relevant search results, and a user’s relevant files from the “outside” of the system environment. More details concerning a user’s documents will be given in the next sub subsection. User’s Embedded Documents As previously mentioned, this system allows the user to link electronic documents to a particular search term. The assumption is that the user might want to use the same keyword to find information on the internet or to find his local document. The other assumption made for this system implementation is that the user might want to enrich information from internet search results with his local documents or vice versa. These embedded documents might be available in many formats, such as a note, a drawing, a physical model, a book etc. However, it is possible to transfer this format to an electronic format. This can be categorized into three types, namely, pictures, office documents, and multimedia (sounds and moving pictures) as shown in figure 5.7. In order to embed the documents into the system, a browsing menu has been created. This menu will appear as a pop-up window when the “add picture”, “add document” or “add media” buttons in the multitab pad are clicked. Basically, this browsing menu contains browsing tools like “Explorer” in MS windows, where the user can define the “drive” and “directory” of the user’s document file as illustrated in figure 5.7. Based on the above three categories, a list of filtered documents will be shown in the file list box. This filtering system is depicted in code 5.3 below. To quickly view a selected file, the user must click one of the files listed in the file list box. The user will then be able to see the selected picture or document or play selected media files. The user may also want to add some additional text as a remark to the file, such as why it is important to be embedded in a particular search term. This file will be stored in the database and will be loaded to the multitab pad in the search menu when the user clicks the ”open” button. Otherwise, if no quick view or comments are listed on a document file, then a double click to a file name listed in the file list box will complete the same operation as clicking the “open” button. The browsing windows will automatically unload whenever the embedding process is successfully implemented. Storing and loading a picture, an office document or a media file categorized as a binary data type is completed using a different process than other types of

96


Figure 5.7: User’s Files Inclusion

Private Sub Form_Load() ’Adding User document ActiveAddDocumentTrigger = True If DocumentTrigger = "pic" Then Frame1.Visible = True File1.Pattern = "*.jpg;*.jpeg;*.jpe;*.jfif;*.gif; *.bmp;*.dib;*.png;*.tif;*.tiff; *.wmf;*.emf" Image1.Visible = True OLE1.Visible = False WindowsMediaPlayer1.Visible = False ElseIf DocumentTrigger = "doc" Then Frame1.Visible = True File1.Pattern = "*.doc;*.xls;*.ppt" Image1.Visible = False OLE1.Visible = True WindowsMediaPlayer1.Visible = False ElseIf DocumentTrigger = "med" Then Frame1.Visible = False File1.Pattern = "*.asx;*.wax;*.m3u;*.wmx;*.wvx;*.avi;*.wmv; *.asf;*.wm;*.wma;*.mid;*.midi;*.rmi; *.wav;*.mpeg;*.mpg;*.mp2;*.m1v; *.mp;*.snd;*.au;*.mp3;.mov" ’Image1.Visible = False ’OLE1.Visible = False WindowsMediaPlayer1.Visible = True WindowsMediaPlayer1.Width = 3300 WindowsMediaPlayer1.Height = 3495 End If End Sub

Code 5.3: Documents browser

5.7

5.7

DIALOGUE MANAGEMENT

97

data such as text, integers, dates, etc. A binary data type needs a streaming process in order to store or to load a binary data type to and from a recordset. In order to do so, a “stream” object that represents the binary text data needs to be constructed. Because this stream object is constructed for streaming the binary data, the stream type needs to be set as “adTypeBinary”. The process of embedding a user’s local document file can be described as follows. First, a recordset will be opened and a new row of data will be added. Next, the chosen embedded file will be loaded to an open stream object using the “LoadFromFile” method. To assign the binary data from the stream object to the field in the recordset, the “read” method is used and then the stream object will be closed. Meanwhile, the streaming process to load the binary data from a recordset is slightly different. Before it can be loaded to a viewer in the file browsing window or multitab pad in the search menu, the binary data will be assigned to an open stream object by using the “write” method and then will be saved into a temporary file by using the “savetofile” method. This temporary file will actually be loaded into the viewer. Each of these temporary files are different in how they will be loaded and represented to the user as it is illustrated in code 5.4. After the loading process of the viewer into a browsing window or multitab pad in the search menu has been completed, the temporary file (MyTempPictureFile or MyTempDocFile or MyTempMediaFile) will be deleted. The difference in how a user’s embedded file loaded to CDIRS as can be seen in code 5.4 depends on its type. A static image will be loaded into an image container, and an office file will be loaded into an OLE (object linked embedded) container. Meanwhile, moving pictures and sound will be played in a media file. In addition, since more than one picture, office or media file can be embedded into a single search term, a record locator is placed in each tab. This record locator can move from one record to the next or to the previous record and also allows jumping to the first or the last record. However, since most office or media files involve large bytes and therefore require more computer memory capacity, only the header of the record will be moved to the record locator. This file will only be loaded when the user clicks the “load” command for the office file and “play” button for the media file. Unlike a picture or media file that easily fits into a picture container or media player no matter how big the file, an office file cannot be properly viewed in a small OLE container. However, this technology allows the file to be opened in a computer program in which the file can be viewed properly. An example would include a Microsoft ® Office Word file that is embedded into a user’s search term. This file would be opened in its original format in Microsoft ® Office Word whenever the user double-clicks the OLE container. This file will go back into the OLE container whenever the user closes Microsoft ® Office Word.

98


5.8

Context Management

5.8

As mentioned in 5.7.1, each search term in the “search” sub-modules contains structured URLs, pictures, and documents that have a meaningful relationship with each other. However, at the higher level or at the level of search terms, they are unstructured and therefore contextless. Contrarily, in practice a designer might have more than one keywords for a design problem or a design idea to be searched in order to receive complete information. Consequently, these keywords are connected in the designer’s mind. This implemented search system allows designers to implement their own connections between all search terms in particular contexts. The context management is responsible for building, visualizing and manipulating the contexts in internet design information searches of a particular design project. The sub-module “context editor” is responsible for creating a context. Once a context has been made, it can be modified or deleted as will be detailed in 5.8.1. Although making an explicit context out of a design information search is important, more importantly is how to visualize the context and transfer it in a necessary case. A context visualization sub-module that handles the process of visualizing the connection of two or more search terms for a particular context will be described in 5.8.2. In the case of designs created by teams, a design team member may want to copy a context from other member, or a user may want to use a context from a previous design project. In this case, the context search and copy process is possible through the “context search and copy” sub-module that will be described in 5.8.3.

5.8.1

Context Editor

In this sub-module, a user is able to create a context by defining the context name and a text description of the context. The name and the description should represent the design problem or design idea. All available search terms will be shown and the user may want to choose at least two of them before a context will be created. Before the user chooses one of these search terms and, if necessary, puts it into a context, the user can visualize the lower level context where the connection between the search term, the relevant URLs and the user’s embedded files are shown. This visualization will be described in more detail in the next subsection. Once these contexts are created, they can be edited or even deleted by the user. By then, the user may want to add more search terms into a context or even remove a search term from a context. In many cases, the user might want to use a context from another project or user. Therefore, it is possible to either copy the full context or part of it. In the case of partial copying, the user can edit the context and delete unnecessary search terms. This “context editor” sub-module is available in the “project” module and in the “search” module. When a user revisits an unfinished design information

5.8

CONTEXT MANAGEMENT

Sub init_Picture() ’Loading Picture If PictureRs!doc_name "" Then FramePicture.Caption = PictureRs!doc_name Dim MyPictureStream As New Stream Dim MyTempPictureFile As String ’jcv ’MyTempPictureFile = "d:\cdirs\" & PictureRs!doc_name MyTempPictureFile = CurDir & "\" & PictureRs!doc_name MyPictureStream.Type = adTypeBinary MyPictureStream.Open MyPictureStream.Write PictureRs!doc_content MyPictureStream.SaveToFile MyTempPictureFile, adSaveCreateOverWrite Image1.Picture = LoadPicture() Image1.Picture = LoadPicture(MyTempPictureFile) MyPictureStream.Close Set fso = CreateObject("Scripting.FileSystemObject") Set MyPictureFile = fso.GetFile(MyTempPictureFile) MyPictureFile.Delete Set fso = Nothing Set MyPictureFile = Nothing End If End Sub Private Sub cmdLoadDoc_Click() ’Loading Office Docs If FrameDoc.Caption "" Then Dim MyDocStream As New Stream MyTempDocFile = "d:\cdirs\" & DocRs!doc_name MyDocStream.Type = adTypeBinary MyDocStream.Open MyDocStream.Write DocRs!doc_content MyDocStream.SaveToFile MyTempDocFile, adSaveCreateOverWrite OLE1.Delete OLE1.CreateLink (MyTempDocFile) MyDocStream.Close End If End Sub Private Sub cmdPlayMedia_Click() ’Loading Media Files On Error Resume Next If lbMedia.Caption "" Then Dim MyDocStream As New Stream MyTempMediaFile = "d:\cdirs\" & MediaRs!doc_name MyDocStream.Type = adTypeBinary MyDocStream.Open MyDocStream.Write MediaRs!doc_content Set fso = CreateObject("Scripting.FileSystemObject") If fso.fileExists(MyTempMediaFile) Then If WindowsMediaPlayer1.playState = wmppsPlaying Then WindowsMediaPlayer1.Close lbMedia.Visible = True End If WindowsMediaPlayer1.Visible = True WindowsMediaPlayer1.url = MyTempMediaFile ’ Else MyDocStream.SaveToFile MyTempMediaFile, adSaveCreateOverWrite On Error GoTo 0 WindowsMediaPlayer1.url = MyTempMediaFile ’MediaPlayer1.play End If Set fso = Nothing MyDocStream.Close End If End Sub

Code 5.4: Document loading

99

100


5.8

search process of a particular design project, he/she might want to build a context from the contextless stored search terms or modify a stored context. The user also might want to have a visualization of the stored context or search terms in order to not lose the “context” for finding information because the process is postponed. Therefore, this “context editor” sub-module is located in the “project” module that appears when a revisited user is successfully logged onto the system. Otherwise, if the user wants to build a context during a search process, the “context editor” is also available in the “search” module.

5.8.2

Context Visualization

Since the contexts are constructed in a hierarchical way, the visualization of contexts has granularity as shown in figure 4.2. At the ”project” level, this module will show the contexts of a project, while at the ”context” level, this module will show a list of keywords. At the lowest level, a keyword will show lists of URLs and a user’s embedded documents. The visualization will increase the explicitness of the context, and will give the user instantaneous results in order to do any necessary editing or adding. Sub updateJavaGraph() Dim javaAppletHTML ’refreshData() Select Case gVizType Case cKeywordDetails teststring = getKeywordDetails(gKeywordid) Case cKeywordContexts teststring = getKeywordContexts(gKeywordid) Case cContextKeywords teststring = getContextKeywords(gContextid, gShowDetails) Case cWork teststring = getWork(gUserID, gProjectID, gShowDetails) Case cSharedProjects teststring = getSharedProjects(gUserID) End Select javaAppletHTML = "" + _"" + _ "" + _ "" + _ "" + _ "" + _ "" + _"" WebBrowser1.Document.body.insertAdjacentHTML "BeforeEnd", javaAppletHTML End Sub

Code 5.5: Context visualization

The visualization screen contains a web browser and an empty hyper text

5.8

CONTEXT MANAGEMENT

101

markup (HTM) file. A Java applet will be used to change the parameters in an HTM file before it will be executed in the web browser, as illustrated in code 5.5. This java applet has been developed to interactively display these visualizations, allowing the user to rearrange, select and modify the information at hand. The applet is capable of rendering and creating an arbitrary layout of large interconnected graphs and allowing two-way communication with its surrounding client. In our implementation, an inspector pane on the right side of the visualization was built in a Visual Basic form to display and edit details of the selected component. Each visualization is fed by one or multiple SQL queries. The CDIRS entities are mapped to different visual elements, for example, URLs are shown via little thumbnails of the actual website (automatically generated by CDIRS in the bookmarking function), while documents, contexts, keywords and projects each have different basic shapes and colors. In order to cope with large quantities of data, the graph visualization uses a fisheye lens distortion. Items in the center are displayed in full, while their size is decreased when dragged to the sides. This enables the presentation of all elements at the same time. For the purpose of this research and regarding its size, only the context and the details of the search term visualization have been implemented and tested. In the future, it may be possible to have the visualization at the project level, the reverse relationship of the search term and context (the visualization of all contexts which are search terms are included), and all context of a particular shared project implemented as it is already prepared in the code. In the situation when the user wants to see the details of a search term before deciding to include it into a context as portrayed in the subsection 5.8.1, the updateJavaGraph subroutine will select the cKeywordDetails case. For this case, the SQL command will be executed to retrieve the search term and all URLs and embedded documents regarding the search term. Otherwise, if the user wants to visualize a context, the updateJavaGraph subroutine will select the cContextKeywords case. Therefore, the SQL command will retrieve all search terms related to the specific context and define their relationship before completing the same procedure in detailing the search terms as mentioned before. The representation of such search term detail and context visualization is depicted in figure 5.8. A context is represented by an oval, while a search term is represented by a box. For a detail search term, each URL is represented by its screenshot thumbnail, while embedded documents are represented by icons, depending on their type, including pictures, office files and media. The relationships among all of these entities are defined by lines. On the right-hand side of the web browser, the description of each entity can be found when the user selects it. For example, in the first example of figure 5.8, when the user clicks the URL’s thumbnail, the details of this URL are shown and the user is able to visit the URL by clicking the ”open” button. As mentioned above, all of the URLs’ thumbnails have been created by executing an embedded OLE Control eXtension, or OCX, in the web browser of the browser pop-up window that shows the results of the bookmarking process. Once

102


(a) Search term detail visualization

(b) Context visualization

Figure 5.8: Context visualization

5.8

5.9

CONTEXT MANAGEMENT

103

a URL is successfully stored in the database, the capturescreen OCX file will be executed to capture the active screen of the web browser and save it as an image file as illustrated in code 5.6. If newbookmarkid > 0 Then ’make screen capture as a thumbnail, first determine filename ’fname = Replace(tempKeywordIDString, " ", "_") fname = "thumb_" + Str(newbookmarkid) fname = CurDir + "\assets\" + fname + ".jpg" ’then do the actual screencapture (capturescreen.ocx necessary). WebBrowser1.SetFocus winhandle = GetFocus f = CaptureScreen1.CaptureSpecificScreen(winhandle, fname, JPG, False, 92, 92) End If

Code 5.6: Create thumbnail

5.8.3

Context Search and Copy

The “context search and copy” sub-module allows a user to find and copy the right and necessary contexts from other users or other projects. In this sub-module, the user either wants to browse all available contexts from other users or projects, or find it within categories, for example, a type of product category. However, other users can only copy the context if the owner decides to share the context. The decision to share the context or not is made by the owner of a new design project in the “project creator” sub-module. However, for a design project that is executed by a team of designers, one of the team members, usually the team leader who creates the design project, must make sure to click the “share” option to allow other members to have access to the context. When a user chooses a project by clicking the projectID in the shared project list, all contexts and individual search terms that belong to the project will be shown as depicted in figure 5.9. Both contexts and individual search terms have the ability to be visualized in order to ensure the user that chosen contexts or individual search terms are correct. Since a search term can appear in more than one context and a context can appear in more than one project, each search term and context must be unique. When a user copies a context from another project or from other projects belonging to another user, the system will give this context a new context identification (ID) and each search term ID will be replaced with a new one. Accordingly, all of the relevant URLs and a user’s embedded files from each search term in a context will also be copied. Unnecessary search terms can be removed from a context in the context editor sub-module, while unnecessary URLs and embedded documents can be deleted directly from the list when the user executes the search term in the “search” module.

104


5.10

Figure 5.9: Search and copy context

5.9

Structured modules list

The general overview of the system is broken down and sharpened into structured modules and sub-modules. Each module or sub-module is a reflection of a specific function of the implemented system and together they construct the general function mentioned in CDIRS. For example, User Profile and Project Profile are two modules that construct the Profile Management. As shown in figure 5.10, these structured modules and sub-modules are listed as follows:

5.10

Modules Interaction

This section describes the relationship and interaction between modules and submodules. The modules and sub-modules of the implemented system will interact with each other, representing the general functions as described in section 5.4.

5.10

MODULES INTERACTION

Login

User Profile

Project

Search

Project Profile

Project Creator

New Project

Context Editor

Join Project

Copy Context or query

Initial queries Context creation

queries

History Context Visualization Results

Accurate Queries Keywords Visualization

Relevant Results

Supportive Documents

Figure 5.10: The structured content list

105

106

5.10.1


5.10

User Profile, Project Profile and Search Interaction

When a user logs into CDIRS, the user profile module will seek the combination of the provided user ID and password in the database. Users giving IDs that do not exist or are a wrong combination of user-ID passwords will be asked to sign-up as a new user or exit the system. Figure 5.11 shows that a new user must deliver user profile information to the system before creating a new project profile. For a returning user, he or she can continue to work on one of the users’ unfinished projects that is listed in the project profile sub-module. The user will be provided with information by the user profile module about the latest working project and time/date of the last successful login. Should the user need to create a new project, it will be possible to create one through the project creator sub-module. When the user creates a new project, requirements and information on the project ID, project name, project description and project goal will be stored. The user will also have an opportunity to put any “initial keywords” in the project creator that will be used in the search sub-module. The user can also decide whether or not to share the context. Once the project is created, the user can begin an internet information search, or if the user wants to continue a listed project, the user can select and execute this command.

5.10.2

Project Creator, Search and Context Editor Interaction

Before the user actually starts retrieving information from the internet via the search sub-module, the user will be given a chance to collect potential query texts (keywords, or a combination of keywords or sentences) that are already on the user’s mind based on his or her knowledge, experiences, or information regarding the design task (design goal, description, type of product, and requirements) when a project is created. In chapter 3, this is called initial knowledge. This refers to any knowledge held by the user at the time before the search is begun. These initial query texts (or initial keywords, initial combination of keywords, or initial sentences) will be sent to search sub-modules by the sub-module project creator (see Figure 5.12). In a sub-module search, the search engine will retrieve the information from the internet and present the results to the user. The user can then decide on the relevance of the results. From these iterative search processes, the user might want to refine the query text, or may have a new idea on a better query text based on the represented results. The user can also delete the query text if the results are not relevant. When a refined query text or a new query text is entered, the search module will record them in the history memory. If necessary, the user can pick one of these recorded query texts for retrieving information from the internet. For the duration of the retrieval of information from the internet in the search sub-module, the user actually not only gain any knowledge from the incoming in-

5.10

MODULES INTERACTION

107

User login into CDIRS User sign up as a new user

Un-existing user User Profile

User create new design project User continue the design project User type in the initial knowledge Project Profile Project Creator User start the information search process

Internet

Search

Figure 5.11: User profile, project profile and search modules interaction

formation of the search result, but also will develop contexts among the individual query texts. The user may also want to enrich this context with his/her own local

108


5.11

User type in the initial query text

Project Creator

User type in the query text

Internet

Search

User pick the query texts

User Visualize the context

Context editor

User choose query text from memory

User add a supportive file

User decides on results relevancy

User Visualize the query text

Figure 5.12: Project creator, search and context editor modules interaction

computer support files such as MS Office, pictures and media files. However, this context is still implicit to the user. To make this context explicit, the user can connect at least two query texts and give it a context name and description within the context creator sub-module. It is possible for the user to visualize each query text (keyword-URLs-pictures-documents-media files) before the user puts it into a particular context. Once the context is created, it can be shared and visualized.

5.11

Concluding Remark

The profile management allows the system to personalize search engines, and thus the information obtained in the search process. In this way, a designer, or a group of designers for a project, have their own search processes. If the search terms are the manifestation of the user’s knowledge and the search paths are the user’s emerging context knowledge, then the personalization of this search process can play a big role in design knowledge management. It then becomes possible to store the manifestation of the designer’s knowledge. Moreover, if the search paths are built from a designer’s experience, a novice designer may learn from a designer with more expertise by accessing stored context knowledge. The use of the pop-up window screen is to keep the user in “context” with the

5.11

CONCLUDING REMARK

109

search process. The parentheses around the word context are used to distinguish the term from the technical terminology in this chapter 4. When a user accesses a search engine in a conventional way, the screen will redirect to the web site of the clicked URL from the search results. In one way or another, the user will lose his context of the search process when he/she cannot see the search term or the search results, because it is situated in different environment. This proposed system allows the user to move freely from one search term, access past search terms in the history, bookmark search terms or URLs, as well as ensure that the user will be able to stay in the same place with his/her information search processes. The user also can still in context and continue the unfinished search or a revisited search process. As the designer usually keeps important hard copies of information and documents of such design projects in a particular folder. This implemented system offers the possibility to connect a search term in an internet information search process and the electronic version of the supported documents that exist from other parts of the design process, such as brain storming notes, sketches, office files. This way of treating important information and documents may potentially offer a solution to the well-known lateen design or other knowledge management problems, including how to get the right information at the right time and at the right place. Furthermore, in this thesis, the “context” is technically defined as the relationship between two or more search terms that are meaningful for the user. Therefore, this kind of context is very explicit, even to another user when it is transferred. However, the level of its explicitness can increase by adding some text for notification, comments or visualization. This system supports the assumption that allows the user to comment when embedding a local documents file to a search term and build a new context, but also represents the relationship between inter-search terms and search terms-URLs-embedded files in a graphical representation. At this moment, there are three types of user electronic documents that can be embedded into the implemented system. These are the types that are most likely obtainable in the early design phase. For instance, a scanned user’s conceptual paper-pen drawing file, a word brainstorming notice file, a spreadsheet budget and schedule file,and a multimedia animation file are possible examples of a connection with a search process. However, since most of the computer programs that run in Microsoft ® Windows operating systems include most of the 3-D design computer programs recognizable to the OLE technology, it may be possible in the future to embed these kinds of files into a search process, or vice versa. All sub-research questions listed at the beginning of this chapter have been answered during the explanation of this implemented web-based design information retrieval system, and can be considered as added values to the conventional internet search system.

Chapter 6

System Life-Cycle Illustration and Evaluation

”There can be no literary equivalent to truth.” - Laura Riding

6.1

Introduction

In chapter 4 and chapter 5, the concept of the system and how it technically works were described. This chapter has a more practical nature and attempts to illustrate how this system can be applied in a very early design stage project. There are two design project cases that will be illustrated. These cases will demonstrate how the context can be built and how the context can be useful for other designers or other design projects. In the end, these two cases were also used during the evaluation of the CDIRS system by several members of academia and industrial practitioner experts.

6.2

System Life-Cycle Illustration2

There are several points of emphasis in this system life cycle illustration, including the following: (a) describing the system using step-by-step instructions, (b) showing how context can be built, (c) showing how context can be shared and 2 This illustration is built-up partly from the observation of several participants who volunteered to simulate the same assignments as mentioned in this chapter with and without using CDIRS. Some pictures used in this illustration have already been appeared in chapter 5.

111

112

SYSTEM LIFE-CYCLE ILLUSTRATION AND EVALUATION

6.2

useful for other designers or other projects, (d) subsequent points and (e) how a novice designer can learn from an experienced designer. This illustration will not include all of the steps entailed in using CDIRS, such as the logon and entering project profiles, but rather, will focus on information searches and context building/manipulating.

6.2.1

The Design Assignments

The first given assignment was to design yogurt packaging for a mobile and busy person with the following requirements: • Light and easy to be carried • Affordable price • Environmentally friendly • Easy to manufacture The second design assignment was to design a garden chair for an area with four seasons that can withstand the extreme climate changes with the following requirements: • Light and movable • Affordable price • Environmentally friendly • Easy to manufacture

6.2.2

Context Building

From the requirements, the designer intuitively could think and want to find solutions for several topics and aspects–termed as initial knowledge– such as: • Materials • Users/customers • Tools needed to design • Manufacturing possibilities For the materials topic, the designer might want to search for: • Light material: carton, aluminium, plastic • Green material

SYSTEM LIFE-CYCLE ILLUSTRATION2

6.2

113

• Recycleable material • Cheap material For the users/customers topic, the designer might want to search for: • User habits • Local tradition/culture • Local climate • Local food These topics should remain in the designer’s mind and might differ from one to another. To start an information search, a designer can start with any topic, possible solution or search query. The user does not have to have structures in action because all typed queries will be recorded in the short memory recorder, allowing he or she to freely jump backward or forward. Meanwhile, the designer should not be afraid that all of his or her search results will be automatically permanently recorded; unlike existing search engine features, the search terms and results will only be recorded if the designer decides to record them. Although he or she might think about the previous material, any search term coming to his or her mind could be directly typed into the search box, as can be seen in Figure 6.1, where the designer discovered the ”bottle type packaging” idea.

Figure 6.1: Information search starts

The designer will then have to decide from the listed search results which are relevant, based on his or her judgement, as can be seen in Figure 6.2.

114


6.2

Figure 6.2: Designer’s relevant judgement

With a list of bookmarked search results, a designer might want to add his or her pictures or files to certain related keywords, as illustrated in Figure 6.3. At this point, the designer can begin to build the lowest level of context, namely, connected keywords, bookmarked relevant URLs, and the user’s files.

Figure 6.3: Designer’s local document inclusion

6.2

SYSTEM LIFE-CYCLE ILLUSTRATION2

115

With a list of recorded individual keywords, the designer might want to build a higher level of context, namely a group of keywords that are meaningful or have certain topics in common, for example, user habits, formgiving, climate, and the culture, as partly depicted in Figure 6.4.

(a) User’s habits context

(b) Formgiving context

Figure 6.4: Context building

In the end, the designer might want to visualize the context, and from there, each of the URLs can be checked and the context can be changed/edited, as can be seen in Figure 6.5.

116


6.3

Figure 6.5: Context visualization

6.2.3

Context Use

In the previous subsection, the nature of context building was illustrated. In this subsection, the second example, the ”garden chair” design assignment, will be used to illustrate the use and manipulation of available context. When the first and second design assignment are compared, some topics are almost the same, although they are different in product types, for instance, both require to search information about ”material”. Therefore the designer might think that some earlier design project recorded information could be useful. Before copying the available contexts from the first assignment (see: Figure 6.6), the designer might want to reviewed it first by visualize the contexts or each of the search terms. This only possible if the contexts have been shared by the owner. After reviewing them, the designers may decide to copy the ”Dutch Culture” and ”climate” contexts for the garden chair/furniture design assignment. When copying the context, all keywords within that context, including all URLs and user’s files, are also copied, as can be seen in Figure 6.7. Designers might then delete or add other URLs and files for such keywords. Of course, it is also possible to delete or add keywords from a certain context.

6.3

SYSTEM EVALUATION

117

Figure 6.6: Review and copy contexts

6.3

System Evaluation

In section 6.2, the design case examples and possible situations of how the proposed system can be used and support designers have been illustrated. This section reports the evaluation of the proposed CDIRS. This evaluation is not intended to evaluate the usability of the developed systems, but rather to evaluate the implementation of the concept of ”context” and its applicability in a design project. The reason behind this is that the full usability test would reserve a lot of effort and take a lot of time out of the limitation of this research. Meanwhile, doing so would give no guarantee that the concept of ”context” and other proposed information searches in earlier design phase improvements could be evaluated and better revealed. Hence, this evaluation should find an acceptable number of participants and evaluation time, while it should also represent the opinions of design communities and situations. If the participants are not familiar with the system, this could hinder their best opinions on such matters of interest or hinder them from seeing the possible cases that could happen in real life. Furthermore, if the participant does not realize the possible situations that could help in real life, they will not be able to give an educated opinion on the system or may not be aware of system advancements.

118


6.3

Figure 6.7: Having copied contexts, search terms, and continued the search

6.3.1

Evaluation Strategies and Methods

An evaluation panel, consisting of experts that either have academic or industrial experience, was formed. The assumption was made that academic experts will be theoretically stronger, while industrial practicing experts will be more familiar with novel and practicing design issues. This demonstration will mainly focus on the analysis phase of design because it is assumed that in this phase, a lot of design information retrieval from internet activities will occur. These experts will have a demonstration of the CDIRS application on two design cases. The demonstration will include the following functions: 1. Search for information and optional context building, 2. Use of context from another user, which may or may not share the project. This demonstration will overcome the problems of ”unfamiliar” practices, and at the same time, give an overview of the system’s capabilities and the ”context” theory behind it. After the demonstration, experts may have a chance to gain hands-on experience of the system by using it to complete their own fake design project, with researchers standing by to offer assistance. If necessary, could search for information on their real design project ”live”. However, the demonstration is designed to be enough for experts to develop an opinion without using the system.

6.3

SYSTEM EVALUATION

119

From each expert, the following will be collected: 1. Data about his/her background and experience in design and information retrieval, 2. Opinions about existing search engines, 3. Expectations for a future (to-be) search engine 4. Opinions about CDIRS’ utility and efficiency in regards to context building, context usage and context sharing, 5. Expected key benefits, 6. Expected key drawbacks and 7. Suggestions for the CDIRS and for the methodology and research. The assessments will be collected using questionnaires completed by the experts after the demonstration session.

6.3.2

Evaluation Results

Experts’ Profile The concept of context and CDIRS was discussed, presented, and demonstrated before ten experts. The experts were grouped into two groups: members of academia and industrial practitioners. For members of academia, their expertise has been proven by their long-term involvement in design education, research, experience in guiding students’ design projects, or having industry experience before embarking on their careers in academia. Members of academia that were involved in this evaluation are professionals, such as lecturers or senior lecturers at faculty members of the Industrial Design Engineering, Delft University of Technology. The expertise of industrial practitioners was assessed by their long-term involvement in design projects and consultations in the industry. The experts from the industry ranged from small-medium to large international companies, from pure design companies to product data management consultations, and from general design to specific consumer products design work. The companies that were involved in this evaluation are located in the Netherlands. They include NewProducts, Fabrique, Philips and Philips Design. All of the experts stated that they have experience in consumer products and industrial design projects. While, some of them mentioned experience in automotive and professional products. All of them mentioned that during their design projects, they collect information from multiple sources, such as colleagues, previous design projects’ documentations, other available surrounding documents and the internet. They see themselves not as experts in finding information from the internet, but as experienced in finding information from the internet and quite often using

120


6.3

internet search engines for collecting information for their design projects. All of them prefer using the ”Google” search engine to find information on the internet. Members of academia also ranked other popular search engines, including the meta search engine (such as ”mamma”), Yahoo, Altavista, and MSN. Meanwhile, practitioners, after Google, preferred Yahoo, Altavista, MSN, and the meta search engine. All of them expect search engines to easily find their expected results. Experts’ Opinions on Existing Search Engines As can be seen in Table 6.1, members of academia scored the usefulness of existing search engines in supporting design projects as 3.6 out of 5, while the industrial practitioners scored 3.0 or were quite neutral.

Table 6.1: Experts’s opinions on the usefulness of existing search engines (1-5; 5 is Very useful)

Group Academia Industrial Practitioner

Mean 3.6 3.0

Standard Deviation 0.5 0.8

The academic experts thought it easy to find relevant information using current internet search engines, in which they gave a score of 3.3 out of 5. Conversely, the industrial practitioners thought it harder to find relevant information using current search engines, reflected in their score of 2.3 out of 5, as described in Table 6.2. Table 6.2: Easiness to find relevant information using existing search engines(1-5; 5 is easy)


Mean 3.3 2.3


Both members of academia and industrial practitioner experts agree that the current features offered by search engines are not really helpful for aiding a design project, as depicted in Table 6.3.

Table 6.3: Helpfulness of features offered by search engines (1-5; 5 is helpful)


Mean 2.5 2.1


6.3

SYSTEM EVALUATION

121

Academic experts were not in favor of agreeing that existing search engines needed improvement. On the contrary, industrial practitioner experts agreed that existing search engines needed to be improved (Table 6.4). Table 6.4: Existing search engines needing to be improved (1-5; 5 is agree)


Mean 2.5 3.8


The experts were asked about the possibility of automatic bookmarking and history features offered by popular search engines, and whether these features could be applied in improving design information searches. With these features, designers could record their information search processes. The experts were divided on their opinions in terms of the usefulness and necessity of these features. Members of academia were not in favor, while the industrial practitioners’ views were quite different. However, both groups conceded that these feature could be very helpful during the collecting of design information from the internet, as can be seen in Table 6.5. Table 6.5: The possible impact of automatic bookmarking and history features in design processes )

Group & Point of evaluation Academia Useful Needed Helpful Industrial Practitioner Useful Needed Helpful

Mean

Standard Deviation

2.0 2.5 3.0

0 0.7 1.4

3.6 3.0 3.2

0.5 0.8 0.5

Experts’ Opinions on Future Search Engines Having collected the experts’ opinions on existing search engines, it was good to know what they expected if a new kind of search engine should become available. Below are the results of this questionnaire. Both members of academia and industrial practitioners agreed that it was not a need to embed search engines in a computer-aided design system, as drawn in Table 6.6. Industrial practitioners found dedicated and unique search processes and information search results necessary, while members of academia did not. This fact can be found in Table 6.7.

122


6.3

Table 6.6: Embedding search engines in a CAD (1-5; 5 is ultimately needed)


Mean 2.0 2.8


Table 6.7: Dedicated and unique search processes for each design project (1-5; 5 is unique for a project)


Mean 2.3 3.6


Both members of academia and industrial practitioners found that it would be useful if the search context could be visualized, as seen in Table 6.8. Table 6.8: Search context visualization (1-5; 5 is useful)


Mean 3.6 3.6


Both members of academia and industrial practitioners found it necessary and useful if search engines could connect search results with users’ local digital documents and were very much in favor of it, as can found in Table 6.9. Table 6.9: Connection between search results and users’ local digital documents (1-5; 5 is needed and useful)


Mean 3.6 4.5


Furthermore, some experts gave their expectations that such features should be included in future search engines verbally and include the following, listed below: Search engines should determine from earlier searches and documents what contexts makes a keyword relevant. Relevant hits are saved, as well as the context in which they were relevant. Search engines should also keep track of successful and bad combinations of keywords and should give advice on better combinations, e.g. when searching for ”clay”, the engine knows from the documents that ”styling clay” is

6.3

SYSTEM EVALUATION

123

relevant; it will exclude ”soil” and ask if Play-doh is to be included or not • Have a high hit rate on design-related topics • Differ between convergent and divergent searches • Easily find visual material Guide the process of including relevant search terms and excluding irrelevant ones Search engine: Results are ranked by designers. Descriptions of the pages discuss whether or not one can find prices, pictures and explanations on how things work, etc. Expert Opinions of CDIRS In general, both members of academia and industrial practitioners found CDIRS helpful, as can be seen in Table 6.10. Table 6.10: General impression on CDIRS (1-5; 5 is needed and useful)


Mean 3.3 3.8


one of the experts from the industry included a brief feedback after the demonstration and is quoted below: I think the application is helpful, but it just requires too many steps, too many interactions and too much organization. All of the good intentions will be lost in a work situation. The key is that it does not block you in working. It surely makes searching and showing the search process easier, but it is the steps before that; creating the database and maintaining it The industrial practitioner experts reluctantly logged on to the system every time to begin the information start, but members of academia have no problem for that, as shown in Table 6.11. Table 6.11: Logging on to personalize the search (1-5; 5 is comfortable anyway)


Mean 4.0 1.8


For this matter, one of them gave his opinion as below:

124


6.3

There should be no ’border’ to begin searching; it should be an implicit part of a project/project team Both groups of experts were too distracted to key-in the project profile before starting the search, as can be found in Table 6.12. Table 6.12: Project profile data key-in (1-5; 1 is distracting)


Mean 2.0 2.6


Industrial practitioner experts found the particular searching interface useful, while members of academia were quite neutral on this matter, as can be seen in Table 6.13. Table 6.13: CDIRS search engine interface (1-5; 5 is very useful)


Mean 3.0 4.0


However, both groups of experts found the capability of the proposed system to link search activities to users’ documents very important (55% of them issued a score of 5), as can be found in Table 6.14. Table 6.14: Users’ document inclusion (1-5; 5 is very important)


Mean 3.5 4.1


Building the context is very important, according to the academic experts; the industrial practitioners agree, as can be seen in Table 6.15. Table 6.15: Context building (1-5; 5 is very important)


Mean 4.3 3.3


Members of academia were a bit more in favor of context visualization as a good presentation of context, while industrial practitioners were neutral on this point, as can be seen in Table 6.16.

6.3

SYSTEM EVALUATION

125

Table 6.16: Context visualization (1-5; 5 is very good)


Mean 3.3 3.0


Table 6.17: Context copying and modifying capability (1-5; 5 is very useful)


Mean 3.3 3.0


Both groups of experts were in favor of the usefulness and capability of copying and manipulating the context for a design project, as can be found in Table 6.17. Members of academia found that the capability of CDIRS to copy and modify the context was important for collaborative designs, but industrial practitioners’ opinions were opposite that of members of academia, as can be found in Table 6.18. Table 6.18: Context in collaboration design (1-5; 5 is very useful)


Mean 4.3 2.8


Members of academia found that the most useful features of CDIRS could be ranked as: 1) context building, 2) including the users’ documents into the search process and 3) keeping the original capabilities of search engines. Meanwhile, industrial practitioner experts found that the most useful feature of CDIRS was its capability to uniquely compartmentalize the search processes into a design project. After that, they found that the users’ document inclusion and keeping the original search engine capabilities were also advancements in CDIRS. In general, both groups of experts suggested that the user interface was not an urgent matter of improvement, as stated in Table 6.19. Table 6.19: User interface improvement (1-5; 5 is not an urgent matter)


Mean 3.3 3.8


However, both groups of experts suggested reducing the complexity of CDIRS, as can be seen in Table 6.20. Both groups of experts also suggested improving the context visualization, as can be seen in Table 6.21.

126


6.3

Table 6.20: CDIRS complexity (1-5; 5 is accepted complexity)


Mean 2.3 2.8


Table 6.21: CDIRS context visualization improvement (1-5; 5 is very good)


Mean 2.6 2.8


Some other suggestions are quoted below: It is very important that it is intuitive and easy to use with minimum effort Don’t make it too big and complex and don’t include too many features Don’t copy documents to the CDIRS repository if it is used in combination with Product Data Management (PDM) or Design Collaboration Systems. Combine internet and intranet searches

6.3.3

Discussion

There are different characteristics for design projects in industry and in academics, such as how big the projects are, how tight the deadline is, and how much pressure is present from the market or the competitors. Usually, a design project in the industry is bigger than an academic design project. The time schedule for meeting the deadline is tight and the pressure from the market or competitor is high. This last design project characteristic is not often present in academic projects. This situation is consistently in agreement with [Court, 1997], where in the end, designers from industry tend to coup the deadline and pressure by not spending much time finding information, but rather using the information they already possess. The evaluation results on experts’ opinions on existing search engines reflect the above fact. Members of academia are assumed to have more time to use search engines to find information on the internet. Therefore, they have more appreciation and awareness of the advancements in existing search engines, as long as it directly gives the needed information. On the contrary, for industrial practitioner experts, current search engines are not really helpful in finding relevant information. Therefore, they want improvement. Because of their tight time schedules, they tend to seek information rather than explore all possible beneficial sources.

6.4

CONCLUDING REMARKS

127

This assumption is consistent with the fact that they expect future search engines to better manage the search process and give results uniquely dedicated to a design project (so they can use it again for other projects); this is the feature of CDIRS that they appreciated most. From this evaluation, the concept of ”context”, the search personalization, search processes, results compartmentalization, context building and manipulating are all acceptable and work both in academia and industry. However, the proposed CDIRS system itself needs to be improved in terms of its usability (user interface and complexity presentation), which is acceptable, because for the time being it has been developed only for the purpose of the proof-of-concept.

6.4

Concluding Remarks

In this chapter, two design cases have been used to illustrate the CDIRS life-cycle. Although it is not detailed step-by-step from the user logon into the system, this example gives the illustration of how a context can be built step-by-step. The second example has been used to show how contexts can be used and manipulated. The two cases have also been used to evaluate a demonstration. The strategy and method of evaluation have been described and the results have been presented in this chapter. The discussion of these evaluation results draws the conclusion at the end.

Chapter 7

Conclusions and Future Work

Under normal conditions, the research scientist is not an innovator but a solver of puzzles, and the puzzles upon which he concentrates are just those which he believes can be both statedand solved within the existing scientific tradition. - Thomas Kuhn

7.1

Introduction

This chapter discusses the general conclusions and the limitations of this research work. Based on the achievements of the research work, some future research directions are recommended in this chapter.

7.2

Conclusion

This thesis has define major problems of utilizing data, information and knowledge in design process. Further, it also has defined the incompatibility of current search engines and the absence of a system that can fully support the information search process for designers in the early phases of a design process, as instances of the problems mentioned above as outlined in chapter 1. The concept of context has been explored and proved that context plays a role in supporting designers’ information searches especially in the early phases of design and is structured in designers’ minds in the form of: 129

130

CONCLUSIONS AND FUTURE WORK

7.2

• Connecting and grouping designers’ search terms, while allowing designers to jump from one problem to another, one solution to another, and one focus to another, which are reflected by the iterative information search processes • Connecting memories of delayed judgements of relevance and going back when designers need to revisit, revise or modify search terms • Giving a starting point for unfinished information searches • Connecting other information and knowledge from other sources for useful design processes within the search process. Because it is structured within designers’ minds, knowledge about context is not easy to record or utilize, either by the owner or by other designers. This research work defines and proposes a system, called Contextual Design Information Retrieval System (CDIRS), that implements the utilization of context in order to increase the benefits of search engines in the earlier phases of design as well as making the contexts in design information searches explicitly visible, recordable, and transferable.

7.2.1

History: short-term memories

There are two possible reasons why designers resupply or revise search terms during the iterative information search process. First of all, the information need is not yet mature and designers need to complete a trial-and-error process. Based on his or her initial knowledge, as founded from the empirical study described in chapter 3, designers supply a number of search terms and then revise them while the design concept and understanding of such concept evolves; therefore, the information need also evolves. The second reason is that it is possible for designers to delay judgement on search results, as one of the characteristics of an early phase, and come back to the judgement process or revise the results of a judgement process after receiving more information or knowledge for a certain context. The two possibilities listed above are supported by the ”history” features in CDIRS. Each and every search term is recorded, and therefore, during the information search process using the search engines, the designers can always revisit the previously supplied terms or supply a new or revised search term. Otherwise, the supplied search terms could get lost in the designer’s mind, or be overlooked when the designer needs to review them or their judgement of the search results. One feature of CDIRS is similar to the automatic bookmarking and history of some search engines. However, it is different in scope and purpose. The automatic bookmarking and history features of some search engines are designed to work in bulk, where each search term is recorded in long-term storage for the history of the use of the search engine by the user. In contrast, the history in CDIRS is designed for an information search process (that could be done by designers more

7.2

CONCLUSION

131

than once) of a certain design project to support the above-mentioned purposes. It is flushed away when the designer leaves the information search process or the design project. Together with bookmarking features, which will be described in the next subsection, they assist the designers in keeping search terms in context with an iterative of isolated information search processes.

7.2.2

Bookmarking: Long-term memories and design process capturing

The current bookmarking systems, found at the internet web browser level and not on search engines, have limitations. At the internet web browser level, the bookmarking system ends up with disconnected search results and search processes. First, they are technically situated in different places. Second, the search results are recorded but not the search terms. This means that after some time, the designers could forget of the search terms, and therefore, could loose the clue from where the bookmarked results came. This makes it impossible to check other search results that might have not yet been judged, or results that need to be revisited after the designer gains more understanding. By not recording the search terms, the system might be unable to advise or give a context to designers of where the starting point was of unfinished search processes. As already mentioned above, the automatic bookmarking system in some search engines gives no ability for the designers to have their own judgment. The bookmarking system automatically records the clicked search results whether they are relevant to the designer or not. In contrast, the CDIRS bookmarking system will only record the judged search terms and the URLs of relevant search results, and meanwhile will allow designers to see all listed search results. As the search terms are products of the designer’s thinking, these recorded search terms reflect the designer’s thinking evolution to solve the design problems.

7.2.3

File inclusion: Building low-level context

CDIRS allows designers to make explicit connections between multiple information sources and types, as mentioned in [Wiegeraad, 1999]. For the purpose of this research, CDIRS allows designers to include other types of electronic files, including images, office files, and media files. By connecting this information to recorded search terms, its search results, and its list of URLs of relevant search results, CDIRS makes this type of context, namely, knowing the contextual connections, explicitly visible.

7.2.4

Context Editor: Building and modifying contexts

Contexts can be characterized by their same focus, topics, and relevance, as concluded in the literature review of this thesis. With these characteristics, the existing contexts can be recognized in design process, as described in chapter 3. CDIRS allows designers to group search terms (including the URLs of relevant

132


7.2

search results and connected electronic files) into a particular focus, topic, problem solver, etc., and store them in a database. By doing so, CDIRS also allows designers to modify certain contexts if necessary.

7.2.5

Context Visualization: Making explicit context visible

Context editors make the implicit context in a designer’s mind explicit and thus suitable to be stored or modified. The benefits of context will increase if these explicit connections are visible to the owner or others. By making the context visible, it will be possible for designers to review the connections and connected search terms, relevant search results, and files, which means reviewing developed design concepts or problem solvers. This visualization also makes the designer’s context transparent to others. This visualization, although explicit, still allows room for interpretation.

7.2.6

Copy Context: Making sharable contexts transferable

In a design team or in collaborative design projects, designers communicate with each other. During this communication, parties may share contexts. However, they might also want to share their information on that context. CDIRS allows designers to transfer sharable contexts to others.

7.2.7

Search Personalization and Compartmentalization

In order to implement all of the above-mentioned features in CDIRS, the search process needs to be personalized and structured into design project compartments. In daily practices, designers search for information on the internet, print it out and put it and all other necessary information, such as sketches, notes and contacts, into a design project folder. CDIRS allows designers to manage all contextual information in one system.

7.2.8

Implementable Contexts

The empirical study as described in chapter 3 concludes that two types of context exists in a design process. The contexts in CDIRS include the type that can be implemented into a computer system in order to support designers’ information search processes in the earlier phases of design.

7.2.9

CDIRS as Knowledge Elicitation and a Transfer Mean

The greatest obstacle for knowledge elicitation is its gathering from different sources and types and to put it in the context of design problem-solving. Because CDIRS is capable of storing and retrieving contextual information for a certain

7.3

FUTURE WORK

133

design focus or topic, it can act as a model for general knowledge elicitation for other applications. Because CDIRS is capable of storing, retrieving and visualizing contextual information, it opens up opportunities for novice designers to learn from experienced designers. It also reduces the risk of “brain drain”, because designers’ thinking products and processes can be captured.

7.3

Future Work

7.3.1

Limitation of the Project

As it was not the intention of this project to create a new search engine, some difficulty occurred in the operation of CDIRS that ran over existing search engines. At this time, the system cannot do a search within a defined context, as is possible with some search engines that provide a search history. During the internal evaluation of the system, it was also found that the bookmarking system failed to recognize advertisement pages and some web pages that have dynamic page names. The feedback from the experts in the evaluation suggested reducing the complexity of CDIRS. Although some experts found the context visualization useful, others suggested simplifying the visualization. CDIRS also has limitations in accepting three types of designers’ electronic files, namely, static images, office files, and dynamic or media files. As they are successfully implemented, it might helpful in the future to accept a kind of computer-aided design system file. CDIRS is implemented as a stand-alone system and only runs under a Windows operating system. This project can possibly be scaled up to a client-server system, a fully web-based system or other operating systems to widen its supports for designers of (global collaborative) design projects. Because of limited time and resources, CDIRS was not fully tested in terms of its usability.

7.3.2

Recommendations

The proposed system, CDIRS, is radically changing the user-interface concept of search engines, from a single isolated query to contextual multiple queries and user-expert dialogue-like interfaces. However, this approach still needs many improvements and evaluations in the future, especially by search engine companies. Some possible future directions of this research can be formulated and include the following: • It is still in attention and concern of many researchers to answer why certain designers could chose an appropriate design methodology and others could not. Likewise, the question emerges why certain designers (especially the

134


7.3

experience ones) can have efficient information search and others not. An effective to investigate this, is to use CDIRS to observe the way of experience and novice designers. • In the information search process, creativity from the part of the user is involved. The usage of CDIRS may supply information about creativity in information search • It has been widely noticed that there is a discourse for using artificial intelligent or intelligence agents to artifice or augment the process of judging relevance. By observing how CDIRS is used to make those judgments, opportunities to reformulate the process are opened. Therefore other domains, such as artificial intelligent (AI) and psychology possible to benefit from this implemented system. • There are many structured knowledge portals and other design tools available; it would be interesting to have a single integrated design support environment, where designers can draw and sketch while doing information searches. • At the cutting edge of internet technology is a portal where people can share pictures, videos, files, and chat, such as Friendster ©and MySpace ©. Here, there is a chance to scale CDIRS as a designers’ community portal, where designers can safely share their ideas, files, and knowledge globally.

Bibliography

Ahmed, S. (2005). Encouraging reuse of design knowledge: a method to index knowledge. Design Studies, 26(6):565–591. Akaishi, M. and Spyratos, N. (2004). Discovering implicit relationships in a web of contexts. In Tanaka, Y., Doerr, M., and Jantke, K. P., editors, Intuitive Human Interfaces for Organizing and Accessing Intellectual Assets, volume 3359 of Lecture Notes in Computer Science, pages 175–188. Springer Berlin / Heidelberg. Akaishi, M., Spyratos, N., Hori, K., and Tanaka, Y. (2005). Connecting keywords through pointer paths over the web. In Jantke, K. P., Lunzer, A., Spyratos, N., and Tanaka, Y., editors, Federation over the Web, volume 3847 of Lecture Notes in Computer Science, pages 115–129. Springer Berlin / Heidelberg. Akman, V. (2000). Rethinking context as a social construct. Journal of Pragmatics, 32:743–759. Akman, V. and Surav, M. (1996). Steps toward formalizing context. AI Magazine, 17(3):55–72. Anick, P. G. and Vaithyanathan, S. (1997). Exploiting clustering and phrases for context-based information retrieval. In SIGIR ’97: Proceedings of the 20th annual international ACM SIGIR conference on Research and development in information retrieval, pages 314–323, New York, NY, USA. ACM Press. Austin, S., Steele, J., Macmillan, S., Kirby, P., and Spence, R. (2001). Mapping the conceptual design activity of interdiciplinary teams. Design Studies, 22(3):211–232. Baeza-Yates, R. A. and Ribeiro-Neto, B. A. (1999). Modern Information Retrieval. ACM Press / Addison-Wesley. 135

136

BIBLIOGRAPHY

Bardasz, T. and Zeid, I. (1992). Cognitive model of memory for mechanical-design problems. Computer-Aided Design, 24(6):327–342. Barnhart, R. K. (1988). The Barnhart dictionary of etymology. The H. W. Wilson Company. Bazire, M. and Brézillon, P. (2005). Understanding context before using it. In Dey, A. K., Kokinov, B. N., Leake, D. B., and Turner, R. M., editors, Modelling and Using Context, volume 3554 of Lecture Notes in Computer Science, pages 29–40. Springer. Bevan, N. (1999). Quality in use: meeting user needs for quality. Journal of Systems and Software, 49(1):89–96. Bevan, N. (2000). Specifying and measuring quality in use. In ICSE, page 819. Beyer, H. and Holtzblatt, K. (1998). Contextual design: defining customercentered systems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. Beyer, H. and Holtzblatt, K. (1999). Contextual design. interactions, 6(1):32–42. Braha, D. and Maimon, O. (1997). The design process: Propertise, paradigm and structure. IEEE Transactions on system, Man, and Cybernetics–Part A: System and Humans, 27(2):146–166. Brézillon, P. (1999a). Context in artificial intelligence: I. a survey of the literature. Computer & Artificial Intelligence, 18(4):321–340. Brézillon, P. (1999b). Context in problem solving: A survey. The Knowledge Engineering Review, 14(1):1–34. Budzik, J., Hammond, K. J., and Birnbaum, L. (2001). Information access in context. Knowledge-Based Systems, 14(1,2):37–53. Burden, E. (2002). Illustrated Dictionary of Architecture. McGraw-Hill. Buvaˇc, S., Buvaˇc, V., and Mason, I. A. (1995). Metamathematics of contexts. Fundamenta Informaticae, 23(2/3/4):263–301. Buvaˇc, S. and Kameyama, M. (1998). Introduction: Toward a unified theory of context? Journal of Logic, Language and Information, 7(1):1. Cave, P. R. and Noble, C. E. (1986). Engineering design data management. In Leech, D. J., editor, Proceedings EMTA ’86, pages 301–307, England. M. Jackson and Son. Chalmers, D., Dulay, N., and Sloman, M. (2004). A framework for contextual mediation in mobile and ubiquitous computing applied to the context-aware adaptation of maps. Personal and Ubiquitous Computing Journal, 8(1):1–18.

BIBLIOGRAPHY

137

Chen, P. P.-S. (1976). The entity-relationship model–toward a unified view of data. ACM Transactions on Database Systems,, 1(1):9–36. Chen, P. P.-S. (2002). Entity-relationship modeling: Historical events, future trends, and lessons learned. In Broy, M. and Denert, E., editors, Software Pioneers: Contributions to Software Engineering, pages 100–114. Springer-Verlag. Clarkson, P. J. and Hamilton, J. R. (2000). ’signposting’, a parameter-driven taskbased model of the design process. Research in Engineering Design, 12:18–38. Court, A. W. (1997). The relationship between information and personal knowledge in new product development. International Journal of Information Management, 17(2):123–138. Cross, N. (1995). Engineering Design Methods: Strategies for Product Design. John Wiley & Sons. Crowley, J. L., Coutaz, J., Rey, G., and Reignier, P. (2002). Perceptual components for context aware computing. In Borriello, G. and Holmquist, L. E., editors, UbiComp 2002: Ubiquitous Computing, Proceedings 4th International Conference, G¨ oteborg, Sweden, September 29 - October 1, 2002, volume 2498 of Lecture Notes in Computer Science, pages 117–134. Springer. de Jong, T. and Rosemann, J. (2002). Naming components and concepts. In de Jong, T. and van der Voordt, D., editors, Ways to study and research : urban, architectural and technical design. Delft University Press. de Jong, T. and van der Voordt, D. (2002). Ways to study and research : urban, architectural and technical design. Delft University Press. de Jong, T. and van Duin, L. (2002). Design research. In de Jong, T. and van der Voordt, D., editors, Ways to study and research : urban, architectural and technical design. Delft University Press. Dentsoras, A. J. (2005). Information generation during design: information importance and design effort. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 19(1):19–32. DeVinne, P. B. (1987). The American heritage illustrated encyclopedic dictionary. Hougton Mifflin Company. Dey, A. K. (2001). Understanding and using context. Personal and Ubiquitous Computing Journal, 5(1):4–7. Dey, A. K. and Abowd, G. D. (1999). Towards a better understanding of context and context-awareness. Technical Report GIT-GVU-99-22, Georgia Institute of Technology.

138

BIBLIOGRAPHY

Dourish, P. (2004). What we talk about when we talk about context. Personal and Ubiquitous Computing Journal, 8(1):19–30. Dourish, P., Bellotti, V., Mackay, W., and Ma, C.-Y. (1993). Information and context: lessons from the study of two shared information systems. In COCS ’93: Proceedings of the conference on Organizational computing systems, pages 42–51, New York, NY, USA. ACM Press. Dumais, S., Cutrell, E., and Chen, H. (2001). Optimizing search by showing results in context. In CHI ’01: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 277–284, New York, NY, USA. ACM Press. Dumitrescu, R. (2007). Context Dependent Digital Shape Editing in Product Design. PhD thesis, Delft University of Technology. Dumitrescu, R., Catalano, C. E., Giannini, F., Falcidieno, B., and Vergeest, J. S. M. (2005). Curve and skeleton based shape deformations to support product design. In Pan, Y., Vergeest, J., Lin, Z., Wang, C., Sun, S., Hu, Z., Tang, Y., and Zhou, L., editors, Computer Aided Industrial Design & Conceptual Design’2005: applications of digital techniques in industrial design engineering, pages 302–307. Beijing: International Academic Publishers. Eckert, C., Maier, A., and McMahon, C. (2005). Communication in design. In Clarkson, J. and Eckert, C., editors, Design process improvement - a review of current practice. Springer. Eppler, M. J. (2004). Knowledge communication problems between experts and managers. an analysis of knowledge transfer in decision processes. ICA working paper 1/2004, University of Lugano. Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional. Fallman, D. (2003). Design-oriented human–computer interaction. In CHI Letters: Proceedings of CHI2003, Conference on Human Factors in Computing Systems, volume 5, pages 225–232, Fort Lauderdale, Florida. ACM Press. Franklin, B. J. (1998). Constructing a service: Context and discourse in housing management. Housing Studies, 13(2):201–216. French, M. J. (1998). Conceptual Design for Engineers. Springer. Glare, P. G. W. (1982). Oxford Latin dictionary. Oxford University Press. Glock, F. (2001). Design work in contexts – context in design work. In Lloyd, P. and Christiaans, H., editors, Designing in Context, pages 199–218.

BIBLIOGRAPHY

139

Gomes, P., Pereira, F. C., Ferreira, J. L., and Bento, C. (2001). Using analogical reasoning to promote creativity in software reuse. In von Wangenheim, R. W. . C. G., editor, Procs. of the Workshop Programme of the Fourth International Conference on Case-Based Reasoning, pages 152–158. Gove, P. B. (1981). Webster’s third new international dictionary. Meriam-Webster Inc. Greenberg, S. (2001). Context as a dynamic construct. Human-Computer Interaction, 16(2, 3, & 4):257–268. Groff, T. R. and Jones, T. P. (2003). Introduction to Knowledge Management: KM in Business. Butterworth-Heinemann Ltd. Gu, T., Pung, H. K., and Zhang, D. Q. (2005). A service-oriented middleware for building context-aware services. Journal of Network and Computer Applications, 28:1–18. Guha, R. V. (1991). Context: A formalization and some applications. Phd thesis, Stanford. Hatamura, Y. (2006). Decision-making in engineering design. Springer-Verlag. Hekkert, P., Keyson, D., Overbeeke, K., and Stappers, P. J. (2000). The delft id studio lab: Research through and for design. In Achten, H., de Vries, B., and Hennessey, J., editors, Design Research in the Netherlands 2000, pages 133–142. Hekkert, P. and van Dijk, M. (2001). Designing from context: Foundation and application of the vip approach. In Lloyd, P. and Christiaans, H., editors, Designing in Context, pages 383–394. Heskett, J. (2003). Toothpicks and Logos: Design in Everyday Life. Oxford University Press. Holtzblatt, K. (1994). War stories and experience designing with contextual techniques. In Plaisant, C., editor, CHI Conference Companion, page 343. Hori, K. (1997). Concept space connected to knowledge processing for supporting creative design. Knowledge-Based Systems, 10:29–35. Hoshino, K. (1978). Encyclopedic Dictionary of Architecture and Building Construction. Maruzen. Hummels, C. and Overbeeke, C. (2000). Actions speak louder than words: shifting from buttons and icons to aesthetics of interaction. In Pizzocaro, S., Arruda, A., and Moraes, D. D., editors, Design plus Research, pages 284–290.

140

BIBLIOGRAPHY

Hyde, R. (1989). Design procedures in architectural design: application in caad. Design Studies, 10(4):239–245. ISO13407 (1999). Human-centred design processes for interactive systems. ISO9241-11 (1998). Ergonomic requirements for office work with visual display terminals (vdts) - part 11 : Guidance on usability. Jambak, M. I. (2000). Design of information architecture for supporting machining of prismatic components in the automated flexible manufacturing system. Master’s thesis, Malaysia University of Technology. Jambak, M. I. and Vergeest, J. S. M. (2004). An empirical study on context knowledge in engineering design practice. In Kiyoki, Y., Wangler, B., Jaakkola, H., and Kangassalo, H., editors, Information modelling and knowledge bases XVI. IOS Press. Jambak, M. I., Verlinden, J. C., and Vergeest, J. S. M. (2005). Context visualization in web-based design information retrieval system. In Proceeding of The 9th World Multi-Conference on Systemics, Cybernetics and Informatics. Järvelin, K. and Wilson, T. D. (2003). On conceptual models for information seeking and retrieval research. Information Research Online Journal, 9(1):145– 180. Jin, Y. and Chusilp, P. (2006). Study of mental iteration in different design situations. Design Studies, 27(1):25–55. Kari, J. and Savolainen, R. (2007). Relationships between information seeking and context: A qualitative study of internet searching and the goals of personal development. Library & Information Science Research, 29(1):47–69. Khedr, M. and Karmouch, A. (2005). Acai: agent-based context-aware infrastructure for spontaneous applications. Journal of Network and Computer Application, 28(1):19–44. Kiyoki, Y., Kitagawa, T., and Hayama, T. (1994). A metadatabase system for semantic image search by a mathematical model of meaning. SIGMOD Record, 23(4):34–41. Knoop, W. G. (1997). The empirical research discussion platform: Report k-366. Technical report, Faculty of Industrial Design Engineering, Delft University of Technology. Kuhlthau, C. C. (2005). Towards collaboration between information seeking and information retrieval. Information Research Online Journal, 10(2). Lang, S. Y., Dickinson, J., and Buchal, R. O. (2002). Cognitive factors in distributed design. Computers in Industry, 48(1):89–98.

BIBLIOGRAPHY

141

Lieberman, H. and Selker, T. (2000). Out of context: computer systems that adapt to, and learn from, context. IBM System Journal, 39(3 & 4):1–16. Liu, Y. C. and Bligh, T. (2003). Toward and ’ideal’ approach for concept generation. Design Studies, 24(4):341–355. Mácˇel, O. (2002). Naming components and concepts. In de Jong, T. and van der Voordt, D., editors, Ways to study and research : urban, architectural and technical design. Delft University Press. Maier, R., Hadrich, T., and Peinl, R. (2005). Enterprise Knowledge Infrastructures. Springer. Mattelmäki, T. (2005). Applying probes – from inspirational notes to collaborative insights. CoDesign, 1(2):83–102. McCullough, M. (2001). On typologies of situated interaction. Human-Computer Interaction, 16(2, 3, & 4):337–349. McMahon, C., Lowe, A., and Culley, S. (2004). Knowledge management in engineering design: personalization and codification. Journal of Engineering Design, 15(4):307–325. Mitchell, C. T. (2001). The role of context: Reassessing design success and failure. In Lloyd, P. and Christiaans, H., editors, Designing in Context, pages 221–230. Morroni, M. (2006). Knowledge, Scale and Transactions in the Theory of the Firm. Cambridge University Press. Motschig-Pitrik, R. (2000). A generic framework for the modeling of contexts and its applications. Data & Knowledge Engineering, 32(2):145–180. Murray, J. A. H., Bradley, H., Craigie, W. A., and Onionss, C. T. (1989). Webster’s third new international dictionary. Oxford University Press. Ozkaya, I. and Akin, O. (2006). Requirements-driven design: assistance for information traceability in design computing. Design Studies, 27(3):381–398. Pahl, G. and Beitz, W. (1995). Engineering Design: A Systematic Approach. Springer. Perry, D. E. (1994). Issues in process architecture. In Ghezzi, C., editor, International Software Process Workshop, pages 138–140. Qin, S. F., Harrison, R., West, A. A., Jordanov, I. N., and Wright, D. K. (2003). A framework of web-based conceptual design. Computer in Industry, 50:153–164. Rembold, U., Nnaji, B. O., and Storr, A. (1993). Computer Integrated Manufacturing and Engineering. Addison Wesley Longman.

142

BIBLIOGRAPHY

Riloff, E. and Hollaar, L. (1992). Text databases and information retrieval. In Allen B. Tucker, J., editor, The Computer Science & Engineering Handbook. CRC Press. Rodgers, P. A., Caldwell, N. H., Clarkson, P. J., and Huxor, A. P. (2001). The management concept of design knowledge in modern product development organizations. Int. J. Computer Integrated Manufacturing, 14(1):108–115. Roozenburg, N. J. M. and Eekels, J. (1995). Product Design: Fundamentals and Methods. John Wiley & Sons. Rouse, W. B. and Cody, W. J. (1989). A theory based aprroach tp supporting design decision making and problem solving. Information and Decision Technology, 15:291–306. Saracevic, T. (1975). Relevance: A review of and a framework for the thinking on the notion in information science. Journal of the American Society for Information Science, 26(6):321–343. Savolainen, R. (2006). Time as a context of information seeking. Library & Information Science Research, 28(1):110–127. Schilit, B. N. and Theimer, M. M. (1994). Disseminating active map information to mobile hosts. IEEE Network, 8(5):22–32. Schwotzer, T. (2002). Context driven spontaneous knowledge exchange. In Minor, M. and Staab, S., editors, Proceeding of 1st German Workshop on Experience Management: Sharing Experience about Sharing of Experience, pages 131–138. Segers, N. M., de Vries, B., and Achten, H. H. (2005). Do word graphs stimulate design? Design Studies, 26(6):625–647. Serafini, L. and Giunchiglia, F. (2002). Ml systems: A proof theory for contexts. Journal of Logic, Language and Information, 11:471–518. Shafer, S. A. N., Brumitt, B., and Cadiz, J. (2001). Interaction issues in context-aware intelligent environments. Human-Computer Interaction, 16(2, 3, & 4):363–378. Sleeswijk Visser, F., Stappers, P. J., van der Lugt, R., and Sanders, E. B.-N. (2005). Contextmapping: experiences from practice. CoDesign, 1(2):119–149. Snoek, H., Christiaans, H., and Hekkert, P. (1995). The effect of information type on problem representation. In Goldschmidt, G. and Porter, W. R., editors, Proceeding of 4th Design Thinking Research Symposium. MIT. Stappers, P. J. (2005). Designing as a part of research. In van der Lugt, R. and Stappers, P. J., editors, Proceeding of the symposium ’Design and growth of knowledge’, pages 11–13. TU Delft, StudioLab Press.

BIBLIOGRAPHY

143

Stappers, P. J. and Sleeswijk Visser, F. (2006). A gentle introduction to context. In Stappers, P. J., van der Lugt, R., Sleeswijk Visser, F., and Hekkert, P., editors, Context and Conceptualization, number ID4215. Faculty of Industrial Design Engineering, TU Delft. Stellingwerff, M. C. (2005). Virtual Context: Investigating the characteristics and opportunities of digital visualisation media for situated approaches to architectural design in an urban environment. PhD thesis, Technische Universiteit Delft. Stenmark, D. (2002). Information vs knowledge: The role of intranets in knowledge management. In Proceedings of the 35th Hawaii International Conference on System Science. Stonehouse, G. H. and Pemberton, J. D. (1999). Learning and knowledge management in the intelligent organization. Participation & Empowerment: An International Journal, 7(5):131–144. Strzalkowski, T., Lin, F., Perez-Carballo, J., and Wang, J. (1997). Building effective queries in natural language information retrieval. In Proceedings of the fifth conference on Applied natural language processing, pages 299–306, San Francisco, CA, USA. Morgan Kaufmann Publishers Inc. Talen, E. (2006). Design for diversity: Evaluating the context of socially mixed neighbourhoods. Journal of Urban Design, 11(1):1–32. Theodorakis, M., Analyti, A., Constantopoulos, P., and Spyratos, N. (2002). A theory of contexts in information bases. Information Systems, 27(3):151–191. Thompson, G. (2005). Quality management. In Clarkson, J. and Eckert, C., editors, Design process improvement - a review of current practice. Springer. Tuomi, I. (1999). Data is more than knowledge: Implications of the reversed knowledge hierarchy for knowledge management and organizational memory. Journal of Management Information Systems, 16(3):107–121. Ullman, D. G. (2001). Robust decision-making for engineering design. Journal of Engineering Design, 12(1):3–13. Unwin, S. (2003). Analysing Architecture. Routledge. van Breemen, E. J. J. (1996). Empirical results of observing product development proceses: K-329 the desys d1 experiment. Technical report, Faculty of Industrial Design Engineering, Delft University of Technology. van der Vegte, W. F. and Horv´ ath, I. (2002). Consideration and modeling of use processes in computer-aided conceptual design: A state of the art review. Transactions of Society for Design and Process Science, 6(2):25–59.

144

BIBLIOGRAPHY

van Rompay, T., Hekkert, P., and Muller, W. (2005). The bodily basis of product experience. Design Studies, 26(4):359–377. Vergeest, J. S. M. (2001). Shape context - informal description and formal definition. Technical report, Faculty of Design, Engineering and Production, Delft University of Technology. Vergeest, J. S. M. and Jambak, M. I. (2007). Shape context. Private Conversation. Wang, S. and Ariguzo, G. (2004). Knowledge management through the development of information schema. Information and Management, 41:445–456. Warren, J., Worthington, J., and Taylor, S. (1998). Context: new buildings in historic settings. Oxford Architectural Press. Wiegeraad, S. (1999). Development of a Design History Information System: Capturing and Re-Using the Knowledge Behind the Product. PhD thesis. Winograd, T. (2001). Architectures for context. Human-Computer Interaction, 16(2, 3, & 4):401–419. Xu, J. and Croft, W. B. (2000). Improving the effectiveness of information retrieval with local context analysis. ACM Transactions on Information Systems, 18(1):123–138.

Summary

Large amounts of data, information, and knowledge are used during a design process, especially during the earlier stages of design. However, past research proves that designers often neglect information and instead rely on discussions with colleagues, although the data, information and knowledge abundantly surround the designers. Besides varying in size, the differences in type and coming from different domains, the difficulties in utilizing these resources are largely due to the absence of ”context”, namely how to bring the right data, information, and knowledge into a design context for a particular design process. In the era of the internet, where the number of websites is still growing, the opportunities for designers to retrieve design information from the internet are increasing. However, most internet search engines are not compatible with designers’ information search processes, especially during the earlier phases of design (analysis and conceptual design). These internet search engines are typically intended to be used once during an information search process, while designers search for design information iteratively in a divergent or convergent search process. Moreover, there are two reasons why these search engines are not really fit to the design process in the early phases. First of all, these search engines assume the information need that is reflected in every search term of an information query, is mature, while in the early phases of design, the concepts are vague and the problems are ill-defined. Therefore, the information needs themselves are subject to be found. Second, because queries are not connected, the use of the available search engines at this moment does not give designers the opportunity to treat and utilize the contexts that have been built during the search process. Instead, those contexts are implicit and stored mentally. This research work was aimed at developing a search system that is ”natural” to the designer in the earlier phases of the design process, but more than that, captures the designer’s thinking evolution. By assuming that every search term 145

146 is a product of a designer’s thinking process, the prospect of recording judged search terms will open up possibilities of capturing a designer’s thinking path in each design project as groups of contexts. Furthermore, at this moment, the effort towards knowledge utilization in design practice is generally feeble, including research attempts to answer three major questions, namely, how to gather knowledge, how to store and represent knowledge, and how to manage it. It is possible that the risk of brain drain that often happens when a designer leaves a company can be reduced if knowledge about information searches, both the process and the results, can be stored. In order to simultaneously complete an initial literature survey on a few anchor papers, this research work began by studying the empirical data of a previous conceptual design tool research, where the communication between designers and experts were recorded. In the present study, it can be concluded that designers are actually building up knowledge in order to handle the information search process, namely knowledge about the context of each query and the incoming information from experts. This empirical study also found that each designer has his or her own information searching path which is dependent on his or her tacit knowledge. Also from this present study, formalisms of design processes and context knowledge were proposed. Meanwhile, in an intensive and comprehensive literature study, a reconstruction of the meaning of ”context”, and its concept from various domains and applications, was done. This literature study was started by finding the root of the term context and then collecting common meanings of context from some popular and widely used dictionaries. Although there was no consensus found on the definition of context, where the meaning of context was at times even opposite in some domains, this literature study revealed the emergence of the meaning of context that can be understood by readers from different domains or applications. In order to reconstruct this meaning of context, different approaches were used. The literature study also crystalized the characteristics of context–how it can be recognized, how researchers from many disciplines treat and handle it, and other context-related words, such as focus, relevance, topics, and judgement. As a result from this literature study, the definitions of context for the purpose of this research were proposed, and the research problem statement was revisited. Based on this study and further literature studies, a system for supporting designers in retrieving design information from the internet was conceptualized. In this stage, the term “context” was technically defined as a relationship between search terms that are meaningful to the designers. In system conceptualization, the use of search engines by designers is analogous to the designer-expert questions and answers. This system conceptualization used the Gane-Sarson’s data flow diagram notation and entity relationship diagram to express the functions and the information design and to specify its architecture. Guided by the results of system conceptualization, a system called a webbased Contextual Design Information Retrieval System (CDIRS) was developed and implemented. It interfaces designers and search engines in order to increase

SUMMARY

147

the benefits of search engines in the earlier phases of design, as well as making the contexts in design information searches explicitly visible, recordable, and transferable. This system was also designed to comply with the nature of a designers’ way of searching for design information. After conducting internal testing, the system was used by a number of invited users to simulate how information searching was done in the early phase of a design project. By observing these users, two cases involving context-building and context-use were made using CDIRS. An evaluation panel, consisting of experts with academic and industrial experience backgrounds, was formed. The assumption was made that academic experts would be theoretically stronger, while industrial experts would be more familiar with novel and practicing design issues. It was decided to demonstrate CDIRS, rather than asking the panel members to operate the system. In this way, an overview of the system’s capabilities and the context theory behind it, could be obtained. The two design cases were demonstrated to the panel, to show the building and the use of context while applying CDIRS. Although the demonstration was designed to allow experts to give their opinions on CDRIS, per request, the experts experienced the system hands-on side-by-side with the researcher. Finally, the experts wanted to operate CDIRS for real and actual design problems before giving their opinions by filling out the questionnaire. From this evaluation it was concluded that, with some minor suggestions, the proposed ”context” concept implemented in CDIRS was well accepted and proven to work in design assignments.

Samenvatting3

Tijdens een ontwerpproces worden grote hoeveelheden gegevens, informatie en kennis gebruikt, vooral in de vroegere fasen van het ontwerpen. Uit eerder gedaan onderzoek blijkt echter dat ontwerpers vaak informatie negeren en in plaats daarvan terugvallen op discussies met collega’s, ondanks de overvloed aan gegevens, informatie en kennis die hen omringt. Behalve de variatie in omvang, de verschillen in type en domein van herkomst, komen de moeilijkheden bij het gebruik van de informatiebronnen vooral door het ontbreken van ”context”; hoe moeten de juiste gegevens, informatie en kennis in een ontwerpcontext gebracht worden voor een bepaald ontwerpproces. In het internettijdperk, bij een nog steeds groeiend aantal webpagina’s, nemen de mogelijkheden voor ontwerpers toe om via internet informatie te krijgen. Maar de meeste internet-zoekmachines zijn niet afgestemd op zoekprocessen van ontwerpers, vooral tijdens de vroegere fasen van het ontwerpen (analyse en conceptueel ontwerpen). Deze internet-zoekmachines zijn typisch bedoeld voor incidenteel gebruik, terwijl ontwerpers juist informatie zoeken op een iteratieve manier, divergerend of convergerend. Allereerst gaan deze zoekmachines ervan uit dat de informatiebehoefte, uitgedrukt in een zoekterm, zelf al rijp is, terwijl in de vroege fasen van het ontwerpen de concepten vaag en de problemen nog niet goed zijn gedefinieerd. De informatiebehoeften zelf moeten dus nog gevonden worden. Ten tweede, omdat de zoekopdrachten niet gekoppeld zijn bieden de huidige zoekmachines geen mogelijkheden aan de ontwerpers om contexten die tijdens het zoekproces zijn opgebouwd verder te gebruiken. In plaats daarvan worden contexten impliciet en mentaal opgeslagen. Het onderzoek richtte zich op het ontwikkelen van een voor de ontwerper ”natuurlijk”zoeksysteem voor de vroege ontwerpfasen, maar dat ook het denkproces van de ontwerper volgt Aannemende dat iedere zoekterm een product is van de gedachten van de ontwerper, geeft het registreren van ingegeven zoektermen 3 Summary

in Dutch

149

150 de mogelijkheid om de gedachtegang van een ontwerper vast te leggen in de vorm van groepen contexten. Verder is er in het algemeen nog weinig onderzoek gedaan naar het gebruik van kennis in de ontwerppraktijk, met als belangrijkste drie vragen hoe kennis te vergaren, hoe het op te slaan en te representeren en hoe het te beheren. Mogelijk kan het gevaar van brain drain, wanneer een ontwerper een bedrijf verlaat, worden gereduceerd als kennis over het informatie-zoeken, zowel het proces als de uitkomsten, kunnen worden vastgelegd. Tegelijk met een eerste literatuurstudie, begon het onderzoek met een studie naar empirische gegevens uit een eerder onderzoeksproject naar conceptuele ontwerptools, waar de communicatie tussen ontwerpers en experts waren geregistreerd. Uit deze studie kan worden geconcludeerd dat ontwerpers in feite kennis opbouwen om het informatiezoekproces te kunnen uitvoeren, namelijk kennis over de context van iedere zoekopdracht en de binnenkomende informatie van de experts. Deze empirische studie gaf ook aan dat iedere ontwerper zijn of haar eigen informatiezoekpad heeft afhankelijk van zijn of haar voorkennis. Van deze studie werden tevens formalismen van ontwerpprocessen en contextkennis voorgesteld. Intussen werd een intensieve en uitgebreide literatuurstudie uitgevoerd, waarmee het begrip en het concept ”context”werd gereconstrueerd gezien vanuit verschillende domeinen en toepassingen. Deze literatuurstudie ging uit van het basisbegrip ”context”en vervolgens werden betekenissen van context uit populaire en veelgebruikte woordenboeken verzameld. Hoewel er geen consensus is gevonden in de definitie van context, waarbij de betekenis van context uit sommige domeinen soms zelfs tegengesteld was, kwam toch een betekenis van context naar boven die door lezers uit verschillende domeinen en toepassingen begrepen wordt. Om deze betekenis te herleiden werden verschillende benaderingen gebruikt. De literatuurstudie kristalliseerde de karakteristieken van context uit, hoe het wordt herkend, hoe onderzoekers uit verschillende disciplines het hanteren, evenzo voor contextgerelateerde termen als focus, relevantie, onderwerp en beoordeling. Met de resultaten uit de literatuurstudie konden de definities van context ten behoeve van dit onderzoek worden voorgesteld, and werd de onderzoeksvraagstelling herzien. Gebaseerd op deze en verdere literatuurstudies werd een systeem geconcipieerd voor het ondersteunen van ontwerpers bij het verkrijgen van informatie via internet. In dit stadium werd context technisch gedefinieerd als een relatie tussen zoektermen die betekenisvol zijn voor ontwerpers. Bij het concipiëren van het systeem was er een analogie tussen het gebruik van zoekmachines door ontwerpers en de vragen en antwoorden tussen ontwerpers en experts. Bij deze systeemconceptualisatie werden de Gane-Sarson datastroomdiagramnotatie en entiteit-relatiediagrammen gebruikt om het functie- en informatieontwerp uit te drukken en om de architectuur te specificeren. Vanuit het systeemconcept werd een systeem, webgebaseerd Contextual Design Information Retrieval System (CDIRS), ontwikkeld en gemplementeerd. het vormt een interface tussen ontwerpers en zoekmachines om de voordelen van zoekmachines in de vroege fasen van het ontwerpen te verbeteren, en om contexten

SAMENVATTING3

151

van het informatie zoeken expliciet zichtbaar te maken, en te kunnen vastleggen en doorgeven. Het systeem is ook aangepast aan de manier waarop ontwerpers zoeken naar ontwerpinformatie. Na interne tests werd het systeem door een aantal uitgenodigde personen gebruikt om te simuleren hoe het zoeken naar informatie verloopt in de vroege fasen van een ontwerpproject. Door deze gebruikers van CDIRS te observeren werden twee cases ontwikkeld, van het opbouwen van context en van het gebruik van context. Er werd een panel gevormd bestaande uit experts met academische en met industrile achtergrond. De aanname hierbij was dat academische experts theoretisch sterker zouden zijn en experts uit de industrie meer vertrouwd met nieuwe en praktische ontwerpproblemen. Er werd besloten om CDIRS te demonstreren en de panelleden niet te vragen het systeem te bedienen. Op deze wijze kon een overzicht worden verkregen van de mogelijkheden van het systeem en de achterliggende contexttheorie. Beide ontwerpcases werden aan het panel gedemonstreerd om het bouwen en het gebruik van context te tonen. Hoewel de demonstratie was opgezet om de experts gericht te vragen naar hun opinie over CDIRS, was er meer sprake van een hands-on ervaring samen met de onderzoeker. Tenslotte wilden de experts het systeem daadwerkelijk gebruiken voor echte, actuele ontwerpproblemen alvorens hun opinie te geven d.m.v. het vragenformulier. Uit de evaluatie kwam naar voren dat het voorgestelde concept van context, zoals gemplementeerd in CDIRS, goed ontvangen werd en bleek te werken in ontwerpopdrachten.

Inhaltsangabe4

Während eines Entwurfsprozesses werden große Mengen von Daten, Informationen und Wissen gebraucht, vor allem in den fr¨ uheren Phasen eines Entwurfs. Fr¨ uhere Untersuchungen beweisen jedoch, daß Designer oft Informationen ignorieren und sich stattdessen auf Diskussionen mit Kollegen verlassen. Sie tun dies ¨ trotz des Uberflusses von Daten, Informationen und Wissen, der sie umringt. Außer der Variation in Umfang, dem Unterschied in Typ und der Herkunftsdomäne, liegen die Schwierigkeiten beim Gebrauch von Informationsquellen vor allem am Fehlen von Zusammenh¨ angen. Die Frage ist, wie die richtigen Daten, Informationen und das richtige Wissen mit einer bestimmten Entwurfsaufgabe in Zusammenhang gebracht werden k¨ onnen. Im Internetzeitalter, bei der noch immer wachsenden Anzahl von Webseiten, nehmen die Möglichkeiten f¨ ur Designer zu um u ¨ber das Internet Informationen zu bekommen. Die meisten Internetsuchmaschinen sind jedoch nicht abgestimmt auf Suchprozesse von Designern, vor allem während in den fr¨ uhen Entwurfsphasen (Analyse und Konzept). Internetsuchmaschinen sind auf einmaligen Gebrauch abgestimmt. Designer hingegen suchen wiederholt Informationen, mal ausweitend, und ein andermal zielgerichtet. Es gibt zwei Hauptgr¨ unde, warum Suchmaschinen nicht wirklich zur fr¨ uhen Entwurfsphase passen. Zum Ersten gehen diese Suchmaschinen davon aus, dass der Informationsbedarf, ausgedr¨ uckt in einem Suchbegriff, selbst schon ausgereift ist. Hingegen sind in den fr¨ uhen Entwurfsphasen die Konzepte vage und die Probleme noch nicht gut definiert. Die Informationsbed¨ urfnisse selbst m¨ ussen noch gefunden werden. Zum Zweiten sind Suchaufträge bei heutigen Suchmaschinen nicht aneinander gekoppelt. Damit bieten sie keine Möglichkeit f¨ ur Designer um Zusammenhänge, die w¨ ahrend des Suchprozesses aufgebaut werden, weiter zu benutzen. Stattdessen bleiben solche Zusammenhänge f¨ ur Designer implizit, und sie werden nur im Ged¨ achtnis bewahrt. Die Untersuchung richtet sich auf die Entwicklung eines Suchsystems, das der 4 Summary

in German

153

154 fr¨ uhen Entwurfsphase auf ’nat¨ urliche’ Weise entspricht und dar¨ uber hinaus in Betracht zieht, wie Designer Ideen entwickeln. Das System nimmt an, daß jeder Suchbegriff ein Produkt des Denkprozesses eines Designers ist. Die Möglichkeit, bewertete Suchbegriffe mit einer Bewertung zu speichern, eröffnet wieder Möglichkeiten um den Gedankengang eines Designers per Designprojekt als Gruppen von Zusammenhängen darzustellen. Desweiteren gibt es noch wenig Untersuchungen u ¨ber den Gebrauch von Wissen in der Designpraxis, insbesondere zu drei wichtigen Fragen: wie Wissen sammeln, wie es speichern und präsentieren und wie es verwalten? Hier Es gibt die Gefahr eines ’brain drain’, wenn ein Designer einen Betrieb verlässt. M¨ oglicherweise kann diese Gefahr reduziert werden, wenn Wissen u ¨ber Informationssuchen, sowohl u ¨ber den Prozess als auch u ¨ber die Ergebnisse, festgelegt werden k¨ onnen. Diese Untersuchung begonn mit einer ersten Literaturstudie und gleichzeitig mit einer Analyse von empirischen Daten aus einem frherem Untersuchungsprojekt nach konzeptuellen Designwerkzeugen, in dem die Kommunikation zwischen Designer und Experten registriert wurden. Aus der Analyse kann geschlossen werden, daß Designer tats¨ achlich Wissen aufbauen um den Informationssuchprozess ausf¨ uhren zu k¨ onnen, n¨ amlich Wissen u ¨ber die Zusammenhänge von jedem Suchauftrag und u ¨ber die dazukommenden Informationen von Experten. Diese empirische Studie ergab auch, dass jeder Designer seinen oder ihren eigenen Informationspfad hat, abh¨ angig von seinem oder ihrem Vorwissen. Als Ergebnis der Studie werden formelle Elemente fr Designprozesse und Wissenszusammenhänge vorgestellt. Zugleich wurde eine intensive und ausf¨ uhrliche Literaturstudie ausgef¨ uhrt, in der der Begriff und das Konzept ’Kontext’ aus der Sicht verschiedener Gebiete und Anwendungen konstruiert wird. Diese Literaturstudie ging aus von dem Basisbegriff ’Kontext’. Zun¨ achst wurde die Grundbedeutung des Begriffs festgestellt. Dann wurden Bedeutungen von Kontext aus populären und viel gebrauchten Wörterb¨ uchern gesammelt. Obwohl kein Konsens in der Definition von Kontext gefunden wurde, und die Bedeutung von Kontext manchmal widerspr¨ uchlich wiedergegeben wurde, konnte mithilfe der Literaturstudie doch eine Bedeutung des Begriffes Kontext festgestellt werden, die f¨ ur Leser aus verschiedenen Bereichen und Anwendungen verst¨ andlich ist. Um diese Bedeutung zur¨ uckzuf¨ uren, wurden verschiedene Ann¨ aherungen gewählt. Die Literaturstudie kristallisierte den charakteristische Elemente von Kontext heraus: wie er erkannt wird, wie Untersucher aus verschiedenen Disziplinen ihn handhaben. Dies wurde auch getan f¨ ur kontextverwandte Begriffe wie Fokus, Relevanz, Thema und Beurteilung. Mit den Ergebnissen aus der Literaturstudie wurde eine Definition von Kontext f¨ ur die Zwecke dieser Untersuchung vorgestellt, und die urspr¨ unglich gestellte Untersuchungsfrage neu formuliert. Basierend auf dieser und weiterer Literaturstudien wurde ein System konzipiert, das Designer bei der Informationssuche im Internet unterst¨ utzen soll. In diesem Stadium wird Kontext technisch definiert als eine Beziehung zwischen Suchbegriffen die f¨ ur Designer bedeutungsvoll sind. Beim Konzipieren des Sys-

INHALTSANGABE4

155

tems wird eine Analogie geschaffen zwischen dem Gebrauch von Suchmaschinen durch Designer, und den Fragen und Antworten zwischen Designern und Experten. Bei der Systemkonzeption wurden Gane - Sarson Datenstromdiagrammrechnungen und Wesen - Beziehungsdiagramme angewendet, um die Funktions- und Informationsform auszudr¨ ucken und um die Systemarchitektur zu spezifieren. Auf der Basis der Ergebnisse der Systemkonzeption wurde ein System entwickelt und implementiert: das web-based Contextuel Design Information Retrieval System (CDIRS). Es ist ein Interface zwischen Designer und Suchmaschine, das die Vorteile von Suchmaschinen f¨ ur die fr¨ uhen Entwurfsphasen Phasen noch vergrößert, und dar¨ uberhinaus Zusammenhänge bei Designinformationssuchen deutlich sichtbar, speicherbar und transferierbar macht. Das System wurde so gestaltet, daß es der Herangehensweise von Designern bei der Suche nach Entwurfsinformation entspricht. Nach ersten internen Tests wurde das System durch eine Anzahl eingeladener Personen benutzt, um zu simulieren, wie das Suchen nach Informationen in den fr¨ uhen Phasen eines Entwurfsprojektes verl¨ auft. Die Beobachtung dieser Benutzer resultierte in zwei F¨ allen von CDIRS-Benutzung: dem Aufbauen eines Kontextes, und dem Gebrauch eines Kontextes. Ein Expertenpanel mit akademischen und mit industriellen Hintergrund wurde geformt. Die Annahme hierbei war, daß akademische Experten theoretisch stärker und Experten aus der Industrie vertrauter mit neuen und praktischen Entwurfsproblemen sein w¨ urden. Es wurde beschlossen, CDIRS zu demonstrieren und die Panelmitglieder nicht zu fragen, das System zu bedienen. Auf diese ¨ Weise kann eine Ubersicht erlangt werden von den Möglichkeiten des Systems und der dahinterliegenden Kontexttheorie. Beide Entwurfsfällen wurden dem Panel demonstriert, um das Aufbauen und den Gebrauch von Zusammenhängen zu zeigen. Obwohl die Demonstration geplant war, um die Experten gezielt nach ihrer Meinung u ¨ber CDIRS zu fragen, wurde daraus mehr eine ’hands - on’ Erprobung zusammen mit den Untersuchern. Schließlich wollen die Experten das System tatsächlich benutzen f¨ ur echte Entwurfsprobleme, bevor sie ihre Meinung abgaben beim Ausf¨ ullen eines Fragebogens. Das Ergebnis dieser Evaluation war, daß das vorgestellte Konzept von Kontext in CDIRS gut angenommen wurde, und daß das System, mit Ausnahme von einigen Details, bei der Entwurfsarbeit brauchbar ist.

Yhteenveto5

Suunnitteluprosessissa - varsinkin sen alkuvaiheissa - käytetään runsaasti erimuotoista tietoa ja tiet¨ amyst¨ a. Tutkimukset kuitenkin osoittavat, että suunnittelijat usein laiminly¨ ov¨ at sen k¨ ayt¨ on ja tukeutuvat sen sijaan kollegoiden kanssa käytyihin keskusteluihin. Sen lisäksi, ett¨ a niden k¨ aytett¨ avien tietovarastojen koko, tyyppi ja alkuperä vaihtelevat, niiden k¨ ayt¨ on vaikeus johtuu puutteellisesta sidoksesta asiayhteyteen (konteksti), eli siit¨ a, miten tuoda oikea tieto ja tietämys tiettyyn suunnittelutilanteeseen. Internetin aikakaudella, kun www-sivustojen määrä on jatkuvasti kasvussa, suunnittelijan mahdollisuus hy¨ odyntää internetistä saatavissa olevaa tietoa kasvaa. Useimmat internet-hakukoneet eivät kuitenkaan ole yhteensopivia suunnittelijan tiedonhakuprosessin kanssa, varsinkin kun on kyse suunnittelun alkuvaiheista (ongelma-analyysi ja k¨ asitteellinen suunnittelu). Internet-hakukoneet ovat tyypillisesti tarkoitettu k¨ aytett¨ av¨ aksi tiedon kertaluonteiseen hakemiseen, kun taas suunnittelijan hakuprosessi on toistuvaa, suunnitteluun liittyvän, konvergoituvan tai divergoituvan tiedon etsint¨ a¨ a. Lisäksi on olemassa kaksi syytä, miksi internet-hakukoneet eiv¨ at kovin hyvin sovellu alkuvaiheen suunnitteluprosessiin. Ensinnäkin, hakukoneet olettavat, ett¨ a hakutermin määrittämä tiedon tarve on tarkkaan harkittu, kun todellisuudessa suunnittelun alkuvaiheissa käsitteet ovat epämääräisi¨ a ja ongelmat ep¨ aselvi¨ a. T¨ astä syystä tiedon tarve itsessään on haun kohteena. Toiseksi, olemassa olevien hakukoneiden käyttö ei tällä hetkellä anna suunnittelijalle tilaisuutta k¨ asitell¨ a ja hyödyntää sisältöä, joka on rakennettu hakuprosessin aikana, koska haut eiv¨ at ole yhteydessä toisiinsa. Sen sijaan sisällöt ovat implisiittisi¨ a ja varastoitu jokaisen suunnittelijan omaan muistiin. Tämän tutkimusty¨ on tarkoituksena oli kehittää hakujärjestelmä, joka on ”luonnollinen”suunnitteluprosessin alkuvaiheen suunnittelijoille ja joka tallettaa muistiinsa suunnittelijan ajatusmallin kehittymist¨ a suunnittelutyön edetessä. Oletus, että jokainen hakutermi on tuotos suunnittelijan ajatteluprosessista, antaa mah5 Summary

in Finnish

157

158 dollisuuden tallentaa arvioituja hakutermejä ja tulkita suunnittelijan ajattelupolkua suunnitteluprojektiin liittyvien kontekstien joukkona. Tällä hetkellä aiemman suunnittelutiet¨ amyksen hy¨ odynt¨ aminen on käytännössä vähäistä. Aiemmissa tutkimuksissa ei ole my¨ osk¨ a¨ an kyetty vastaamaan kolmeen keskeiseen pääkysymykseen: kuinka tiet¨ amyst¨ a voidaan ker¨ at¨ a, miten sitä voidaan tallentaa ja kuinka sitä voidaan käsitell¨ a. Usein, kun ty¨ ontekij¨ a j¨ attää työpaikkansa, mukana häviää myös hänen tieto-taitonsa. T¨ am¨ an vaikutusta on mahdollista lieventää, jos tietämys informaatiohauista, niin prosesseista kuin tuloksista, voidaan varastoida. Tämä tutkimusty¨ o aloitettiin alustavalla tutustumisella kirjalliseen lähdeaineistoon sek¨ a hakemalla kokemustietoa suunnittelutyökaluista, joissa kommunikointi suunnittelijoiden ja asiantuntijoiden kanssa tallennettiin. Tästä selvitystyöstä voitiin tehd¨ a johtop¨ a¨ at¨ os, ett¨ a suunnittelijat todellisuudessa muodostavat tietämyst¨ a selviyty¨ akseen tiedonhakuprosessista; kyse on tehtyjen kyselyjen kontekstista ja asiantuntijoilta saadusta tiedosta. Tämän empiirisen tutkimuksen tuloksena todettiin, ett¨ a jokaisella suunnittelijalla on oma tiedonhakupolkunsa, joka on riippuvainen hnen omasta hiljaisesta tiedostaan. Tutkimuksessa laadittiin myös suunnitteluprosessia ja siin¨ a käytettävää kontekstitietämystä koskeva formalismi. Syvällisen ja kokonaisvaltaisen kirjallisuustutkimuksen perusteella määriteltiin kontekstin k¨ asite eri soveltamisen aloilla ja sovelluksissa. Tämä kirjallisuusselvitys aloitettiin selvitt¨ am¨ all¨ a konteksti -termin alkujuuret ja sen jälkeen keräämällä tämän käsitteen yleisi¨ a merkityksi¨ a muutamasta laajalti käytetystä sanakirjasta. Vaikka yksik¨ asitteist¨ a merkityst¨ a termille ”konteksti”ei löydetty ja vaikka joissakin lähteiss¨ a oli k¨ asitteelle olemassa samaan aikaan jopa aivan vastakkaisia merkityksiä, täm¨ a kirjallisuusselvitys paljasti konteksti-termin käyttötavan eri lähteissä ja sovelluksissa. Jotta konteksti-termin täsmällinen määritteleminen oli mahdollista, oli käytett¨ av¨ a erilaisia l¨ ahestymistapoja. Kirjallisuusselvitys myös kiteytti konteksti-termin ominaisuuksia: kuinka se voidaan tunnistaa, kuinka tutkijat eri tieteenaloilla suhtautuvat siihen ja k¨ aytt¨ avät sitä, sekä muut konteksti-termin sukulaissanat, kuten tarkentuminen (focus), relevanssi, aihe (topic) ja arvio (judgement). Tuloksena t¨ ast¨ a kirjallisuusselvityksestä saatiin ehdotus konteksti-termin mäa¨rittelemiseksi t¨ am¨ an tutkimuksen tarkoitukseen ja tutkimusongelman tarkentamiseen. Perustuen tehtyyn selvitysty¨ oh¨ on ja täydentäviin kirjallisuusselvityksiin pystyttiin mäa¨rittelem¨ aa n j¨ a rjestelm¨ a konsepti, joka voi tukea suunnittelijaa saamaan ¨ internetistä informaatiota suunnittelutyönsä tueksi. Tässä vaiheessa termi ”konteksti”mäa¨riteltiin suunnittelijalle merkityksellisten hakutermien suhteena. Tavoitteena oli kehitt¨ aa arjestelm¨ a, jota suunnittelijat käyttävät hakukoneena ja ¨ j¨ joka on toimintaperiaatteeltaan analoginen suunnittelija-asiantuntija kommunikaation kanssa. T¨ am¨ an j¨ arjestelm¨ an periaate kuvattiin toiminnallisuuden osalta Gane–Sarson:n tietovirtakaavioiden avulla ja käyttäen ER-kaavioita kuvaamaan tiedon rakennetta ja arkkitehtuuria. Määrittelyn pohjalta suunniteltiin ja toteutettiin verkkopohjainen suunnittelutyötä tukeva j¨ arjestelm¨ a, Contextual Design Information Retrieval System

YHTEENVETO5

159

(CDIRS). Se tukee suunnittelijoiden ja hakukoneiden vuorovaikutusta siten, että hakukoneita voidaan hy¨ odynt¨ a¨ a tehokkaasti alkuvaiheen suunnittelussa, kuten myös tekemään suunnitteluinformaation kontekstin selkeästi näkyväksi, tallennettavaksi ja siirrettvksi. Jrjestelm on suunniteltu noudattamaan suunnittelijalle luontevaa tapaa etsi¨ a suunnitteluinformaatiota. Sisäisen testauksen j¨ alkeen j¨ arjestelm¨ a¨ a testattiin ulkoisten käyttäjien kanssa. N¨ ain saatiin selville, kuinka tiedonhakua toteutetaan todellisten suunnitteluprojektien alkuvaiheissa. Testik¨ ayt¨ on tuloksena saatiin analysoitavaksi kaksi tilannekuvausta, jotka sis¨ alsiv¨ at sek¨ a kontekstin rakentamisen että käyttämisen CDIRSjärjestelmn avulla. Tämän jälkeen perustettiin arviointilautakunta, joka koostui akateemisista ja teollisuuden asiantuntijoista. Oletuksena oli, että akateemiset asiantuntijat ovat teoreettisesti vahvempia, kun taas teollisuusasiantuntijoille tutumpia olisivat uudenlaiset ja k¨ ayt¨ ann¨ onl¨ aheiset suunnitteluongelmat. Arviointilautakunnan jäseniä ei pyydetty k¨ aytt¨ am¨ a¨ an j¨ arjestelmää, vaan päädyttiin demonstroimaan heille CDIRS:n toimintaa. T¨ all¨ a tavoin oli mahdollista muodostaa yleiskuva järjestelmän mahdollisuuksista ja sen taustalla olevasta konteksti-käsitteen teorian toimivuudesta k¨ ayt¨ ann¨ oss¨ a. Arviointilautakunnalle demonstroitiin kaksi suunnittelutilannetta, joissa n¨ aytettiin, kuinka kontekstia voidaan rakentaa ja hyödyntää CDIRS-j¨ arjestelm¨ ass¨ a. Vaikka kokeilu oli suunniteltu siten, että asiantuntijat pystyiv¨ at antamaan mielipiteens¨ a järjestelmästä, pyynnöstä he myös pä¨ asivät kokeilemaan j¨ arjestelm¨ a¨ a k¨ ayt¨ ann¨ ossä yhdessä tutkijan kanssa. Lopulta asiantuntijat halusivat k¨ aytt¨ aa arjestelmäa¨ myös todellisissa ja var¨ CDIRS-j¨ sinaisissa suunnitteluongelmissa, ennen kuin antoivat mielipiteensä täyttämällä kyselylomakkeen. T¨ ast¨ a arvioinnista voitiin tehdä johtopäa¨tös, että muutaman pienen parannuksen kanssa ehdotettu konteksti-ksitteen toteuttaminen CDIRSjärjestelmässä sai hyv¨ an vastaanoton ja osoittautui toimivaksi suunnittelutehtävissä.

Matome6

製品の概念設計においては、その製品に関連する適切な情報と知識が必要とされる。しかしながら、過去の研究が示すように、多くのデザイナーが大量の情報に囲まれているにもかかわらず、それらを有効に用いず、情報獲得の手段については、デザイナー間の対話に頼っている。設計に関する情報には、サイズ、型やドメインによる違いがあるが、それらの情報の利用を難しくするものは「コンテクスト」の取り扱いにある。特定の設計過程において設計のコンテクストの把握は難しく、しばしばそれらは考慮されない。

インターネットが普及している時代において、情報量が増加するにつれ、デザイナーが設計に関する情報を得る機会も増える。しかし、多くのインターネット上の検索システムは、デザイナーの情報探索プロセスに対応できない。これらの検索システムは、一時的な情報の獲得に使用される。それに対して、デザイナーの情報探索プロセスは、返しを含む発散あるいは収束プロセスである。さらに、検索システムの使用には、特定の語彙を必要とするが、初期の設計過程においては、設計のための概念があいまいであるため、それらの取得とその利用が難しい。また、検索システムは、情報の探索過程に使用されたコンテクストを利用することができない。

本研究の目的は、初期設計過程においてデザイナーが自然に使用可能（つまり、コンテクストを利用可能）であり、かつ、デザイナーの思考過程を考慮した検索システムを開発することである。

6 Summary

in Japanese

161

162

すべての探索語彙がデザイナーの思考過程から導かれるものであると仮定すれば、本システムを用いることにより、その思考過程をたどることができるようになる。このため、どのように知識を獲得、保存し表現するかという研究課題の解決に貢献し、また設計対象と設計知識を保存することにより、知識流出のリスクを減少させることができる。

第一に、本研究では重要と思われる文献調査を行った。同時に、既存の設計支援システムを用いた設計実験を行った。この結果、デザイナーは、エキスパートからの対話を通して情報検索のための情報を獲得することが観察された。また、デザイナーは各々の知識背景に依存する情報探索ルートを持っていることがわかった。設計実験と文献調査を通して、本研究では設計過程とコンテクストに関する知識の形式方法を提案した。

本研究ではさらに、文献調査を包括的に行い、多様なドメインから導かれるコンテクストの意味を考察した。調査は、第一に、広義の辞書などから導かれるコンテクストの語源と意味について行われた。調査の結果、それらの意味は一貫しておらず、しばしば対義的に定義されていた。また、このことから、コンテクストの意味は多様なドメインやアプリケーションから創発されるものであることが明らかになった。更なる文献調査と研究に基づき、本研究ではデザイナーのインターネット上の情報獲得支援システムの概念設計を行った。本システムでは、コンテキストを「デザイナーにとって意味のある検索語彙の関係」と定義した。本システムにおいて、インターネット上での情報探索は、エキスパートとの対話プロセスとして位置づけられる。また本システムは、機能と情報設計を表現し、システムのアーキテクチュアを特定するため、Gane-Sarson のデータフローダイアグラムと実体間関係ダイアグラムの表記を用いている。これらの概念設計にもとづいて、本研究では、Conceptual Design Information Retrieval Systems (CDIRS）を開発および実装した。本システムは、初期設計過程で検索エンジンを用いることによる効果を高めるために、デザイナーと検索エンジン間のインターフェースの役割を担う。また、本システムは、設計のために検索されたコンテクストを明示的に表現、記録、転送可能にする。さらに、本システムは、デザイナーの設計に関する情報探索を自然な形（コンテキストを用いた形）で実現させる。

本研究では、コンテキストの獲得とその利用について、本システムの実現可能性に関する実験と評価を行った。また、大学と企業からエキスパートを招き、本システムの実用性に関する評価を行った。ここで、大学のエキスパートは理論について、また、企業のエキスパートは、実際の設計に関してより多くの知識を有すると仮定した。システムの評価は、エキスパートが実際に利用するのではなく、デモンストレーションの形式によって行った。２通りの設計ケーススタディについて、本システムを用いて評価を行った。これらの評価の結果、エキスパートは実際の設計において、本システムの導入が有効であることを示した。これらの実験と評価により、本研究において示した概念とシステムは、設計過程において広く役立つことを検証した。

7 ¨ Ozet

Bir tasarım s¨ ureci boyunca, ¨ ozellikle tasarımın erken safhalarında b¨ uy¨ uk miktarda veri, bilgi ve birikim kullanılır. Ancak ge¸cmi¸s ara¸stırmalar tasarımcıların bol veri ve bilgiyle çevrili olmalarına raˇ gmen, genellikle bilgiyi ihmal edip onun yerine meslekta¸slarıyla yaptıkları tartı¸smalara dayandıklarını kanıtlar. Bu kaynakların kullanımındaki zorluklar boyuttaki deˇgi¸sim, t¨ urdeki farklılıklar ve farklı alanlardan gelmi¸s olmalarının yanı sıra b¨ uy¨ uk öl¸cu ¨de baˇglamın eksikliˇgine; yani belirli bir tasarım i¸cin doˇ gru veri ve bilginin tasarım baˇglamına nasıl getirildiˇgine baˇglıdır. Hala web sitesi sayısının arttıˇgı internet ¸caˇgında, tasarımcılar i¸cin internetten tasarım bilgisine eri¸sme fırsatları artmaktadır. Ancak bir¸cok internet arama motoru tasarımcıların, ¨ ozellikle tasarımın ilk safhalarındaki (analiz ve kavramsal tasarım) bilgi arama s¨ ure¸cleri ile uyumlu deˇgildir. Tasarımcıların tekrarlanan ıraksak ve yakınsak arama s¨ ure¸cleriyle tasarım bilgisi aramalarına kar¸sın bu internet arama motorları genelde bir kez bilgi arama s¨ ureci boyunca kullanım i¸cin ama¸clanmı¸stır. Ayrıca bu arama motorlarının erken safhalarda ta˙ olarak bu arasarım s¨ urecine tam anlamıyla uymamalarının iki nedeni vardır. Ilk ma motorları bilgi sorgusunda kullanılan her arama teriminin yansıttıˇgı gerekli olan bilginin olgun olduˇ gunu kabul eder, ancak tasarımın erken safhalarında kavramlar muˇglak, problemler iyi tanımlanmamı¸stır. Bu sebeple gerekli bilginin ken˙ disi bulunmalıdır. Ikinci olarak, sorgular birbirleriyle baˇglantılı olmadıˇgından ¸su anki mevcut arama motorlarının kullanımı tasarımcılara arama s¨ ureci boyunca olu¸sturulan baˇglamların i¸slenmesine ve yararlanılmasına fırsat vermez. Bunun yerine bu baˇglamlar ¨ ort¨ ul¨ ud¨ ur ve zihinde saklanır. Bu ara¸stırma çalı¸sması tasarım s¨ urecinin erken safhalarında tasarımcıya doˇgal gelen, ve bundan daha ¸cok tasarımcının d¨ u¸su ¨nce geli¸simini kapsayan bir arama sistemi geli¸stirmeyi ama¸clamı¸stır. Her arama teriminin tasarımcının d¨ u¸su ¨nme s¨ urecinin bir u un¨ u olduˇ gu varsayılarak yargılanmı¸s arama terimlerinin kaydedil¨r¨ me ihtimali tasarımcının her tasarım projesini baˇglamlar grubu i¸cinde d¨ u¸su ¨nme 7 Summary

in Turkish

163

164 yolunu kavrama olasılıklarını a¸cacaktır. Buna ilaveten ¸su anda tasarım pratiˇgindeki bilgi kullanım ¸cabası, ki buna bilgi nasıl toplanır, bilgi nasıl saklanır ve sunulur, ve bu nasıl kullanılır u ¨¸c ana sorusunu cevaplamaya yönelik ara¸stırma giri¸simleri de dahildir, genellilke zayıftır. Bir tasarımcı ¸sirketi terkettiˇginde sıklıkla ortaya ¸cıkan beyin g¨ o¸cu ger bilgi aramasıyla ilgili bilgi, s¨ ure¸c ve ¨ riskinin azaltılması, eˇ sonu¸clar olarak kaydedilebiliyorsa m¨ umk¨ und¨ ur. Bu ¸calı¸smaya ba¸slangı¸c literat¨ ur ara¸stırmasını e¸szamanlı birka¸c temel makaleyle tamamlamak u ¨zere, tasarımcılar ve uzmanlar arasındaki ileti¸simin kaydedildiˇgi önceki bir kavramsal tasarım ara¸c ara¸stırmasının deneysel verisi ¸calı¸sılarak ba¸slanmı¸stır. Bu ¸calı¸smada tasarımcıların aslında her sorgu baˇglamıyla ilgili, birikim ve uzmanlardan gelen bilgi olmak u ureciyle ba¸sa ¸cıkmak ¨zere, bilgi arama s¨ i¸cin birikim in¸sa ettikleri sonucuna varılabilir. Bu deneysel ¸calı¸sma ayrıca her tasarımcının kendi zımni bilgisine dayanan kendi bilgi arama yolu olduˇgunu bulmu¸stur. Ayrıca bu ¸calı¸smayla tasarım s¨ ure¸clerinin ve baˇglam bilgilerinin ilkeleri önerilmi¸stir. Bu arada yoˇ gun ve kapsamlı bir literat¨ ur ¸calısmasıyla ’baˇglam’ın anlamının yeniden in¸sası ve ¸ce¸sitli alanlardan ve uygulamalardan kavramı yapılmı¸stır. Bu literat¨ ur ¸calı¸sması baˇ glam teriminin k¨ ok¨ u bulunarak ve bazı pop¨ uler ve ¸cokca kullanılan s¨ ozl¨ uklerden ortak anlamlar toplanarak ba¸slatılmı¸stır. Bazı alanlarda baˇglamın tanımı birbirinin tam kar¸sıtı olsa da ve baˇglamın tanımında bir gör¨ u¸s birliˇgi olmasa da, bu literat¨ ur ¸calı¸sması farklı alanlardan ve uygulamalardan okuyucuların anlayacaˇ gı bir tanımın ortaya ¸cıkı¸sını göstermi¸stir. Baˇglamın bu tanımını yeniden in¸sa etmek i¸cin farklı yakla¸sımlar kullanılmı¸stır. Bu literat¨ ur ara¸stırması ayrıca baˇ glamın niteliklerini: nasıl te¸shis edileceˇgini, farklı öˇgretilerden ara¸stırmacıların bunu ve odak, ilinti, konular ve karar gibi diˇger baˇglamla ilintili kelimeleri nasıl i¸sleyeceˇ gini ve ele alacaˇgını belirginle¸stirmi¸stir. Bu literat¨ ur ara¸stırmasının sonucu olarak bu ¸calı¸smanın amacı olan baˇglamın tanımları o¨nerilmi¸s ve ara¸strıma problemi ifadesi yeniden g¨ ozden ge¸cirilmi¸stir. Bu ve gelecek literat¨ ur ¸calı¸smalarına dayanarak tasarımcıların internetten tasarım bilgisine ula¸smalarını destekleyen bir sistem kavramsalla¸stırılmı¸stır. Bu a¸samada baˇ glam terimi teknik olarak, tasarımcılar i¸cin anlamlı olan arama terimleri arasındaki ili¸ski olarak tanımlanmı¸stır. Sistem kavramla¸stırılmasında arama motorlarının tasarımcılar tarafından kullanılması tasarımcı-uzman sorularına ve cevaplarına benzerdir. Bu sistem kavramla¸stırması fonksiyonları ve bilgi tasarımını ifade etmek ve bunun mimarisini belirtmek i¸cin, Gane–Sarson’un veri akı¸s diyagram g¨ osterimini ve varlık ili¸ski diyagramını kullanmı¸stır. Sistem kavramla¸stırması sonu¸clarının rehberliˇginde aˇg-bazlı Baˇglamsal Tasarım Bilgisi Eri¸sim Sistemi (BTBES) – Contextual Design Information Retrieval System (CDIRS) – geli¸stirilmi¸s ve hayata ge¸cirilmi¸stir. Bu sistem tasarımın erken safhalarındaki arama motorlarının yararını arttırmak ve tasarım bilgisi aramalarındaki baˇ glamları a¸cık¸ca g¨ or¨ ul¨ ur, kaydedilebilir ve ta¸sınabilir yapmak i¸cin tasarımcılar ve arama motorlarını kesi¸stirir. Bu sistem ayrıca tasarımcının tasarım bilgisini arama yolunun doˇ gasına uymak u ¨zere geli¸stirimi¸stir. Dahili testler yapıldıktan sonra, bir tasarım projesinin erken safhalarında bil-

7 ¨ OZET

165

gi aramasının nasıl yapıldıˇ gını benzetmek u ¨zere sistem birka¸c davetli kullanıcı tarafından kullanıldı. Bu kullanıcılar g¨ ozlemlenerek baˇglam-kurma ve baˇglamkullanma örnekleri BTBES kullanılarak yapıldı. Akademik ve end¨ ustriyel tecr¨ ubesi olan uzmanlardan olu¸san bir deˇgerlendirme j¨ urisi kuruldu. Akademik uzmanların teorik olarak daha g¨ u¸cl¨ u, end¨ ustriyel uzmanların yeni ve pratik tasarım problemlerine daha a¸sina oldukları varsayımları yapıldı. J¨ uri u ÿelerinden BTBES sistemini ¸calı¸stırmalarını istemektense, sistem u u¸s ve ardındaki baˇglam ÿelere a¸cıklandı. Bu yolla sistem yetisi hakkında genel gör¨ teorisi elde edilebilecekti. BTBES uygulanırken baˇglamın olu¸sumunu ve kullanımını göstermek amacıyla iki tasarım ¨ orneˇ gi j¨ uriye gösterildi. Bu gösterim uzmanların BTBES’le ilgili (istek u ¨zerine) fikir vermelerine izin verecek ¸sekilde geli¸stirilmi¸s olmasına raˇgmen, uzmanlar sistemi uygulamalı olarak ara¸stırmacıyla yan yana tecr¨ ube ettiler. Son olarak, uzmanlar soru formunu doldurup fikirlerini vermeden önce BTBES’yi ger¸cek ve ¸simdiki tasarım problemleri i¸cin ¸calı¸stırmak istediler. Bu deˇgerlendirmenin sonucu olarak, BTBES’le hayata ge¸cirilen ’baˇglam’ kavramı u¸cu oneriyle kabul edildi ve tasarım görevlerinde ¸calı¸stıˇgı ispat önermesi birka¸c k¨ ¨k ¨ edildi.

Ringkasan8

® K@ ,AK@ X Qå éÊÓñ m. Y ¯ AÜ ßð @ QK , áK A X ð Q ¯ ÕË@ X á »AKñ »X , à @ñëA Jª ¯ à@ X , ú æ AÓPñ . å QJ K A X @PA ¯ @ñê K á ºJJ»ñJ ÜØ ñËñë XQ K à AJJÊJ ¯ ,ú¯ AJK á » @ . áK A X È ð @ úæ A¯ ¸ YJ K ¨Q . .

, AK@ X àñ¯ñËð , H@ðAm. á«X ú æ ñº X Y¯ á»P@ YJJÓ éJ J. Ë à@ X , áK @ ú æ AÓPñ®K@ áºJ Ë ð XQ®ÜØ ® K@ .A¿QÓ ©Ê J Ê¾ ø X AK Y QK á K @ à @ñëA Jª ¯ à@ X , ú æ AÓPñ , @ YJ K. QK. © K ¨ YJ K. ø P X © K@ X à@ X , J k. , à Pñ »ð @ ÕË@ X @ YJ K. QK. ©J ®ÖÞ X á J Ë ñ»

® K@ , AK@ X ø A¿AÜ Ø àA Ü ß A¾ K ñJK @ AK ºJJ » à @ XA JJ» AKP A¿ éË@ X @ A¿QÓ á º K A® J Ü Ø à@ X , úæ AÓPñ .

Q àAÓX , I K JK @ @P@ ø X .ñJK QK áK A X ð Q ¯ ÕË@ XX QK. © K ºJJ » ÕË@ X à @ñëA Jª ¯ ® K@ ÉJÓAªÓ J ú æ AÓPñ . ¸ñJKð @ Q J K A X Y®» ¨ ñ Ê¯ ¸ñJ.ÜØ éÊK , éJ.ÓAKQK. ð Q K áñ èCÓñk. K QJK @ ø QjJ ¯ á Ó á ºJJ. » , ú¯ AJK á » @ . I K QJK @ ø P X áK A X á «X ¸ñmk ¸ YJ K I

à@ X Ë AK @ úæ A¯) Q áK A X È ð @ ú æ A¯ ø X áññë . JK A X áK AK QjJ¯ ð Q¯ » K QJK @ ø Qj J ¯ á Ó .(úæ AË @ñ J ® ð Q ¯ èAJ . ÕË@ X ú ¾¯ ú Í A¾ á »ñJKð Q ¯ X á K @ I

Q èAJ. ÕË@ X ©Ëð @ - ©Ëð @ QK. ú æ AÓPñ®K@ ø QjJÓ J K A X ÈAë Y¯ ,ú æ AÓPñ®K@ à AK QjJ¯ á K @ ø Qj J ¯ á Ó , ÐA K - ÐA K Q¯ . I ® ÒJÓ ðAK @ Q. ÊÓ © K à AK Qj J ¯ ð Q ¯ á ºÓñA ªÓ ø X ÈAë Y¯ , ©KAÓ éÊK éË@ X @ ú m' ñ» HA¿ ÕË@ X á ºÊJ » @ðQK © K á »ñËQ¯ X © K ú æ AÓPñ®K@ @ñêK. » @ñÖ Þ ,È ð @ úæ A¯ . ¸@ AK. á«X àA¾J JJ ¯ YK X ¸ YJ K á ËAQ ¯ @ñÖ Þ à X Cg. ¸ YJ K

8 Summary in Indonesian and written in Jawi/old Malay. This ancient Indonesian and Malaysian script was disappeared from Indonesian society during the Nederlandsche Oost-Indische occupation, while it has still been taught and used limitedly in Malaysia nowadays.

167

168

ß ® K@ , àA KP A¿ J . QK á »ñ ë © K ¹J K. ñ éË@ X @ Hñ àQ » , @ ð Y » . á »ñ Ü X ð PA ËQ ¯ X © K ú æ A ÓPñ

Y®» ¨@ ñÊ ¯ ø QÜØ ¸ YJ K á K @ ø Qj J ¯ á Ó à AKñ ºª¯ , ¨ñK. ñëQK ¸ YJ K áK @ à AK QjJ¯

. àñ ºJJ » , á ìÛ AÓ . à AK Qj J ¯ ð Q ¯ AÓC «AK. QK © K ºJJ» á ºK A®JÜ Ø ¸ñJKð @ Q JK A X QK à@ X H Q QK IK . à Q ºJ ¯ X á ®ÒJ

@ ºJJ » ø ñ «A J. ÜØ ¸ñJ Kð @ á »ñ © K Õæ àñ Q J K A X Ag. Q» @PA g á «X k. ñKX áK @ à AJ J ÊJ¯

@ ø P X éJ J.Ë ú¯ AK , áK A X ð Q ¯ È ð @ ø X Q ºJ ¯ QK. úæ ñËñ®K @ ÕºK QÓ ¸ñJ Kð @ , IK

Q ¿ J @ñê K º ª ªÓ » , QJ K A X Qº¯ éË @ Éë éË X @ úm' ñ» HA á ®Ò

. á«X . JK A X

' Qº¯ QK. á ËAg. ÕºK QÓ ¸ñJKð @ ¨ ñ Ê¯ ¸ñJ . ÜØ á » @ I ® K º«@X © K ú m ñ» HA¿ ÕºK QÓ , IK @ ø P X éJ J. Ë .ºJJ» - ºJJ» áËñ®Óñ» ø A¿AJ. áK A X ¹J K ð Q¯ ¬A K ø X Q J K A X » éJ AÓ áK A X ø X à @ñëA Jª ¯ á º K A® J Ü Ø Aê ð @ , á K @ ¨@ PA ¾ à AJ J ÊJ ¯ ¸ñA ÓQ K , ¨ Pñ

Ó àA Ü ß A¾ K , á ºËñ à@ X á ®ÒJ ®ÓñªÓ àAÜß A¾K. , IK @ AK , Qå. áË @ñQ¯ ¹J K H. @ñj.JÓ ¸ñJKð @ . Ó èCKA«A . àPñ J ªÓ àA Ü ß A¾ K. à@ X , á ºÊJ á º«ñ ªÓ © K brain drain ñºJ P ú « @Pñ

®ÒJÓ A CJ K. ø X Ag. QK AA J K. ÉJ Aë ¹K @ AK. , ¹k. , à @AëA ð Q ¯ è @ñJ . ø P X P@ñ Ê¿ Q J K A X ¨ Pð ¯ð AÓ à AK Qj J ¯ X I ¯@ X á K P Aj J ¯ ð Q ¯ àñ . á®ÒJ

Q Q ÉKPñk. ¬ . K. Y®» AK. QK È@ð @ PñK@ J Ë ø X ñJ à @AÓAQK. @PAm áºJ ÊJÓ ¸ñJKð @ »ñ BñÓX ¨ñ J¯ à AJ J ÊJ¯ èAJ. ø P X Q ® Ó@ AK@ X ø Qk. C® ÜØ á «X á K @ à AJ J ÊJ¯ , ©J J¯ , á K @ à AJ J ÊJ ¯ ø P X .ÐA¾K P X úÎë @ à@ X Q J K A X PA JK @ ú æ A¾J K ñÓñ » àAÓX , áK A X È@ñJ ñ »

@ AK , úæ AÓPñ ® K@ ø P Aj JÓ ¹J J» ºJJ » àñ JÜØ QJ K A X @ñê K á ºËñ X IK «A ®ÒJ X I ¯@

. .

Q á»ñÒJÓ A¿ñk. áK @ ®Ó@ ø X ñJ . úÎë @ ø P X áK. @ðAg. à@ X à @AK AKQ¯ ¬ AJ K ø P X ºJJ »

® K@ á º J¯@ Y JÓ ¸ñJ Kð @ ø QK YJ Ø QJ K A X ¬ AJ @ñê K - ø Q K YJ á ËAg. úG AK ñ®Ü © K úæ AÓPñ

.

J J »Q ©JK à @ñëAJª¯ à X áK A X ð Q ¯ , á K @ ø X ñJ ÕË@ X A¿ñk . . ¹K QÓ à @ñëA Jª ¯ Y ¯ ¨ñ K . áºJ BñÓPñ¯X ºJJ » Q @ PA JJÖ Þ ºJJ » » à@ X ú G P @ , J JK @ ©K PñK@ J Ë ø X ñJ ÕË@ X , IK Q á»ñÒJÓ ø P X BñÓX áK @ PñK@ J Ë ø X ñJ .ú æ A¾Ê¯ @ à@ X ¨@ YK. ú ¾K. QK. P X ú æ»ð QñºK P X ¸ YJ K àñ » I ¯@ XX ¯ B @ð .QÊ® ¯ © K ñÓA ¿ ¬Q .K. ø P X ºJJ » AJº á » A® Ó à@ X HA¿ Q» @

RINGKASAN8

169

ø X ñJ , ¨ YJ K. A¿ AK. QK. X áK B ÐA ñKA á «A J K QK. ©J Ë A I ¯@ X á K P @ àA ÓX ,ºJJ» ú æJ J ¯ X à@ X ¨@ YK . ú ¾K. QK. ø P X h AJ. Ô¯ éJ Ë ð @ ú G Qª Ó X I ¯@ X © K ºJJ » ú G P @ º«ñ ªÓ áK @ PñK@Q J Ë á K @ PñK@Q JË ø X ñJ . á »AJ »X éÊK á »YJ ¯ ú ¾K. QK. , á K @ AJº Ó ú æ»ð Q ñ ºK QÓ ¹JKð @ . A¾Ê¯ @ éÊK A ¿ñk . ú æ «A KX A K @ àA Ü ß A¾K. , úÎJ» X AK @ àA Ü ß A¾K. ºJJ » ¹J Q»@PA ¿ á ºËAJ QºªÓ á ú G Q® ºJJ » á «X K @ A¿QK. ©K áK B HA¿ ú ¾K. QK. à@ X , ¨@ YK. ú ¾K. QK. X ú æJ ÊJ¯ @PA ¯ éJ Ë ð @ ú æJ J ¯ X , á K @ PñK@Q J Ë ø X ñJ ÉJ Aë ñKA éËA . á êJ ÊJ ¯ à@ X ,¹J ¯ ñK , à@ ñJ ÊK P ,ñº¯ . ù ë AJK . X éÊK ú æ J ÊK X © K á ê Ê ÓQ ¯ à@ X á K @ ú æ J ÊJ ¯ ú » AK. á »ñk . @X éÊK ºJJ » Q »ð J J J . , á Kñ Q J K A X ¨ñ ø P X à@ X á K @ ø X ñ K@ J Ë ø X ñ J Ë Pñ j Y JÓ © K Õ æ è@ ñ

.

Q á ºJ K P@X ºJJ » , á K @ ¬A ê K Y ¯ .ú æ AË @ñ J® »X éÊK I K JK @ ø P X ú æ AÓPñ®K@ ÉJ J. ÒªÓ ¿ @PAJK @ á«ñK. ñë ú ¾J. , Õæ à AJ AË @ñ J® ºª¯ ø X . Q JK A X ú ¾K. AJºÓQK. © K ú m' ñ» HA á ºJ K á «X à@ X Q J K A X @PA JK @ H. @ñ k. àA »ñËAJKX ,Q JK A X éJ Ë ð @ ø QjJ¯ á Ó à @AKñºª ¯ » . úÎë @ º ªÓ á K @ Õæ úæ AË @ñ J ® Gane-Sarson’s Data Flow Ð@Q »AK X úæñK á »AKñ

' AKQå ú æ AÓPñ®K@ à@ X ú æ«ñ¯ áK A X á»ñm. ñJÓ ¸ñJKð @ Entity Relationship à@ X Jº J P @ . àPñ á»AÓAKX ©K Õæ è@ñJ. , H ñK. X ©K Õæ » Y®» á »Qå@ XQK. «A K. X éÊK Contextual Design Information Retrieval System (CDIRS) à@ X àñ à @AKñº» áºJºªJ JÓ ¸ñJKð @ ø Qj J ¯ á Ó à@ X Q J K A X PA JK @ ú æ JJ. Òj. JÓ AK @ . á ºJ AJJ ÒÊ®Ö ß @ X Ó ºJJ » H ñ J ÜØ A ¿ñk , áK A X È ð @ úæ A¯ ø X ø Qj J ¯ á Ó , á ºÊJ ® ÖßX ¸ñJKð @ á º«ñ . .

© K ú æ AÓPñ® K@ à AK QjJ ¯ @PA g ù ë ñJÜ Ø áK A X X A¿ñk . á K @ Õæ .Õç' Q »X ðAK @ ,ÕºK P X KA K . Q J K A X ú » AK. È@Pñ ¸ñJKð @ AKñ ºª ¯ ¬Q . K. éJ Ë ð @ á »AKñ »X á K @ Õæ , ÉK QK@ á »ñ»B X éÊJ ® K@ @PA g àA Ü ß A¾ K á ºJ . áK A X ¹JK ð Q ¯ èAJ È ð @ úæ A¯ ø X ø Qk X úæ AÓPñ á «X . .

BñÒJ Ó

á «X HAK. X ºJJ » à @AKñ ºª ¯ à@ X á Kñ «A J. Ô¯ á ºJ. J ÊÓ © K ñA ¿ @ð X , á K @ AKñ ºª ¯ ú G AÓA ªÓ . CDIRS á »AKñ ºªÓ

170

Öß X A¿@ ÁJ »CK. QKB á ÂKX úÎë@ @PA K ø P X ø QK X QK ÁJ K ,ú æ @ñ ËA®K @ ÉK AK èAJ . éJ J. Ë ú æK P ð AJ K ú æJ Öß X A¿@ á ÂKB A¿ ø P X úÎë@ ú æJ Óñ @ .¼ñJK . X ø Qð Y JK @ à@ X Q áºñ KñK X . áK A X J»QK ñ@ ñëAK éJ J. Ë ø ð YJK @ ø P X A¿QÓ IK

@ PAJJÖÞ , H@ñ» , á K @ @PA g á ÂKX . úGA ¾Ü Ø A¿QÓ AJJ ÜØ ÁJ JÒJJ» , CDIRS á »ñÜ ß YJÓ ¼ñJ Kð @ à@ ñJ ÒÒ» . áK A X ñA ¿ @ð X . á »ñm.' ñKX I K @ X ú æÂJ» CK. ø X ºJJ» ø P ð AK à@ X Õæ ' Â KA K. X ºJJ » ÕæÂ K. á »ñ á ÂKX ø A¾K X à@ X àñ m. ñJÓ ¼ñJKð @ , ÉK AK YJ» á»ñÜß X X

K ðB @ð . CDIRS ¼ñJKð @ á ºJJ ºÂKñ Ü Ø úÎë@ @PA K QÃ@ áK A X X á K @ ñÜ ß X àñ Q JJ Ó QK á Â KX , A¿QÓ úæ J K ð @ á ºK .ú æJ ÊJK AÓAQK. ú GA¾ÜØ IK @ X úÎë@ @PA K , à@A

. ÜØ

á ÂKX A¿QÓ ú æ J K ð @ á ºK Q. ÜØ ÐñÊJ. AJ K ñA ¿ á ºJ @QK ñÂJÓ úÎë@ @PA K , ú G Q ê» @

IJ ºK Y á Â KX ,@ñî E. á ºËñ JÒJ X IK X áK @ ú æ @ñËA®K @ ø P X . à@AJ KAKQK Q¯ X ú æJ ÂJÓ I K @ X CDIRS ÕË@ X á ºJ AJJ ÒÊJÖß @ X à@ X á »ñk . AKX ÁJK ºJJ» I» , à PA à X ½K @ AK á ÂKX AÜ ß QK X ® J ÓQK . áK A X X H@A

. . ºJJ »=konteks

1

Committee Members’ Profile

Prof. dr. Petra Badke-Schaub is a psychologist and full professor of design theory and methodology at Faculty of Industrial Design Engineering, Delft University of Technology. Prior to hold this chair, she was a senior lecturer and researcher at Institute of Theoretical Psychology, Otto-Friedrich-Universit¨ at Bamberg, Germany.

Dr. Joris S. M. Vergeest is an expert in Computer Aided Design, an associate professor and a leader of Dynash (Dynamic Shape Advancement) research group at Department Design Engineering, Faculty of Industrial Design Engineering, Delft University of Technology. One of his main research interest is shape context.

Prof. Dr. Hannu Jaakkola is a full professor of information technology at Tampere University of Technology (Pori), Finland where he is also appointed as Director of Pori Doctor School and a permanent steering committee of European Japanese Conference on Information Modelling and Knowledge Bases. 171

172

Prof. Dr. Yasushi Kiyoki is a full professor of multi database and multimedia database at Faculty of Environmental Information Department of Environmental Information, Keio University, Japan.

Prof. dr. ir. Mehmet Aksit is a full professor at the Department of Computer Science, University of Twente and affiliated with the institute Centre for Telematics and Information Technology. He is the head of the Software Engineering chair and the leader of the Twente Research and Education on Software Engineering (TRESE) Group.

Prof. dr. Paul P. M. Hekkert is a full professor of form theory and head of Design Aesthetics Department at Faculty of Industrial Design Engineering, Delft University of Technology. His ”context”definition in ”Vision in Product”(ViP) attracted and triggered many researchers in industrial design to explore the field of context. Prof. dr. Pieter Jan Stappers is a full professor of design techniques at Faculty of Industrial Design Engineering, Delft University of Technology. His interests focus on developing techniques and tools that support designers (and other creative people) in early phases of idea and concept development. He and his colleagues in Design Studio Lab, are developing the theory of ”contextmapping”.

Prof. ir. Daan van Eijk is a full professor of applied ergonomics and a practicer of consultancy for product development and innovation in Netherlands. He is also a member of the Dutch platform for product development (Nederlands Platform Productontwikkeling - NPP).

Vitae

Muhammad Ikhwan ’Iwan’ Jambak was born in Palembang, Indonesia on September 08, 1969. He finished secondary school in 1988, and studied Chemical Engineering at Sriwijaya University. Despite doing research in chemical labs as traditionally has been done by other students, he did a computer simulation of level control for his research that became the first ever chemical engineering research at the faculty using computers in the early 90’s. He graduated with his Bachelor of Engineering degree in 1993. Thereafter, he became a computer programmer in industry for several years before he went to Malaysia to finish his Master’s of Engineering in the field of Computer Integrated Manufacturing (CIM) at the Faculty of Mechanical Engineering, Malaysia University of Technology. During this period, he was awarded as a junior researcher for the CIM project under a Malaysian government grant. While he was finishing his master’s thesis, he presented his research work and was accepted as a PhD student (in Dutch: Assistent in Opleiding or AIO) at the Faculty of Industrial Design Engineering, Delft University of Technology in March 2000. In October 2000 he became a member of the Integrated Conceptual Advancement (ICA) project. He was assigned to explore new kinds of modeling entities called the nucleus. In mid 2002, he moved and focused more on contextual design information retrieval in the early phase of design. Prior to the defense of this thesis, he was invited to be a member of the special interest group, ”Design Creativity” for the Design Society.

173

Appendix A –f-file Session 19

13:08:25 a[]0 activity (start_of_assignment;;) # the activities are renamed to studying the assignment 13:09:40 a[1]1 activity ("studying the assignment"; marking the assignment on page 1) 13:12:35 a[1]1 activity ("studying the assignment"; marking the assignment on page 2) # the activity is renamed to making notes on the assignment 13:13:00 a[1]1 activity ("making notes on the assignment"; making notes about the requirements; 42) # sample 1 # the request following this activity indicates an information # collection, the activity is therefore placed before the ri[]1 and # its time is changed to that of ri[]1, the description is shortened 13:13:30 a[1]3 activity ("collecting technical information"; collecting information on the technical environment) 13:13:30 ri[]1 request (what are the different types of rear-wheels on which the generator has to fit, how are they integrated in their environment, how does the internal of the hub look like such as chain gear-case, overcoat guard, pedal brake, calliper brake and drum brake) # end sample 1 # this activity which occurs more than once is named sketching rear # axle area 13:15:00 a[1]4 activity ("sketching rear axle area"; sketching; 42 centre) # this answer comes when s is in an activity that is another than the # one in which the request was raised 13:15:30 ii[1]1 answer information sheet ’hub’; 1) # s goes back to a[]3 this activity swap is inserted 13:15:45 a[2]3 activity ("collecting technical information") 13:15:45 ri[]2 request (does the bicycle has a drum brake) 13:15:45 ii[]2 answer (a drum brake and a five speed gear hub) 13:15:45 a[2]1 activity ("making notes on the assignment"; writing down these data; 42) 13:16:00 a[3]3 activity ("collecting technical information"; reading sheet ’hub’; 1) 13:16:25 a[3]1 activity ("studying the assignment"; reading the assignment) 13:16:35 a[3]1 activity ("studying the assignment"; reading the assignment) # this answer comes when s is in an activity that is another than the one in which the request was raised 13:16:40 ii[2]1 answer (the rear wheel has a diameter of 26 or 28 inch; 42) # the request following this activity indicates s is investing the # drive aspects a[1]7 is placed in front of ri[]3 and time is changed # accordingly also the name into investigate how to drive the # generator 13:17:00 a[1]7 activity ("investigate how to drive the generator"; looking for a turning and non turning part near the hub; 42) 13:17:00 ri[]3 request (is it allowed to change the cup around the hub) 13:17:00 ii[]3 answer (no it is not allowed to change the cup) # sample 2 13:18:30 a[1]7 activity ("investigate how to drive the generator"; considering an alternative outside axle) 13:18:45 io[]1 result (the use of inertia is not a reasonable alternative) 13:19:30 ri[]4 request (is it allowed to construct outside the hub, on the axle or on the driving cup) 13:19:30 ii[]4 answer (yes it is allowed to construct outside the hub) # end sample 2 13:20:00 io[]2 result (i continue with this solution that is, outside the hub) 13:20:25 a[2]4 activity ("sketching rear axle area"; sketching rear axle section; 42 bottom) 13:22:00 a[2]4 activity ("sketching rear axle area"; marking eventual position in red; 42) # a[1]10 belongs to the start of an investigation of loaction, the name is changed 13:23:20 a[1]10 activity ("investigate the locations"; get new page 43) # sample 3 # both activities following are the same

9 complete

sessions documentation in van Breemen, 1996

175

176

APPENDIX

13:23:30 a[1]10 activity ("investigate the locations") 13:23:30 a[1]10 activity ("investigate the locations"; write down requirements for location: must not hinder and must not get damaged; 43 top) 13:24:00 ri[]5 request (construction of current available generators: types, power, torque, number of revolutions) # end sample 3 # sketching is done to investigate locations, thus a[1]13 changes into # a[4]10 13:24:45 a[1]10 activity ("investigate the locations"; sketching rear axle area; 43 centre) 13:25:00 ii[]5 answer (information sheet ’generator section’; 2) 13:26:00 ri[]6 request (what are these black bodies; 2) 13:26:00ii[]6 answer (these are the coil and the magnet) 3:27:00 io[]3 result (so a magnet, coil and soft iron are the parts) # a[2]10 is changed to a[1]100 which is an investigation of product requirements, a[1]100 is swapped with ri[]7 because this request belongs to this new activity 13:27:30 a[1]100 13:27:30 ri[]7 13:27:30 ii[]7 13:27:40a[1]100 13:28:00 ri[]8 13:28:00 ii[]8 13:28:15 a[1]100 13:28:30 io[]4

activity ("write down requirements"; takes new sheet; 44) request (requirements for magnet/coil, use of existing types) answer (no req’s, free to choose) activity ("write down requirements"; writing down these data; 44) request (use of existing parts because of price considerations) answer (no, price must be in relation with target consumer group) activity ("write down requirements"; writing down these data; 44) result (i will not count with technical constraints because of unknown target consumer group and production quantity) # activity is done to investigate the location for the generator changed # to a[]10 13:28:30 a[2]10 activity ("investigate the locations"; hatching a sector in the sketch of the rear axle area; 43) # sample 4 # still looking for a location to place the generator 13:29:00 a[2]10 activity ("investigate the locations"; placement of the generator, first choice between alternatives, deciding which alternatives already can be dropped) # end sample 4 13:30:00 a[2]10 13:31:30 a[2]7

activity ("investigate the locations"; sketching 43, black) third occurence of a[]7 activity ("investigate how to drive the generator"; looking for turning and non-turning parts, turning: hub, non-turning: axle, brake arm, luggage carrier; 43 bottom) 13:31:30 io[]5 result (no construction on the hub) 13:33:00io[]6 result (placement generator on stand for the luggage carrier and horizontal extension of the frame) 13:33:15 io[]7 result (this part is best fit; 43 red hatched sector) 13:33:30 io[]8 result (ring on the spokes, driving the generator; 44) 13:35:00 io[]9 result (alternative is driving the generator via the chain) # two alternatives are found for locating the generator, this is written down 13:35:15 a[3]10 activity ("investigate the locations"; writing down this result) # sample 5 # from now the two concepts are evaluated 13:35:30 a[1]17 activity ("chosing one of two concepts"; investigate chances of spoke versus chain drive alternatives) # end sample 5 # activity continues 13:36:30 a[1]17 activity ("chosing one of two concepts"; sketching chain wheel etc.; 45) 13:37:30 ri[]9 request (sizes of chain guard) 13:37:30 ri[]10 request (distance crank to rear hub) activity continues 13:38:15a[1]17 activity ("chosing one of two concepts"; sketching; 45) 13:38:40 ii[1]10 answer (information sheet ’chain line’ to derive distance crank to rear hub, no sizes available; 3) # sample 6 13:39:00 a[1]17 activity ("chosing one of two concepts"; chosing one of two concepts) 13:39:30 io[]10 result (ring on spokes requires an extra part and a means to transfer the moment) # end sample 6 13:40:15 ii[2]10 answer (distance crank to rear hub is 46 cm) # s is starting to collect information on the geometry of the frame, wheels and chain drive 13:40:20 a[4]3 13:40:30 ri[]11 13:41:15 13:41:30 13:41:30 13:41:30 13:42:00 13:42:00

io[]11 ii[]11 ri[]12 ii[]12 ri[]13 ii[]13

13:42:30 a[1]20 13:43:00 io[]12

13:43:20 a[1]20 13:44:00 ri[]14 # sample 7

activity ("collecting technical information"; writing down these data; 45 top) request (picture of the whole bicycle) # in fact this result belongs to a[]17 but s is already in a new activity result (choose driving the generator via the chain, looks to have best chance) answer (information sheet ’bicycle’; 4) request (is 46 cm belonging to a wheel size of 26 or 28 inch) answer (it belongs to wheel size of 28 inch) request (is the size much smaller when a 26 inch wheel in used) answer (no, it is not much smaller) # s starts sketching to visualize the collected information, activity renamed activity ("sketching frame geometry"; drawing along the ruler the crunk-hub line; 46) result (the size for a 26 inch wheel is chosen at 44 cm by me, if the dynamo fits there, it fits also on a 28 inch wheeled bicycle; 45 top) activity renamed activity ("sketching frame geometry"; drawing vertical lines with pencil; likely 46) request (diameter of chain wheels)

# activity renamed 13:44:30 a[1]20 13:44:30 ri[]15 13:45:00 ii[1]15

activity ("sketching frame geometry"; sketching the frame on a scale 1:2; 46) request (sizes of chain wheels, h/b ratio of chain, stitch of chain, diameter of chain rollers, more accurate sizes of the frame: diameters of tubes in the frame) answer (information sheet ’frame’, with sizes; 5)

APPENDIX A –F-FILE SESSION 19

177

# end sample 7 # s traces the drawing to another page so continuing to sketch the # geometry 13:46:30 a[1]20 activity ("sketching frame geometry"; tracing; 46 to another sheet) 13:47:00 a[1]20 activity ("sketching frame geometry"; getting new paper; 47) 13:49:00 ii[2]15 answer (dimensions of the chain, distance between the links; 47 top) 13:50:00 ii[3]15 answer (the chain line distance is between 40 and 45 mm; 47 top) # sample 8 # s is again looking at the location of the generator although he # first decided to drive via the chain, io[]11, he iterates 13:50:30 a[4]10 # end sample 8

activity ("investigate the locations"; investigating why generator can not be placed on front wheel)

13:52:00 io[]13

result (placement on front wheel has the same objections as earlier alternative for the rear wheel: requires ring on spokes or driving wheel on tire. tire pressure varies and continuous use will cause wear. a ring on spokes is a big extra part, together with a big, busy thing in your wheel. the axle cannot be used, because it stands still) # part of these data can be found on page 48 13:53:30 io[]14 result (generator must be build into the axle during manufacturing; 48?) 13:54:00 io[]15 result (this is not possible due to universal application of product; 48?) 13:55:00 io[]16 result (the chain and gearwheel alternative holds) # sample 9 13:55:15 a[1]23 activity ("investigate the parts of the generator assembly") # end sample 9 # design activity []23 continues 13:55:30 a[1]23 activity ("investigate the parts of the generator assembly"; getting refreshment) 13:56:30 ri[]16 request (is a chain guard assembled on the bicycle) 13:56:30 ii[]16 answer (yes, a chain guard is assembled) 13:57:00 ri[]17 request (detailed information of the driving gearwheel) # s is back to a[]20 and sketches geometry while continue to aks for information 13:57:30 a[2]20 activity ("sketching frame geometry"; sketching) 13:58:00 ii[]17 answer (picture of a driving gearwheel from h.goes, fietsonderhoud; 6) # renaming the activity 13:58:15 # sample 13:58:30 13:58:30

a[2]20 10 a[1]25 ri[]18

activity ("sketching frame geometry"; sketching) activity ("investigating space around the crank assembly"; investigating space around the crank assembly) request (side information of the bicycle)

# end sample 10 13:59:30 ri[]19 request (information on room for gearwheel, guard and crank specifically) # s browses a book for technical information, a[]3 continues 14:00:00 a[5]3 activity ("collecting technical information"; leafing through book, searching for pictures of cranks) 14:00:30 ri[]20 request (is there no second blade at the crank) 14:00:30 io[]17 result (there is a hub gear, so i assume not) 14:00:30 ii[]20 answer (indeed) 14:01:00 ii[]18 answer (pp 108/109 give an impression of bars and available space) # sketching again 14:01:30 a[3]20 activity ("sketching frame geometry"; sketching a 3D view of the crank area; 49) 14:02:00 ri[]21 request (does the bicycle has a stand) 14:02:00ii[]21 answer (yes) 14:02:15 ri[]22 request (is this assembled in between both bars) 14:02:15 ii[]22 answer (yes) # renumber activity 14:02:30 a[3]20 activity ("sketching frame geometry"; sketching stand, rear wheel with spokes, saddle tube; 49) # sample 11 # this activity indicates that s is looking for locations for the generator again, renamed and renumbered accordingly 14:03:30 a[5]10 activity ("investigate the locations"; situating the generator plus driving mechanism) 14:03:30 ri[]23 request (minimal distance between the wheel and frame tube which holds the saddle) # end sample 11 14:03:30 ii[]23

answer (no direct figures, but can be calculated from wheel diameter, distance crank-axle and angle of the saddle tube) 14:05:00 a[1]30 activity ("calculating frame sizes"; calculating frame sizes) 14:05:30 io[]18 result (wheel diameter is 116 cm, 12.42 cm is left) 14:06:00 ri[]24 request (is 28 inch the size of the rim or with pumped up tire) 14:07:00 ii[]24 answer (the ouside diameter including the pumped up tire) 14:07:30 ri[]25 request (does i have the same space in the frame with a 26 inch wheel) 14:07:30 ii[]25 answer (yes the same space with a 26 inch wheel) # s starts sketching again 14:08:00 a[4]20 activity ("sketching frame geometry"; rubbing out and drawing with pencil; 46 likely) # sample 12 # activity continues 14:08:30 a[4]20 # end sample 12 #14:09:00 14:09:30 io[]19 14:09:30 a[6]10 14:11:20 io[]20 14:11:20 ii[3]10

activity ("sketching frame geometry"; drawing to see the space between rear wheel and frame; 49) remember the red page result (definitely choose the rear wheel) # this activity comes down to investigate the location of the generator # due to the information items that follow, activity renamed activity ("investigate the locations"; investigating place of the generator and way to drive it: rear chain wheel, front chain wheel or chain) result (distance between outside tire and frame: calculated wheel radius exceeds the distance between crank and hub!) answer (the distance between crank and hub is correct)

178

APPENDIX

# activity renamed 14:11:30 a[2]30 activity ("calculating frame sizes"; re-calculating) 14:12:00 io[]21 result (solved: about 10 cm is left; 45 top left) 14:12:20 ri[]26 request (i can not read the angle of the frame tube, i have to make a guess: 49 still) 14:12:45 ri[]27 request (did i ask for the radii of the gearwheels) # sample 13 # s is again asking the same information as in ri[]14 14:13:30 ri[]28 request (radii of the gearwheels) # activity renamed 14:13:30 a[7]10 activity ("investigate the locations"; still investigating space) # end sample 13 # waiting belongs to a[]10, renamed, renumbered 14:15:00 a[7]10 activity ("investigate the locations"; waiting for answers) 14:16:30 ii[]14 answer (rear gear wheel diameter is 105 mm, front gear wheel diameter is not known) # data is written down for a[]10 14:17:30 a[7]10 activity ("investigate the locations"; writing down these data; 45 mid) 14:18:00 a[5]20 activity ("sketching frame geometry"; drawing with compasses; 46 likely) # sample 14 # this is a continuation of a[]25 14:18:30 a[2]25 activity ("investigating space around the crank assembly"; investigating where around the crank there is space) 14:18:30 ri[]29 request (detailed information about diameters of frame tubes and crank, and radius of front gear wheel) # end sample 14 14:19:40 io[]22 result (use a global size for diameter of front gear wheel) 14:20:00 a[6]20 activity ("sketching frame geometry"; sketching the area of chain and axles; 46 red, likely) # activity renamed because here s starts to write down results as asked for in the assignment 14:20:00 a[1]33 # sample 15

activity ("writing down results"; writing down why some alternatives fail; 48 likely)

# a decision is made to place the generator, a[]10 continues 14:23:30 a[8]10 activity ("investigate the locations"; decide where the generator will be placed, one concept only is worked out) 14:23:40 io[]23 result (in a normal design assignment 3 concepts are worked out, but now only one, so i must determine which one has the best changes) # end sample 15 14:26:00 ri[]30 14:27:00 ii[]30 14:27:00 ri[]31 14:27:00 ii[]31 14:27:30 ri[]32 14:27:30 ii[]32 14:27:50 ri[]33 14:28:00 a[6]3 # a[]3 continues

request (form of the driving gear wheel) answer (form of a normal chain wheel in a picture of the book) request (can i use this form for the generator driving wheel) answer (the form depends on the links of the chain) request (are they standard) answer (yes) request (picture of the crank) # s uses the book again, a[]3 activity ("collecting technical information"; browsing through book, looking for picture of the crank)

14:28:45 a[6]3 activity ("collecting technical information"; using the index in the book) # sample 16 # this is an a[]10 activity 14:29:45 a[9]10

activity ("investigate the locations"; choosing position of the generator: between both gear wheels or next to the main gear wheel)

# end sample 16 14:31:30 14:32:40 14:33:30 14:34:15 # sample

ri[]34 ii[]34 ri[]35 io[]24 17

request (distance related to crank, which picture did i see) answer (picture is found) request (required space around the crank) result (i assume the dynamo can be made flatter, till 3 or 4 cm, and i assume that it fits in between)

14:35:00 io[]25 result (decide drive is via the main gear wheel) # this is an a[]10 activity 14:35:00 a[9]10 activity ("investigate the locations"; looking for place for the generator) # end sample 17 # at 14:36:30 the subject is thinking aloud questioning himself where to place the generator and asks about problems with gear wheel, the tension of the chain and the transmission 14:36:30 io[]26 # sample 18 # this 14:38:30 a[9]10 14:38:30 ri[]36 14:38:30 ri[]37 # end sample 18

result (best position of cam wheel is behind the front gear wheel. best position of generator is behind saddle tube. The chain moves and stretches, the gear wheel is more stable) is an a[]10 activity activity ("investigate the locations"; looking for place for the generator) request (sizes that i still do not have) request (sizes of the chain guard)

14:39:00 io[]27 result (integrating the generator in the chain guard would be beautiful) 14:40:00 ii[]37 answer (instruction how to derive sizes from the picture of the chain guard in the book, fig. 103; 9) # calculating activity []30 14:41:00 a[3]30 activity ("calculating frame sizes"; determine sizes from the ratios out of the picture, calculation; 21) 14:43:00 io[]28 result (enough space for the generator to put in between) # sample 19 # this is a continuation of a[]23 14:43:30 a[2]23 activity ("investigate the parts of the generator assembly"; listing the components of the product) 14:43:30 io[]29 result (assumptions: measurements do not cause restrictions, thickness will do, accu and electronics


14:43:30 io[]30

179

will fit in, no space limits; 12) result (assumption: dynamo can be flat enough)

# end sample 19 # 14:45:00 E1 reminds S to red page # s starts to sketch the product 14:45:30 a[1]36 activity ("sketching generator"; sketching on A3 page; 13) # sketching generator a[]36 continues 14:46:00 a[1]36 14:47:00 io[]31

activity ("sketching generator"; sketching on previous page; 12) result (components are battery, electronics, generator and possibly transmission between gear wheel and generator; 12) activity ("sketching generator"; drawing driving wheel in sketch; 13) request (what was the outer diameter of the generator)

14:47:25 a[1]36 14:47:50 ri[]38 # sample 20 # s indicates that he is looking for technical information, this is confirmed by the requests that follow, a[]3 continues 14:48:30 a[7]3 14:48:30 ri[]39 14:48:30 ri[]40 14:48:30 ri[]41 14:48:30 ii[]41 # end sample 20

activity ("collecting technical information"; looking for diameter of generator) request (number of revolutions of a generator) request (influence of number of revolutions on number of windings) request (is it controlable with number of windings) answer (voltage of generator is proportional to number of windings)

14:50:00 ii[]38

answer (this is a physical model of a generator; Union side dynamo) # still looking for information on the generator

14:50:30 a[7]3 activity ("collecting technical information"; guessing outer diameter of generator) 14:51:00 io[]32 result (40 mm is no problem for building in a generator) # the subject is thinking aloud asking himself how to build in the generator in relation with the chain 14:52:00 io[]33 result (generator is pressed down by its own weight but rotation of the gear wheel presses it against the chain, causing too much wear) # s continues with sketches of the generator 14:53:00 a[2]36 activity ("sketching generator"; sketching on new a3 page: 14) 14:53:00 io[]34 result (an alternative is pressing the generator against the chain wheel by a spring: 14) # sample 21 # here s is back to investigate how to drive the generator, a[]7 14:53:45 a[3]7 activity ("investigate how to drive the generator"; evaluating the drive of the generator, it is a problem) 14:53:45 io[]35 result (battery and electronics are no problem) 14:53:45 io[]36 result (cables can be wired on the frame; 12 red) 14:53:45 ri[]42 request (chain guard plus generator as one product acceptable) # end sample 21 14:54:00 ii[]42 answer (i can not decide that) 14:55:00 io[]37 result (chain guard and generator assumed to be integrated) # s is investigating the design constraints, this activity will be renamed 14:55:30 a[1]41 activity ("writing design constraints"; writing down this result; 14) 14:56:00 io[]38 result (no functional research to electronics, functionality needed is no problem) 14:56:00 io[]39 result (flashing back light when stopping) # activity renamed 14:56:30 a[1]41 activity ("writing design constraints"; writing down this result; 12) 14:57:00 ri[]43 request (there are 40 mins left) 14:57:00 ii[]43 answer (yes) 14:58:00 ri[]44 request (are current chain guards injection molded) 14:58:00 ii[]44 answer (i think so) 14:58:30 io[]40 result (chain guard will be injection molded this is acceptable, integrating functions; 12?) # sample 22 # this again is an activity in driving the generator, a[]7 14:59:00 a[4]7

15:01:00 a[4]7

activity ("investigate how to drive the generator"; way how to press the generator against the wheel, alternativeve: horizontally shifting, problem: heavy loaded in horizontal direction)a[]7 continues activity ("investigate how to drive the generator"; choose between the two ways of pressing generator against the gear wheel)

# end sample 22 15:02:00 io[]41 result (wheel can turn back but this is no problem for a generator) # s is collecting information from the physical model a[]3 continues 15:02:20 a[8]3 activity ("collecting technical information"; looking at generator model) 15:02:40 io[]42 result (part of generator stands still) 15:03:00 ri[]45 request (this is a coil, is the core turning; 2) 15:03:00 ii[]45 answer (yes core is turning) # activity renamed 15:03:00 a[2]41 activity ("writing design constraints"; writing down these data; 14) 15:04:30 ri[]46 request (soft iron not needed to transport the magnetic field when soil is direct around magnet) 15:04:30 ii[]46 answer (no, but still needed to lead the magnetic field through the coil) 15:04:30 ri[]47 request (always need the soft iron) 15:04:30 ii[]47 answer (yes the soft iron is always needed) # it is assumed s is sketching the generator here, there is no index to a drawing paper, thus a[]36 continues 15:05:00 a[3]36 activity ("sketching generator"; sketching) # sample 23 # s indicates that driving the generator causes to look for alternative constructions, activity is renamed to project this 15:06:00 a[1]46 activity ("investigate alternative generator constructions"; looking for alternative generator construction, outside drive in another way) # end sample 23 # s continues sketching on an overlay 15:07:00 a[4]36

activity ("sketching generator"; tracing with underlay of generator section on new page; 2,15)

180

APPENDIX

15:07:00 io[]43

result (existing dynamo is 4 cm wide, figure is 6.5 cm wide, so ratio is 1.625; 2, 15)

15:09:00 15:09:00 a[1]48 15:10:00 io[]44 15:10:45 io[]45 15:12:00 15:12:30 15:12:30 15:12:30 15:13:00 15:13:30 # sample

30 min left # s calculates generator geometry, activity renamed activity ("calculating generator geometry"; calculating) result (biggest width is 55 mm derived from sketch on page 15) result (gear wheel of generator is in direct contact with main gear wheel and has a form opposite of it just as the links of the chain) io[]46 result (heavy forces on this part, thus metal sheet) io[]47 result (dynamo fits in the gear wheel) # it is clear from the context that s is back to a[]7 a[5]7 activity ("investigate how to drive the generator"; looking at page 15) io[]48 result (dynamo hub is pushed against the gear wheel with a spring) io[]49 result (bended metal sheet attached to frame with nuts) io[]50 result (high torsion tension) 24

# s is now constructing parts of the generator assembly 15:14:30 a[1]50 activity ("constructing generator parts"; determining # guide of generator) 15:14:30 io[]51

result (assumption: two slits will do) #15:14:30 if i had more accurate info i could do more, now this costs me to much time

# end sample 24 15:15:00 io[]52

result (use pull-spring instead of push-spring)

# s continues to sketch the generator 15:16:00 a[5]36 activity ("sketching generator"; getting new page; 16) 15:16:00 a[5]36 activity ("sketching generator"; sketching solutions; 16) 15:17:00 io[]53 result (dynamo on metal sheet pending at 3 points in a slot. metal sheet assembled on bigger metal sheet pulled against gear wheel by a spring) 15:18:00 io[]54 result (one pole plate, under outside cover) 15:18:00 ri[]48 request (the other pole at this little axle; 2) 15:18:00 ii[]48 answer (yes) # sample 25 # s now looks to electrical problems and designs for it, activity # renamed 15:18:30 a[1]52 # end sample 25

activity ("designing electrical solutions"; solving problem of closing current loop)

15:19:30 io[]55 15:20:00 io[]56

result (closing current loop by coil-battery and magnet-frame contacts) result (the pole of the coils leads to the batteries. via inner body pole of magnet will be mounted on the frame) 15:20:30 io[]57 result (batteries above or under tube: the same amount of space available) 15:21:00 io[]58 result (mounting under the tube has the advantage of being pressed away from gear wheel) 15:22:00 io[]59 result (enough space to mount it to the frame here;16) # s continues to sketch the generator 15:22:30 a[6]36 # sample 26

activity ("sketching generator"; sketching on new page; 17)

# this activity point to the fact that s is concerned with part # construction again, a[]50 continues 15:23:30 a[2]50 activity ("constructing generator parts"; looking how to use the chain guard) 15:23:30 io[]60 result (generator attached to frame with metal sheet; 17) 15:23:30 io[]61 result (form of the chain guard will be changed) # end sample 26 15:24:00 15:24:00 15:24:00 15:24:00 15:24:30 15:26:00

io[]62 result (battery hangs on the metal sheet) io[]63 result (the cells will be placed here) io[]64 result (this will be enough) io[]65 result (chain guard must separate chain and this parts) io[]66 result (the battery can be placed) io[]67 result (all components assembled on the metal sheet) # s writes down design results, a[]33 continues

15:26:15 a[2]33 activity ("writing down results"; writing this down literally; 17) 15:26:30 io[]68 result (attachment of metal sheet to frame tube) # s keeps on writing results 15:26:40 15:26:45 15:27:30 15:27:45 15:27:45 # sample

a[2]33 io[]69 io[]70 io[]71 io[]72 27

activity ("writing down results"; writing this down; 17) result (new shape of chain guard because with the open form the cells do not fit in; 17) result (construction has a width of 55 mm, chain guard also) result (chain guard protects generator against dust and water; 17) result (the generator must be water proof because chain guard can not be)

15:28:45 ri[]49 request (how specify the design) 15:28:45 ii[]49 answer (evaluate the requirements; 31) # end sample 27 15:29:15 io[]73 15:30:15 io[]74

result (main aspect, generating sufficient current. not proofed by calculations. number of revolutions will be different. number of windings will be adapted to that) result (different aspect, mounting on rear axle. not done because i do not want a ring on the spokes. the


15:32:30 io[]75 15:33:30 io[]76 15:35:30 io[]77 15:37:00 io[]78 15:37:30 15:37:30 15:38:30 15:39:20 15:40:00 15:40:45 15:41:15 15:41:45

io[]79 io[]80 io[]81 io[]82 ri[]50 io[]83 io[]84 a[0]34

181

rear gear wheel has less space for a construction. therefore mounting on horizontal frame tube between rear axle and crank) result (requirement 1, easy maounting. metal sheet is mounted to horizontal frame tube by two or more bolts, hanging stable. batteries are also on the metal sheet) result (requirement 2, by adapting the number of coil windings the same power can be generated. for charging the batteries some more power is required, however the absence of slip increases the efficiency) result (requirement 3, sufficient light at every speed. by low speed batteries are discharged. must be of sufficient capacity to feed the light) result (the speed of the gear wheel determined the generator power. its speed variations are, because of the gear in the hub, less than those of the wheel) result (requirement 4 depends on the battery capacity. 4 penlites must be enough for 10 minutes light) result (batteries must be removable for replacement) result (requirement 5, optimal adaption of generator because of less rotation differences) result (requirement 6, chain guard protects against most of the water) request (how often is the chain guard under water) result (water no problem assuming generator is as rigid as a traditional one) result (for water mounting above the tube is better, but for mounting reasons i choose under) activity (end\_of\_assignment;;)

Appendix B – f-file Session 2

{\#} {\#} {\#} {\#} {\#} {\#} {\#} {\#} {\#} {\#} {\#} {\#} {\#} {\#}

in some cases an io seemed concrete and useful, but no *clear* usage was found in the protocol (e.g. io[1], io[7], io[8], io[9], ...) sometimes an io was almost identical to a previous one (e.g. io[3]=io[2]), and therefore ignored for the diagram. ********* the following has been done to create the .g4 file: results are added by tjamme wiegers on 11 februari 1997 the ignored results io[4] and io[5] are inserted again, activity a[20]1 is extended with result io[102], and two comments are changed into the results io[103] and io[104]. this appears to be usefull for better information analysis. E1 is tjamme wiegers E2 is joris vergeest

13:31:10 start{\_}of{\_}assignment {\#} start of activity a[1] reading assignment 13:31:10 a[1]1 activity (reading the assignment) {\#} start of activity a[2] making inventory of requirements 13:34:20 a[2]1 activity (making inventory of the requirements. Sheet 29: Requirements) {\#} sample 1 13:35:00 a[2]1 activity (still making inventory of requirements) 13:35:00 ri[1] request (i want to know how existing generators look like) 13:35:00 ri[1] request (i want that now) {\#} end{\_}of{\_}sample 1 13:35:50 ii[1] answer (a real generator is handed over to S; a Union side dynamo) 13:36:00 ri[3] request (are these generators suited for mounting on the rear axis) 13:36:00 ii[3] answer (no; there exist generators mounted on or near the hub, examples will be provided for) 13:37:00 a[2]1 activity (making notes) 13:38:00 ii[3] answer (explanation about how a rear generator is driven) {\#} start of activity a[3] finding critical requirements 13:38:45 a[3]1 activity (finding the critical requirements) 13:39:00 io[1] result (requirement 5 is the most critical one) {\#} sample 2 {\#} start of activity a[6] determining mechanical power 13:40:00 a[6]1 activity (determining how to calculate the max 12{\%} additional *mechanical* power allowed) 13:41:00 ri[4] request (i need some formulae) {\#} end{\_}of{\_}sample 2 13:41:00 13:41:20 13:42:20 {\#} the 13:43:00 13:43:00 13:43:00 {\#} the 13:43:00 13:43:00 13:44:20 13:44:50

ii[4] answer (just ask) a[6]1 activity (making notes on new sheet. Sheet 30: Power) ri[5] request (how is angular speed derived from linear speed) following is used in a[6]1, but this is the current activity box, so it will not give rise to a link. io[2] result (i assume the wheel is 28 inch) ri[6] request (is an inch 2.5 cm) ii[6] answer (yes) following result is used in the current activity box io[3] result (the wheel radius is an estimated 70 cm) ii[5] answer (you can calculate angular velocity from the wheel circumference) a[6]1 activity (using the calculator) a[6]1 activity (making notes and calculations)

183

184

APPENDIX

{\#} clock rings {\#} sample 3 13:45:00 a[6]1 activity (calculating additional power) {\#} end{\_}of{\_}sample 3 13:47:00 a[6]1 activity (using calculator and thinking) {\#} the following activity has been added due to ri[7] start of activity a[101] determining electrical power 13:47:40 a[101]1 activity (calculating electric power) 13:47:40 ri[7] request (what is the formula for the power) 13:47:40 ii[7] answer (you mean the electric power of the generator?) {\#} 13:47:40 S confirms this 13:48:16 ii[7] answer (a data sheet is handed over to S. Copy 1: Dynamo principles) 13:48:30 a[101]1 activity (reading the data sheet ’Dynamo principles’) 13:49:40 a[101]1 activity (using the calculator) {\#} clock rings {\#} sample 4 13:50:00 a[101]1 activity (calculating the power) {\#} the following activity has been added due to ri[8] {\#} start of activity a[6]2 13:51:00 a[6]2 activity (calculating mechanical power) 13:51:00 ri[8] request (what power needs a cyclist to do 18 km/hour) {\#} end{\_}of{\_}sample 4 13:51:00 ri[9] request (is power the same as energy) 13:52:00 ri[10] request (i still don’t have the good formulae) {\#} the following was ignored, but is replaced again 13:52:00 io[4] result (i need to divide energy by time) 13:53:20 a[6]2 activity (using calculator) {\#} the following is an interrupted continuation of a[101]1 {\#} start of activity a[101]2 13:53:40 a[101]2 activity (examines data sheet ’Dynamo principles’) 13:54:00 a[101]2 activity (making notes) 13:54:30 a[101]2 activity (takes new page of paper. Sheet 31: Electricity) 13:54:30 ii[8] answer (do you need the cyclist’s power as function of speed?) {\#} clock rings {\#} sample 5 {\#} apparently the mechanical power activity a[6]2 is resumed {\#} start of activity a[6]3 13:55:00 a[6]3 activity (calculate mechanical power) 13:55:00 ri[8] request (what is the required power of a cyclist) {\#} end{\_}of{\_}sample 5 13:55:00 ii[8] answer (i can’t find that) 13:55:50 ii[8] answer (at 20 km/h 20{\%} additional power is needed, for different speeds this will be different) 13:55:50 ri[8] request (but i need the cyclist’s power at 18 km/h) 13:56:40 ii[8] answer (presumably 45 watts) 13:57:30 a[6]3 activity (making notes) {\#} electric activity is resumed {\#} start of activity a[101]3 13:58:50 a[101]3 activity (calculate electric power) 13:58:50 ri[13] request (how can 5.4 watt be generated) {\#} the following was ignored, but is replaced again 13:58:50 io[5] result (i think it is in the opposite way as for the electric engine) {\#} clock rings {\#} sample 6 {\#} start of activity a[20] determining variables for electric power 14:00:05 a[20]1 activity (determining the relevant variables for the power of the generator) 14:00:05 ri[7] request (i still need the formulae for the generator power) {\#} end{\_}of{\_}sample 6 14:00:50 ii[7] answer (here a plot of voltage of an existing generator for 0.5 ampere. Copy 2: Dynamo example data) 14:03:00 ii[7] answer (information sheet about voltage-current-power. Copy 3: Electricity formulae) 14:04:00 a[20]1 activity (making notes and looking at the electricity formulae) 14:04:00 io[102] result (P=U*I and other notes, on new sheet: Electrical performance; sheet 31) {\#} the following activity has been added {\#} start of activity a[102] determinig electrical consumption 14:04:00 a[102]1 activity (determine electrical consumption) 14:04:00 ri[15] request (what is meant with a normal lighting system) {\#} sample 7 missed 14:05:00 ii[15] answer (that is a front and a rear light, the front light is 6V and 0.45A or 0.4A, the rear light is 6V 0.05A) 14:05:50 a[102]1 activity (writing down the answer. Sheet 31: Electrical performance) 14:07:50 ri[16] request (how to calculate the resistance of two resistors in parallel)

APPENDIX B – F-FILE SESSION 2

14:07:50 14:08:50 {\#} the 14:08:50 14:09:30

ii[16] answer (you can then add the currents to find the resulting resistance) ii[16] answer (is that sufficiently clear?) following was ignored, but is replaced again a[23]1 activity (confirming that point) a[102]1 activity (looking at data sheet and making notes)

{\#} clock rings {\#} sample 8 14:10:00 a[102]1 activity (determining power to feed the two lights) {\#} end{\_}of{\_}sample 8 {\#} the following result is used by a[104]1 14:12:00 io[6] result (i found the required power, the rotation speed is known. Sheet 31) 14:12:00 io[7] result (there is dependence on delay, area of the magnet poles, and the number of magnet poles) {\#} apparently calculating electric power {\#} start of activity a[101]4 14:12:00 a[101]4 activity (calculating electric power) 14:12:00 ri[17] request (how is flux calculated) 14:13:20 a[101]4 activity (examining a real generator) 14:13:40 a[101]4 activity (taking new sheet of paper and sketching a solution. Sheet 33 : Principle solutions, solution 1) {\#} sample 9 missed 14:15:00 a[101]4 activity (sketching solution 2 on sheet 33) 14:16:10 a[101]4 activity (looking at information sheet 1: Dynamo principles) 14:16:50 ii[17] answer (information sheet 4: Flux) 14:17:20 ii[17] answer (explanation about principles of flux; Copy 5: Excited voltage) 14:17:40 a[101]4 activity (making notes on new sheet. Sheet 32: Voltage calculation) 14:18:30 ii[17] answer (real parts are handed over and explained: coil, soft iron and magnet) 14:19:20 ii[17] answer (pictures of coil lay-out are given. Copy 6: Coil) {\#} sample 10 14:20:30 a[101]4 activity (looking at the needed formulae) {\#} end{\_}of{\_}sample 10 14:21:00 14:23:40 14:23:40 14:24:00 14:24:00 14:24:40 14:24:40

a[101]4 activity (studying the sheets) ri[18] request (how is it with the pole changes) ii[18] answer (explanation about the pole changes) ri[19] request (so nr of pole changes per rotation equals nr of poles) ii[19] answer (yes) io[8] result (i found the formula to calculate the power. Sheet 32: Voltage calculation) io[9] result (there are many variables, so i must fix some variables to start the calculation)

{\#} clock rings {\#} sample 11 14:25:20 a[101]4 activity (determining which assumptions can be made) {\#} end{\_}of{\_}sample 11 14:26:30 ri[20] request (are the 2 and 4 on this sheet constants. Sheet 32) 14:28:00 ii[20] answer (explains the voltage and flux aspects in the plot. Copy 5: Excited voltage) {\#} the following activity has been added {\#} start of activity a[103] determining power loss 14:29:00 a[103]1 activity (determine electric power loss) 14:29:00 ri[21] request ( does this formula give the effective voltage) 14:29:00 ii[21] answer (the voltage is for an unloaded generator) 14:29:00 ri[22] request (how is power loss calculated) 14:29:00 ii[22] answer (from the resistance of the wire) 14:29:40 ri[23] request (so a long wire is disadvantageous) 14:29:40 ii[23] answer (yes) {\#} sample 12 14:30:00 a[103]1 activity (working with that formula. New sheet, 40: Voltage recalculation) {\#} end{\_}of{\_}sample 12 {\#} the following comment is changed into a result 14:32:00 io[103] result (i leave this subject for a while) {\#} start of activity a[35] finding principle solutions 14:32:00 a[35]1 activity (finding some principle solutions. Sheet 33: Principle solutions) {\#} the following has been added {\#} start of activity a[104] choosing battery type 14:33:40 a[104]1 activity (choosing the battery type) 14:33:40 ri[24] request (current of existing batteries) 14:34:00 ii[24] answer (performance of some batteries. Copy 7: Batteries) 14:35:05 ri[25] request (are they equally expensive) 14:35:05 ri[26] request (must the choice for a battery be optimal for cost) 14:35:05 ii[26] answer (no optimal is needed) 14:35:05 ii[25] answer (larger batteries are more expensive) {\#} clock rings {\#} sample 13 14:36:00 a[104]1 activity (finding appropriate battery)

185

186

APPENDIX

{\#} end{\_}of{\_}sample 13 {\#} the following link is inserted 14:36:00 ii[101] use (io[6] required electrical power) {\#} 14:36:45 e1 reminds s to red page {\#} the following result is used by a[38]1 14:37:40 io[10] result (the appropriate battery) 14:37:40 a[104]1 activity (making notes of selected battery. Sheet 34: Battery and area, line 1) {\#} the following result is considered the same as io[12] 14:38:50 io[11] result (i found the dimensions of the electronic parts on the same information sheet. Copy 7, Batteries) {\#} the following activity has been rephrased {\#} start of activity a[38] determining dimensions of parts 14:38:50 a[38]1 activity (determining dimensions of the parts; writing the dimensions and power consumption of the electronics; sheet 34, line 2 and 3) 14:38:50 ii[102] use (io[10] selected battery type) 14:39:40 a[38]1 activity (finding out the sizes of the different parts) 14:39:40 ri[27] request (what is the size of the generator) {\#} clock rings {\#} sample 14 14:40:05 a[38]1 activity (drawing the sizes of the parts. Sheet 35: Arrangement, upper half) {\#} end{\_}of{\_}sample 14 14:41:00 ri[28] request (can i consider the electronics just as a volume) 14:41:00 ii[28] answer (yes) {\#} the following result is used by a[41]1 14:41:30 io[12] result (the dimensions of the parts. Sheet 35: Arrangement) {\#} start of activity a[41] finding stacking method 14:41:30 a[41]1 activity (starting to attempt various ways of stacking the parts. Sheet 35: Arrangement, lower half) 14:41:30 ii[103] use (io[12] dimensions of the parts) 14:41:30 a[41]1 activity (making arrangement drawings. Sheet 35) 14:43:10 io[13] result (stacking method) 14:43:50 ri[29] request (how much space is available near the rear wheel) 14:44:20 io[14] result (i suppose most space is at the non-chain side, between rear bridge and the spokes) 14:45:00 ii[29] answer (23 mm space, hub has diameter of 105 mm) 14:45:00 a[41]1 activity (writing down these measures. Sheet 34: Battery and area) 14:45:30 ri[30] request (distance between spokes and frame is 23 mm) 14:45:30 ii[30] answer (yes) 14:45:30 ii[29] answer (drawing of a hub is handed over and explained. Copy 8: Hub) 14:46:10 ri[31] request (but the requirements tell that the product must be on the axis) 14:46:40 ii[31] answer (explains difference between space for mounting and space occupied by the product) 14:46:50 ri[32] request (so better not place a driving wheel against the tire) 14:46:50 ii[32] answer (no) {\#} sample 15 14:47:00 a[41]1 activity (finding a lay-out given the dimensions) {\#} end{\_}of{\_}sample 15 14:47:00 a[41]1 activity (making drawings of hub and spokes. Sheet 34) 14:48:50 a[41]1 activity (investigating place of windings and magnet. Sheet 34) 14:48:50 io[15] result (i assume that the windings are at rest and the coil turns, so no sliding contacts are needed) {\#} S says coil when he means magnet {\#} sample 16 14:50:00 io[16] result (i go back to my calculations because i have my two unknown variables now, i can fill them in) {\#} start of activity a[101]5 14:51:10 a[101]5 activity (looking at an earlier data sheet) 14:51:10 a[101]5 activity (drawing boxes. Sheet 37: Wire) 14:51:30 ri[33] request (is the generator most effective when the wires are near the poles) {\#} end{\_}of{\_}sample 16 14:51:30 ii[33] answer (yes) 14:51:40 ri[34] request (can the poles be the halves of a circle) 14:51:40 ii[34] answer (yes) 14:52:00 ri[35] request (surface in the formula is that the surface of one pole or of the two together) 14:52:50 ii[35] answer (of the two together) 14:53:30 a[101]5 activity (making sketches) 14:53:50 io[17] result (diameter of coil is still left as a variable) {\#} activity a[41]1 is briefly resumed to check available space for generator {\#} start of activity a[41]2 14:54:00 a[41]2 activity (looking at information sheet ’Hub’, at the picture of brake-arm. Copy 8) {\#} start of activity a[101]6 14:54:30 a[101]6 activity (using calculator) {\#} the following result is used in a[103]2 and in a[101]7 14:55:05 io[18] result (i assume radius is 8 cm)


{\#} sample 17 {\#} 14:56:00 S, using the calculator intensively, overhears the sample question {\#} end{\_}of{\_}sample 17 14:56:00 a[101]6 activity (making calculations and notes. Sheet 37: Wire) {\#} the 14:56:40 14:56:40 14:57:40 14:57:40 14:57:40 {\#} the

following result is used in a[101]7 io[19] result (613 windings) io[20] result (that seems too little to me) a[101]6 activity (comparing the number 613 with other generators) io[21] result (this generator has 155 windings) io[22] result (i suspect that voltage loss is an important factor) power loss activity is actually resumed at 14:57:40 (not at 15:06:15)

{\#} (inserted during .g3 creation) {\#} start of activity a[103]2 14:57:40 a[103]2 activity (calculating electric power loss) 14:58:40 ri[36] request (to calculate the voltage loss for this length of the wire i need the resistance of the winding. Sheet 37: Wire) 14:58:40 ii[36] answer (resistance of 1 meter copper wire with cross section of 1 square mm is 1.7 times 10 to the minus 8 ohms) 14:58:40 ii[104] use (io[18] radius of 8 cm) {\#} clock rings {\#} sample 18 {\#} an io has been inserted below (due to mistake in .g1 file) {\#} the following is used in a[103]2, which is the current activity box 15:00:00 io[101] result (i found the length of the wire. Sheet 37: Wire) 15:00:00 ri[37] request (is the diameter of the wire important for the power) {\#} end{\_}of{\_}sample 18 15:00:00 15:00:00 15:00:00 15:01:40

ii[37] ri[38] ii[38] ri[39]

answer (no) request (why then not take a very small diameter) answer (then you get more loss) request (the length of the wire, is it for one or for all coils of the pole or of the pole pair) 15:01:40 ii[39] answer (for the pole pair) {\#} used in current activity box 15:02:20 15:04:00 15:05:00 15:05:00 15:05:30 15:05:30 15:05:30 15:05:30

io[23] result (the resistance of the wire) a[103]2 activity (calculating) io[24] result (the voltage) io[25] result (it is probably too high) ri[40] request (information about the magnet) ii[40] answer (look at the real magnet) ri[41] request (do these marks indicate the poles) ii[41] answer (yes)

{\#} sample 19 15:06:15 a[103]2 activity (finding how to reduce the voltage loss, what the variables are for that) 15:07:20 ri[42] request (how many poles are there on the magnet) {\#} end{\_}of{\_}sample 19 15:07:20 ii[42] answer (it can be any number) 15:07:20 ri[43] request (why not using many poles) 15:07:20 ii[43] answer (the restriction is that about 2 mm distance is needed between the soft irons) {\#} assumed end of activity a[103]2 here, a[101]6 is resumed {\#} start of activity a[101]7 15:09:00 15:09:00 15:09:00 15:09:00 15:09:00

a[101]7 activity (calculate electric power) ii[105] use (io[18] radius of 8 cm) ii[106] use (io[19] number of windings) ri[44] request (is the real magnet different from the one on this data sheet) ii[44] answer (explains the lay-out of the two coils)

{\#} remark: S means coil when he says magnet. 15:10:00 ii[44] answer (explains principle of soft iron and magnetic flux) 15:11:10 ri[45] request (is there a max size on the magnet, is diameter 8 cm very large) 15:11:10 ii[45] answer (that is rather large, but not extremely large) {\#} activity to find shape for generator starts here {\#} start of activity a[105] determining shape of generator 15:11:10 a[105]1 activity (determining shape of generator) 15:11:10 ri[46] request (can the magnet get any shape) 15:11:10 ii[46] answer (yes) 15:12:40 ri[47] request (could it be a plastic carrier with a magnet covering it) 15:12:40 ii[47] answer (yes, shows an example) {\#} clock rings {\#} sample 20

187

188

APPENDIX

15:12:50 a[105]1 activity (determining a disc with magnetic material on it) {\#} the following comment is changed into a result 15:12:50 io[104] result (determining a disc with magnetic material on it, i will later calculate that) {\#} end{\_}of{\_}sample 20 15:14:40 ri[48] request (if the soft iron has a u-shape, is then the effective surface doubled) {\#} sample 21 15:15:00 a[105]1 activity (looking for a smart way to mount the soft iron) 15:15:00 ri[49] request (I must form an idea of the soft iron and the coil) 15:16:00 a[105]1 activity (making a drawing of a horse shoe magnet. New sheet 39: Horse shoe) {\#} end{\_}of{\_}sample 21 15:17:20 ri[50] request (must the magnet touch the soft iron) 15:17:20 ii[50] answer (no it must not) 15:18:00 ri[51] request (is it good to have the soft iron and coil close) 15:18:00 ii[51] answer (distance between them must be as small as possible) {\#} the following is used in a[107]1 15:19:00 io[26] result (the outer shape for a flat generator) 15:19:00 a[105]1 activity (drawing that shape. New sheet 38: Soft iron) {\#} sample 22 15:20:00 a[105]1 activity (drawing a cross section at a particular point; sheet 38) 15:20:40 ri[52] request (does the generator work only at the points between the magnet poles) {\#} en{\_}of{\_}sample 22 15:22:00 ii[52] answer (discusses shape proposal and placement of wire) {\#} the following is added {\#} start of activity a[106] determining inner structure of generator 15:23:40 a[106]1 activity (determining inner structure details of generator) 15:23:40 ri[53] request (so the coil must be at points where there is no magnet) 15:23:40 ii[53] answer (yes) 15:24:20 a[106]1 activity (sketching to determine how many poles can be made with the soft iron. Sheet 36: poles) {\#} clock rings {\#} sample 23 15:25:05 io[27] result (i don’t have that 23 mm at the bottom due to the brake arm) {\#} start of activity a[41]3 15:26:00 a[41]3 activity (finding out how much space there is) 15:26:00 ri[54] request (is this the hub of the particular bike) {\#} end{\_}of{\_}sample 23 15:26:00 ii[54] answer (yes) 15:26:00 a[41]3 activity (checking the amount of space for the generator) {\#} in the following line the time has been corrected (1 min. added) {\#} (probably error in .f1 file) {\#} start of activity a[2]2 15:26:50 a[2]2 activity (checking the requirements at first) 15:27:40 ri[55] request (is it bad to make the windings non-uniform, can i leave a gap in it) 15:27:40 ii[55] answer (you can get less voltage) 15:28:40 ri[56] request (a side view of the hub) {\#} start of activity a[41]4 15:28:40 a[41]4 activity (making a drawing) 15:28:40 ii[56] answer (do you want the cross section?) 15:28:40 ri[57] request (no i need the pipes, the frame of the bike) 15:30:05 ii[57] answer (a sketch of the frame. Copy 9: Frame) {\#} sample 24 15:30:05 a[41]4 activity (investigating how much space is available for the generator, it is restricted by the break arm) {\#} end{\_}of{\_}sample 24 {\#} 15:31:00 e1 says that the assignment ends after half an hour 15:31:00 a[41]4 activity (making a drawing of the frame tubes) {\#} the following is added {\#} start of activity a[106]2 15:31:50 a[106]2 activity (checking internal structure of the generator) 15:31:50 ri[58] request (is this a possible situation, can the soft irons overlap) {\#} 15:31:50 s shows to e1 a proposal 15:31:50 ii[58] answer (yes) {\#} the following is used in a[101]8 15:33:00 io[29] result (the number of pole pairs is changed to 8) {\#} the following is added {\#} start of activity a[101]8 15:33:00 a[101]8 activity (recalculating electric power) 15:33:00 a[101]8 activity (i check this with the formulae because of changed area measures) 15:33:00 io[30] result (there is a linear dependence so i can change the number of windings accordingly) 15:33:00 ii[107] use (io[29] new number of pole pairs is 8) 15:33:50 ri[59] request (does the overlap of soft iron and magnet determine the area) 15:33:50 ii[59] answer (yes) 15:35:10 a[101]8 activity (drawing a ring with overlapping soft irons. Sheet 36: Poles)


{\#} sample 25 15:35:20 a[101]8 activity (recalculating the formula. Sheet 40: Recalculation) {\#} end{\_}of{\_}sample 25 15:36:30 a[101]8 activity (making drawing and calculations. Sheet 36: Poles) 15:38:50 a[101]8 activity (making calculations and notes. Sheet 36: Poles, and 40: Recalculation, lines 4,5,6) {\#} the following is used in a[106]3 15:39:00 io[40] result (33 windings. Sheet 40: Recalculation) 15:39:00 io[41] result (i assume that the voltage loss is small because of low windings) {\#} start of activity a[107] making total concept 15:39:00 a[107]1 activity (starting to make a total concept) {\#} sample 26 15:40:07 a[107]1 activity (starting to make a simple technical drawing) {\#} end{\_}of{\_}sample 26 15:40:07 ii[108] 15:40:10 a[107]1 15:41:00 a[107]1 15:42:00 a[107]1 15:44:00 a[107]1 {\#} clock rings

use (io[26] outer shape of generator) activity (drawing 3 circles etc. Sheet 41: Product sketch) activity (filling the circles with markers) activity (sketching soft iron. Sheet 41) activity (starting to make a cross section drawing. Sheet 41 upper right corner)

{\#} sample 27 15:45:15 a[107]1 activity (drawing a cross section) {\#} end{\_}of{\_}sample 27 15:46:15 15:46:15 15:47:00 15:48:00 15:49:00 15:49:30

ri[60] request (is it better to make the distance between soft iron and magnet smaller) ii[60] answer (yes) a[107]1 activity (looking at earlier drawing) a[107]1 activity (taking care of battery and electrical circuit) a[107]1 activity (tracing the component arrangement. From sheet 35 to 41) a[107]1 activity (tracing outer shape and sketching frame tubes. Sheet 54: Shape)

{\#} sample 28 15:50:05 a[107]1 activity (determining the outer shape. Sheet 54: Shape) {\#} end{\_}of{\_}sample 28 {\#} the following is added {\#} start of activity a[106]3 15:52:00 a[106]3 activity (design of inner structure) 15:52:00 a[106]3 activity (i want to work on a detail) 15:52:00 io[42] result (ring of synthetic material, with a magnetic ring sticked on, the thickness of the synthetic ring prevents contact between soft iron and magnet) 15:52:00 ii[109] use (io[40] number of windings is 33) 15:53:00 a[106]3 activity (sketching. New sheet 44: Nylon disc) 15:53:20 io[43] result (when when sticking the iron to one side, the electrical field will be less at the other side because the synthetic ring will be in the way) 15:53:40 a[106]3 activity (start drawing on new sheet. Sheet 42: Saucers) 15:54:00 io[44] result (magnetic ring is placed between two saucers of synthetic material. The place where it is clamped is thicker and functions as a bearing. Sheet 43: Section) {\#} clock rings {\#} sample 29 15:55:00 a[106]3 activity (drawing the bearing. Sheet 43: Section) {\#} end{\_}of{\_}sample 29 15:56:00 a[106]3 activity (filling the saucers orange, etc.) {\#} start of activity a[107]2 15:58:20 a[107]2 activity (finishing the intersection drawing. Sheet 43) 16:00:00 a[107]2 activity (drawing of the outer form) 16:01:30 io[45] result (requirement 5 was important, requirement 3 seems covered by requirement 4, requirement 6: the product is fully covered. The driving must be lead from a spoke to a disc on the axis to prevent an extra interstice. Req. 1: it is mounted on the rear axis, requirement 2: i calculated the required current first, the 5 milliampere for the electronics has been neglected. requirement 4: the electronics together with the batteries take care of that) {\#} clock rings 16:05:10 io[46] result (requirement 5: 12{\%} equals 5.4 watts, i assumed halogen lights on the front) 16:06:40 end{\_}of{\_}assignment

189

Appendix C –CDIRS Documentation

Forms AddDocumentForm, ContextForm, CreateContextForm, FrmLoginForm, KeywordContextForm, ListDocumentsForm, ProjectProfileForm, RelevantForm, FesultBrowserForm, SearchForm, SharedProjectsForm, UserProfileForm, WelcomeForm

Sample Listing – Copyright of M.I. Jambak SearchForm Code

Attribute VB_Name = "SearchForm" Attribute VB_GlobalNameSpace = False Attribute VB_Creatable = False Attribute VB_PredeclaredId = True Attribute VB_Exposed = False Sub init_Media() lbMedia.Caption = "" If MediaRs!doc_name "" Then lbMedia.Caption = MediaRs!doc_name If WindowsMediaPlayer1.playState = wmppsPlaying Then WindowsMediaPlayer1.Close End If With WindowsMediaPlayer1 .Visible = False .Height = 2415 .Width = 3255 .Left = 120 .Top = 840 End With lbMedia.Visible = True End If End Sub Sub init_Doc() FrameDoc.Caption = "" If DocRs!doc_name "" Then FrameDoc.Caption = DocRs!doc_name OLE1.Delete End If End Sub Sub init_Picture() If PictureRs!doc_name "" Then FramePicture.Caption = PictureRs!doc_name Dim MyPictureStream As New Stream Dim MyTempPictureFile As String MyTempPictureFile = CurDir & "\" & PictureRs!doc_name MyPictureStream.Type = adTypeBinary MyPictureStream.Open MyPictureStream.Write PictureRs!doc_content MyPictureStream.SaveToFile MyTempPictureFile, adSaveCreateOverWrite Image1.Picture = LoadPicture() Image1.Picture = LoadPicture(MyTempPictureFile) MyPictureStream.Close Set fso = CreateObject("Scripting.FileSystemObject") Set MyPictureFile = fso.GetFile(MyTempPictureFile) MyPictureFile.Delete Set fso = Nothing Set MyPictureFile = Nothing End If End Sub Sub StartGoogleSearch(searchString) Dim url As String, searchArgs As String ’encode search arguments (replace spaces with plus signs) searchArgs = Replace(Trim(searchString), " ", "+") ’compose complete url url = "http://www.google.com/search?hl=en&lr=&ie=UTF-8&safe=off&q=" + searchArgs ’navigate to the page! WebBrowser1.Navigate2 url Exit_StartGoogleSearch: Exit Sub

191

192

APPENDIX

Err_StartGoogleSearch: MsgBox Err.Description Resume Exit_StartGoogleSearch End Sub Private Sub BookmarkList_DblClick() ResultBrowserForm.WebBrowser1.Navigate2 LTrim$(Trim$(BookmarkList.List(BookmarkList.ListIndex))) URLtext = LTrim$(RTrim$(BookmarkList.List(BookmarkList.ListIndex))) BookmarkTrigger = True ResultBrowserForm.Show End Sub Private Sub cmdAddDoc_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then DocumentTrigger = "doc" AddDocumentForm.Show (modal) End If End Sub Private Sub cmdAddMedia_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then DocumentTrigger = "med" AddDocumentForm.Show End If End Sub Private Sub cmdAddPicture_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then DocumentTrigger = "pic" AddDocumentForm.Show End If End Sub Private Sub cmdClose_Click() WorkRs.Close ProjectRs.Close KeywordRs.Close WelcomeForm.Show Unload Me End Sub Private Sub cmdContext_Click() ContextFromWelcomeTrigger = False KeywordRs.Close ’re-open table keyword keywordAr = "SELECT * FROM keywords WHERE user_id = ’" & WorkRs!user_id & "’ AND project_id = ’" & WorkRs!project_id & "’" KeywordRs.Open keywordAr, cdirsdb, adOpenStatic, adLockOptimistic ContextForm.Show Me.Hide End Sub Private Sub cmdDeleteKeyword_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then Dim Msg, Style, Response Msg = "DELETE the keyword ?" Style = vbYesNo + vbCritical Response = MsgBox(Msg, Style, "CDIRS") If Response = vbYes Then Dim DeleteBookmarkAndDocumentRs As New Recordset Dim DeleteBookmark As String Dim DeleteDocument As String DeleteBookmarkAndDocumentRs.Open "SELECT * FROM keywords WHERE keyword_id = ’" & ListKeyId.List (KeywordCombo.ListIndex) & "’", cdirsdb, adOpenStatic, adLockOptimistic cdirsdb.Errors.Clear cdirsdb.BeginTrans If DeleteBookmarkAndDocumentRs.RecordCount > 0 Then DeleteBookmarkAndDocumentRs.MoveFirst While Not DeleteBookmarkAndDocumentRs.EOF DeleteBookmark = "DELETE * FROM bookmarks WHERE keyword_id = ’" & DeleteBookmarkAndDocumentRs!keyword_id & "’" DeleteDocument = "DELETE * FROM documents WHERE keyword_id = ’" & DeleteBookmarkAndDocumentRs!keyword_id & "’" cdirsdb.Execute DeleteBookmark cdirsdb.Execute DeleteDocument DeleteBookmarkAndDocumentRs.MoveNext Wend End If DeleteBookmarkAndDocumentRs.Close cdirsdb.Execute "DELETE * FROM keywords WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’" If Err = 0 Then cdirsdb.CommitTrans SSTab1.Tab = 0 KeywordRs.Close ’re-open table keyword keywordAr = "SELECT * FROM keywords WHERE user_id = ’" & WorkRs!user_id & "’ AND project_id = ’" & WorkRs!project_id & "’" KeywordRs.Open keywordAr, cdirsdb, adOpenStatic, adLockOptimistic KeywordCombo.Clear BookmarkList.Clear ListKeyId.Clear If KeywordRs.RecordCount > 0 Then KeywordRs.MoveFirst While Not KeywordRs.EOF ListKeyId.AddItem KeywordRs("keyword_id") KeywordCombo.AddItem KeywordRs("keyword") KeywordRs.MoveNext Wend ListKeyId.ListIndex = KeywordCombo.ListIndex End If FramePicture.Caption = "" Image1.Picture = LoadPicture() FrameDoc.Caption = "" OLE1.Delete lbMedia.Caption = "" If WindowsMediaPlayer1.playState = wmppsPlaying Then WindowsMediaPlayer1.Close End If With WindowsMediaPlayer1 .Visible = False .Height = 2415 .Width = 3255 .Left = 120 .Top = 840 End With

APPENDIX C –CDIRS DOCUMENTATION

Else cdirsdb.RollbackTrans MsgBox Error, , "CDIRS" End If End If End If End Sub Private Sub cmdFullListDoc_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then DocumentTrigger = "doc" ListDocumentsForm.Show End If End Sub Private Sub cmdFullListMed_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then DocumentTrigger = "med" ListDocumentsForm.Show End If End Sub Private Sub cmdFullListPicture_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then DocumentTrigger = "pic" ListDocumentsForm.Show End If End Sub Private Sub cmdLoadDoc_Click() If FrameDoc.Caption "" Then Dim MyDocStream As New Stream MyTempDocFile = "d:\cdirs\" & DocRs!doc_name MyDocStream.Type = adTypeBinary MyDocStream.Open MyDocStream.Write DocRs!doc_content MyDocStream.SaveToFile MyTempDocFile, adSaveCreateOverWrite OLE1.Delete OLE1.CreateLink (MyTempDocFile) MyDocStream.Close End If End Sub Private Sub cmdMovefirstDoc_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If DocRs.RecordCount > 0 Then DocRs.MoveFirst Call init_Doc End If End If End Sub Private Sub cmdMovefirstMedia_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If MediaRs.RecordCount > 0 Then MediaRs.MoveFirst Call init_Media End If End If End Sub Private Sub cmdMovefirstPic_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If PictureRs.RecordCount > 0 Then PictureRs.MoveFirst Call init_Picture End If End If End Sub Private Sub cmdMovelastDoc_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If DocRs.RecordCount > 0 Then DocRs.MoveLast Call init_Doc End If End If End Sub Private Sub cmdMovelastMedia_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If MediaRs.RecordCount > 0 Then MediaRs.MoveLast Call init_Media End If End If End Sub Private Sub cmdMovelastPic_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If PictureRs.RecordCount > 0 Then PictureRs.MoveLast Call init_Picture End If End If End Sub Private Sub cmdMovenextDoc_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If DocRs.RecordCount > 0 Then DocRs.MoveNext If DocRs.EOF Then MsgBox "Moving past the last record." & _ vbCr & "Try again.", , "CDIRS" DocRs.MoveLast Else Call init_Doc End If End If End If End Sub Private Sub cmdMovenextMedia_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If MediaRs.RecordCount > 0 Then MediaRs.MoveNext If MediaRs.EOF Then MsgBox "Moving past the last record." & _

193

194

APPENDIX

vbCr & "Try again.", , "CDIRS" MediaRs.MoveLast Else Call init_Media End If End If End If End Sub Private Sub cmdMovenextPic_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If PictureRs.RecordCount > 0 Then PictureRs.MoveNext If PictureRs.EOF Then MsgBox "Moving past the last record." & _ vbCr & "Try again.", , "CDIRS" PictureRs.MoveLast Else Call init_Picture End If End If End If End Sub Private Sub cmdMovepreviousDoc_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If DocRs.RecordCount > 0 Then DocRs.MovePrevious If DocRs.BOF Then MsgBox "Moving past the first record." & _ vbCr & "Try again.", , "CDIRS" DocRs.MoveFirst Else Call init_Doc End If End If End If End Sub Private Sub cmdMovepreviousMedia_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If MediaRs.RecordCount > 0 Then MediaRs.MovePrevious If MediaRs.BOF Then MsgBox "Moving past the first record." & _ vbCr & "Try again.", , "CDIRS" MediaRs.MoveFirst Else Call init_Media End If End If End If End Sub Private Sub cmdMovepreviousPic_Click() If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If PictureRs.RecordCount > 0 Then PictureRs.MovePrevious If PictureRs.BOF Then MsgBox "Moving past the first record." & _ vbCr & "Try again.", , "CDIRS" PictureRs.MoveFirst Else Call init_Picture End If End If End If End Sub Private Sub cmdPlayMedia_Click() On Error Resume Next If lbMedia.Caption "" Then Dim MyDocStream As New Stream MyTempMediaFile = "d:\cdirs\" & MediaRs!doc_name MyDocStream.Type = adTypeBinary MyDocStream.Open MyDocStream.Write MediaRs!doc_content Set fso = CreateObject("Scripting.FileSystemObject") If fso.fileExists(MyTempMediaFile) Then If WindowsMediaPlayer1.playState = wmppsPlaying Then WindowsMediaPlayer1.Close lbMedia.Visible = True End If WindowsMediaPlayer1.Visible = True WindowsMediaPlayer1.url = MyTempMediaFile Else MyDocStream.SaveToFile MyTempMediaFile, adSaveCreateOverWrite On Error GoTo 0 WindowsMediaPlayer1.url = MyTempMediaFile ’MediaPlayer1.play End If Set fso = Nothing MyDocStream.Close End If End Sub Private Sub cmdProfile_Click() NewProjectTrigger = False FromSearchTrigger = True ProjectProfileForm.Show Unload Me End Sub Private Sub cmdRelevant_Click() RelevantForm.Show Me.Hide End Sub Private Sub cmdRemoveDoc_Click() If ListKeyId.List(KeywordCombo.ListIndex) "" And FrameDoc.Caption "" Then Dim Msg, Style, Response Msg = "REMOVE the Document ?" Style = vbYesNo + vbCritical Response = MsgBox(Msg, Style, "CDIRS") If Response = vbYes Then


Dim deleteDoc As String deleteDoc = "DELETE * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_name = ’" & FrameDoc.Caption & "’" cdirsdb.BeginTrans cdirsdb.Execute deleteDoc If Err = 0 Then cdirsdb.CommitTrans If DocRs.State = adStateOpen Then DocRs.Close End If Dim DocString As String DocString = "SELECT * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_type = ’" & "doc" & "’" DocRs.CursorLocation = adUseClient DocRs.Open DocString, cdirsdb, adOpenStatic, adLockOptimistic If Not DocRs.RecordCount > 0 Then OLE1.Delete FrameDoc.Caption = "" Else DocRs.MoveFirst Call init_Doc End If Else cdirsdb.RollbackTrans MsgBox Error, , "CDIRS" End If End If End If End Sub Private Sub cmdRemoveMedia_Click() If ListKeyId.List(KeywordCombo.ListIndex) "" And lbMedia.Caption "" Then Dim Msg, Style, Response Msg = "REMOVE the Media file ?" Style = vbYesNo + vbCritical Response = MsgBox(Msg, Style, "CDIRS") If Response = vbYes Then Dim deleteMedia As String deleteMedia = "DELETE * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_name = ’" & lbMedia.Caption & "’" cdirsdb.BeginTrans cdirsdb.Execute deleteMedia If Err = 0 Then cdirsdb.CommitTrans If MediaRs.State = adStateOpen Then MediaRs.Close End If Dim MediaString As String MediaString = "SELECT * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_type = ’" & "doc" & "’" MediaRs.CursorLocation = adUseClient MediaRs.Open MediaString, cdirsdb, adOpenStatic, adLockOptimistic If Not MediaRs.RecordCount > 0 Then If WindowsMediaPlayer1.playState = wmppsPlaying Then WindowsMediaPlayer1.Close End If lbMedia.Caption = "" lbMedia.Visible = True Else MediaRs.MoveFirst Call init_Media End If Else cdirsdb.RollbackTrans MsgBox Error, , "CDIRS" End If End If End If End Sub Private Sub cmdRemovePic_Click() If ListKeyId.List(KeywordCombo.ListIndex) "" And FramePicture.Caption "" Then Dim Msg, Style, Response Msg = "REMOVE the Picture ?" Style = vbYesNo + vbCritical Response = MsgBox(Msg, Style, "CDIRS") If Response = vbYes Then Dim deletePicture As String deletePicture = "DELETE * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_name = ’" & FramePicture.Caption & "’" cdirsdb.BeginTrans cdirsdb.Execute deletePicture If Err = 0 Then cdirsdb.CommitTrans If PictureRsState = adStateOpen Then ictureRs.Close End If Dim PictureString As String PictureString = "SELECT * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_type = ’" & "pic" & "’" PictureRs.CursorLocation = adUseClient PictureRs.Open PictureString, cdirsdb, adOpenStatic, adLockOptimistic If Not PictureRs.RecordCount > 0 Then Image1.Picture = LoadPicture() FramePicture.Caption = "" Else PictureRs.MoveFirst Call init_Picture End If Else cdirsdb.RollbackTrans MsgBox Error, , "CDIRS"

195

196

APPENDIX

End If End If End If End Sub Private Sub cmdRemoveUrl_Click() If BookmarkList.List(BookmarkList.ListIndex) "" Then Dim Msg, Style, Response Msg = "REMOVE the bookmark ?" Style = vbYesNo + vbCritical Response = MsgBox(Msg, Style, "CDIRS") If Response = vbYes Then Dim deleteUrl As String deleteUrl = "DELETE * FROM bookmarks WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND url = ’" & LTrim$(RTrim$(BookmarkList.List(BookmarkList.ListIndex))) & "’" cdirsdb.BeginTrans cdirsdb.Execute deleteUrl If Err = 0 Then cdirsdb.CommitTrans BookmarkList.RemoveItem (BookmarkList.ListIndex) Else cdirsdb.RollbackTrans End If End If End If End Sub Private Sub cmdStopMedia_Click() If WindowsMediaPlayer1.playState = wmppsPlaying Then WindowsMediaPlayer1.Close End If With WindowsMediaPlayer1 .Visible = False .Height = 2415 .Width = 3255 .Left = 120 .Top = 840 End With lbMedia.Visible = True Set fso = CreateObject("Scripting.FileSystemObject") If fso.fileExists(MyTempMediaFile) Then fso.DeleteFile MyTempMediaFile force End If Set fso = Nothing End Sub Private Sub cmdUnloadDoc_Click() OLE1.Delete If MyTempDocFile "" Then Set fso = CreateObject("Scripting.FileSystemObject") If fso.fileExists(MyTempDocFile) Then Set MyDocFile = fso.GetFile(MyTempDocFile) MyDocFile.Delete End If Set fso = Nothing Set MyDocFile = Nothing End If End Sub Private Sub Form_Load() If ProjectRs!project_name "" Then lbProject.Caption = ProjectRs!project_name Else lbProject.Caption = "" End If SearchTermHistory.Clear KeywordCombo.Clear BookmarkList.Clear ListKeyId.Clear If KeywordRs.RecordCount > 0 Then KeywordRs.MoveFirst While Not KeywordRs.EOF ListKeyId.AddItem KeywordRs("keyword_id") KeywordCombo.AddItem KeywordRs("keyword") KeywordRs.MoveNext Wend ListKeyId.ListIndex = KeywordCombo.ListIndex End If WebBrowser1.Navigate ("www.google.com") ’WebBrowser1.Navigate ("www.yahoo.com") SearchTerm.Text = "" With WindowsMediaPlayer1 .Visible = False .Height = 2415 .Width = 3255 .Left = 120 .Top = 840 End With lbMedia.Visible = True End Sub Private Sub KeywordCombo_Click() Dim BookmarkString As String Dim PictureString As String Dim DocString As String Dim MediaString As String ’initiation BookmarkList.Clear Image1.Picture = LoadPicture() FramePicture.Caption = "" OLE1.Delete FrameDoc.Caption = "" If MyTempDocFile "" Then Set fso = CreateObject("Scripting.FileSystemObject") If fso.fileExists(MyTempDocFile) Then Set MyDocFile = fso.GetFile(MyTempDocFile) MyDocFile.Delete End If Set fso = Nothing Set MyDocFile = Nothing End If If WindowsMediaPlayer1.playState = wmppsPlaying Then WindowsMediaPlayer1.Close End If lbMedia.Caption = "" WindowsMediaPlayer1.Visible = False lbMedia.Visible = True If MyTempMediaFile "" Then Set fso = CreateObject("Scripting.FileSystemObject") If fso.fileExists(MyTempMediaFile) Then Set MyMediaFile = fso.GetFile(MyTempMediaFile) MyMediaFile.Delete End If Set fso = Nothing Set MyMediaFile = Nothing End If SSTab1.Tab = 0 ’change bookmark, picture, document, and media; do google search


197

If KeywordCombo.List(KeywordCombo.ListIndex) "" Then If ListKeyId.List(KeywordCombo.ListIndex) "" Then BookmarkString = "SELECT url FROM bookmarks WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’" BookmarkRs.Open BookmarkString, cdirsdb, adOpenStatic, adLockOptimistic If BookmarkRs.RecordCount > 0 Then BookmarkRs.MoveFirst While Not BookmarkRs.EOF BookmarkList.AddItem BookmarkRs("url") BookmarkRs.MoveNext Wend End If BookmarkRs.Close If PictureRs.State = adStateOpen Then PictureRs.Close End If PictureString = "SELECT * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_type = ’" & "pic" & "’" PictureRs.CursorLocation = adUseClient PictureRs.Open PictureString, cdirsdb, adOpenStatic, adLockOptimistic If PictureRs.RecordCount > 0 Then PictureRs.MoveFirst If PictureRs!doc_name "" Then FramePicture.Caption = PictureRs!doc_name Dim MyPictureStream As New Stream Dim MyTempPictureFile As String MyTempPictureFile = CurDir & "\" & PictureRs!doc_name MyPictureStream.Type = adTypeBinary MyPictureStream.Open MyPictureStream.Write PictureRs!doc_content MyPictureStream.SaveToFile MyTempPictureFile, adSaveCreateOverWrite Image1.Picture = LoadPicture() Image1.Picture = LoadPicture(MyTempPictureFile) MyPictureStream.Close Set fso = CreateObject("Scripting.FileSystemObject") Set MyPictureFile = fso.GetFile(MyTempPictureFile) MyPictureFile.Delete Set fso = Nothing Set MyPictureFile = Nothing End If End If If DocRs.State = adStateOpen Then DocRs.Close End If DocString = "SELECT * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_type = ’" & "doc" & "’" DocRs.CursorLocation = adUseClient DocRs.Open DocString, cdirsdb, adOpenStatic, adLockOptimistic If DocRs.RecordCount > 0 Then DocRs.MoveFirst If DocRs!doc_name "" Then FrameDoc.Caption = DocRs!doc_name End If End If If MediaRs.State = adStateOpen Then MediaRs.Close End If MediaString = "SELECT * FROM documents WHERE keyword_id = ’" & ListKeyId.List(KeywordCombo.ListIndex) & "’ AND doc_type = ’" & "med" & "’" MediaRs.CursorLocation = adUseClient MediaRs.Open MediaString, cdirsdb, adOpenStatic, adLockOptimistic If MediaRs.RecordCount > 0 Then MediaRs.MoveFirst If MediaRs!doc_name "" Then lbMedia.Caption = MediaRs!doc_name End If End If ’do google StartGoogleSearch KeywordCombo.List(KeywordCombo.ListIndex) ’change the keyword checker KeywordIDCheck = LTrim$(RTrim$(ListKeyId.List(KeywordCombo.ListIndex))) Keywordtext = LTrim$(RTrim$(KeywordCombo.List(KeywordCombo.ListIndex))) Frame1.Enabled = True End If End If Unload ResultBrowserForm End Sub Private Sub SearchButton_Click() If SearchTerm.Text "" Then StartGoogleSearch SearchTerm.Text ’change the keyword checker Keywordtext = SearchTerm.Text SearchTermHistory.AddItem (SearchTerm.Text) SearchTerm.Text = "" Frame1.Enabled = True End If End Sub Private Sub SearchTerm_KeyDown(KeyCode As Integer, Shift As Integer) If KeyCode = vbKeyReturn Then Call SearchButton_Click End If End Sub

198

APPENDIX

Private Sub SearchTermHistory_DblClick() StartGoogleSearch SearchTermHistory.List(SearchTermHistory.ListIndex) Keywordtext = SearchTermHistory.List(SearchTermHistory.ListIndex) End Sub Private Sub SSTab1_Click(PreviousTab As Integer) If ActiveAddDocumentTrigger = True Then Unload AddDocumentForm End If If ActiveListDocumentTrigger = True Then Unload ListDocumentsForm End If End Sub Private Sub WebBrowser1_BeforeNavigate2(ByVal pDisp As Object, url As Variant, Flags As Variant, TargetFrameName As Variant, PostData As Variant, Headers As Variant, Cancel As Boolean) On Error Resume Next If InStr(url, "google.com") = 0 Or InStr(url, "google.com/url") > 0 Then ’If InStr(url, "yahoo.com") = 0 Or InStr(url, "yahoo.com/url") > 0 Then Cancel = True ’open secondary browser ResultBrowserForm.Show ResultBrowserForm.WebBrowser1.Navigate2 url URLtext = url ’checking the URL Dim KeywordIDCheckRs As New Recordset Dim FindKeywordIDArgument As String FindKeywordIDArgument = "SELECT * FROM keywords WHERE user_id = ’" & WorkRs!user_id & "’ AND project_id = ’" & WorkRs!project_id & "’ AND keyword = ’" & Keywordtext & "’" KeywordIDCheckRs.Open FindKeywordIDArgument, cdirsdb, adOpenStatic, adLockOptimistic If KeywordIDCheckRs.RecordCount > 0 Then Dim BookmarkCheck As New Recordset Dim FindBookmarkArgument As String FindBookmarkArgument = "SELECT * FROM bookmarks WHERE keyword_id= ’" & KeywordIDCheckRs!keyword_id & "’" & " AND " + "url = ’" & URLtext & "’" BookmarkCheck.Open FindBookmarkArgument, cdirsdb, adOpenStatic, adLockOptimistic If BookmarkCheck.RecordCount > 0 Then BookmarkTrigger = True End If BookmarkCheck.Close End If KeywordIDCheckRs.Close End If End Sub

Appendix D –Expert Questionnaire Form

Expert Profile 1. Gender: M F 2. Age: 3. What kind of products did you design (a) Consumer products (b) Automotive (c) Building (d) Medical product (e) Others: 4. How would you describe your design expertise? No experience 1 2 3 4 5 Expert 5. Do you often collect information regarding your design from other sources besides from your colleagues? (a) Only from colleagues (b) Yes from previous project (c) Yes from documents (books, journals, patents, drawing, etc) (d) Yes from internet (e) Yes from colleagues, previous project, documents and internet (f) Other: ........................................................ 199

200

APPENDIX

6. How often do you use a web-based search, to collect your design information? Never 1 2 3 4 5 Always 7. How would you characterize your expertise in collecting design information from the internet? No experience 1 2 3 4 5 Expert 8. Please rank the usefulness of the following search engines, in order from 1 to 5 (1 is the most useful) (a) Yahoo (b) AltaVista (c) Google (d) MSN search (e) Meta search engine 9. Which feature of your first rank search engine do you like the most? (a) Easy to use (b) Easy to find the expected result (c) Inspire ideas (d) Other .... Expert opinions on existing search engines 1. What is your opinion about the usefulness of existing search engines to support a design project? Not useful 1 2 3 4 5 Very useful 2. What is your opinion about the easiness of finding relevant design information using current search engines? Hard 1 2 3 4 5 Very easy 3. What is your opinion about the helpfulness of features of the existing search engines (bookmark, history, etc)? Not at all 1 2 3 4 5 Very helpful 4. Do you agree that the existing search engines need to be improved in order to be helpful for designers during the design project? Not agree at all 1 2 3 4 5 Agree 5. If yes, what part of these search engines should be improved?, please rank in order 1-5

APPENDIX D –EXPERT QUESTIONNAIRE FORM

201

(a) Capability to retrieve the relevant information (b) The algorithm to rank the collected information (c) The user-interface (d) More 6. What is your opinion about the impact of ‘Google’s My Search History’ (Figure 1) on the design process?

Figure 1: Google’s My Search History

- Not useful 1 2 3 4 5 Very useful - Not needed 1 2 3 4 5 Meet designer’s need - Not helpful in design 1 2 3 4 5 Very helpful Expert opinions on future search engines 1. What is your opinion about the embedding of internet search engines in the design process? e.g. embedding a search engine in a CAD System. Not needed 1 2 3 4 5 Ultimately needed 2. What is your opinion about a search engine and its results when these are dedicated and unique for a project? Not necessarily 1 2 3 4 5 It should be unique for a project

202

APPENDIX

3. What is your opinion about a search engine that is able to visualize the search context? Not needed 1 2 3 4 5 It needed and useful 4. What is your opinion about a search engine that could connect the search result with the existing documents? Not needed 1 2 3 4 5 It needed and useful 5. Will you briefly characterize a search engine that can be helpful to designers? Expert opinion on CDIRS 1. How useful did you find the provided system in general? Not useful nor helpful 1 2 3 4 5 Very useful and helpful 2. Like the ‘google account” -in order to save and edit search results and contexts- in CDIRS, a user’s profile needs to be created (Figure 2). After that, the user (designer) needs to log on every time to start a search. What is your opinion about these accountable search systems?

Figure 2: User’s profile

Distracting my search process 1 2 3 4 5 I am comfortable anyway 3. In order to make a search dedicated to a design project, the user has to key-in the project profile, including the initial keyword (Fig 3), What is your opinion about this? Distracting my search process 1 2 3 4 5 I am comfortable anyway 4. What is your opinion of the CDIRS searching interface, as you can see the relevant links, relevant documents, the right queries, and the history of queries in one interface, as shown in Fig 4 ? Not useful 1 2 3 4 5 Very useful


203

Figure 3: Project profile

5. What is your opinion on the user-interface for question 4? Very bad 1 2 3 4 5 very good 6. What is your opinion on the CDIRS features from question 4 that can link local documents to the search activities? Not important 1 2 3 4 5 Very important 7. Using the CDIRS, users can build their search contexts. This feature may allow the users’ search context to be explicit and visualized, shared by others and manipulated if necessary. (a) What is your opinion about building a search context during information collecting for product development/design as shown in Fig 5 Not important 1 2 3 4 5 Very important (b) What is your opinion about the context visualization in CDRIS? Very bad 1 2 3 4 5 Very good

204

APPENDIX

Figure 4: Searching with CDIRS

(a) Context building

(b) Typical context

Figure 5: Context treatment

(c) In practice, will the feature of copying and manipulating contexts (where the keywords, documents are also copied) be useful for other similar projects like those shown in Figure 6? Not useful at all 1 2 3 4 5 Very useful (d) In practice, will the feature of copying and manipulating contexts be useful for collaborative design? Not useful at all 1 2 3 4 5 Very useful


205

Figure 6: Copying context/keywords

8. Which property of the provided system will be the most useful? Please rank, in order 1-5 (a) (b) (c) (d) (e)

The context building Design project uniqueness To keep the search history Able to keep own document in a search result / context Able to keep the origin search engine advancements

9. To what extent do you think the system provided should be improved? (a) User interface in general Very bad 1 2 3 4 5 Not an urgent matter (b) Complexity Too complex 1 2 3 4 5 Accepted complexity (c) Context visualization Very bad 1 2 3 4 5 Very good 10. In your opinion does the provided system meet the designer’s expectations? Not at all 1 2 3 4 5 Very much 11. Will you briefly describe what should be improved in the CDRIS?

Context Knowledge


The concept of context is used in many fields of research and applications. An architectural object can be understood from its context. The “Dome of Rock” architecture and the urban surrounding, can be understood in the context of Islam Christian-Jews religions and the Arab-Israeli conflict. In this case, context is a kind of connection means between an architecture or urban design with social life and history. Another kind of connection gives a meaning to a group of matrix-style unstructured characters , as above. The characters are contextually grouped as “Context Knowledge” . This book explores the concept of context in order to support designers’ information search in the early design phases. The hypothesis is that the absence of context is the cause of difficulties to utilize data , information and knowledge surrounding designers

MUHAMMAD IKHWAN JAMBAK