by florian.prasse -

#6 Final Prototype and Video

Have fun with this Video to find out what my actual Prototype is.

Reflection

This project began with a vague idea to visualize CO₂ emissions — and slowly took shape through cables, sensors, and a healthy amount of trial and error. Using a potentiometer and a proximity sensor, I built a simple system to scroll through time and trigger animated data based on presence. The inspiration came from NFC tags and a wizard VR game (yes, really), both built on the idea of placing something physical to trigger something digital. That concept stuck with me and led to this interactive desk setup. I refined the visuals, made the particles feel more alive. I really want to point out how important it is to ideate and keep testing your ideas, because there will always be changes in your plans or something won’t work etc. Let’s go on summer vacation now 😎

by florian.prasse -

#5 Vizualisation Refinement and Hardware Setup

Over the past few weeks, this project slowly evolved into something that brings together a lot of different inspirations—some intentional, some accidental. Looking back, it really started during the VR project we worked on at the beginning of the design week. We were thinking about implementing NFC tags, and there was something fascinating about the idea that just placing an object somewhere could trigger an action. That kind of physical interaction stuck with me.

NFC Tag

Around the same time, we got a VR headset to develop and test our game. While browsing games, I ended up playing this wizard game—and one small detail in it fascinated me. You could lay magical cards onto a rune-like platform, and depending on the card, different things would happen. It reminded me exactly of those NFC interactions in the real world. It was playful, physical, and smart. That moment clicked for me, I really like the idea that placing something down could unlock or reveal something.

Wizard Game

Closing the Circle

That’s the energy I want to carry forward into the final version of this project. I’m imagining an interactive desk where you can place cards representing different countries and instantly see their CO2 emission data visualized. For this prototype, I’m keeping it simple and focused—Austria only, using the dataset I already processed. But this vision could easily scale: more countries, more visual styles, more ways to explore and compare. Alongside developing the interaction concept, I also took time to refine the visualization itself. In earlier versions, the particle behavior and data mapping were more abstract and experimental—interesting, but sometimes a bit chaotic. For this version, I wanted it to be more clear and readable without losing that expressive quality. I adjusted the look of the CO2 particles to feel more alive and organic, giving them color variation, slight flickering, and softer movement. These small changes helped shift the visual language from a data sketch to something that feels more atmospheric and intentional. It’s still messy in a good way, but now it communicates more directly what’s at stake.

Image Reference

Image 1 (NFC Tag): https://www.als-uk.com/news-and-blog/the-future-of-nfc-tags/

Image 2 (Wizard Game): https://www.roadtovr.com/the-wizards-spellcasting-vr-combat-game-early-access-launch-trailer-release-date/

by florian.prasse -

#4 Alright… Now What?

So far, I’ve soldered things together (mentally, not literally), tested sensors, debugged serial communication, and got Arduino and Processing talking to each other. That in itself feels like a win. But now comes the real work: What do I actually do with this setup?

At this stage, I started combining the two main inputs—the proximity sensor and the potentiometer into a single, working system. The potentiometer became a kind of manual timeline scrubber, letting me move through 13 steps that represent a line, which should be a test for a potential timeline? The proximity sensor added a sense of presence, acting like a trigger that wakes the system up when someone approaches. Together, they formed a simple but functional prototype of a prototype, a rough sketch of the interaction I’m aiming for. It helped me think through how the data might be explored, not just visually, but physically, with gestures and motion. This phase was more about testing interaction metaphors than polishing visuals—trying to understand how something as abstract as historical emissions can be felt through everyday components like a knob and a distance sensor. This task pointed out to me, how important testing and the ideation of your ideas can be, to get a better understanding of your own thoughts and to form a more precise imagination of your plan.

Small Prototype to connect sensors in one file

Things about to get serious

Building on the knowledge I gained during the ideation phase, I connected my working sensor system, a potentiometer and proximity sensor to the Processing sketch I had developed during design week. That earlier version already included interaction through Makey Makey and homemade aluminum foil buttons, which made for a playful and tactile experience. In my opinion, the transfer to Arduino technology made the whole setup easier to handle and much cleaner—fewer cables, more direct control, and better integration with the Processing environment. The potentiometer now controls the timeline of Austria’s CO2 emissions, while the proximity sensor acts as a simple trigger to activate the visualization. This transition from foil to microcontroller reflects how the project evolved from rough experimentation into a more stable, cohesive prototype.

by florian.prasse -

#3 Serial Communication Between Arduino and Processing

By this point, I had some sensors hooked up and was starting to imagine how my prototype might interact with Processing. But getting data from the physical world into my visuals? That’s where serial communication came in! On the Arduino side, I used “Serial.begin(9600)” to start the connection, and “Serial.println()” to send sensor values. In my case, it was messages like “true” when a hand moved close to the distance sensor, and “false” when it moved away. On the Processing side, I used the Serial library to open the port and listen for data. Every time a new message came in, I could check if it was “true” or “false”, and change what was being shown on screen — red background, green background, whatever. So I was prototyping the prototype, you could say.

Why this is so fascinating and helpful 🤯

I wanted to build something quick, easy to use and reactive—and serial communication made it possible to prototype fast without diving into WiFi, Bluetooth, or custom protocols. It lets me test ideas in minutes: turn a knob, wave a hand, watch the screen respond. And for something as conceptual and messy as visualizing CO2 history with simple and fast coding, that immediacy is everything.

Imagine you’re at an interactive museum exhibit about climate change. As a visitor approaches a screen, a hidden distance sensor detects their presence. The Arduino sends “true” to Processing, which triggers a cinematic fade-in of historical CO2 data and a narration starts playing. When the visitor steps away, the system fades back into a passive state, waiting for the next interaction. That whole experience? Driven by serial communication. One cable. A few lines of code. Huge impact.

Some helpful links for those who are interested in serial communication:

https://learn.sparkfun.com/tutorials/connecting-arduino-to-processing/all

by florian.prasse -

#2 First Steps with Arduino

So my initial project about the CO2 emissions in AUT had 13 steps on a timeline you could loop through with key controls. So I’m thinking how am I gonna set my Arduino parts up, to work with my existing concept? This blogpost should tell you about my first steps, trying to figure that out. Connecting the parts—trying to get progress towards the concept of my existing one.

My thoughts creating this code were pretty loose at first. I just wanted to get some kind of input from the potentiometer, without fully knowing what I’d do with it yet. I had the concept of a CO2 visualization in the back of my mind, and I knew I had split the data into 13 time periods earlier, so I figured I’d map the potentiometer to 13 steps and see what happens. It was more about testing how I could interact with the data physically, using whatever tools I had lying around. The code itself is super basic—it just checks if the current step has changed and then sends that info over serial. It felt like a small but useful first step.

Also i integrated a distance modulino already thinking about how i could use this one for my prototype.

With a very basic setup from the library, to get the input of the sensor. I wrote a sketch that just triggers true or false when i move my hand over the sensor. I am thinking about my very first idea of the design week, to trigger an interaction/visualisation when i step on a plate with the shape of the country I want to see the emission data of. Maybe I can go in this direction this time? I want to give you another picture to show you what I mean.

Of course, this will not be realizable now but thinking about the map interaction could be a good concept for the technological boundaries I have set with my pieces I got from the FH.

by florian.prasse -

#1 Topic Introduction: Looking at CO2 Emissions in Austria

During a past project, I started working with data about Austria’s annual CO2 emissions. I created my own dataset using global emission data, filtered down by country and year—all done with Python, which I was using for the first time, very interesing technology—so convenient. It was a bit of a learning curve, but also really cool to see the results take shape.

One thing that stood out was how certain moments in history, like war times, had a visible effect on the emission levels. That connection between historical events and environmental data got me thinking: how can I turn this into something people can interact with and experience beyond just reading numbers?

From Makey Makey to Arduino

I started with a simple setup using Makey Makey to build a basic interaction. It worked for a quick demo, but I quickly realized I wanted more control and flexibility. So now, I’m shifting to Arduino. I found a few components at the FH lab and I’m planning to use those to build something more responsive and physical. I’m not totally sure yet how I want everything to work, but I’m interested in seeing how these parts could represent parts of the data—like maybe scrubbing through time or showing intensity of emissions with light or movement.

Just Starting to Explore

Right now, I don’t have a clear final concept, and I’m okay with that. This part of the process is more about experimenting, testing out ideas, and seeing what happens when the data meets the physical world. I think there’s a lot of potential in making climate data more tangible—not just for me, but for others who might interact with it. So my next step is to start playing with the Arduino board, hook up the sensors, and just try stuff. Maybe something will click, maybe I’ll go in a totally new direction. Either way, I’m curious to see where it leads.

by florian.prasse -

WebExpo Talk #2: Elis Laasik

Beyond Design Tools: Prototyping in code

In this second post, I want to recap the talk of Elis Laasik at WebExpo 25, where she discussed the topic of design prototyping in code. Elis, with her extensive experience in the field, explained how prototyping using basic HTML, CSS, and JavaScript—along with some JavaScript frameworks—can be an efficient way to approach web development. She highlighted that this method is especially valuable in professional contexts, where prototyping plays a crucial role in shaping the user experience, testing ideas, and ensuring that the final product aligns with business goals.

One of the main points that Elis emphasized was that these prototypes don’t require a backend or a database. Instead, the focus is entirely on the front-end elements, like the user interface and customer journey. This approach allows teams to test how the website or app behaves in real time, which can be much more useful than static design mockups. Since the prototype is coded directly, it is much closer to the finished product, giving stakeholders a more accurate sense of how the final product will look and function. The fact that it’s interactive and responsive adds another layer of realism to the process, which can be especially valuable in understanding the user experience.

This approach to prototyping really stood out to me, as it closely mirrors the way I work on personal projects. When I’m building a website on my own, I tend to start coding right away, rather than creating a design in tools like Figma first. I find that coding a prototype feels more “real” because I can see the project develop as I work on it. It also allows me to directly address how the website will behave, rather than just looking at a static design. I could relate to what Elis was saying because, for me, starting to code early gives a more authentic sense of the project’s progress and helps me figure out how the website will work from a functional perspective.

Elis also mentioned that prototyping in code can be particularly useful when dealing with complex user interactions or when there is no shared vision across the team. By coding the prototype, it’s easier to explore different solutions and test how users will actually engage with the site or app. This kind of flexibility and control can be crucial in situations where the design needs to be flexible or constantly evolving.

That said, Elis pointed out that there are certain scenarios where using code for prototyping might not be the best approach. For smaller projects or when branding design is a significant focus, she suggested it might be better to start with a traditional design tool like Figma. In these cases, the need for high-fidelity visuals or design accuracy might take precedence over functionality in the early stages. I completely understand this perspective, especially when the main goal is to define the visual identity of a brand before diving into the technical aspects.

In conclusion, Elis’ talk provided a lot of valuable insights into the practical use of code-based prototypes. It was interesting to see how this approach is applied in professional environments and how it can be a useful tool for creating realistic, interactive designs. For me, it reinforced the idea that prototyping with code isn’t just about creating something functional—it’s about exploring possibilities, improving user experience, and aligning the product with business objectives.

by florian.prasse -

WebExpo Talk #1: Nadieh Bremer

Creating an effective & beautiful data visualisation from scratch

The field trip to Prague is over, and I’ve been thinking about the really interesting talk by Nadieh Bremer. Nadieh is a freelance data visualization designer from the Netherlands, and her work focuses on turning raw data into interactive and static visual art. It was fascinating to see how she approaches data, especially since my interest in data visualization started a few years ago during my bachelor’s in graphic and information design. This talk made me think in new ways about the potential of visualizing data, and I’m excited to dive deeper into it.

One of the things that stood out to me the most during the talk was how Nadieh works with D3.js, a JavaScript library for creating (interactive) data visualizations. I was amazed by how quickly she could take raw data—just numbers—and turn them into beautiful, meaningful visualizations. She made it look so easy, and the fact that she could transform the data into something visually stunning in such a short amount of time really caught my attention. I had heard about D3.js before and had been meaning to check it out, but like most people, I never had the time. So, this talk came at the perfect moment for me, and it made me realize just how powerful and useful this tool is for working with data.

As someone who has mainly worked with data in print media, I’ve always focused on static visualizations. Most of the techniques I’ve learned are for creating things like printed charts, posters, or other fixed formats. But seeing how Nadieh used D3.js to create interactive, dynamic visualizations opened up a whole new world for me. The idea that data can be more than just something to look at on paper—that it can be experienced and interacted with—was something I hadn’t fully considered before. With D3.js, the data is not just displayed; it’s alive and engaging. You can hover over elements to get more information, zoom in to explore trends, and see the data change in real-time. This is something you simply can’t do with traditional print media, and I’m excited to explore how I could bring this kind of interactivity to my own work.

What I also found really interesting was how data can be art. Nadieh’s visualizations weren’t just about presenting data clearly; they were also about making the data visually appealing and impactful. She showed that data visualization doesn’t have to be cold or purely functional—it can be something beautiful. This idea was a bit of an eye-opener for me, as I’d always thought of data as something to be communicated in a straightforward, no-frills way. But seeing her work made me realize that data can be both informative and artistic, and it’s something I want to try in my own designs.

The talk really showed me the potential of D3.js and how it can take data visualization to a whole new level. It’s not just about making a chart or graph anymore. It’s about telling a story through data, using color, motion, and interactivity to make the information more engaging and easier to understand. This is something that I think would take much longer to achieve using traditional print techniques, and it’s a huge opportunity for people like me who are interested in graphic design and information design.

Overall, I’m really glad I got to experience Nadieh’s talk. It made me realize just how much more there is to data visualization and how powerful tools like D3.js can be for creating engaging, interactive, and even artistic visualizations. I’m excited to start experimenting with D3.js myself and see where it takes me. I’ve learned that data doesn’t have to be static and technical—it can be creative and expressive, even be used in an artistic sense. And that’s a new perspective I learned and will keep in mind as I continue to work with data.

by florian.prasse -

Speed Dating: Prototyping

This post will be a quick recap of the speed dating session at the start of the semester. The goal was to create prototypes for a possible master’s thesis topic. In class we divided into two groups and talk about each others prototypes in a small amount of time. Due to my decision on swapping majors after the first semester, this task was a challenge for me. I had no clue what to do actually and just tried to connect my previous knowledge with the goal of this task. My love for typography always played a big role in my work and I tried to develop a playground to interact with letters and their movement.

The first concept was to have some kind of object that will is suppused to be thrown against a wall. It should invite people to let out their emotions. Imagine it like a rage room but the collision of the object and the wall is interactive. Depending on the speed of the object, the wall displays a collection of words as type.

The second prototype was a more relaxing way to interact with typography. Based on movement and impact on pressure plates, the wall shows different letters being formed by the people. My idea was to show their behavious in form of typography. Letters are always expression a kind of personality. In this case I want the people to connect with letters and get to know the power of expression through typography.

Class Feedback

It was interesting to see that noone acutally understood what I actually wanted to express. This also lead to a feedback saying the second concept could be offensive to some extent. As I mentioned in the first paragraph, it was hard to create something understandable as a lofi prototype, so I understood the reactions and i tried to reflect how I could make it more understandable. So I knew I had to get more experience to learn more about prototyping and interaction.

by florian.prasse -

Prototyping a Data Visualisation Installation

In this second part of the IDW25 recap I want to talk about the prototype I created of my CO2 project. The goal for me was to build an installation to interact with the data visualisation. For this I chose makey makey and built a control mechanism with aluminium foil and a pressure plate. To send the data from processing to the projector I used Arena Resolume. My concept was based on the CO2 footprint. So you activated the animation with steping on the pressure plate. Here are first sketches of my idea.

I thought about making an interactive map where you step on different countries and realease fog in a glas container. But that was too much to create in one week so I reduced the concept to projecting the boundary I showed in my last blog post. I kept it simple and connected the makey makey to aluminum foil to control the time line with a finger tap. The processing output is being projected on the wall.

Conclusion

It was interesting to get to know the possibilities of the used technology to visualise data and therefore I had a lot of fun during production. I will definitly keep working on this project to see where it can go. Also expand the data set to compare more countries. In the first part of the blog post I mentioned that there are probably better programs to make more visually appealing animations for such a topic. But for a rough protoype this was completly fine.