The beauty of cities is that no two are precisely the same. Each has a unique history, architecture, politics, and culture. Even the smallest town is a collection of households who have over the years built up a shared identity and arrangements for working, living, and playing together. New communities differentiate in this way astonishingly fast, typically in a generation or less. In the 1950s, Long Island’s Levitt own was the poster child for homogeneous, mass-produced American suburbia. Driving through today, you can hardly find any two houses that still look alike. Over the last half-century since they were built, they’ve been expanded and customized by their owners in countless ways. By living together in our cities, tweaking their basic design to meet our changing realities and forging social bonds with our neighbors, we make them uniquely ours. That’s why urban design is as much an art as it is science. It has to respond to countless local variables and idiosyncrasies.
While it hasn’t always been that way, today, technology design is becoming more like urban design. For the last century, our devices were highly standardized objects, produced identically on an industrial scale, and designed to perform a few functions. As late as the mid-1990s, in the course of a year you probably only used a single computer—usually a desktop model—and a handful of software packages. Today, we routinely “do” computing each day though conscious and unconscious interactions with dozens or even hundreds of different kinds of devices running thousands of different pieces of software—our laptops, iPads, and smartphones to be sure, but also computers embedded in buildings, appliances, automobiles, traffic signals, and so on. Mobile devices have liberated computing from the desktop and kicked this shift into high gear. Now digital technology has to respond to and engage with what’s happening around it, just as good architecture requires careful consideration of a building’s surroundings.
In 2004, social-media guru Clay Shirky gave a name to the kind of technology created by place-based communities: “situated software.” Years before Apple launched its App Store, Shirky noticed that his students at New York University’s Interactive Telecommunications Program were building social software for themselves using nothing but open-source code and microcontrollers. Their approach was antithetical to the “Web School” that had prevailed up to that point, “where scalability, generality, and completeness were the key virtues.” Instead, situated software was “designed for use by a specific social group, rather than for a generic set of‘users’ ”9
You can find situated software on any smartphone, where for almost any life situation one might encounter, as Apple’s ads proclaimed in 2009, “There’s an app for that.” Some apps are only for use on the go. Others are for certain kinds of places, or specific social settings. For instance, iTrans will give you the schedule for the subway into Manhattan, and Exit Strategy will tell you which car to ride so you’re closest to the correct egress when you disembark. It also cleverly caches a street map of Manhattan that you can browse offline underground, because New York is alone among world cities in its lack of underground mobile coverage. In San Francisco, Uber can summon a taxi with one click. In Manhattan most us still hail our cabs by hand. But in a pinch you might reach for CabSense, an app that analyzes millions of location-tagged taxicab pickup records collected by the city to identify the best corner to catch one. In Tel Aviv there’s an app that sends alerts whenever Hamas rockets are inbound from the Gaza Strip. An alumnus of the MIT Media Lab living in the Iraqi capital of Baghdad has reportedly designed an app that lists recent kidnappings and the going rate for ransom. And Apples Siri, which hails from Silicon Valley, might be the most suburban technology ever created: its voice recognition is perfect for connected cars but completely useless on noisy city sidewalks.
Shirky’s students built situated software because, for the first time, they could. “Making form-fit software for a small group of users has typically been the province of banks and research labs,” Shirky explained. “The kinds of scarcities the Web School was meant to address—the expense of adequate hardware, the rarity of programming talent, and the sparse distribution of potential users—are no longer the constraints they once were.”11 Today, the infrastructure that’s needed to build and distribute a smartphone app is already in place, and either free or rentable; it costs almost nothing to turn a novel idea about how to interact with the city into a piece of software that meets the needs of a handful of people in close proximity. For Shirky, situated software didn’t even have to be that good, as long as it scratched some collective itch.
Situated software also connected the Web to the physical world. In fact, those connections were critical to making the designs successful. The two student projects that inspired Shirky’s thinking, Scout and CoDeck, both “had the classic problem of notification—getting a user to tune in requires interrupting their current activity.” Both “hit on the same solution: take most of the interface off the PC’s dislocated screen, and move it into a physical object in the lounge, the meeting place/dining room/ foosball emporium in the center of the ITP floor.” Scout was like Dodgeball, which we saw in chapter 4, but instead of using phones to check in, students swiped their university ID card. CoDeck was basically YouTube wrapped inside a 1970s Betamax videocassette player: people could use its buttons as controls to share and comment on each other’s video creations. Unlike our experience of software on the desktop, where the entire experience plays out in a single window, situated software spills out into the larger world and inserts itself into our lives. Both projects had websites where users could interact with the software, but as Shirky noted, “the core piece of each is location in physical space that puts the application in a social context.”
Shirky’s essay was a powerful premonition of how the smartphone software ecosystem would unfold. As the same conditions that had existed inside ITP were duplicated in entire cities—wide adoption of smartphones, heavy use of online social networks, and a sensory infrastructure that phones could use to orient themselves to the physical world—demand for situated software exploded. When Apple’s iTunes App Store opened, it put an odd twist on Shirky’s original model by making it possible for situated software to exploit a Web-scale distribution channel. By 2010 nearly one in three adult mobile phone users in the United States had downloaded at least one of more than five hundred thousand different apps available for smartphones.
Now that it’s on the street, computing will never be the same. The screens of our desktop operating systems like Windows and OSX are like the suburbs, split up into a handful of single-use zones—Microsoft Office, the Web browser, and deeply immersive games. The software ecosystem of the iPhone is instead a mirror image of the urban world it has grown up in—like a great city street, it’s populated by quirky little storefronts that work together to create a fine-grained mix. The iPhone may have come from Cupertino, in suburban Silicon Valley, but its true potential is being realized on the streets of San Francisco, New York, London, and Shanghai.
Shirky’s essay echoes Jane Jacobs’s observations on great cities. “Situated software isn’t a technological strategy,” he writes, “so much as an attitude about closeness of fit between software and its group of users, and a refusal to embrace scale, generality or completeness as unqualified virtues.” The grassroots revolution that transformed urban planning in Jacobs’s era took on similar assumptions when it came to city design. It was a response to the excesses of urban planning’s own “Web School,” the large-scale reshaping of the city practiced by power brokers like Robert Moses with little regard for the street life of the city.
Читать дальше