Joshua Walton and James Tichenor are a creative technology duo currently working at Microsoft. They are well known for their pioneering work in creating immersive interactive architecture at the LAB at the Rockwell Group where they created the open-source tool SpaceBrew, a switchboard for choreographing physical spaces and objects through digital behaviors. We sat down with Josh and James to talk about the role of prototyping and the importance of thinking through making.
You’re known for being at the bleeding edge of digital design. How did you guys get started?
Josh: We have different backgrounds. My undergrad degree was in interaction design, a very early program in IxD, and then I went to graduate school at Cranbrook Academy of Art for Design. I think one of the things I really valued at Cranbrook was learning through making and the importance of exploring materials. Most of those materials were digital, and I’ve always been interested in the relationship between software and design. One thing that James and I have a common approach to is that we like to try things out firsthand in order to gain intuition for those things. It’s really different to try something and reflect on what things were working and what were not working and build up a vocabulary.
James: The thing about building up a vocabulary is so key to what drives learning about a new technology for me. I’m really interested in things that don’t exist yet. If a thing doesn’t exist, but you care about how it comes into the world, the right descriptive languages often don’t exist to describe ways to do it other than to craft it. And those variables that are going to make it good or bad, if you really care about them then you have to figure out a way to work in those media, and that’s what we did at the Rockwell Group Lab. We made so many prototypes, because if you just left it up to the A/V contractor, you wouldn’t be able to really specify the details of what brings an interactive space to life. Or you need to build enough prototypes for that to become the spec. You need to work in it to figure out what is going to make or break that thing for you even if you’re not doing all the production yourself. That’s what really drives it.
I did my undergraduate schooling in Architecture and then studied design computation at MIT. I only went there because I felt like I could only imagine crazy scenarios involving technology–but who cared what I thought. I had to start building enough to have stronger vocabularies and tools, more than I had to be the guy doing all of it.
Josh: Part of that is working on the real problems, too. It’s very easy in design to solve all the problems that aren’t really the ones inhibiting those things from being in the world. That’s why you see all the companies work on legislation because they realize that you can’t make huge shifts without shifts in the government. I guess at a smaller scale you’ll realize that the manufacturing isn’t what you thought it would be, and you realize that it’s going to be totally different and you solved the wrong problems, or problems that aren’t the ones that are really stopping you from creating something.
James: In any large project, or project with a lot of unknowns and crazy variables, like an interactive space or a building that’s not done yet, a lot of the process is trying to figure out where the points are that you will have the most leverage, because you’re not going to be able to do all of it. And what can you do at those inflection points to specify that it lands where you want it to land. Where are those levers? And that’s a lot of what you’re trying to do, and making and building things helps make that a lot more crisp and well defined. We always talk about that great paper, “What Do Prototypes Prototype” that talks about how prototypes can’t do everything. Your time is limited and your time working on a project is limited, so you want to make sure that what you make and control is the part that’s going to transform the experience of it the most.
The word design means so many things to so many people, and I’m really interested in this idea of interaction design being about a user’s real experience. That you’re designing something almost in their mind, you know what I mean?
I always think about design as decision-making and the prototypes are a way of asking very specific questions. That’s what I’m always trying to work with young people to help them define the questions they are trying to ask through their prototypes.
Josh: I really love that because you see many people prototype and not really have a point of view on what they are trying to learn from it. It’s valuable as a sketch, but prototypes do this other thing which is help you gain comfort around different areas of a project.
James: Sometimes you sketch as a communication with other people, and sometimes it’s with yourself, and sometimes it’s amongst other aspects. You want it to surprise you as opposed to sketching which is a communication tool. Sometimes you make prototypes that are purely for presentation, but you should make those only when you need to use those and figure out when you’re doing which.
I’d love to talk about SpaceBrew. What was the idea behind the development of SpaceBrew?
Josh: We built a lot of different systems in the past to run installations and there were many common themes in those. One of the things that we noticed is that they require a lot of technical expertise. We started off making something that would be good for workshops, so it had to be really fast. We think of it first as a prototyping tool, but then we’ve seen people use it in more permanent installations. That’s a similar trajectory to Processing. The people who developed Processing never thought it was going to be used in a project that went somewhere [beyond a user’s experiments], but when it wound up being used in more permanent, larger scale projects, they thought, “Well, that’s cool”.
James: I think there was a lot of inspiration from Arduino in that. When Arduino first came out, many people who worked with microcontrollers didn’t quite understand it because they thought, “I have a PIC which is cheaper, more robust, more precise, and better in terms of all technical specifications. Why use this?” But this other thing, the Arduino, just made a few things easier and faster when you are first thinking about a project. But then, surprisingly, people built all these tools to make the Arduino work faster, work better, and actually meet those technical needs. People were able to work around the Arduino. It is easier somehow to make something easy and simple fit other people rather than make something huge and complicated boiled down to a single group. It’s easier to build the bottom of the pyramid than the top.
Josh: We’ve always had this idea about routing being important, but in past systems, you never spent your time routing because it’s too hard. You’d have to write these configuration files and all this stuff, so the core part of Spacebrew is: Let’s make routing from one project to another project as simple as we could make it. One thing that surprised me is that people use it for prototyping even just for the components of their own projects in a single device; they’ll use it to separate the inputs and outputs so that they can split the work up differently.
Some of my students were using it that way and I wondered if it was overkill because the beauty of the switchboard is that connects multiple, discrete devices to one another. On the other hand, if they need to have a project with, say, a visual output in one place with physical inputs in another, it’s nice to be able to point them to something that I know will work.
James: We talked about how to build more ecosystems around that, or build more sharing tools around that. Because it gets really nice when you get these little choreographies made of components of hardware and software that speak to Spacebrew as a publisher or a subscriber [Spacebrew’s structure for inputs and outputs]. You can say, “I know that works, over there, and I know that other thing works over here.” Then you just focus on putting them together or you focus on making a new piece to introduce into the system.
Josh: For Spacebrew, we’ve always held this fundamental idea of “Play nice with others” because a lot of systems like this try to do too many things. For example, they might try to copy the files from computer to computer, which is good, except that there are already a lot of great tools for that. Instead of SpaceBrew trying to play that role, it just plays well with those tools. So that’s why people can use it in installations.
Josh: Earlier in my career I built tools all the time, and I got skeptical and upset with myself over doing that if I didn’t use them all the time. I found that if I built a tool and I won’t use it then I probably shouldn’t have built it.
Josh: The other big thing is that you wouldn’t just make a graph. A lot of times you’ll see someone do Arduino with Processing and feel like they would like to graph these 3 data points, but they just don’t have time. But if it’s already there you’ll just use it.
There are starting to be a lot of other systems that are Internet of Things type prototyping. Does it worry you that there are so many tools out there now?
Josh: We try to play nice with those tools, but the biggest thing is that Spacebrew is kind of a service, but it’s also a methodology, so we are really okay with people completely replicating the methodology. For instance, I know of one effort where someone is rewriting the server in another language and that’s okay. I actually think that it’s going to be a while before people should be concerned about those issues because it’s in its infancy. I always make the analogy of the Altair computer, the one with just the switches in the front… it’s like trying to so fiercely protect personal computing based on that computer. That wasn’t it. No one thought that the Altair would be the end of personal computing. It took quite a few iterations before anyone had any real intuition or sense of what that should be. I feel like we are in the same phase, but people are pretending that they have it more figured out than they do.
James: I think it’s also because they saw personal computers get adopted, but forgot about the parts where they didn’t make sense and they were early. So maybe some things don’t need to scale to everyone. I think that methodology is so important. Right now we are trying to figure out what parts you need to know to make things talk to each other. We’re trying to find out a good model that works for that.
Josh: I think it’s actually back to a pretty basic design thing about prototyping as a tool for gaining intuition about the technology. I don’t think people have really good instincts for the Internet of Things right now, so the whole idea is let’s say we use this to develop a good sense around what kind of things work and what things don’t. It doesn’t mean that Spacebrew is the tool to use forever. It means that we can take the intuition we glean from the Spacebrew experiments into the next thing we would do.
What’s the most exciting thing that’s been done with Spacebrew (either your projects or other people’s)?
Josh: My favorite things are just the jam sessions themselves–live demos and workshops where groups of people use Spacebrew together and come up with ideas and experiments to try out on the spot– because they don’t always work, and there is always difficulty in and kind of live event like that. It happened after the talk today at the Sketching in Hardware Summit when people here started downloading Spacebrew. Just as we were presenting, there were a bunch of people out in the audience there with working examples. That’s the most exciting thing: seeing how quickly people can get up to speed with using it. One of my favorite moments is that the whole Python library was written in one jam session. I think it was someone from NYC Resistor. He just came in, understood the methodology right away, and just made it. Then afterwards he kept updating it, too.
James: I think there are those moments that you feel Spacebrew can capture an improvisational spirit, where people ask themselves, “I wonder what it would be like if this connected to that?”
Those are my favorite moments, too. I find that I’m connecting a light to my heart rate, but the wondering what it would be like to have the robotic arm responding to it.
Josh: I remember being at hardware hacking things where someone would want to connect their project or a part of their project to someone else’s project, and we would sit around trying to figure out how to do it, and it just was prohibitive to do in a short period of time when networking wasn’t the focus. One other piece of intuition we are getting already is that as designers we’re going to really want to change the way we make objects so that they are created with the idea of connected behavior in mind. I already feel this way from the little bit of stuff we’ve done with Spacebew. If you take the simple example of the light, what kind of sensing and actuation that light would have, how can it ride that really fine line of being abstract enough to be reusable and specific enough to be useful.
James: One other thing that we are able to do in Spacebrew is make things not so precious as a product–it’s more of a prototyping focus. Because maybe all you want in a light switch is a switch that lets you query its state. You don’t need to know all these other things like, did someone walk by, how long did someone touch it, etc. Maybe you don’t need all of that information because that doesn’t help. And that’s a lot of the challenge with the Internet of Things objects, is they have this weight that they have to be a real product and they have to hit a bunch of markets all at once. We love that Spacebrew can help people explore the value of Internet of Things behaviors by building them and trying them out in real time.