DYNAMO: A Dynamic Architectural Memory On-line
Dept. of Architecture, Urban Design and Planning
University of Leuven, ASRO, Arenbergkasteel
B-3001 Heverlee (Leuven), Belgium
Dept. of Architecture, Urban Design and Planning
University of Leuven, ASRO, Arenbergkasteel
B-3001 Heverlee (Leuven), Belgium
This paper reports on ongoing research about the role of cases in the field of architectural design education. Part of this research comprises the development of DYNAMO, a web-based design assistant for student-architects. DYNAMO, which stands for Dynamic Architectural Memory On-line, can be considered a Case-Based Design (CBD) tool in so far that it was inspired by the cognitive view underlying Case-Based Reasoning (CBR). CBR is a paradigm within the field of Artificial Intelligence (AI), based on a memory-centred model of cognition. Yet, instead of simulating this model within a computer program by using AI techniques, the objective of the tool is to facilitate and nurture this way of reasoning within the human designer's mind. In addition, DYNAMO attempts to enrich the model by situating it in a larger context. The idea is to provide a platform for interaction and knowledge exchange between designs and (student-) designers in various contexts and at different levels of experience.
After a quick repetition of the cognitive model underlying CBD, the paper will outline the main ideas behind DYNAMO, thereby pointing out how the tool incorporates this model, and at the same time extrapolates it beyond the individual. This extrapolation comes down to stimulating and intensifying interaction, not only between a single user and a computer system, but also between design projects, among (student-)designers, and between practice and education. Section three discusses the early implementation of these theoretical ideas in a working prototype. More specifically, it describes the three main components of the tool: the cases, the underlying structure, and the user interface. Finally, DYNAMO is situated in the context of other comparable tools that have recently been or are being developed in the field of architectural design.
The cognitive model behind CBD
Implicitly, or otherwise, all CAAD (Computer-Aided Architectural Design) systems embody a particular view of design and designers (Tweed, 1998). Central to the view embodied by DYNAMO is the model of cognition underlying CBD, and CBR in general. There is neither space nor need to describe all details of this model in depth in this paper. Instead, we will focus on two aspects that are crucial to understand the objectives of our tool.
One aspect in which CBR differs from other views of reasoning is that people’s knowledge does not only consist of abstract, generally applicable principles, but also of concrete, specific experiences (cases) (Riesbeck & Schank, 1989; Kolodner, 1993). Within the domain of architecture, the term ‘experience’ can be interpreted in several ways (Heylighen, 1998). Strictly speaking, having experience in architectural design means having designed yourself. In a wider sense, visiting buildings, i.e. physically experiencing built objects designed by others, can be considered a form of gaining experience too. Finally, architects often acquire knowledge ‘second hand’ through pictures, drawings and texts about existing projects in magazines, books, expositions and lectures. What all these interpretations of experience have in common, is that there is a concrete design project at stake. Concrete projects play a key role in the field of architectural design. Practising architects are typically concerned with the actual concreteness of the specific objects they are designing rather than with generalisations (Liddament, 1999). But also architectural education heavily relies on concrete cases. The particulars in a given project offer students an integrated view of design issues that would be lost if these issues were taken up separately.
The theory of Dynamic Memory
A second aspect of CBR’s cognitive model on which we would like to dwell, is the dynamic behaviour of human memory. Being based on the theory of Dynamic Memory, the model claims that memory is dynamically changing with each new experience (Schank, 1982). Thinking of memory as a constantly growing trace of experience seems more plausible than considering it as a static knowledge base, as more traditional cognitive models do. Both Rule-Based and Model-Based Reasoning reduce the human mind to a mere repository of general principles. When it uses its knowledge, that knowledge is not changed, which obviously does not correspond to the way in which human memory works. Designers and people in general learn from their experiences and using memory itself is such an experience.
The model does not only claim that memory changes, but also proposes some specific kinds of changes. The simplest way in which a memory improves its behaviour is obviously by acquiring new cases. Each experience is stored in memory, providing it with additional familiar contexts for new situations. As already mentioned, cases in architectural design can be acquired by actively designing, but also by visiting a building or browsing architectural magazines.
Sometimes, however, a case is not immediately stored in the right way. This causes the case to be recalled in a situation for which it turns out to be irrelevant or inappropriate. Hence, a second manner in which memory changes is by re-indexing already stored cases. It allows memory to fine-tune its recall apparatus so that it remembers cases at more appropriate times. As will be illustrated in section two, in architecture it is even highly questionable whether there exists such a thing as the ‘right way’ to store a design project in memory.
A third kind of memory change is the creation of new generalisations. This way of learning derives from the fact that what starts as a new experience, different from the norm, eventually might become the norm. What is considered normal in architecture today was not normal ten years ago (Tweed, 1998). And what goes for architecture in general, equally applies to individual architects, design offices or architecture schools.
Convinced of the importance of concrete cases in architectural design, and inspired by the theory of Dynamic Memory, we decided to develop a design tool in which concrete design projects play the central role. The tool, which is intended to assist student-architects in the design studio, tries to kill two birds with one stone. At short notice, it provides students with a rich source of inspiration, ideas and design knowledge for their present design task, as it is filled with a permanently growing collection of design cases. Its long-term objective is to initiate and nurture the life-long process of learning from existing designs as suggested by CBD's model of cognition.
CBD provides us with a plausible explanation of how people, and more specifically designers, acquire (design) knowledge. Yet, like all design theories, it privileges one particular view of design, thereby obscuring other equally valuable aspects. In case of CBD, design is considered predominantly a cognitive activity, whereas the social aspects of acquiring design knowledge are largely underplayed. In the field of architecture, however, knowledge and insights are developed and renewed as much through interaction as by individuals in isolation. DYNAMO can become an important theatre for this interactive process of knowledge development, by offering a platform where different forms of interaction can take place, and at the same time acting as a repository to nurture these interactions and store their results. Therefore, the tool is conceived as an (inter-)active workhouse rather than a passive warehouse (Schank & Cleary, 1995): it is interactively developed by and actively develops its users’ knowledge.
A first form of interaction DYNAMO supports is the confrontation between different design projects. Consider, for instance, the recent extension of the Musée des Beaux Arts in Lille (France) designed by Ibos and Vitart and Rossi's Bonnefantenmuseum in Maastricht (The Netherlands). Both projects share the same program, the period in which they were built, and their location nearby an existing building - the old Musée des Beaux Arts and the Wiebenga Hall respectively. Yet, the way in which the new building stands towards the old is quite different. In Maastricht the approach can be coined 'juxtaposition', whereas in Lille the relation between both buildings is one of 'reflection', as the new museum is literally a mirror of the old (see Figure 1).
Vice versa, a similar concept may underlie quite different designs. Take for instance two projects by Robbrecht and Daem, the Aue pavillions for Documenta XI in Kassel (Germany) and the office building for the Katoen Natie in Antwerp (Belgium). Although these designs differ considerably in program, site and context, one of the major ideas underlying both is that of a train passing another one.
This kind of confrontation between dissimilar projects based on similar concepts - and vice versa - can provide crucial insights into a specific project, as well as into architectural design in general.
In order to support and stimulate such confrontations, DYNAMO has at its core a web of indices that allows retrieving and browsing between design cases in multiple ways. Every project is labelled with several features and linked to projects with common characteristics. If we consider design cases as encapsulations of design knowledge, this web of indices further enhances each case’s value. It allows students to approach a design from different perspectives and to situate it in relation to other designs. The knowledge content of DYNAMO therefore does not only reside in the cases it contains, but also in the web of indices between them.
Between human designer and computer
A second form of interaction DYNAMO supports is that between the human user and the computer system. The tool is interactive in the sense that students cannot only use the web of indices to consult and navigate between the cases in memory, they can also change and improve memory as suggested by the CBD model, i.e. by adding new projects, making new links between them, creating extra indices etc. Involving the user in case collection for a field like architectural design goes without saying. Yet, extending this approach to (re-)indexing probably needs some further explanation.
As already mentioned, it is highly questionable whether there exists a 'right way' to store a design project in memory; in other words, whether it is possible to label it once and for all by a set of indices (Heylighen, 1997). One reason is that the meaning and interpretation of a project - and thus its position among other projects - changes over time due to changes in its use, other projects imitating or opposing it, or new developments in its environment. Take for example Van den Broek & Bakema's Auditorium of the Technical University in Delft (The Netherlands). Until recently, this colossal concrete building looked like a spaceship dropped on the campus by accident. With the arrival of Mecanoo's new library, however, the Auditorium has gained a totally new context. The spaceship, rather than having fallen from the sky, has landed at the foot of an inviting green hillock, as if the place was always meant as a landing pad for spacecraft (Wortmann, 1998).
A second reason for involving the user in the process of (re-)indexing is that an architect will not interpret the same project in the same way all the time, since his present design task may influence his interpretation considerably. Being involved with a specific design makes him look differently at previous projects and come to new insights, leading to new or additional indices.
Calling in the user, i.e. a (student-)architect actively involved in designing, in case collection and (re-)indexing has the advantage that DYNAMO can draw on his knowledge to permanently nourish its content and refine its indices so as to stay in tune with his evolving needs, preferences and insights.
This approach, however, is only feasible when the tool is used collectively by multiple (student-) designers connected via the web. By inherently compensating for the weaknesses of individual users, this collective use creates a whole potentially stronger than any individual designer (Press, 1998). DYNAMO therefore can be called interactive, not only in the traditional sense of human-computer interaction, but also because it supports interaction among students, studio teachers and other designers in multiple ways.
First, it gives students access to the work - and thus design knowledge - of architects outside the studio. In most theoretical courses like architectural theory and history, students are confronted with a fairly narrow canon of works by exemplary architects, usually through a static slide show. DYNAMO provides them with a much broader collection of cases, and this in a format that better fits their designerly way of thinking (Cross, 1982). Important to note in this respect is that ultimately the tool is to become part of an integrated design environment that supports sketching, modelling and testing from the very start of the design process (Neuckermans, 1992).
Second, DYNAMO serves as a collective external memory (Wegner, 1987) for the students and design teachers in the studio, enabling them to store and share knowledge, expertise and insights accrued in the course of the design process. This repository acts to inform the assignment and generate well-founded design solutions.
Finally, the tool has the potential to increase the frequency and quality of the dialogue among students as well as between students and studio teachers. Newly added cases or indices, for example, may act as points of departure for discussion by highlighting specific aspects of the assignment not initially shared (Press, 1998). Rather than from some mysterious process in an individual architect's mind, it is often through such discussions that new concepts in architecture emerge.
Between practice and education
A fourth level of interaction the tool wants to support, is between architectural education and the world of practice for which students are being prepared at school. In most architectural schools today the relation with professional practice is limited to hiring practising architects for studio teaching. Being accessible to both students and professional designers, DYNAMO provides an opportunity to expand and at the same time intensify this relationship. Architects working in practice may draw fresh insights from students' work. Vice versa, input from practice (design projects as well as indices) keeps schools permanently updated about the constantly changing problems and processes within the profession and the society at large, which enables them to formulate design assignments of topical interest. This does not mean that education should submit its agenda unconditionally to the 'hot topics' in practice. Instead, it should take those topics further and, not hindered by the constraints of practice, play the role of an experimental laboratory, a think tank for architectural design. In this way, DYNAMO offers the prospect of building a bridge - made up of cases - between education and practice, facilitating productive exchange of design efforts between both parties.
Although the tool itself does not perform any form of (case-based) reasoning, it nevertheless can be ascribed a certain form of action in the sense that it actively develops students' design knowledge by stimulating them to learn from previous projects. When adding a new case to DYNAMO, for example, the user is responsible for representing and labelling the project in such a way that important aspects are legible and easily accessible (Akin, 1997). This forces him to view the project from different perspectives and to answer questions like ‘what does this project tell me?’, ‘in what circumstances might it be a relevant example?’ and ‘where does it fit in relation to the other projects?’, questions that enhance the user’s ability to understand the project and remember it later on (Schank & Cleary, 1995). In this way, the tool promotes the kind of thinking that helps to learn in a better way from existing designs.
Using DYNAMO in the design studio in addition ensures that design knowledge is gained in the same context as it will be used. In general, students very rarely bring knowledge acquired in theoretical courses to the studio (Marda, 1997). The reason is that they have not mentally encoded the material in terms of issues they face when designing. Because they have not thought about how it helps to solve problems at stake during design, the knowledge is difficult to access when they do face such a problem (Schank & Cleary, 1995). In the studio, on the other hand, the project in which students are involved provides a framework to organise newly acquired knowledge. Thus, the project does not only serve as a motivator - it stimulates students to learn because they are eager to design a good project - but also as a guiding context to integrate what they learn.
This section turns from the theoretical issues of DYNAMO to its implementation as a working tool. A first prototype has been developed within the scope of a graduate’s thesis (Segers, 1998; Heylighen et al., 1998) and has recently been refined. The prototype consists of three major components: 1. a collection of cases – the actual content of the tool; 2. the underlying database that structures this content; and 3. the user interface allowing to both consult and modify the content.
Cases in DYNAMO are entire building designs, both built and unrealised projects. With an eye on a wide applicability, extension to include other design scales - both upwards to urban design and downwards to building elements - should be possible. For each case, all information available is collected on a central, dynamically constructed (web-)page with links to the corresponding files. Using a web-based approach allows us to combine traditional media, such as text, images and graphics, with 3D-models, computer animation, video and sound.
The advantages of this combination are manifold. Compared to written data, the visual and spatial representation of architecture better fits the architect’s way of thinking. Essentially, a design comes into being through manipulation of non-verbal information: the designer knows, thinks and works in a visual way (Cross, 1982). Furthermore, the combination of several modes of representation provides students with a richer learning experience (Vora & Helander, 1997), resulting in a better understanding of the design. Finally, the use of hypertext allows us to link the tool to external information resources on the World Wide Web, which considerably enlarges the scope of its content.
The underlying database that structures the cases was created with Microsoft ® Access 97. For each case the database inventories a set of indices, i.e. features that can serve as filter criteria during retrieval. Three of them – architect, building name and user who entered the project – are obligatory indices and must be filled in for each project in the system. Not so much because they are extremely important characteristics, but because their combination serves as an ID that identifies each case in an objective, unambiguous way.
The remaining indices are optional and only filled in when the feature is considered relevant. In the most recent version of the prototype, they are clustered into five categories: concept (metaphor, analogy, …), form & space, function (present purpose, original purpose in case of conversion, …), construction (construction material, type of construction, …) and context (period, site, climate, …). All together, this web of provisional indices allows approaching the cases from different perspectives and selecting them by various criteria.
We deliberately use the term ‘provisional’ because as soon as the tool will be in use, users can index cases by other features than initially available in the prototype. So far, the provided categories and indices roughly cover the issues usually at stake during architectural design. Yet, despite many shared interests among architects in general, there is considerable variation across individuals in how they go about designing (Tweed, 1998). By actively involving the users, i.e. (student-)architects in the indexing process, the tool can be made more in tune with their specific interests and needs. For example, one could imagine an architect who loves music and would like to categorise designs according to famous composers or different music styles.
The interface required to access DYNAMO is composed of different modules. The user interacts with the tool through a standard web-browser, in the prototype Netscape ® Communicator 4.05. He can consult the system by simply specifying his selection criteria on a search page. The query may be very simple, for example, a specific building program. It is also possible to enter more complex queries so as to find cases that match two or more criteria, for instance, conversion of warehouses in a suburban context during the 1990's. Upon submission, the query is handled by a PHP-script on the server that bridges the gap between browser and database. By means of Open Database Connectivity (ODBC) this script can search the database for cases that match the query without having to start up Access. When the search is completed, the script transmits the catch to the browser, which displays the result as a list of cases with links to the corresponding pages.
In Figure 2, for example, the leftmost panel of the browser shows the result of a search for private residences on a sloping site. When clicking the name of a specific project in the list, its central page appears in the bigger right-hand panel. Here it features the page of the Koshino House designed by Tadao Ando. At present, the information on this project available in the tool comprises a 3D CAD-model, drawings (axonometry, several plans and cross section) and photographs, a text excerpt from a book, and finally a short list of bibliographic references, which can serve as a kick-start to more detailed study. Indeed, DYNAMO does not pretend to replace all existing information on architectural design projects. Rather, it wants to make these projects accessible in a - for designers - cognitively comfortable way.
Apart from consulting the projects present in the system, the interface also allows feeding the tool - with new cases and/or indices - via the browser without having to change to another program. When adding a project, the user first sees a dialogue box requesting to fill in the case’s ID – i.e. architect, user and building name – and to select the file(s) he wants to enter (see Figure 3). As soon as this mandatory information is submitted, a new dialogue box pops up with the request to specify one or more optional indices. In the same way, the user can add supplementary files to cases already present in the tool or label cases with extra indices.
Experiences with DYNAMO and related work
In order to test the functional performance and explore the underlying theoretical ideas, the prototype was recently used in a 4th year design studio. The 48 students who attended the studio were asked to design a public library within a former factory hall, focusing on the re-use of industrial architecture. Before the start of the assignment, DYNAMO was filled with information on several libraries and conversion projects suggested by the studio teachers. Students were able to access this information not only from the computers at school, but from every PC connected to the Internet.
After the conceptual phase of the project, students were given a questionnaire in order to examine whether the tool succeeded in engaging students. With two exceptions, all of them would like to use DYNAMO again in future design assignments. Although this indicates that students liked the tool, they were not necessarily engaged in ways that completely met with our expectations. In principle, we expected that students would consult the cases in the database, but also actively participate in adding and commenting on projects. This goal was probably too ambitious because of the very limited time schedule of the assignment. As one student put it in the questionnaire, "it seems a very interesting tool, but we simply don't have any time to use it." Moreover, students were far from being encouraged by their design teachers to use DYNAMO. In general, design teachers are rarely burning with enthusiasm to introduce computer tools in design education (Neuckermans & Geebelen, 1999). In case of CBD tools, this enthusiasm is even harder to find, as these are thought to increase the danger of students blindly copying previous projects considerably. In addition, it should be mentioned that at the time of this project, the computers were not yet located in the design studio itself, but in a separate computer class. As long as students must leave their drawing board in order to access a CBD system, the majority of the students simply will not use it. Although these factors – lack of time, of encouragement by the teachers, and of computers in the studio - may not relate directly to DYNAMO itself, they may have prevented the tool from functioning the way it was originally meant to. In spite of these obstacles, however, the responses suggest that students were very enthusiastic about DYNAMO.
With an eye on future improvements, the questionnaire also asked how students liked several aspects of the prototype, such as the interface, cases, selection criteria, etc. On a five point scale (1=very negative 5=very positive), the average rating for all aspects was either positive or neutral. The selection of cases, choice of indices, language used (English), and user friendliness received slightly higher ratings than the user interface, ease of learning and speed of the program.
Based on the feedback received in these questionnaires, the prototype has now been improved. In the near future, this new version will be used in a 2nd year design studio, led by more enthusiastic design teachers, and equipped with sufficient computers. In addition, we are planning a more detailed analysis of the learning outcome of the first experience with DYNAMO. The most ambitious goal is to analyse the impact of using DYNAMO on the quality of students' final project, and the influence of factors like frequency and duration of use, computer skills, etc.
Awaiting the results of this analysis, let us conclude by situating DYNAMO with regard to its nearest relatives amongst other digital archives, intelligent libraries and CBD systems. LORA, the Library Of Recommended Architecture, is an on-line library for exemplary 20th-century architecture (http://www.archimedia.khs-linz.ac.at/loraagent/). Architects, students and journalists are asked to submit their favourite projects, which are listed either according to architects or to the users who recommended them. In addition, projects can be searched by type, year of construction, city and country. ArchINFORM is a similar database including over 7000 built and unrealised projects from various architects and planners (http://www.archINFORM.de/). Once again, the main focus is on architecture of the 20th century. Projects can be selected by architect, town or keyword. At first sight, both systems show significant similarities with DYNAMO, e.g. they are web-based and on-line accessible, projects are entire buildings, etc. However, like many catalogues, their indexing system seems to serve historians and critics better than architects. Whereas the former regard an existing design as a subject to study, the latter perceive it as a source of images and concepts that can drive their own projects. By actively involving the users, i.e. (student-)architects in the indexing process, the collection could be made more in tune with their specific needs. Yet, there is no possibility to index projects interactively, or - in case of ArchINFORM - even to submit new cases. Furthermore, neither of both systems intends to become part of an integrated design environment.
Within the field of CBD, we would like to mention three systems that show several similarities with DYNAMO. To our knowledge, Archie-II is the longest running and most developed CBD tool for conceptual building design. Efforts to generalise the system have resulted in Design-MUSE, a general shell for developing CBD tools, which proves the relevance of the approach for other design disciplines (Domeshek & Kolodner, 1997). Archie-II stores floor plans of courthouses and libraries, supplemented with stories from different stakeholders - people who carried out, use or maintain the building - about how the design turned out (Domeshek & Kolodner 1993). Making such stories available to future architects shows several advantages: a story may propose solutions, warn of potential pitfalls or suggest evaluation criteria. Yet, organising several stories around a case implies a highly complex indexing system, which makes user participation in case collection or (re-)indexing extremely difficult, if not impossible. Facilitating such participation is one of the major ambitions of DYNAMO.
A second CBD tool we want to mention is MEMORABILIA (Oxman & Oxman, 1993). This system stores memorable design cases that have the status of precedents in order to provide student-architects with meaningful concepts for museum design. Apart from being exclusively meant for students, a major difference with DYNAMO lies in the origin of these concepts. In MEMORABILIA, the system developers have identified a concept vocabulary by analysing architectural literature. In DYNAMO, on the other hand, concepts are interactively identified and refined by the users, i.e. by (student-) architects actively involved in designing.
A similar user-defined approach to indexing is found in EDAT, which is undoubtedly the closest relative of DYNAMO (Akin et al., 1997). Similarities are striking and include the tool's objectives and underlying pedagogical ideas as well as some aspects of its implementation. EDAT is conceived as a centralised store for information gathered by student designers in the early stages of the design process. Just like DYNAMO, the tool forces students to represent and index design information in a clear and comprehensible way. The work on EDAT provides an important foundation for the further development of DYNAMO. Because the EDAT project had to be terminated, its developers were in fact quite pleased to see their approach carried on in our research.
Discussion and future work
Inspired by the view of cognition underlying CBD, we are developing a web-based design tool to support student-architects during design. We have outlined the theoretical ideas behind the tool, thereby pointing out how it incorporates CBD's view while at the same time extending it beyond the individual. Furthermore, we have described an early implementation of the tool as a working prototype. ‘Real’ CBD researchers will probably judge DYNAMO unworthy of the label 'CBD', because the tool itself does not perform any (case-based) reasoning. Indeed, since cases are opaque to the system - i.e. it does not have any knowledge of the cases beyond their indices - the only thing DYNAMO can do is retrieve them, based on the values of their indices. Whether and how these cases are (re-)used for new design tasks is left completely to the user. Yet, one cannot deny the concept of the tool being firmly rooted within the theory of Dynamic Memory. Moreover, its interactive approach to (re-)indexing does, if not supply, then at least stimulate the kinds of awareness needed to effectively call in previous cases during design, i.e. a productive 'balance' between relevance, innovation, difference, etc. (Liddament, 1998).
Nevertheless, the objective of our research is obviously not to obtain the CBD - or whatever other - label, but to clarify and support the use of cases in architectural education and practice. The utility of CBD is evidenced in a wide range of disciplines. But as we also have noted, it upholds a particular view on design which cannot be forced to fit our growing understanding of design as a socially mediated activity, and of the role of interaction in the development and renewal of design knowledge. Therefore, we have opted for an extrapolation of CBD so as to embrace this social aspect of architectural design. This might help to generate a design tool that is cognitively comfortable to designers (as it is based on their cognitive behaviour) and at the same time engages them into interaction with other designers in different contexts and at different levels of experience.
Although DYNAMO has already received much positive feedback from students who used the prototype, we are the first to admit that further evidence is needed for the relevance and value of our approach. Therefore, we are planning a more detailed analysis to shed more light on the learning outcome of using the tool. A further step is to deploy the prototype across multiple design studios within different classes, schools and even professional offices connected through the web so as to fully exploit its potential of knowledge exchange between (student-)architects. Although this scenario still lies largely in the future, we are already aware of some important problems such distributed use would bring about, especially with regard to (inter-)active indexing. It is far from likely that (student-)architects in different contexts and at different levels of expertise will automatically agree upon a common indexing vocabulary. A possible solution may therefore be to link DYNAMO’s indexing system to a recognized thesaurus, such as the on-line Art and Architecture Thesaurus of the Getty Research Institute (http://shiva.pub.getty.edu/aat_browser/). This would force users to select indices that are available in the thesaurus. However, we do not intend to undertake this step before we have more robust empirical results to support our approach.
This research is sponsored by the Fund for Scientific Research (FWO) Flanders, of which Ann Heylighen is a research-assistant. The authors would like to thank Jan E. Bouwen, Benjamin Geebelen, Kris Nuyts and Toon Van Borm for their critique, comments and suggestions and Karen Depoortere for keeping an eye on the spelling and grammar of the text. A very special thanks goes to Raf Segers, who implemented the first version of the prototype, and to Peter Ariën for his assistance with this implementation.