Municipal devices

There’s a somewhat unknown symbol of Chicago called the “Municipal Device”. Basically a Y in a circle. It’s a representation of Wolf Point, where the main, north, and south branches of the Chicago river converge. It’s not nearly as ubiquitous as the Chicago flag or the city seal, but it’s actually all over the place if you look carefully. It’s embedded in building facades, attached to an occasional streetlamp, and the logo of the Chicago Public Library. (It’s even part of a light pouring through the girders of the Division Street Bridge.)

If you know me well enough you’ll understand that the very idea that Chicago has a municipal device that’s embedded in the built environment but seldom noticed is appealing on all kinds of levels.

Surely you see where I’m headed with this.

In the case of the symbol the word “device” is a throwback to heraldry. But what about the more typical definition, a functional device? What examples of this are specifically in the service of the municipality?

Let’s start at street level. The public way currently hosts plenty of digital, networked objects.

Photos: left by Flickr user Sterno74, upper right by Chicago Tribune

There are 4,500 networked (solar-powered) parking meters on city streets. The CTA is outfitting train platforms and bus shelters with digital signage with transit information. Even some of our public trash cans are networked objects.

Add to these public shared bike stations (coming soon), all the non-networked screens on the sides of buses and buildings, and infrastructure systems like traffic signal controls, snowfall sensors, streetscape irrigation, and video cameras.

Lastly — and most importantly — are the legions of networked people walking down any given street. Smartphones turn a sidewalk of pedestrians into a decentralized urban sensor network. (A topic for a future post.)

The point is, none of these municipal devices are interoperable, very few work from a common platform, and only a handful are actually open in the sense that a sidewalk is open and public.

How the physical public way is actually used is a good model as we consider what a real digital public way comprised of these disarticulated “devices” might be like. The sidewalk, for instance, is a public space with fairly liberal parameters for usage. Beyond being a route for perambulation it’s a place for free speech and protest, vending, chalk artistry, flâneurism, kids’ lemonade stands, café seating, poetry distribution, busking, throwing bags, chance encounter, and all sorts of other things. Public space in general is the primary mode of information throughput in an urban area.

The question we’re asking ourselves at the city is, how would a digital public way that seeks this level of openness and breadth of use actually work? And what would city government need to do to ensure that the best foundation is laid for this to come to pass? (We’ve begun design and have a few early-stage pilots planned, but my hope with this post is that it begins the conversation broadly about what could and should be.)

Here’s a very low-tech example of a networked public object. All bus stops in the city have signs with a unique SMS shortcode. Waiting riders can text this number for a list of upcoming buses and times. Conceptually this is a one-on-one networked interaction between a person and a public object, the sign. (Technically of course it involves a wide-area network, but we know that near-field communication is on the horizon, and coming to the CTA.)

One way to think about a digital public way is to ask what benefits would accrue to residents and visitors if all public objects were queryable like this. It makes sense for transit, possibly even with certain of the city’s service vehicles, but that seems a limited way of interacting with a municipal device: one-way and purely informational.

There are two other ways of thinking about an open digital public space, it seems to me, and they both have to do with thinking of the city as a platform for interaction.

Photo by Jack Blanchard

The first is to recognize that interaction with all forms of government is increasingly happening online and/or via mobile devices. For instance, plenty of cities have mobile service request (e.g., pothole reporting) smartphone apps. If we think of the currently-installed devices listed above as merely end-points for a network connection to be built upon the city becomes a kind of physicalized network, a platform, for other uses. What might it mean to extend the currently-proprietary network connections for these devices for extremely local, public use? What might it mean for digital literacy in our communities if service requests could be made at the physical locations that they are needed? Thinking of these thousands of points of network tangency enables a scale of functionality that no website or mobile app ever could.

The second is also about platforms. Chicago’s open data portal hosts hundreds of regularly-updated, machine-readable data sets. These sets are the vital signs of the city: public safety, infrastructural, educational, business data, and on and on. They also represent a platform for creating new things. Developers can access the data directly via the portal’s API (application programming interface), building apps that provide new functionality and in some cases radically new uses of the data. (The Apps for Metro Chicago competition hosts a good gallery.)

Now conceive of the city itself as an open platform with an API. Physical objects generate data that can be combined, built upon, and openly shared just as it can be from the data portal. The difference in this scenario is location. Where much of the data in the portal is geo-tagged, data coming from the built environment would be geo-actionable. That is, in the city-as-platform scenario certain data is only useful in the context of the moment and the place it is accessed.

Photo by Jen Masengarb

Here’s a simple example.

The bus shelter you’re waiting at informs you (via personal device or mounted screen) that the public bike share rack at your intended destination is empty. It suggests taking a different bus only a minute behind the one you are waiting for in order to access a bike a few blocks from where you had intended. It offers to reserve the bike to ensure its availability and sends you a map of protected bike lanes (plotted to avoid traffic congestion around a street party) that you can use to reach your final destination.

What’s key about this is the diversity of data sources involved — real-time bike rack status (and reservation), bus locations, route info, protected bike lane locations, traffic volumes and incidents, and cultural event data — but also the fact that it would be nearly meaningless in any place but that exact shelter.

This scenario is the result of a network of interlinked municipal devices. But it needn’t be city government that creates such a scenario end-to-end. By exposing and documenting the data that makes the above possible (as we do with Bus Tracker and Train Tracker) we would enable developers to create their own ecosystem of applications. It’s a business model and the driver of the emergence of civic startups.

You could call such a set of open, networked objects the beginning of an urban operating system and certainly there’s another discussion entirely to be had around how what I’ve described forms the basis of a common operations platform for managing city resources internally. But I’m growing skeptical of calling all this an operating system, at least in the sense we traditionally do. Much of the talk of an urban OS focuses solely on centralized control. But if you’re true to the analogy of a computer operating system it would have to be a platform for others to build applications upon. In truth, this is a lot more like a robustly deployed, well-documented set of fault-tolerant API endpoints than it is an OS.

Drawing by Ralph Fletcher Seymour from Chicago In Picture and Poetry, by Horace Spencer Fiske

On the original Y-shaped municipal device there’s an odd slogan that sometimes accompanies it: I Will. It’s a quotation from a turn-of-the(-last)-century poem by Horace Fiske. If you can get past its priapismic opening and closing lines, you’ll find a pretty forgettable example of overly-gilt regionalist verse.

It’s curious. I will what? In the poem, Chicago, embodied as a goddess, seems to be saying that she will “reach her highest hope beyond compare”. Which doesn’t really say anything at all. What does she hope for?

Mr. Romer’s answer is to do with this moment what Burning Man does every summer: Stake out the street grid; separate public from private space; and leave room for what’s to come. Then let the free market take over."

Cross-posted at Medium. Years ago, when I was just moving into the world of urban technology, I stumbled upon the urban “walkshop” format developed by Adam Greenfield and Nurri Kim (refined and expanded by Mayo Nissen). These walking tours were collaborative, lightly-structured investigations of surveillance and communications machinery sprinkled throughout various cities. Though these walkshops […]

Cross-posted at Medium. CityFi partners John Tolva and Story Bellows frequently find themselves on the frontier of urban change. Their facilitation of major projects often convenes public-private stakeholders, utilizes new models of technology and innovation, and drives policy development, all with the goal of making our cities more livable, vibrant and economically competitive. Currently, this […]