3.1.3.2. ‘Kurort’: Methods
The ‘Kurort’ project is created according to a truly processpatching approach. As a general design approach, it was decided to use a design method inspired by participatory design. The most important aspect borrowed from participatory design is the early inclusion of the participant; this was done by means of early prototypes where the audience could interact with the work. The artists and the team undertook studies into brain function research and neural networks. The core development of the system was dealt with by Stock, the engineer for the V2_Lab, in close collaboration with Verouden, who was also the mediator, on a technical level, with Oei. Verouden, who has a mixed background, represented the mediator in this team. On a conceptual level, the emotions for Lizzie were based on dramaturgical values selected by the artist. As mentioned earlier, in this phase of the project, several approaches, such as the implementation of non-technical elements, were used to circumvent the shortcomings of the system. These physical and analogue parts bear references to ‘bricolage’ aesthetics. The ‘Kurort’ concept is focused on the experience; it doesn’t work according to a clear set of technical requirements, that could be solved by the technicians in the team. In a sense, the ‘Kurort’ project shows most resemblance to experience design, although this does not make it easier in terms of design approaches, as experience design is a relatively new branch in design practice. In H.C.I. practice, it is possible to distinguish roughly two approaches to technical development; either the engineer solves a clearly defined problem or the engineer realises a system design plan. The latter approach is usually based on a design prototype. For the engineers in the ‘Kurort’ case, it was difficult to build something when the idea was not clear. This is partly caused by the problem that emotion theory still does not provide us with communication concepts to translate emotions into a computable language (see also 2.2.7.2.). Moreover the lack of ‘problems’ or clear technical requirements caused a vacuum for several of the ‘Kurort’ engineers, who preferred to work using a problem solving approach. In the research and development process, it was decided to re-phrase the project’s objectives. The artistic objective is thought of from a user’s perspective; this needed to be translated into the requirements for the technical backbone of the system. The project manager and the V2_Lab coordinator took the initiative to re-formulate the artistic concept and the engineers had a problem to solve: how can the system convert or translate the actions of the participants into emotions? Although this was still a rather abstract problem, it turned out to be a better approach for the engineers. The disadvantage of this ‘problem creating’ approach though, is that it doesn't really acknowledge the value of the 'connecting' or 'knitting' artistic method(s), and this might be something worthwhile to solve, as practicality isn't the only valuable asset in art nor in technological progress. Moreover, the ‘problem creating’ approach does not fully support the importance of the participant or audience as a key player in establishing the experience. I conclude with another aspect that is often experienced in participatory design, and which was briefly mentioned in the previously discussed ‘whisper’ project. The coinciding trajectories of software testing and user-testing cause trouble as the test results are useless and the software tests are carried out in unreliable ways. This was confirmed by Scott deLahunta, the mentor of the ‘Kurort’ project.[244] Furthermore the test report by Johannes Birringer [245] shows us the difficulty to communicate the goal and the testing event to the testers, as testing the environment does not resemble the known concept of user testing (of new products), neither does it resemble a try-out situation (as in theatre). This turned out to be a source of frustration by some of the audience members as well as for the engineers and artists. Also Birringer confirmed that the test results in this case are far from useful, as it is impossible to distinguish the technical short-comings from the interaction flaws. It is however, not recommended to separate the technical from the artistic or conceptual interaction aspects entirely as this might lead to more obstacles for future integration of the two. A stable working low-tech prototype for testing purposes is suggested as the most efficient and effective approach to take. (See also the hacked prototype for the ‘M.U.S.H.’ device as described in 3.1.1.)In these situations, a chronological development trajectory is recommended, as was applied in the ‘M.U.S.H.’ project. In the aRt&D Matrix below, the conflicts between problem solving and connecting are listed. The reductive method demands a sharp goal and no divergence, while the processpatching method demands space for user-centred iteration and improvisation.
| Artistic aim, objective | Method | Characteristics | Group dynamics, team composition | Advantages / Disadvantages |
| Problem solving | Reductive method | Single or limited disciplinary problem solving approach, applied research, practical method | Technicians as facilitators, artists as engineer in single / limited disciplinairy situation, no improvisation | Sharp goal, clear aim, useful for tool development, no divergence, lineair, predictable, assistance or facilitations rather than co-operation |
| Innovating arts, re-contextualising technology, creating new connections | Process patching | (Re-)mixing and re-appropriating methods from scientific fields and (non) technologies, aesthetic driven, often large scale | Parallel and intersecting methods and approaches, from involved disciplines |
Freedom to change methods re-contextualisation, space for cooperation, ground for new discoveries and innovation, |
| Participatory method | Itterative process, design method thought from the end-user / participant's perspective | Complicated tocombine with problem solving, interdisciplinary cooperation, 3-th space | Ground for co-operation, experience oriented applications, difficult to combine with problem solving | |
| User centred design method | Design method focussing on theparticipant(s) experience | Focus on end- user/participant |
(fig. 20. overview ‘Kurort’ methods (Bold))
