We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Mutually Assured Construction

00:00

Formal Metadata

Title
Mutually Assured Construction
Title of Series
Number of Parts
234
Author
License
CC Attribution - ShareAlike 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Cooperation is difficult, and designing for it is even harder. Even when everybody agrees on an end goal, and everybody agrees on what is needed to achieve that end goal, it does not mean that everyone (or even anyone) will be able to take the first step, which is a most important step.
MereologyType theoryGame theorySpectrum (functional analysis)Projective planeBitPhysical systemConstructor (object-oriented programming)Group actionTerm (mathematics)Focus (optics)Strategy gamePermanentComputer animationJSONXMLUMLLecture/Conference
Multiplication signBitConstructor (object-oriented programming)Lecture/Conference
Multiplication signStrategy gameRevision controlArmLecture/ConferenceMeeting/Interview
Strategy gameContext awarenessGame theoryNuclear spaceQuicksortComputer animation
Constructor (object-oriented programming)CASE <Informatik>Strategy gameDecision theoryFrictionLecture/Conference
QuicksortStrategy gameFrictionData structureDisk read-and-write headMereologyDecision theoryPhysical systemProcess (computing)Centralizer and normalizerComputer animationMeeting/InterviewLecture/Conference
Physical systemDecision theorySet (mathematics)Core dumpQuicksortBranch (computer science)Different (Kate Ryan album)BitRevision controlAxiom of choiceNumberAuthorizationProjective planeLecture/Conference
NumberAxiom of choiceMomentumOrder (biology)FrictionTerm (mathematics)Physical systemDecision theoryProcess (computing)Cellular automatonInterpreter (computing)Lecture/Conference
VotingWebsiteInequality (mathematics)Triangle1 (number)Integrated development environmentExtension (kinesiology)Right angleLecture/Conference
Denial-of-service attackSound effectSystem callQuicksortEquivalence relationAbsolute valueRight angleData structureLecture/ConferenceMeeting/InterviewComputer animation
Manufacturing execution systemMassForm (programming)CryptographySet (mathematics)Database transactionPhysical systemCASE <Informatik>Lecture/ConferenceMeeting/Interview
PlastikkarteQuicksortAutonomic computingForestDecision theoryMixed realityLeakSpacetimePhysical systemSoftware testingLecture/ConferenceMeeting/Interview
VotingComplex (psychology)View (database)HoaxGroup actionAlgorithmPhysical systemQuicksortLecture/Conference
Constructor (object-oriented programming)Physical systemPropositional formulaLecture/Conference
Decision theoryDependent and independent variablesProjective planeLecture/Conference
Different (Kate Ryan album)MathematicsConstructor (object-oriented programming)Neighbourhood (graph theory)Stress (mechanics)Optimization problemComplex (psychology)Process (computing)Lecture/ConferenceMeeting/Interview
BuildingBlock (periodic table)QuicksortProjective planeCASE <Informatik>Different (Kate Ryan album)Boundary value problemOpen setGreatest elementLecture/Conference
Open setPhysical systemProjective planePoint (geometry)BuildingProcess (computing)Multiplication signModule (mathematics)Data structureTelecommunicationLecture/ConferenceMeeting/Interview
MetreData structureVideoconferencingDigital photographyPoint (geometry)Multiplication signComputer animationLecture/Conference
PermanentCentralizer and normalizerProjective planeTransportation theory (mathematics)Square numberQuicksortMereologyRootRoutingCycle (graph theory)Order (biology)Event horizonLecture/ConferenceMeeting/InterviewXML
Decision theoryTransportation theory (mathematics)Physical systemLine (geometry)GravitationUniform resource locatorRight angleLecture/ConferenceMeeting/Interview
SoftwareShared memoryPropositional formulaOpen setTransportation theory (mathematics)PrototypeProcess (computing)Lecture/Conference
Decision theoryDependent and independent variablesProjective planeSimilarity (geometry)Natural numberScaling (geometry)PlotterChannel capacityNetwork socketPower (physics)Computer animationLecture/Conference
Computer networkInfinite conjugacy class propertyPlotterOrder (biology)InternetworkingSoftwareFood energyChannel capacityLecture/Conference
Food energyPoint (geometry)Film editingSoftwareChannel capacityCASE <Informatik>Physical systemPlotterInjektivitätMeeting/InterviewComputer animationLecture/Conference
Infinite conjugacy class propertyChannel capacityPoint (geometry)Decision theoryEmailVideo gamePlotterPrototypeEvent horizonProjective planePhysical systemFood energyRight angleCASE <Informatik>Lecture/Conference
QuicksortProjective planeSheaf (mathematics)2 (number)Decision theoryLecture/Conference
Data managementBuildingComputer-assisted translationProcess (computing)Augmented realityStudent's t-testGroup actionCondition numberVirtualizationDifferent (Kate Ryan album)MathematicsQuicksortBitSoftwareInteractive televisionComputer animationLecture/Conference
Student's t-testVirtual realitySoftwareStudent's t-testDecision theoryBuildingComputer-assisted translationLaptopPoint (geometry)Process (computing)BitLecture/ConferenceMeeting/Interview
Multiplication signBuildingData managementMereologyStudent's t-testDecision theoryProjective planeMeeting/InterviewLecture/Conference
Decision theoryResource allocationMathematicsProjective planeMultiplication signLecture/Conference
Internet der DingeWeb 2.0Computing platformPatch (Unix)Thermal radiationSpacetimeFocus (optics)Traffic reportingReal-time operating systemMultiplication signTerm (mathematics)Local ringLecture/ConferenceMeeting/Interview
Arithmetic meanNumberThomas BayesPatch (Unix)Thermal radiationData conversionSource codeDifferent (Kate Ryan album)Multiplication signMeasurementLecture/ConferenceMeeting/Interview
Different (Kate Ryan album)QuicksortMeasurementContingency tableArmExecution unitContext awarenessMassLecture/ConferenceMeeting/Interview
Hill differential equationSoftware repositoryThermal radiationMathematical analysisMultilaterationBuildingInternet forumFile formatSlide ruleLecture/Conference
Multiplication signMappingThermal radiationMereologyDifferent (Kate Ryan album)Interface (computing)FrequencyTerm (mathematics)ResultantLevel (video gaming)Lecture/Conference
Term (mathematics)Sound effectVisualization (computer graphics)TwitterDecision theoryObject (grammar)QuicksortThermal radiationMobile appPatch (Unix)MappingLecture/Conference
Mobile appUniformer RaumContext awarenessoutputForm (programming)Thermal radiationInternetworkingProjective planeMereologyDifferent (Kate Ryan album)Wave packetLine (geometry)Game theoryQuicksortPlastikkarteAreaMultiplication signLecture/Conference
Uniformer RaumTelecommunicationData conversionMeeting/InterviewLecture/Conference
Uniform resource locatorSoftwareProjective planeTelecommunicationLoop (music)Line (geometry)MereologyUniformer RaumLecture/Conference
Uniform resource locatorQuicksortLine (geometry)Decision theoryTelecommunicationLecture/ConferenceComputer animation
VideoconferencingBitBasis <Mathematik>2 (number)Game theoryVideo gameArmQuicksortLecture/ConferenceComputer animation
CuboidDigital photographyLine (geometry)VideoconferencingVolume (thermodynamics)MereologySign (mathematics)Block (periodic table)Correlation and dependenceComputer animation
Standard deviationFlash memoryWater vaporGlobale BeleuchtungMeeting/InterviewComputer animation
Projective planeProcess (computing)Shared memorySpeech synthesisWhiteboardComputer animationLecture/Conference
Different (Kate Ryan album)Broadcasting (networking)Contrast (vision)VideoconferencingProjective planeProcess (computing)Computer animationLecture/ConferenceMeeting/Interview
Point (geometry)Projective planeBuildingConstructor (object-oriented programming)Different (Kate Ryan album)Computing platformCASE <Informatik>Lecture/Conference
Projective planeScaling (geometry)Observational studyShared memoryLine (geometry)Different (Kate Ryan album)CASE <Informatik>Similarity (geometry)Lecture/Conference
Multiplication signTunisProjective planeLecture/ConferenceMeeting/Interview
Projective planePhysical systemIntegrated development environmentLecture/Conference
Relational databaseDecision theoryCASE <Informatik>Moment (mathematics)Figurate numberMereologyProjective planeMultiplication signWebsiteWave packetFrequencyQuicksortLecture/Conference
Menu (computing)Row (database)Group actionCoefficient of determinationState of matterMultiplication signObject (grammar)Different (Kate Ryan album)Complex (psychology)Revision controlAreaProjective planeTrailData structureTable (information)Data managementNeighbourhood (graph theory)MathematicsLevel (video gaming)Lecture/Conference
Lattice (order)MathematicsRow (database)Multiplication signRegular graphContext awarenessProjective planeLecture/Conference
Group actionProjective planeBitContext awarenessData conversionProcess (computing)Lattice (order)QuicksortLecture/Conference
Code division multiple accessComputer virusDecision theoryShared memoryQuicksortLevel (video gaming)Different (Kate Ryan album)Complex (psychology)Speech synthesisProjective planeWhiteboardBitLecture/Conference
Projective planeLevel (video gaming)ForestDenial-of-service attackMultiplicationHill differential equationCASE <Informatik>SequenceSource codeData management
Complex (psychology)Similarity (geometry)VotingMultiplication signLecture/ConferenceMeeting/Interview
Computer animation
Transcript: English(auto-generated)
everybody. Thank you for joining me today. I'm going to be
talking a little bit about designing participatory systems, and I will be discussing about six of the projects that I've done over the last ten, 15 years. The kind of work I do spans quite a broad spectrum from very sort of short-term
temporary spectacular projects to long-term permanent infrastructural projects, and I'm going to try with those six projects to go from one end to the other, and I'm going to be talking about, you know, what I'm hoping to do next. What I specifically want to focus on, though, is a
design strategy that I have been kind of formulating just over the last year or so to try and understand where these projects are going, and that is something called Mutually Assured Construction, and I'm going to explain that in a little bit. I am happy to take questions at the end of the
talk, but actually, I really like to be able to have questions in the middle of the talk as well, so if you do want to ask something or make a comment, please feel free to do so while I'm talking. I think there's a microphone that's going around. I guess you just hold up your hand.
So, I'm going to spend a bit of time now just talking about this idea of Mutually Assured Construction. By way of reminder first, though, I just want to touch on this principle of Mutually Assured Destruction. How many people are actually familiar with this phrase? Do you mind putting up your hand? So it looks like only about
half. Now, in the 70s and 80s, in the 1970s and 80s, this was a phrase that was very much at the forefront of culture. It was this kind of military strategy that had been adopted during the Cold War which essentially said that if I attack you with
nuclear weapons, in the time that it takes for me to attack you, you are going to attack me, and if my bombs land on your country, they will destroy it, and if yours land on my country, it will destroy me.
So as soon as I launch an attack, I'm assuring my own destruction, as it were. And this principle of Mutually Assured Destruction was the one that essentially meant that there was no incentive for either side to initiate a conflict. There was
plenty of incentive to keep increasing the arms, and certainly, there was no incentive to disarm, but there was just no clear incentive to actually initiate a conflict, and what actually happened was that, through this kind of military strategy, a strategy of conflict, it assured by binding
together the futures of the two different parties that neither side acted negatively towards the other. And so for people who grew up in the 70s and 80s, I think that this was certainly at the forefront of, at least when you think about the
sort of threat of nuclear warfare. Now, what I want to do is take that principle further. I find it a really interesting kind of strategy, because in the context where you have two antagonists, they have through basically, you know,
you can spend thousands of hours looking at the game theory around this, but essentially they have adopted a strategy that means that neither side is harmed. I want to go further and say, well, how do you harness those same kind of contradictions and frictions in a way that actually enables you not just to remain static, but actually to be
constructive together, to move forward together? So I've been kind of exploring this idea of mutually assured construction, which is essentially a strategy where we can build and act and make decisions together without requiring consensus. It's all very easy if we have consensus, of course. If we all agree on stuff, then, you know, none of this really
matters. But in the messy world that we live in, in most cases, we do not have consensus before needing to act. And that's really where this kind of idea of mutually assured construction has emerged. Now, as a designer, my interest really is how do
you structure this participation? How do you take things like frictions and contradictions and structure the participation in such a way that this sort of strategy emerges? If you're concerned or interested in
participatory design, one of the most kind of difficult concepts to get your head around is, wait, how do you design for participation? Because part of the principle of participation should be that you kind of devolve or you decentralise the process. But if there's a designer, then
that implies some kind of centralising of decision-making. And this, you know, after many sort of angst-ridden years of wondering how do I step out of being a participatory designer while designing participatory systems, what I realised was that, actually, in any system, in any anything that we create, there is
always somebody who makes decisions that impinge on other people, but it is possible to make decisions about the things that we put in this world that open up the set of possibilities for other people to make decisions. We don't just have to sort of design to simplify, to narrow down the
possibilities. We can actually design to open up the set of possibilities. So, here, I borrow from Heinz von Fürster and say that actually the core principle of participatory design is increasing the number of choices that other people have. And I think that this conflicts a little bit
with a different branch of design which is all about, you know, making things easy and simple and trying to narrow down the set of possibilities and trying to produce, as an author, the final obvious solution. In participatory projects, usually they're so complex that it becomes difficult, really, even to describe them with any authority because
every single participant has a different story for that project. So, the question is, how do we actually deal with the frictions and contradictions in participatory design in order to increase the number of choices? And I think that this is a fundamental
thing that you have to kind of come to terms with as a designer in this kind of situation, that you are going to be making these decisions but, in so far as you can open up that process through your own decision-making, to have the decisions be re-interpreted, re-evaluated, re-scripted,
re-appropriated or whatever by other people, that's your goal in trying to develop a participatory system. So, why is this important now? For me, this is not just about oh, everyone should be doing this together and it's all wonderful if we do stuff and we're all very happy and all that.
It's for very pragmatic reasons. The situation that we find ourselves in the world right now sees these kind of crises in the very infrastructures that have formed our societies over the last few hundred years. Democracies are increasingly decided
by those who opt out, those who don't participate, those who don't vote. They're the ones who, to a large extent, have started to determine the outcome. If you look at the environment, the triangle of climate change and inequality and geography that's actually going to reshape our cities and where people
live and how they live in cities. This is coming right now. Down here, you can see a garage in Miami which has been flooded. Of course, it was all the wealthy and their sports cars that got flooded, but the wealthy can move and the poor cannot. What is going to happen when, in London,
as you see in this top right-hand corner, this is a website called floodbattemap.net where you can map out what sea level rise will have as an effect on the geography. How we're going to deal with essentially internal
immigration, if you like, is going to radically rescript the way that we work with each other. Finance, our financial structures. Everything seems reasonably stable right now, but when you look at the fact that we are at the absolute peak of global debt ever,
which is essentially the equivalent of having a sort of an athlete pump full of steroids and then pumping in more steroids and pumping even more in. When you combine that with crypto currencies which are essentially another form of
transaction, when you combine that with massive tax evasion going on in the wealthy and when you combine that with the fact that financial professionals are now talking about the end of fiat money fiat money is essentially the idea that we can transact in currencies. Financial professionals are actually talking
about the fact that we may no longer be able to transact in currencies. When you combine all of these the idea that our systems will continue to be the same in the next few decades just doesn't add up. Now, of course,
there are a lot of people working on technological solutions to this and in many cases the principle of technologies of such technologies is that they should design for us. They should make decisions on our behalf. You can think of autonomous vehicles. You can think of smart city infrastructure
like this one in Brazil. But when you add into the mix the fact that when you adopt these kinds of technology you're also adopting the NSA having access to all your data. You're having actually Madison leaks of your personal data. When you add into this the fact that actually the data is used
actually proactively to subvert the systems that are designed to regulate it. When you throw into this the fact that the Silicon Valley technology companies are using urban space to beta test their features and that a 15-year-old boy can hack into a telco and then the idea
that it's crazy that fake news influenced voting says Zuckerberg. You realize that the Silicon Valley view of technology is not in any way going to be able to deal with the complexity of all the financial, the environmental and the
democratic complexities that we face over the next few decades. We need to radically redesign the way we live together if we're going to make it through these next sort of 50 years. It's just a plain fact. Now, either we can leave
that to a small group of people who are developing the algorithms and systems and technologies with their own kind of presumptions, their own prejudices to act on our behalf, or we can figure out how we're going to do this together. And I would say that the issues that we face are so complex that
no single voice or even a small collection of voices is going to figure out how to resolve them all. So we necessarily have to act collectively in some way to shape these futures. But we can't wait until we all agree on how to do it. We need to take a step forward even though we don't yet have consensus
on how to act. And that is why the principle of mutually assured construction I think is so important to me. What has kind of emerged for me are three aspects that are key to developing a mutually assured construction system. First of all,
is the idea that the design proposition enables people to work together even though they don't yet have consensus, just kind of explore ways to get people actually doing stuff even though they don't yet know whether they agree on stuff. What I'm looking for here is
essentially instilling a sense of agency in people that they can actually do something. It is possible to respond in some way to the situations that we see coming towards us. The second is enabling people to make decisions together. What we're
looking for here is that people are actually involved in making a decision about the future that essentially binds them with some kind of responsibility for that future. And by doing that together they're actually essentially creating a shared responsibility for that future.
I'm going to go through some of the projects to see how I've tried to probe each of these in a second. And then the third is figuring out how to act together. And here what I'm looking for is ways to enable people who might not normally think that they can accomplish something to actually make a change, make a difference,
do something that has some accountability. That they've actually changed something about their city, their neighborhood, or what have you. So these for me are the principles I've been looking at in Mutually Assured Construction, but I really want to stress that this is not about
crowdsourcing. We're not looking for the optimal solution here. This is not just about saying okay let's all get together and we're going to figure out how to do this. This is about saying actually the only way that we are going to be able to survive the next 50 years is by embracing the heterogeneity of ideas,
about embracing the complexity and the messiness and the fact that there is no one solution, that there are many different ways that we're going to approach this and essentially building in to our design processes ways that we can kind of use those as building blocks if you like. So I'm going to
go through those three things and in each case I'm going to talk about two projects just to illustrate how I've tried to sort of probe different aspects of this. I can't say that necessarily each project answers all the questions, but each of them
has been kind of an experiment in probing the boundaries of this. So working together, collaborating without consensus. I'm going to start with a project called Open Burble from 2006 and there's a little slider down here at the bottom. I don't know whether you can see it at the front, but it basically
goes from temporary cultural to permanent infrastructural. I'm going to do six projects and they're going to go from the temporary all the way to the infrastructural at the end. But I'm starting with Open Burble, which was basically a project that I did in Singapore and I have to say that I wasn't
really thinking that much about participatory systems at that point. As mentioned in the introduction, I'm trained as an architect and I was interested in the way that people design and make cities. In this project, I was looking at how to open up the process to involve other people, ordinary citizens,
in building something that would change their skyline, albeit just for a short amount of time. I essentially made this modular system made of carbon-fibre structure with balloons and electronics. It was members of the public that assembled this. They designed how all the modules went together,
they then inflated it, they controlled it, and they erected basically what became an 18-storey structure that erupted on their skyline, albeit only for one evening.
The video is not very good. 2006, a bit rotten all. Each of those balloons you can imagine is about a metre wide, so it's quite a large structure. I'll move to the photos since that might give a slightly clearer idea. The point was that this was ordinary people for perhaps the first time
really feeling like they could affect and change a structure on their skyline. Flight Path Toronto, moving towards the permanent here, Flight Path Toronto was
a project that I did with Natalie in 2011 where I was commissioned by the city to do a project in their Nathan Phillips Square, which is their central square in front of their city hall. And essentially what I wanted to do was look at public transportation and how to adopt
a transportation methodology where the citizens could get involved in planning out the routes and most particularly in prototyping where the routes should be in order to rapidly reconfigure the city. One of the problems when you do new bus routes or new cycle lanes is they
take ten years to plan, you then disrupt the city and carving out the area, and then everyone or lots of people get upset at the disruption, and sometimes you don't get it right. So there is this kind of relationship between
the citizens of a city and the people who make these decisions where the people who make the decisions cannot fail and the citizens don't really have a say in how to configure the transportation. So what we ended up looking at here in Nathan Phillips Square was how to use zip lines as a transportation system
in the city. So it's thousands of years old, this technology basically just needs gravity. It's fast, it's fun, it's emissionless, and the most important thing is that it's very quick to deploy and to prototype and try out a transportation line, and
then if it's not in the right location, you can quickly redeploy somewhere else. And so the idea was basically to involve the local members of the public in defining and designing these different pathways, and then actually trialling it in person. So what we did was we turned it into a kind of a flying experience
where, you know, you should be able to fly to work, and we created these networks around Nathan Phillips Square essentially anyone could come and try out what it was like. The idea here was that you know, essentially it was a proposition
that enabled us to, if you like, kind of build a shared memory of a possible future. People didn't necessarily need to agree that this was the right thing to do, but they could try it out and then have an opinion on where it should go or how it should go or whether it should not be there at all. And so essentially it enabled us to kind of rapidly prototype
urban transportation in the city and to involve members of the public in that process as well. So, Open Burble and Flightpath were for me you know, they were about this question of getting people to work together without consensus.
The second thing that I mentioned was getting people to make decisions together and building this kind of shared responsibility for a collective future. So I'm going to talk about a couple of projects here that start to move down this scale towards the permanent infrastructural.
Natural Fuse was essentially a plant with a power socket on it. And the amount of power available to the socket is limited by the capacity of the plant to offset its carbon footprint. The idea was basically that you could plug in your electronic items and as
the plant grew and sequestered carbon or captured carbon, it could offset the carbon footprint of your electric devices. The thing is that even one plant was not enough to offset a light that was plugged in. In order to offset the carbon footprint of a
light, you need six plants to offset its carbon footprint. So what happened was they were networked over the internet and when you switch on your device it wakes up and it looks out on the network to see if there's five other devices that are not currently being used to offset energy consumption.
And if there are, then you can borrow their carbon-capturing capacity and offset against your own energy use. And in so doing, the idea is that the community can retain carbon neutrality. Now, in practice, the way this worked was that there was a switch where you could be either selfish or selfless.
If you were selfless, then basically when you switch it on, it looks out on the network. Let's say there's only three plants available, not six. Then you only get enough energy until you start to threaten the carbon footprint of the community. And at that point, as a fuse, it cuts off your energy. So you might only have
five minutes of light and then it'll cut you off. But of course in a participatory system, you need to enable people to decide to be selfish, if the case may be. Somebody might actually need that light on no matter what harm it has against the carbon capturing capacity of the community, and so they would choose selfish. They might have
heard somebody, an intruder in their flat. In that case, you get as much energy as you need, but when and if you harm the carbon footprint of the community, it sends out a kill signal to go and kill somebody else's plant. And so it's done with a vinegar injection over here. And you don't know whose
plant that's going to be, but the point is when you make that decision, you know that you're going to have an impact on somebody else's, but you're also going to have an impact on the community's capacity to distribute their carbon sequestering. In practice, what we do is we give each plant three lives, if you like.
And when your plant loses a life, you get an email that basically says, this person had to be selfish and therefore your plant had to lose a life, and you both CC'd on this. And that gives this opportunity for people to discuss, okay, well, why were you selfish? What actually happened there? What did you need to do? And so it's about building up
essentially a system that encourages cooperative behaviour, doesn't require it, but in the event of selfish behaviour, enables people to be accountable to that question and enter into a discussion around it. And so, for me, this was a
project that essentially prototyped a way to kind of distribute decision-making, in this case on the question of energy use, in such a way that doesn't require us all to agree right at the beginning. So it's been to different places in the world. We had a deployment of about 30 in New York,
then some in Sydney, in Seoul, also in Spain somewhere, and so what we do is we basically set up a shop where people can come and rent these plants for about three to six months or what have you. So, distributing that decision-making in such a way that doesn't require
consensus from the beginning. The second project that I want to talk about in this section is a more recent project called Cinder. Now, with Cinder, and as you can see, we're sort of sliding towards the infrastructural there. With Cinder,
we were commissioned for a school in Cambridge, and it was a new building, fully kitted out with sensors and a building management system. It was a new community, and there was a group of students that were moving into this building. What we ended up creating, and this was
a two-year process where we worked very closely with the incoming students, what we created essentially was a virtual cat, an augmented reality cat that lives in the school. That cat responds to the environmental conditions, to the sensors in the building, to the building management system, and has different behaviours,
it changes colours, it does different things on different days. All of these things were designed by the students. The important thing is that while you can interact with it in certain ways, and you'll see that it sort of gets bigger as different sensor data changes, the students
are learning a little bit about the building management system and the sensor data through this cat and their interactions with it, but when the cat gets hungry, when you've interacted with it too much, it goes out on the network and hunts for food. At that point, the cat will appear on somebody's one student's laptop,
and it will go there and it will beg for food. The student then has a decision to make about how much food to give to the cat, and that is based on the amount of food that they have to give to the cat is based on how much solar energy has been generated today by the solar panels on the building. So they go through this kind of process of thinking about how
much resource they can allocate to the cat, how much they'll have to save for later, and how much they will work with their fellow students on giving food later on. So these are just some clips from the process. It was about 20 workshops with the students to get
through this. I'll just let this play for a little bit. They designed Cinder, they named her her behaviour is how she would respond to the building
management system. He's clearly going to be a CEO one day
So, again, this was a project about figuring out how to take something quite complex like a building packed with technology, get students involved in making some decisions about that, and
essentially having something that is going to grow up with them over the next few years, because this is a new community in a part of Cambridge that is being totally redeveloped, and crucially getting into that decision-making together, making those decisions about the resource allocation together.
So we talked about working together, deciding together, finally, I just want to talk about acting together, and talk about two projects that have looked at this. Acting together, as I said before, it's about
that sense of accomplishment, the sense that you can actually do something that does have a change. And this is often quite difficult because even when you have worked together and made decisions together,
you don't necessarily leave a trace on the world. But, of course, it is fundamental to bringing together those other aspects. So, I'm going to talk about something that took place in 2011 in Japan. Some of you might know that I founded a platform called Patch Bay,
which was essentially a very early Internet of Things generalised data platform and community that enabled sensors of all kinds around the world to be connected into a web infrastructure where people could use each other's data in real-time. What I'm going to focus on, though, is what took place in
Japan following the radiation crisis after the disaster at Fukushima, which is that in the short space of time after that disaster, the Japanese community, people in general in Japan, were just so frustrated trying to find out what was going on in
terms of the radiation. The local governments were issuing PDF reports every few days. They might have a bunch of numbers in them that didn't really mean anything. But nobody really knew what was going on. They wanted to have some kind of sense of data, and what we noticed
in Japan was that the Patch Bay community was mobilising to start to connect up Geiger counters and radiation monitors to publish in real-time data from these sensors across the country. And so, where there had been very little data before, suddenly
there was a whole bunch of data available from many different sources. Now, the conversation that emerged at that time, because there was a lot of discussion about this, because this was messy data to many people. There were measurements that were taken by amateurs
using all sorts of different equipment that they may or may not have connected in correctly, and so there was a whole kind of contingent of people saying, this data is totally pointless because it's not objectively measured, it's not scientifically valid, you're using different units, we don't even know whether
it's the correct data or not. But this fundamentally misunderstood what was going on, which was that people were just trying to make sense of and have some kind of sense that they could do something in this uncertain context. They weren't trying to amass a scientifically objective
dataset. They didn't have any interest in building some kind of data repository for later analysis externally. They just wanted to know, is the radiation worse at the front of my house or at the back of my house? Should I move my bed from this room to this room?
Would that actually be better? These were the kind of questions they were having, and the fact that this was also taking place in a public forum where people had access to data did mean that these people were engaging in all those questions about how do we make this data better? How do I make this data available in a format that you can make use of it? Oh, you're using microsieverts
and I'm using nanogray? Okay, let me figure out how I can convert this. previous slide. What was really important is what started happening later as this dataset started getting broader and broader, which is that people started building stuff on top of that data. Haiyan Zhang built this thing called the
Japan Geiger maps which, for the first time, took all of that data, related it to exposure time, because, of course, with radiation, it's not just the height of radiation, the amount of radiation that you're exposed to, it's also about how long you're exposed to. So if you're exposed to low radiation for a long period of time, that can
also be dangerous. So she built this interface where you could map out different parts of Japan, compare it to pre-disaster radiation levels, and also look at the exposure time in terms of its health effects. So this was one thing that took place. There were visualisations
you can't quite see here, but a way of figuring out where the peaks of radiation are right now. There was another visualisation to look at trends of where the data was peaking. All of these are sort of created by the community. There was a winds of Fukushima Android app which basically
took wind data on Patch Bay, combined it with the radiation data, and predicted where the radiation would next peak, and so on and so forth. There were dozens of these things of people using the data as messy as it was, not just to build up these sort of objective maps, but actually to do stuff that enabled them to make decisions.
So, for example, if you didn't have a Geiger counter, you could use the SMS alert app on your neighbour's radiation sensor. If you didn't have a radiation sensor that could be connected into the internet, there was a form where you could just manually input those numbers, et cetera, et cetera, et cetera. This was people actually trying
to act in a context where they didn't feel like the government was sufficiently motivated to do so. And finally, VoiceOver. VoiceOver is a project from last year, it's something that we worked on
for a couple of years again, in north of England, in an area called East Durham. We were working in a little town village actually called Peterley and Horden, which are right next to each other, and over time, over many sessions working with the local community, one of the
things that emerged was this idea that they were looking to have a voice, if you like. This was former coal mining territory that had been largely cut off, if you like, from the technological development that had been installed in some of the bigger cities.
So, you know, these so-called smart city projects get installed in big cities like Glasgow and Manchester, but a place like East Durham would never have any kind of technological intervention. Public transport had been cut off. There used to be a train line that would go very nearby, but that had
got removed. So what started emerging? I'm kind of compressing a couple of years' worth of workshops. What started emerging during these workshops was the idea of voice, of connecting up different parts of the different villages, Horden and Peterley,
the young to the old, binding together some kind of sense of community where people didn't necessarily speak with their neighbours any more. And what we started thinking about, basically, was how to create a radically public communication infrastructure, not one where
you could have private conversations with each other, but rather one where every conversation would be completely public, and where the infrastructure would be owned and managed by the local community. Now, what that meant, and most importantly, that actually the very physical manifestation
of this would be necessarily bound in to people's ownership of it, if you see what I mean. What that meant was that if you wanted to connect up two different locations, the path that the
communication would take would depend on which of the local community decided to host a fragment of that network. And the project itself could be used as an excuse to go to your neighbour and say, look, we've connected up these two streets,
if you also join into this, we'll be able to get that much closer to the other end of the line. And so the project was partly about deploying this infrastructure. It was partly about the local community actually working with their neighbours to figure out who would take the next
part of this peer-to-peer network, and it was also partly about the question of what you do with this infrastructure. So the way it was shaping up to manifest itself would be that at some location, you could speak and you could perform
or you could do whatever it is you want to do. That sound would echo and ricochet from house to house, go into the house, and you could actually follow the paths of light to see where the audio was going, and as the audio went into your living room, it would come out on a little speaker, and then it would
bounce and go out and carry on down the road to the other end of the line. That was the principle, like I said, a kind of a radically public communication infrastructure where you can see where the lines of communication are going. So the most important thing that emerged from all of this was what do you actually use it for?
How do you govern this infrastructure? How do you start to make decisions about what it is used for? There were all sorts of things that emerged. The idea of using it for reminiscing and stories, bedtime stories, politics, religion, censorship, all these kind of discussions that people might have once they are
kind of connected through this. This is just a little short bit of video to show you how that actually looked on an individual basis, and then this video is not great, but I'm going to show you another video in a second. So here
I think you can see it sort of bouncing down and going down this road, although the light is maybe you could bring the lights down a little bit. Thanks.
Kids loved it for telling jokes. And so here is the radio box that you have on the inside that you can listen to this. Here's a photo just going down the line. I'm going to just show this video because this is actually the community that we worked with, and this is just a couple of minutes. I'll let it play out.
Can you put the volume up a little?
I was the first speaker
saying the poem, which I've just done for you, and I quite enjoyed it. I think it might have been curiosity, but they all came out to see what was going on. They were saying that they couldn't really understand it, but then when they actually saw it, and they understand when I was
speaking my poem, it was sending flashes of light from one signal to another. And it was like black hole illuminations had come to horn. In this project, the process of figuring out having a voice
and of public speaking and of being able to share stories and opinions somehow in public. The way the project developed was essentially to create almost like an excuse for people to talk
with each other. To see people I know throughout the community take on board a project of this size, some very fearful, some not wanting to record, not wanting to speak, not knowing what to say, then realizing actually people were going to listen, and so actually stepping up and going, do you know what? I have got something to say.
And even if that was kids singing in the booth, well if you knew those kids and you knew the big difference that made to them to actually have that, you know, and to actually be able to sing and have it broadcast throughout the street, and you can't put a price on that and what that achieved, and they were all involved in one way or another and this
Horden, East Durham, now all has this in common. I think the community in Horden have been really supportive about voiceover and I've been so overwhelmed with what's happened and how So, one thing I like about this project is the fact that the video does not convey at all the final deployment,
because that was really not really the important thing. The important thing was the process that the local community had gone through to get this deployed. What we discovered along the way was there were three cousins who didn't even know that they all lived near each other and they discovered each other
through this process, and that kind of is the whole point of this kind of project. I'm just going to wrap up just very briefly to say just about a month ago, we released this project called the Urban Innovation Toolkit which is trying to bring together all of these aspects of mutually assured construction.
It was commissioned by the Future Cities Catapult, and essentially it is a software platform for building this kind of shared understanding of an urban innovation project between many different partners, so focusing on the problems, the stakeholders, the methods, the evidence, and the impact, and how all of this
actually connects up. Because in many cases, these innovation projects are technology-led rather than led by the actual people that are involved in the project itself. And so, it's essentially a methodology for trying to do, trying to work with very complex
situations, and making sure that you actually do have some impact, that you are able to evaluate it, that it does have something to do with the problems that you're dealing with, that the stakeholders are involved in the design of that project, et cetera, et cetera. It's something that we worked with six different cities around the UK
to test out and make sure that it actually worked at different scales of project, and there's a bunch of case studies as well where you can look at projects that have been done around the world along similar lines. Essentially, again, this is a project about building a shared memory of a possible future, a way that people who don't
necessarily yet agree on something can work towards some aim. And with that, I will thank you and ask for any questions if you like. Happy to take any questions.
There's a question. Do we need a microphone? Yeah, we have microphones over there. So thank you. So we have plenty of time for questions, and we have a Q&A with two microphones. Maybe a little applause for the volunteers with the microphones in here. And if you have questions, yeah, thank you. And if you have questions, please raise your hands and then we can see you and get your microphone.
Okay, first question comes here. Okay, hi. My question is how did you have, what kind of relationships did you have to establish to involve yourself with this kind of project? The last project in particular? Voice over? No, I mean in general, basically.
Because I'm really wondering how did you get to do what you're doing? How did you involve yourself? How did you enter this kind of participation? Because you seem to be some kind of a design facilitator or something. Yeah, I guess you see, I started, as I mentioned, as an architect, interested in people
and their relationship to each other and the spaces around them. And so early on, in the late 90s, I was actually just working in general on interactive environments. But I think that it was partly, I have to say, due to I was not
very confident in what I was doing. And in many cases, I didn't want to make the final decision about some things, about what it looked like or how it was configured or what it did or what have you. And that was probably the moment where I started kind of opening up the question of, okay, how do I,
I mean, again, very pragmatic reason. How do I get other people to help figure this thing out? But then as the, you know, as my practice evolved and as I kind of started having a methodology of sorts, what I realised was that actually the fundamental to every single project is
conversation. And so a project like VoiceOver, it took two years, actually it probably took a year and eight months to figure out roughly what the project was. For that period of time, nobody knew. And so nobody had a sort of, nobody had ownership of what that project
should finally be. It was really a question of developing a sense of trust over that very long period. And so the relationship of trust is really fundamental. And I have to say that VoiceOver was quite a difficult project. There were many moments where it felt like nothing would ever come together.
And so just kind of being there, and being there constantly, you know, we are in London, so it's about a five-hour train ride away, but we, you know, we'd actually go up and stay there for periods of time actually working on site was kind of crucial.
Okay, that's answered. Thanks. Do we have another question? Yes, in the first row. You or the dog? You or me or the dog? I've been working with groups in London where estates are being cleared and in those there are people with different objectives
based on if you're renting or if you're a homeowner and what happens in all of these is that everyone ends up fighting each other and they all lose out. This happens every time. How can people avoid this problem?
I can't say necessarily I'm the best at conflict management, I think that one really fundamental thing that I've noticed is that if you try and get people around a table to achieve some final goal, that doesn't work because you start to
disagree about whether we can ever get there, whether it's the right thing to get to, whether, you know, whether we should be doing this at all. So what I try and do at the very first stage is structure discussions around what is the goal of the project rather than what is the kind of outcome, if you see
what I mean, and to make sure that that goal constantly changes, and that's an important thing because I think that is different from the way that community design was done before where you would have a goal and you would make sure that stayed the same so that you could constantly check whether you were achieving it. For me,
what I've noticed is that actually what you should do is constantly question not just whether you're on track but whether you're even headed to the right goal at all. So I would suggest that in an area where you have people actually already arguing
in general, getting people at first just to discuss the goal, not even agree on it, but discuss and understand the complexity of the goal of the outcome, not just the outcome itself might be a step towards it. Does that help? Maybe, I'll try. Okay, next question.
Yes, in the last row. In the very last row. Can you see me so far away? Take your time. Thank you. On your last answer, how do you organise
or formulise these constant changes of the goal? Do you have regular meetings with the stakeholders? Do you have a rhythm like every month, every week, we talk about goals, how is it organised? It is, of course, slightly different
for different projects and a different context. We don't necessarily have a temporal rhythm, but what we do try and do is start off with some small group of people, and it really almost doesn't matter who that group of people is, think about a goal that we might be trying to achieve with this project
and then decide who should be at the next meeting that is not here right now. And then at the next gathering, we go through the same process of questioning what is the goal, and who is not in this conversation that should be? And that sort of helps lead to the
next gathering. It's not quite as clean as all that. It's, of course, a little bit more messy than that, but that's the basic principle where we're trying to basically question the goal the whole way through, but also gather more and more ambassadors, if you like, for the project or people that have been involved
in, maybe not in determining that specific manifestation, but at least went into one of the fundamental conversations around the very purpose of the project in the first place. More questions? Yes, over there.
Hello. My question is about how do you then cater to different level of stakeholders? If a stakeholder, I mean, if we say the level of engagement with a primary stakeholder and a secondary stakeholder, how can we
include them in the discussion through equals, like through some sort of, how much of share do we give them in decision making? And also how much can we actually put the ideas of the secondary stakeholders, for example,
into the design of the project? I can't actually see you. Do you mind waving so I can see where I'm speaking? Okay. That's a bit of a complex question. I'm not sure what you mean by the difference between primary and secondary stakeholders, but I think that
I can give an example. You see, okay. For example, we're doing a project, a design project on river management, preventing the shores of the river from flooding. So the primary stakeholders would be the people who own the land on the
sites, the farmers who own the land on the shores of the river that are being most, that are the most vulnerable to the flood. And the secondary would be people who live beyond that, people who have owned land beyond that. But to manage the whole river, you need to start from the forest up in the hill to the
land nearby the river. So there are multiple levels of stakeholders and multiple people who have different levels of, what do you say, stake in that whole design project. In that case, I would actually direct you to the work in Constitucion in Chile, which I can tell you about
afterwards. But there is a very interesting phenomenon going on or that did go on there after the earthquake in a similar kind of situation where there was a complexity of stakeholders. It's not an easy question to answer, but essentially it is founded on the principle of
creating trust. And we can talk about it afterwards if you like. Any other questions? Do we have other questions? Other questions? Next question? No? So I think we're running out of time as well. So maybe we have a big applause for... Thank you.