The deep convergence of networks, software and people makes it an exciting time to be in the technology business. There is much reason to be enthusiastic about modern trends in software and the resulting startup culture and maker culture we are all living in today. But what does it practically mean for how we design and build software? I’ve been building networked applications for over 15 years and have been thinking a lot about how we actually approach our craft differently as a result of these shifts.
As one simple example of deep convergence, consider Twitch Plays Pokemon. If you have not heard of Twitch Plays Pokemon, it’s a simple idea that exploded in popularity this year. In a nutshell, a video gamer used an old Nintendo Gameboy Pokemon game streamed over the Twitch TV video streaming service, but with an important but simple catch: he hooked up the built-in chat system for Twitch to send commands to the game. The chat is available to all viewers. So basically anyone that was watching could try to control the game by typing individual commands in chat like A, B, up, down, etc. Except that everyone else was doing the same thing, so everyone’s commands all happened simultaneously. Everyone had some control in playing the game but no one individual could complete any one task. It was an incredibly simple idea, but it exploded in popularity. Over one million people participated in the first Twitch Plays Pokemon and the idea was later refined and months later has spread to dozens of other games.
What made Twitch Plays so compelling for so many people? It’s certainly not an effective way to beat a video game. It’s painstakingly slow compared to just playing single player. Navigating a simple ledge in Pokemon could take hours in the Twitch Plays version because anyone could disrupt the game by working against the common goal, i.e. typing ‘Down’ and walking off the ledge! Neither was its popularity a product of either the interface or the software. It is literally 18-year old graphics over top of a 25-year old communication protocol. Nothing ground-breaking here.
No, the appeal is the emergent behaviour from all the people participating in the system. People could either choose to work towards the common goal of beating the game or they could work against it, just for the lulz. The notion of negatively disrupting a community just to see what happens has a long, rich, unfortunate tradition on the internet. To combat this behaviour in Twitch Plays, the player base gradually developed systems of maintaining order to allow the game to be beaten and the game became a battleground for order versus chaos. So, all of the really interesting stuff in Twitch Plays games arises out of the combination of the technologies and the simultaneous participation of thousands of players. This is emergent behaviour–essentially it is something greater than the sum of its parts. And emergent behaviour is nearly impossible to model.
So how do we design something that can’t be modeled? How do we approach design in an industry where the very nature of what we’re building is constantly changing? Let’s back up for a moment and reflect on how our craft has evolved during the Agile movement. Agile arose out of a recognition that the software development landscape had shifted the areas of risk and difficulty. What used to be difficult to change without incurring risk had become increasingly easy. So it became more valuable to build working code earlier to test and refine our design decisions and change it later than it had been to make those decisions up front. The way we build software has changed so rapidly; trying to formally adhere to a particular methodology and its rituals misses the point of the Agile movement. Instead of adopting a particular flavour of Scrum or XP and its associated rituals, it’s necessary to be constantly re-evaluating things like where you spend time thinking in the abstract, when you start building something concrete and what you start building. It all depends on exactly what problem you’re trying to solve and what the relative value is in working in code versus working in the abstract.
The abstract design tools for building web applications have changed as the applications themselves have. When we are concerned with the visual presentation of content, we whip out pencil and paper, Illustrator or Photoshop to mock up some ideas. When we are concerned with the organization of that content, we might sketch up some wireframes using whatever method we prefer. For static content websites (think 1999) that might be all we need. These design tools capture enough of the essence of the final product to let us make decisions and steer the design. But as web applications became more interactive, these tools became less capable of fully representing the end product. Flat design sketches couldn’t capture how these products felt as you clicked or hovered over areas. So other tools like “click-through wireframes” or high-fidelity prototypes came into use to better represent the nature of the product, to varying degrees of success. We crafted these ways to try and quickly mock up the flow of more interactive web/mobile applications and help us make good early design decisions.
But what about our Twitch Plays example? What tools could help us model that experience and shape its design? The answer is that no mockup or prototype is going to capture the core of the experience in any meaningful way because the experience only exists as a result of the people in the system.
Increasingly, what we call the “content” is actually other people and other networks. Today’s applications are much more than the visual organization of content. And more than the way you as a user interact with and modify that content. When you interact with the application, you are seeing in real-time the reactions of other people and APIs you’re connected to. When you push and poke at the application, it pokes back! In unpredictable ways your actions affect the wider network and ripple out and back into your experience. Twitch Plays might be an extreme example, but as we wire up our digital products increasingly with interconnected networks, their nature is increasingly a product of the responses that come back from those networks. The experience cannot be wholly represented in mock prototypes that are coded to respond in predictable ways, or even using a set of preset random responses. The power of the application is seeing the emergent behaviour of the system, and recognizing that you are a participant in that emergent behaviour. As with the twitch-plays example, the pieces like the chat software and the emulation software are just catalysts to open up emergent behaviour of thousands of people.
While all the aforementioned design tools, like interactive wireframes and comps, are still in our toolbox, they are less important than previously. Every design problem has to be approached freshly and different tools in our toolbox will be appropriate to each problem. Sometimes that’s sketches. Sometimes that’s a prototype. In some cases, there’s no substitute for direct code experimentation with live data and real networks. What happens when we hook up various APIs and libraries and user bases? In a recent example, we wanted to experiment with Twitter data to see if we could capture trends of emotional sentiment.
These images are snapshots from live coding experiments using Meteor, d3, SentiMental as an analysis tool and socket.io to create a real-time color map of emotion in the US based on incoming tweets. Warm colors represent generally positive tweets and cool colors generally negative. The code to produce these was written from scratch in just a few hours. Experiments like this are a core part of how we design during the early, generative phase of a project.
We treat working code as a design tool, not just an end-product. This idea drives everything about the way we work at Normative. From the way we split our teams, to the way we disseminate ideas internally, to where we sit, everything is touched by this concept. Tools that let us experiment in code in ways that can then be made production-ready are gravy for us. Things like scaffolding in Rails and AngularJS are great examples of the types of tools that let us experiment with design ideas quickly, where in the space of a few minutes a solid API with rich functionality can be thrown together for testing ideas. Recently we have added tools like ReactJS and Meteor to our arsenal of tools to quickly experiment in code. And we are always on the lookout for new tools. Using the right tool at the right time can reduce your effort by an order of magnitude.
The point I’m making is not how difficult these things are to build or to tout our team’s ability to use these tools. Rather, the point is how easy they are to build. Understanding that affects the entire software design process. Our practice is built around recognizing that new ways to quickly experiment are emerging constantly and our work environment is focused around the idea of constantly learning new things.
There is no one tool or set of tools that solve software design problems. Sometimes code is the wrong tool, sometimes it’s essential. We are constantly asking ourselves what the real problem is we’re trying to solve and then collectively, designer and developer alike, we rummage through our growing, changing toolbox for the means to best test our ideas.