Map based illustration of 311 street sign service calls : US census tracts connected by city roadways. Illustration: Jane Kelly

Seeing the City as Software
In the past, I’ve often enough described cities as being “all about difficulty“: about the necessity of negotiating various waits, complaints and fears. Must we accept this, though? Is there anything that can be done about it? Many, many services attempt to address these concerns and inconveniences. Two in particular, New York City’s 311 gateway to non-emergency services and, in the UK, mySociety‘s awesome FixMyStreet, provide good reference points for what I call frameworks for citizen responsiveness. The common essence of both 311 and FixMyStreet is that some issue — say, a pothole, broken street sign or open fire hydrant — is identified by a member of the public and is then raised to the attention of whatever municipal authority is empowered to respond to it. Such frameworks hint at the possibility of a major shift not only in how we design the ways citizens call out trouble spots in the urban landscape, but how we design for the performance of that landscape itself.

311 provides an online point of entry, but its primary form of engagement is a phone call between a citizen with a question and an operator able to point her towards the proper resource or department. But once this connection is made, the caller is deposited right back into the big-city bureaucracy. Similar things are true of FixMyStreet, which collects issues on its users’ behalf and then forwards the aggregated complaints to the relevant department of government.

How might we close the loop? How could we arrange things so that the originator, other members of the public, the city bureaucracy itself and other interested parties are all notified that an issue has been identified and is being dealt with? How might we identify the specific individuals or teams tasked with responding to the issue, allow people to track the status of issues they’re reported, and ensure that observed best practices and lessons learned are gathered in a resolution database?

This street sign is broken. Who you gonna call? Photo: flickr user bondidwhat.

We can begin to treat urban environments as system resources, rather than a mute collection of disarticulated buildings, vehicles, sewers and sidewalks.

Technology entrepreneur Jyri Engeström has suggested stealing a page from the practice of software development as a way of addressing shared problem spaces more generally. This got me thinking about an issue-tracking board for cities – in which each complaint receives a unique identifier, a space to characterize it more fully, and the name of the party responsible for addressing it.

This kind of urban issue-tracking board would have to be visual and Web-friendly, simultaneously citizen-facing and bureaucracy-facing. The issue-tracking board would provide citizens with a variety of congenial ways to initiate trouble tickets, whether they’re most comfortable using the phone, a mobile application or website, or a text message. It would display currently open cases, and gather resolved tickets in a permanent archive or resource. It would use an algorithm to assign priority to open issues on a three-axis metric:

(a) Scale. How many people are affected by the issue? Does this concern just me, me and my immediate neighbors, our whole block, the neighborhood, or the entire city?
(b) Severity. How serious is the issue? In descending order, will it result in imminent loss of life, injury or the destruction of property? Is this, rather, an aesthetic hazard, or even simply a suggestion for improvement?
(c) Urgency. How long has the tag been open?

Because a great many urban issues are going to crop up repeatedly, perhaps it would offer the kinds of tools content-management software for discussion sites has had to evolve over the years: ways to moderate tickets up or down, or mark their resolution as particularly impactful.

Then, of course, it would apply the usual variety of visualizations to the live data, allowing patterns to jump right out. Which city department has the best record for closing out tickets most quickly, and with the highest approval rating? What kind of issues generally take longest to address to everyone’s satisfaction?

Don’t Walk. Until I’m fixed. Photo: Ingrid Krichter.

As I see it, a contemporary framework for citizen responsiveness suited for big cities would offer most if not all of the following features:

- Two aspects of 311, an easy-to-memorize universal point of entry and a catching mechanism of empowered human operators lying just behind it
- A useful spread of other points of access, including desktop and mobile applications
- The kind of location-specific overview provided by services like Everyblock, with maps as one obvious and logical way in
- An appropriate prioritization algorithm
- Moderation tools
- The accountability, transparency and ticking clock-to-resolution offered by an open-ticket system
- A persistent archive of resolved issues
- Top-notch graphic design, capable of holding its own with best contemporary Web practice
- A layer of data analytics and visualization

“We could quite literally assign every cobblestone, traffic light and street sign on the planet a few million addresses.” Photo: Emma Pulido.

Beyond Trouble Tickets, Towards Public Objects
No issue-tracking system, even the best-designed and most cleverly devised, is going to quash the frustrations of city life completely. I believe, though, that the system I sketch out here would give cities a supple and relatively low-cost way to close the loop between Jacobian “eyes on the street,” and the agencies that serve and are fully empowered to respond to them. What I’ve described here is, if nothing else, a way to harness the experience and rich local expertise of ordinary citizens.

But what if we took a single step further out? What if we imagined that the citizen-responsiveness system we’ve designed lives in a dense mesh of active, communicating public objects? Then the framework we’ve already deployed becomes something very different. To use another metaphor from the world of information technology, it begins to look a whole lot like an operating system for cities.

Then we can begin to treat the things we encounter in urban environments as system resources, rather than a mute collection of disarticulated buildings, vehicles, sewers and sidewalks. One prospect that seems fairly straightforward is letting these resources report on their own status. Information about failures would propagate not merely to other objects on the network but reach you and me as well, in terms we can relate to, via the provisions we’ve made for issue-tracking.

And because our own human senses are still so much better at spotting emergent situations than their machinic counterparts, and will probably be for quite some time yet to come, there’s no reason to leave this all up to automation. The interface would have to be thoughtfully and carefully designed to account for the inevitable bored teenagers, drunks, and randomly questing fingers of four-year-olds, but what I have in mind is something like, “Tap here to report a problem with this bus shelter.”

“Tap here to report a problem with this bus shelter.” Photo: Ralph Hockens.

In order for anything like this scheme to work, public objects would need to have a few core qualities, qualities I’ve often described as addressability, queryability and even potential scriptability. What does this mean?

- Addressability. In order to bring urban environments fully into the networked fold, we would first need to endow each of the discrete things we’ve defined as public objects with its own unique identifier, or address. It’s an ideal application for IPv6, the next-generation Internet Protocol, which I described in Everyware as opening up truly abyssal reaches of address space. Despite the necessity of reserving nigh-endless blocks of potentially valid addresses for housekeeping, IPv6 still offers us a ludicrous freedom in this regard; we could quite literally assign every cobblestone, traffic light and street sign on the planet a few million addresses.

- Queryability. Once you’ve got some method of reliably identifying things and distinguishing them from others, a sensitively-designed API allows us to pull information off of them in a meaningful, structured way, either making use of that information ourselves or passing it on to other systems and services.

We’ve so far confined our discussion to things in the public domain, but by defining open interoperability standards (and mandating the creation of a critical mass of compliant objects), the hope is that people will add resources they own and control to the network, too. This would offer incredibly finely-grained, near-realtime reads on the state of a city and the events unfolding there. Not merely, in other words, to report that this restaurant is open, but which seats at which tables are occupied, and for how long this has been the case; not merely where a private vehicle charging station is, but how long the current waits are.

Mark my words: given only the proper tools, and especially a well-designed software development kit, people will build the most incredible ecology of bespoke services on data like this. If you’re impressed by the sudden blossoming of iPhone apps, wait until you see what people come up with when they can query stadium parking lots and weather stations and bike racks and reservoir levels and wait times at the TKTS stand. You get the idea. (Some of these tools already exist: take a look at Pachube, for example.)

- And finally scriptability, by which I mean the ability to push instructions back to connected resources. This is obviously a delicate matter: depending on the object in question, it’s not always going to be appropriate or desirable to offer open scriptability. You probably want to give emergency-services vehicles the ability to override traffic signals, in other words, but not the spotty kid in the souped-up WRX. It’s also undeniable that connecting pieces of critical infrastructure to an open network increases the system’s overall vulnerability — what hackers call its “attack surface” — many, many times. If every exit is an entrance somewhere else, every aperture through which the network speaks itself is also a way in.

“What’s a public object? A sidewalk. A building facade. A parking meter. Any discrete object in the common spatial domain, intended for the use and enjoyment of the general public… which is de facto shared by and accessible to the public, regardless of its ownership or original intention.” Photo: Nino Modugno.

We should all be very clear, right up front, that this poses a nontrivial risk: cyber-sabotage, casual vandalism, the risk of cascading failures. But as my architect friends say, this is above all something that must be “verified in field,” validated empirically and held up to the most rigorous standards.

What do we get in return for embracing this nontrivial risk? We get a supple, adaptive interface to the urban fabric itself, something that allows us not just to nail down problems, but to identify and exploit opportunities. Armed with that, I can see no upward limit on how creative, vibrant, imaginative and productive twenty-first century urban life can be, even under the horrendous constraints I believe we’re going to face, and are perhaps already beginning to get a taste of.

Stolidly useful, “sustainable,” justifiable on the most gimlet-eyed considerations of return on investment, environmental benefit and total Cost of ownership? Sure. But I think we should be buckling ourselves in, because first and foremost, read/write urbanism is going to be a blast.


This essay is adapted from two posts that appeared previously on Greenfield’s blog Speedbird. Read the originals here and here.

Adam Greenfield, author of Everyware and the forthcoming The City Is Here For You To Use, is managing director of Urbanscale LLC, an urban systems design practice. He lives in New York.

Detail from everyblock‘s map interface

Yesterday’s reports of MSNBC’s acquisition of Adrian Holovaty’s Everyblock have generally treated the latter as a “hyperlocal news service.” And to be sure, this is abetted by some of the language Everyblock itself uses to frame and describe what it offers: a “news feed for your block” which can help you “find news nearby.”

But for whatever it’s worth, I’ve never understood Everyblock’s fundamental proposition in quite this way, and here’s why I think understanding what it offers as “news” is giving it short shrift:

As an aggregator of information that is ultimately generated elsewhere, Everyblock is built on the notion of the “open API,” or application programming interface. We can think of an API as a conduit that allows Everyblock to draw upon, and re-present, a wide range of geographically-specific information from external sites and databases, including geotagged pictures from Flickr, restaurant reviews from Yelp, real-estate listings from Trulia, and police, transaction and utility reports generated as a matter of statutory compliance by local government.

Of course, such location-specific information has been gathered since time immemorial, by cities and citizens both. Most all of the formally recorded material even got disseminated, if only in some half-hearted way that barely clears a minimal definition of public disclosure. Squirrelled away in a heterogeneous sprawl of files, repositories, archives, newsroom “morgues,” and never least in personal memory, the time and effort required to compile these tenuous traces into a useful picture of a given time and place would have been exceedingly burdernsome, to say the least.

Nor, frankly, did a first pass at publishing this kind of information to the Internet help much. It was all nominally “on the Web,” yes, but deposited in such a scatter of incompatible formats (including natural language), and in such siloed and hard-to-query locations, that it was effectively as inaccessible to casual inspection as the status quo ante.

The genius of Everyblock isn’t simply that it automates the onerous process of collecting the traces of urban experience. It’s that everything, regardless of source or type, gets rolled up and presented in the easily comprehensible form of a precisely-placed dot on a neighborhood map. In a detail that speaks particularly well of Everyblock and its desire to serve its users, these are not the off-the-rack Google Maps most other sites make do with, but bespoke cartography of unusual clarity and refinement. The result renders the heretofore-obscure workings of neighborhood life explicitly, in something not too far off of real time, and in unprecedentedly high resolution.

Consider the picture that Everyblock offers me of what is, for better or worse, my own zipcode: 10016. At the release of a pulldown menu, I learn things about the streets I’m used to walking that would have remained latent at virtually any point in the past, from the fifty-six crimes reported in Precinct 13 for the week of August 10, 2009 (two robberies, three felony assaults, nine burglaries, no fewer than forty-one grand larcenies, and one grand larceny auto) to the massive tally of 64 violation points racked up by my now-former favorite Indian restaurant – Tiffin Walla, at 127 E 28th St – in the course of its most recent Health Department inspection.

Data points like these are what we interaction designers, mangling the English language somewhat, refer to as “actionable”: they’re direct influences on behavior, if not outright drivers of behavior. (I’d certainly think twice before hitting the lunch buffet at Tiffin Walla again.) But are they “news” by any meaningful definition?

This isn’t information to be consumed with the Week in Review section over Sunday morning bagels and coffee, summarized in the top-of-the-hour recap, or dribbled out across a Chyron feed. It’s information that’s of most interest and best use pushed to us when we’re out in the world. As I tell my students, nothing in the world is as interesting as information about place when you’re in that place, or (perhaps more to the point) about to be.

Laminating place-specific information from the panoply of available and relevant sources into an at-a-glance guide to real-time decisions, and doing so with Apple-quality interaction design, would – to my mind at least –represent an absolutely unbeatable value proposition. And while it’s true that Everyblock, as powerful and as useful as it already happens to be, is still a few crucial steps removed from offering this, nothing in its history or that of its developers suggests that such a thing would be unreasonable to expect as a next evolutionary step.

If, that is, new corporate owners MSNBC leave well enough alone, and don’t simply try to repackage the site as a wrinkle on their news offering.

MSNBC implies that they’ll have the wisdom to do just that: to harvest Everyblock for information that substantiates or otherwise enhances existing news stories, and even potentially use it to generate new ones, but not to meddle with the API design, the cartography, or the other provisions that make the site what it is. Whether or not this will actually prove to be the case, nobody can yet say, but I must admit there are two things about MSNBC that make me skeptical: the “MS” and the “NBC.”

Personally, I’m delighted that Everyblock has found a way to remain viable. In the wake of the 30 June expiry of its sustaining Knight Foundation grant, I’d been concerned that this tool of unparalleled (if, as we’ve seen, occasionally uncomfortable) utility would simply cease to exist. But those of us who love the cities it serves should insist that it continue to be understood properly, whatever the distractions of its new livery: as a platform that helps us compose an active response to the environments we inhabit, and not simply a generator of reportage to be consumed.


As with all review and opinion pieces posted on Urban Omnibus, the views expressed are those of the author only and do not reflect the position of Urban Omnibus editorial staff or the Architectural League of New York.

Adam Greenfield is the head of design direction for service and user-interface design at Nokia. He writes and consults on issues at the intersection of design, technology and culture. He is the author of Everyware: The dawning age of ubiquitous computing, and the forthcoming The City Is Here For You To Use. He lives in Helsinki.

]]> http://urbanomnibus.net/2009/08/hyperlocal-news-makes-news-the-case-of-everyblock/feed/ 2 40.74764711169807 -73.98515224456787