Frameworks for Citizen Responsiveness: Towards a Read/Write Urbanism

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.