 Next speaker's name is Andreas Lüge-Obsen from Coalition. He's an architect migrated from traditional physical design towards interaction design, both within research, teaching, and business. He's developing and designing projects that bridge the physical and the digital attributes for a wide range of both public and private clients, such as Saksabank and Audi also. So talking about physical exception handling, here is Andreas Lüge-Obsen. Here he is. Thank you. And thank you for inviting me. And I think I could be a good person to put after Peter's excellent talk, actually, because I'm one of those guys who could sit around in some of those studios that Peter just talked about. My name is Andreas. I'm educated as a real architect. You know, I can draw, animate, and stuff like that. But I have migrated into the stuff that most of you probably do. And I've been around up here earlier and been a part of some of the institutions up here. But I'm a part of Coalition, which is a small design company situated here in Aarhus. And we do a lot of research and development within the gap between citizen participation. We've done a lot of that. And then advanced interfaces. We do all the other stuff as well. But today I will talk about what we do in the real world and a bit about how we do it. And I'll frame it to the public realm and urban spaces, because physical computing could be many things. But that's where I'll look at it. The physical exception handling, it's a cool title. But there is some truth to it. We can catch a lot of exceptions doing software. But sometimes physical exceptions, they are pretty heavy sometimes and hard to handle. So firstly, I'll just set the stage. It's a one minute movie just showing a bit about how we work, a bit about the physicalities, the different contexts, the different tools and methods that we use. So it's analog, it's digital. Physical is light, software is hardware. It's multi-user setups. It's pretty fragmented. I'll turn to some of these examples later on. But that was just a really quick introduction. So being in a public space, in the public domain, or part of the city, we always think that it's important to remember that the city is built on top of the city. Sounds a bit naive, but it is. The city is made up for centuries by layers of different infrastructures, different ideas and concepts, building traditions. And everything kind of blends together into the city that we know. But most often we tend to think that we can go tabularasa and start from nothing, from scratch. But being inside the city, you kind of always have to add on to something and the smart city concept is, in my opinion, the frosting on top of an already smart city. It's extremely smart already, but we add some new layers to it. And for some reason, and this is just a bit of food of thought that you can bring home, I think it's peculiar that we never question whether we should go digital or not. It's, and for people like you as well, I mean digital is always the answer for some reason. We are in the same boat, I admit, but it is sometimes a bit fun that we can't solve some of the things in an analog way. The way we work with a lot of our urban installations is that we try to find a hook, some simple way for inhabitants, pedestrians, citizens to engage in our environment or in our installations. And we do that by mixing function and fun, so working on the functionality, which is already ready part of something and adding some playful fun layers, or we play with the serious and the surprising, or we play with the informative and the ambient because we are almost vomiting from the constant flow of information and communication that this place wants to push to you anytime. So if you can sometimes turn it into something else, you can create that surprise that will kind of reach out for people. And at the same time we kiss a lot, we try to keep a simple stupid. So a good example on that, and again, I return to some of the tools that we work with that Peter was referring to, Storing, it's a bit of hardware production. But again, we approach these projects from a wide range of perspectives because we look at them from the city or try to solve them both in digital and in physical manners. So we can prototype and we can test a lot of things at home. But the point is that we can prove that the part of the system is working, but it's first when we approach the real context that we can actually understand whether this will be, I mean, in the end, will end up in a neat way. So the concept here and the kiss concept is basically a tunnel which was already there. It's a standard tunnel. It's the city as it is. And on top of that, it's a physical layer of light that solves the functionality of the light, the amount of the lux that needs to be provided in the tunnel. And then the little gimmick that when you enter the tunnel, you turn on the light. When you leave the tunnel, you switch off the light. And in that little simple concept, which is fairly hard to implement in a neat way, you have a lot of potential in play and in engaging for anyone who approaches the tunnel. So the project still provides the functionality of a tunnel that is lit in some way. And at the same time, there's a lot of playful features. So the hook here is basically your presence, right? It's really simple, but you become part of your physical surrounding in a public space. No nemy, no nemy, they need it. So it requires being around. It requires understanding the infrastructure, the software, the steel, the bricks, the concrete, the humans being around there, the rain, traffic, heat, noise, all the annoying things that, for instance, the drone capturer from Tama is confronted with as well. And then, of course, the idiots, I mean, people like you who are not interested in using the stuff the way that I intended it to be used that you need to design for, right? Of course, there are vandalism, but there are also people who are trying to spoof the system or to play around with it, and most often in fantastic ways. So in an example like this, I was part of testing it when we implemented it. Imagine the first thing that I drew on that humongous facade, just imagine it. Anything? Yes, I did. And because of that, we decreased the tail or the possibility of drawing on this facade because people are creative when they get new tools in their hands. But again, the hook here is the stuff that you already have in your pocket. It's the mobile phone or your cellular. It's not even an app. It's a web app, so you don't need to download anything. But it's the idea that you reach out and let people touch the urban surface. In a simple way, there is a queuing system. So when you hook on, you end up in a line. You are automatically locked off, and the next ones in line are connected, and you can play around. So again, this is not a hardcore interface. It's not a critical system, but it's a really easy hook, and people can become fairly creative using it. And again, yes, there's a lot of software in this. Not a lot for you, but there's software in it. But I will still say that it's a small part of the equation. I mean, understanding and utilizing the existing city, understanding the urban squares. Where can you be situated? Where do you have good spots for gathering, understanding the fuzzy users? It's a really broad and fuzzy group of users. They are young. They are old. They have no knowledge of technology. I mean, perhaps they have their phone in the pocket anyway. But helping that stuff out is quite complex. And my point is that when you mix up the software or the app and apply it to a physical space, you have a way better experience than you have by just using a regular app or something. When I prepared this talk, I thought about which apps that had made great memories. I mean, that I have great memories about is absolutely none. I mean, I played Candy Crush, and I'm at level 3,600. And that's the only horrible memory I'd have because it's eaten all my time. But I think that applying technology to physicality brings something. And I'll end up with this. And that's another example. The function is urban furniture. It looks nice when it's not in use. It just has a certain pulse. It wakes up in the evening by itself. And then whenever you approach it, the hook is just, we know you're here, and you're welcome. So it's just adding a small color based on your mass. So it's a range of large capacitive sensors inside it. And the idea is that there's no meaning in this, apart from the fact that you can play around with it. But the physical exception handling that I talked about is the problem is here that people started jumping on them. And even though they were tested in many ways, people found out, and we have videos of that on Instagram, really drunk people, jumping up and the light goes out and they jump down or land on it. And they actually not broke them, but kind of deformed some of the plastic shells. And my point is that sometimes software is simpler to tweak than the physical world is. And because of that, anything that you can catch before implementation of the physical, at least, is really, really important. And that comes to the conclusion of my talk that some of the challenges that we have is that we can simulate and prototype a lot of things. But simulating and prototyping takes out a small part of the entire equation. And so sometimes you prove wrong by just proving something with a prototype. I'm not talking against prototypes. I'm just saying that you need to add it up sometimes and remember that it's only a small part of the equation. Another problem that we have with these very integrated projects between physicality and technology is that, at least in the building industry, many things are split into subcontracts. And it's pretty hard to hand over projects like this to subcontractors that say, now, this is fixed. And then they leave. And I mean, it doesn't work with the physical or it's woven badly together. Most often we come in late with projects like this, which makes it even harder to weave into the API of the physical fabric, if you could say so. So that are some of the problems that we are facing. So my conclusion would be that physical exceptions, they should be caught. And digital ones, they might be tweakable. Thanks for listening. Get up. Get out there and hook up. I'm sad about the stuff being easier to tweak than the physical world because it makes so much sense. But sometimes I guess that's not the way people act. They think we're going to put it out there and then we're going to see what happens. But when you're creating, you've got to get it as fast as you can before you bring it up. But I actually think there was a nice talk from this guy who just sat down. Sorry, I can't remember your name. But I mean, that building software is also building on top of the city, of the city, of the city in some sense. And sometimes we would like to sweep everything and start from scratch, which is not possible. But still, sometimes it is much easier to tweak parts of software. I know you cannot necessarily change the entire structure. But it's hard when something is built to tweak it. Plus, there is a mindset of what you're saying with the smile. You're saying the idiots that are not using it as intended. But really, that is the type of arrogance that stopped you from creating innovation. I mean, the fact that you're very aware of this is, no, you're not that case. But there will be people that are saying, hey, this is how you should be using it. What great case that I like to bring up sometimes is there's this young guy. And he was broken up with by his girlfriend. And she blocked him on all media. Like, he couldn't get in touch with her. So he went into mobile pay. Because he knew he could write a message from mobile pay. And he keeps sending her one crone. Just one crone. I said, please, unblock me. And like, please, you know, I was media to do the mistake. But that's such a good example of the creativity of how just doing it as it was absolutely not intended. Yeah. So thanks a lot. Thanks. Oh, really? And um. And um.