Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.
This group project focused on creating a short video based on a given source, with the aim of communicating a clear and engaging message about air pollution as a global environmental issue. My responsibility was to produce the first one-minute segment, specifically the project background introduction. The goal of this section was to establish context, introduce the problem, and set the tone for the rest of the video. To achieve this, I structured the opening around a gradual narrative progression—from a global perspective to individual human experience.
Through this project, I realized that video editing is not just technical work, but a form of storytelling. Every shot, transition, and timing decision contributes to how the audience understands the message.
One key insight was the importance of visual metaphor. For example, starting with Earth from space helped communicate scale instantly, while ending with breathing emphasized vulnerability. This contrast strengthened the overall narrative without relying on excessive explanation.
I also learned that finding the right footage is as important as editing itself. Selecting clips that are consistent in tone, quality, and meaning significantly improves the final result.
In the weeks leading up to the exhibition, our project evolved through a series of increasingly specific questions rather than clear solutions.As the person responsible for the TouchDesigner system, I initially approached the task as a technical challenge: how to visualise breathing on a large screen. However, the development process revealed that the real difficulty was not technical execution, but conceptual clarity.
We developed three distinct versions of the system. Each version was presented and discussed with David, whose feedback consistently pushed the project beyond its current level rather than simply validating progress.
Version 1: A Clear but Superficial Idea
The first version translated breathing into a simple expanding and contracting form. It was visually legible and technically stable. However, during feedback, a critical issue emerged: The system looked like breathing, but did not feel like breathing. This distinction forced us to confront a common problem in digital media design — the difference between representation and experience.
Version 2: Adding Interaction, Increasing Complexity
In response, we introduced real-time input, allowing the system to respond directly to human breath. While this made the system more interactive, it also introduced instability:
inconsistent sensor input
visual noise
lack of rhythm
During discussion, David shifted the focus again by asking: What is the audience supposed to understand or feel from this interaction?This question exposed a gap between system behaviour and audience interpretation.
Version 3: Designing for Perception
The final version emerged not from adding features, but from removing and refining them. We simplified the visual language and prioritised rhythm over responsiveness. Instead of directly mapping breath to movement, we shaped the output to feel more organic and continuous. This version was ultimately selected for the exhibition.
Reflection
What stands out in this process is not the progression of technology, but the role of critique. Each feedback session did not solve problems — it reframed them. Rather than asking:
“How do we make this work?” We began asking: “What is this actually doing?”
Insight
This experience highlights an important aspect of collaborative design: Good feedback does not confirm decisions. It destabilises them in productive ways. The final outcome was not the result of a single idea, but of sustained negotiation between intention, critique, and revision.
One of the least discussed aspects of DMSP is semantic conflict. Everyone agrees on: “we want something immersive” No one agrees on what immersive means.
Language as Problem. Words like: immersive, interactive, narrative are dangerously vague. In our group: one member imagined theatre, another imagined game design, another imagined data visualization. We were using the same words to describe different worlds.
A useful example of how meaning is not fixed but negotiated can be seen in the interactive installation Tall Ships by Gary Hill. In this work, visitors walk through a dark corridor where projected human figures slowly approach them in response to their movement. While the system behaviour is technically consistent, the interpretation is not. Some viewers experience intimacy, others discomfort, and some even fear.
As critics have noted, the installation produces an “uncannily real exchange” that makes viewers aware of their own psychological state This highlights a crucial issue in collaborative design: even when the system is stable, meaning is not. In our group, we assumed shared understanding when using terms like “immersive” or “interactive”. However, as with Tall Ships, interpretation is shaped by individual perception rather than shared definition. This suggests that meaning in design is not transmitted — it is constructed.
I would like to show our resolution Strategy to solve such questions. We introduced reference mapping. Each member brought: one artwork, one film, one interaction example. We compared them. This externalised assumptions.
In terms of my insight. I think meaning in collaborative design is negotiated, not given. Language is not neutral. It is a design material.
Public exhibition changes everything. In studio, we control lighting, sound, behavior. In public: people interrupt children run through sensors phones flash someone will ask “what does this do?” Looking at installations like Rain Room by Random International, the audience completes the work. Without participants, it is just plumbing. Testing with Humans We ran informal user testing with classmates. Unexpected findings: They didn’t read instructions. They preferred playful ambiguity. They touched what we told them not to. This forced us to design for behaviour, not ideal use. Insight Audience is not passive. They are unpredictable co-authors.
I insert a link named Rain room. The system does not simply react to the audience — it requires them to exist. The audience doesn’t just experience the work — they perform it. Interactive installations shift authorship from designer to system + audience.
In DMSP course we talk a lot about tools: Touch Designer, Arduino, projection mapping, sensors. But collaboration itself is a technology. It requires, for example: protocols, debugging, version control, user testing, maintenance. When collaboration fails, the “system” crashes.
Moreover, I am willing to discuss that the course suggests modelling ourselves like a production company. We tested this. We assigned roles: Director, Technical Lead, Media Designer, Sound Designer, Documentation Lead.
Initially, this clarified responsibility. But we noticed something interesting: Roles created ownership, but also territorialism. The media designer began defending visual decisions as if they were intellectual property. The technical lead became gatekeeper of feasibility.
In terms of ‘comparison’,Looking at collective practices like team Lab, their work appears seamless. But interviews reveal a highly structured internal communication system. They don’t just make immersive work. They engineer collaboration.
In that case, We introduced rotating critique sessions where each role critiques their own domain publicly. This flattened hierarchy.
The result for instance: less ego, more shared language, more integrated design.
In a nutshell, I think collaboration isn’t soft skill. It’s infrastructure.
After reading the feedback, I realized that our concept is actually strong, but our technical work does not yet fully support it. As the person responsible for coding, I started to think more carefully about how the technology can truly express our idea, instead of just creating visual effects. For example, the particle system and noise texture should not only look interesting, but should represent invisible pollution and the slow damage happening to the body before people are aware of it. I was especially inspired by the idea of “destroyed rights” and the political meaning of the passport. Through code, we can create unfair systems, such as random assignment, to reflect the arbitrariness of birth and privilege. I also began to question whether we really need to release real gas or control people’s breathing, or if we can use sound and visuals to simulate these experiences in a safer and more meaningful way. This feedback helped me understand that technology is not just a tool, but a language. From now on, I want to focus on building a clearer experience structure and make sure every technical decision supports our core message.
I followed the flowchart and connected nodes like Audio Device In CHOP, Analyze CHOP, Math CHOP — volume and spectrum data came through fine. But at first I just linked the volume value directly to particle size and speed — the result was really stiff. Particles either stayed still or suddenly jumped, nothing like the “sound mountain” I had in mind. Then it hit me: driving all particles with a single value flattens everything. So I switched back to a Python script inside Geometry COMP, looping through each particle per frame, using Noise TOP to give each point its own base height, then scaling the whole thing with volume. Now the movement feels natural — when the sound gets loud, the whole “mountain” rises, but each particle keeps its own little wobble. One thing that really stuck with me: Sound is a trigger, but it shouldn’t be the only boss. Visualization isn’t about translating sound into an image — it’s about giving sound something that’s already alive, and letting it move along.
