Google’s recent announcement of App Inventor is one of those back-to-the-future moments that simultaneously stirs up all kinds of furtive and long-suppressed hope in my heart…and makes me wonder just what the hell has taken so long, and why what we’re being offered is still so partial and wide of the mark.
I should explain. At its simplest, App Inventor does pretty much what it says on the tin. The reason it’s generating so much buzz is because it offers the non-technically inclined, non-coders among us an environment in which we can use simple visual tools to create reasonably robust mobile applications from scratch — in this case, applications for the Android operating system.
In this, it’s another step toward a demystification and user empowerment that had earlier been gestured at by scripting environments like Apple’s Automator and (to a significantly lesser degree) Yahoo! Pipes. But you used those things to perform relatively trivial manipulations on already-defined processes. I don’t want to overstate its power, especially without an Android device of my own to try the results on, but by contrast you use App Inventor to make real, usable, reusable applications, at a time when we understand our personal devices to be little more than a scrim on which such applications run, and there is a robust market for them.
This is radical thing to want to do, in both senses of that word. In its promise to democratize the creation of interactive functionality, App Inventor speaks to an ambition that has largely lain dormant beneath what are now three or four generations of interactive systems — one, I would argue, that is inscribed in the rhetoric of object-oriented programming itself. If functional units of executable code can be packaged in modular units, those units in turn represented by visual icons, and those icons presented in an environment equipped with drag-and-drop physics and all the other familiar and relatively easy-to-grasp interaction cues provided us by the graphical user interface…then pretty much anybody who can plug one Lego brick into another has what it takes to build a working application. And that application can both be used “at home,” by the developer him- or herself, and released into the wild for others to use, enjoy, deconstruct and learn from.
There’s more to it than that, of course, but that’s the crux of what’s at stake here in schematic. And this is important because, for a very long time now, the corpus of people able to develop functionality, to “program” for a given system, has been dwindling as a percentage of interactive technology’s total userbase. Each successive generation of hardware from the original PC onward has expanded the userbase — sometimes, as with the transition from laptops to network-enabled phones, by an order of magnitude or more.
The result, unseemly to me, is that some five billion people on Earth have by now embraced interactive networked devices as an intimate part of their everyday lives, while the tools and languages necessary to develop software for them have remained arcane, the province of a comparatively tiny community. And the culture that community has in time developed around these tools and languages? Highly arcane — as recondite and unwelcoming, to most of us, as a klatsch of Comp Lit majors mulling phallogocentrism in Derrida and the later works of M.I.A.
A further consequence of this — unlooked-for, perhaps, but no less significant for all of that — is that the community of developers winds up having undue influence over how users conceive of interactive devices, and the kinds of things they might be used for. Alan Kay’s definition of full technical literacy, remember, was the ability to both read and write in a given medium — to create, as well as consume. And by these lights, we’ve been moving further and further away from literacy and the empowerment it so reliably entrains for a very long time now.
So an authoring environment that made creation as easy as consumption — especially one that, like View Source in the first wave of Web browsers, exposed something of how the underlying logical system functioned — would be a tremendous thing. Perhaps naively, I thought we’d get something like this with the original iPhone: a latterday HyperCard, a tool lightweight and graphic and intuitive as the device itself, but sufficiently powerful that you could make real things with it.
Maybe that doesn’t mesh with Apple’s contemporary business model, though, or stance regarding user access to deeper layers of device functionality, or whatever shoddy, paternalistic rationale they’ve cooked up this week to justify their locking iOS against the people who bought and paid for it. And so it’s fallen to Google, of all institutions, to provide us with the radically democratizing thing; the predictable irony, of course, is that in look and feel, the App Inventor composition wizard is so design-hostile, so Google-grade that only the kind of engineer who’s already comfortable with more rigorous development alternatives is likely to find it appealing. The idea is, mostly, right…but the execution is so very wrong.
There’s a deeper issue still, though, which is why I say “mostly right.” Despite applauding any and every measure that democratizes access to development tools, in my heart of hearts I actually think “apps” are a moribund way of looking at things. That the “app economy” is a dead end, and that even offering ordinary people the power to develop real applications is something of a missed opportunity.
Maybe that’s my own wishful thinking: I was infected pretty early on with the late Jef Raskin’s way of thinking about interaction, as explored in his book The Humane Interface and partially instantiated in the Canon Cat. What I took from my reading of Raskin is the notion that chunking up the things we do into hard, modal “applications” — each with a discrete user interface, each (still!) requiring time to load, each presenting us with a new learning curve — is kind of foolish, especially when there are a core set of operations that will be common to virtually everything you want to do with a device. Some of this thinking survives in the form of cross-application commands like Cut, Copy and Paste, but still more of it has seemingly been left by the wayside.
There are ways in which Raskin’s ideas have dated poorly, but in others his principles are as relevant as ever. I personally believe that, if those of us who conceive of and deliver interactive experiences truly want to empower a userbase that is now on the order of billions of people, we need to take a still deeper cut at the problem. We need to climb out of the application paradigm entirely, and figure out a better and more accessible way of representing distributed computational processes and how to get information into and out of them. And we need to do this now, because we can clearly see that those interactive experiences are increasingly taking place across and between devices and platforms — at first for those of us in the developed world, and very soon now, for everyone.
In other words, I believe we need to articulate a way of thinking about interactive functionality and its development that is appropriate to an era in which virtually everyone on the planet spends some portion of their day using networked devices; to a context in which such devices and interfaces are utterly pervasive in the world, and the average person is confronted with a multiplicity of same in the course of a day; and to the cloud architecture that undergirds that context. Given these constraints, neither applications nor “apps” are quite going to cut it.
Accordingly, in my work at Nokia over the last two years, I’ve been arguing (admittedly to no discernible impact) that as a first step toward this we need to tear down the services we offer and recompose them from a kit of common parts, an ecology of free-floating, modular functional components, operators and lightweight user-interface frameworks to bind them together. The next step would then be to offer the entire world access to this kit of parts, so anyone at all might grab a component and reuse it in a context of their own choosing, to develop just the functionality they or their social universe require, recognize and relate to. If done right, then you don’t even need an App Inventor, because the interaction environment itself is the “inventor”: you grab the objects you need, and build what you want from them.
One, two, many Facebooks. Or Photoshops. Or Tripits or SketchUps or Spotifys. All interoperable, all built on a framework of common tools, all producing objects in turn that could be taken up and used by any other process in the weave.
This approach owes something to Ben Cerveny’s seminal talk at the first Design Engaged, though there he was primarily concerned with semantically-tagged data, and how an ecosystem of distributed systems might make use of it. There’s something in it that was first sparked by my appreciation of Jun Rekimoto’s Data Tiles, and it also has some underlying assumptions in common with the rhetoric around “activity streams.” What I ultimately derive from all of these efforts is the thought that we (yes: challenge that “we”) ought to be offering the power of ad-hoc process definition in a way that any one of us can wrap our heads around, which would in turn underwrite the most vibrant, fecund/ating planetary ecosystem of such processes.
In this light, Google’s App Inventor is both a wonderful thing, and a further propping-up of what I’m bound to regard as a stagnating and unhelpful paradigm. I’m both excited to see what people do with it, and more than a little saddened that this is still the conversation we’re having, here in 2010.
There is one further consideration for me here, though, that tends to soften the blow. Not that I’m at all comparing myself to them, in the slightest, but I’m acutely aware of what happens to the Ted Nelsons and Doug Engelbarts of the world. I’ve seen what comes of “visionaries” whose insight into how things ought to be done is just that little bit too far ahead of the curve, how they spend the rest of their careers (or lives) more or less bitterly complaining about how partial and unsatisfactory everything that actually does get built turned out to be. If all that happens is that App Inventor and its eventual, more aesthetically well-crafted progeny do help ordinary people build working tools, firmly within the application paradigm, I’ll be well pleased — well pleased, and no mistake. But in some deeper part of me, I’ll always know that we could have gone deeper still, taken on the greater challenge, and done better by the people who use the things we make.
We still can.
Just in case folks here in town are feeling neglected, fear not: we’re doing events here as well.
As part of Helsinki’s World Design Capital 2010 Ideas Forum, and collaboration with our good friends at Nordkapp, I’m delighted to announce a workshop called “Touchscapes: Toward the next urban ecology.”
Touchscapes is inspired, in large part, by our frustration with the Symbicon/ClearChannel screens currently deployed around Helsinki, how little is being done with them, and how far short of their potential they’ve fallen. Our sense is that we are now surrounded by screens as we move through the city — personal devices, shared interactive surfaces, and now even building-sized displays — and if thinking about how to design for each of these things individually was hard enough, virtually nobody has given much thought to how they function together, as a coherent informational ecosystem.
Until now, that is, because that’s just what we aim to do in the workshop. Join us for a day of activity dedicated to understanding the challenges presented by this swarm of screens, the possibilities they offer for tangible, touch-based interaction, and their implications for the new urban information design. We’ll move back and forth between conceptual thinking and practical doing, developing solid ideas about making the most meaningful use of these emerging resources culturally, commercially, personally and socially.
Attendance is free, but spaces in the workshop are limited, so I recommend you sign up at Nordkapp on the Facebook event page as soon as you possibly can. See you on the 22nd!
Crossposted with Do projects.
The response to the Systems/Layers walkshop we held in Wellington a few months back was tremendously gratifying, and given how much people seem to have gotten out of it we’ve been determined to set up similar events, in cities around the planet, ever since. (Previously on Do, and see participant CJ Wells’s writeup here.)
We’re fairly far along with plans to bring Systems/Layers to Barcelona in June (thanks Chris and Enric!), have just started getting into how we might do it in Taipei (thanks Sophie and TH!), and understand from e-mail inquiries that there’s interest in walkshops in Vancouver and Toronto as well. This is, of course, wonderfully exciting to us, and we’re hoping to learn as much from each of these as we did from Wellington.
What we’ve discovered is that the initial planning stages are significantly smoother if potential sponsors and other partners understand a little bit more about what Systems/Layers is, what it’s for and what people get out of it. The following is a brief summary designed to answer just these questions, and you are more than welcome to use it to raise interest in your part of the world. We’d love to hold walkshops in as many cities as are interested in having them.
What.
Systems/Layers is a half-day “walkshop,” held in two parts. The first portion of the activity is dedicated to a slow and considered walk through a reasonably dense and built-up section of the city at hand. What we’re looking for are appearances of the networked digital in the physical, and vice versa: apertures through which the things that happen in the real world drive the “network weather,” and contexts in which that weather affects what people see, confront and are able to do.
Participants are asked to pay particular attention to:
- Places where information is being collected by the network.
- Places where networked information is being displayed.
- Places where networked information is being acted upon, either by people directly, or by physical systems that affect the choices people have available to them.
You’ll want to bring seasonally-appropriate clothing, good comfortable shoes, and a camera. We’ll provide maps of “the box,” the area through which we’ll be walking.
This portion of the day will take around 90 minutes, after which we gather in a convenient “command post” to map, review and discuss the things we’ve encountered. We allot an hour for this, but since we’re inclined to choose a command post offering reasonably-priced food and drink, discussion can go on as long as participants feel like hanging out.
Who.
Do projects’ Nurri Kim and Adam Greenfield plan and run the workshop, with the assistance of a qualified local expert/maven/mayor. (In Wellington, Tom Beard did a splendid job of this, for which we remain grateful.)
We feel the walkshop works best if it’s limited to roughly 30 participants in total, split into two teams for the walking segment and reunited for the discussion.
How.
In order for us to bring Systems/Layers to your town, we need the sponsorship of a local arts, architecture or urbanist organization — generally, but not necessarily, a non-profit. They’ll cover the cost of our travel and accommodation, and defray these expenses by charging for participation in the walkshop. In turn, we’ll ensure both that the registration fee remains reasonable, and that one or two scholarship places are available for those who absolutely cannot afford to participate otherwise.
If you’re a representative of such an organization, and you’re interested in us putting on a Systems/Layers walkshop in your area, please get in touch. If you’re not, but you still want us to come, you could try to put together enough participants who are willing to register and pay ahead of time, so we could book flights and hotels. But really, we’ve found that the best way to do things is to approach a local gallery, community group or NGO and ask them to sponsor the event.
At least as we have it set up now, you should know that we’re not financially compensated in any way for our organization of these walkshops, beyond having our travel, accommodation and transfer expenses covered.
When.
Our schedule tends to fill up 4-6 months ahead of time, so we’re already talking about events in the (Northern Hemisphere) spring of 2011. And of course, it’s generally cheapest to book flights and hotels well in advance. If you think Systems/Layers would be a good fit for your city, please do get in touch as soon as you possibly can. As we’ve mentioned, we’d be thrilled to work with you, and look forward to hearing from you with genuine anticipation and excitement. Wellington was amazing, Barcelona is shaping up to be pretty special, and Taipei, if we can pull it off, will be awesome. It’d mean a lot to us to add your city to this list. Thanks!
This last installment of our series (I, II) on networked mobility is more of a coda than anything else, and it goes directly to the question of systemic cost, and who bears it. (In the interest of full disclosure, I ought to mention that I’ve been having some lovely conversations with Snapper, the company that provides farecard-based payment services to the transit riders of Wellington, and now Auckland as well, and that I have a stake in the success of their endeavor.)
Any time you’re shifting atoms on the scale presented by even a small town’s transit infrastructure, there’s obviously going to be expense involved, and that has to be recovered somehow. Maintaining such a network once you’ve brought it into being? Another recurring expense, on a permanent basis. Rolling stock, of course, doesn’t grow on trees. Training and paying the front- and back-of-house staff — the people who oversee operations, design the signs, drive the trams, clean the stations, even the folks who get to snap on blue latex and haul the belligerent piss-drunks off the buses — another enormous ongoing outlay. Pensions, unplanned overtime, insurance coverage: these things don’t pay for themselves. All stipulated.
So why do I still believe that transit ought to be free to the user?
Because access to good, low- or no-cost public institutions clearly, consistently catalyzes upward social mobility. This was true in my own family — the free CUNY system was my father’s springboard out of the working class — and it continues to be quantifiably true in the context of urban transportation. The returns to society are the things most all of us, across the center of the political spectrum broadly defined, at least claim to want: greater innovation, a healthier and more empowered citizenry, and an enhanced tax base, for starters.
I’m going to make a multi-stage argument, here, first about the optimal economic design of public transit systems, and later about how the emergent networked technologies I’m most familiar with personally might best support the measures and policies I believe to be most sound. Most of what you’re about to read is bog-standard public-policy stuff; only toward the end does it veer toward the kind of Everyware-ish material regular readers of this blog will be comfortable with, and everyone else may find a little odd. Politically, its assumptions ought to be palatable to a reasonably wide swath of people, from social democrats on the center-left to pro-business Republicans on the right; with suitable modifications, anarchosyndicalists shouldn’t find too much that would give them heartburn.
- Let’s start with the unchallenged basics. Access to reliable transportation allows people to physically get to jobs, education and vital services (e.g. childcare) they might not otherwise.
- Jobs obviously have a direct effect on household wealth; post-secondary education tends to open up higher-paying employment opportunities, and generates other beneficial second-order effects; and services like reliable childcare allow people to accept (formal and informal) employment with time obligations they would not otherwise be able to accommodate.
- A regional transportation grid sufficiently supple to connect the majority of available jobs with workers rapidly and efficiently is never going to be cheap.
- The return on such an investment is, however, considerable — when savings due to reduced road and highway depreciation, etc., are considered as well as direct benefits, on the order of 2.5:1. This isn’t even remotely in the same galaxy as the kind of multiples that get VCs hot & bothered, but it’s not at all bad for a public-sector expenditure. (Note, too, that the proportion of systemic costs generally retired due to user fees is comparatively small.)
- Being able to spread the fixed costs of a transit system over a significantly expanded ridership would increase the economic efficiency of that system, and thus represent a different kind of savings. Given two types of riders — dependent, people for whom public transit is their only real option, and discretionary, folks who choose public transit over other modes only if it’s markedly cleaner, safer, more convenient, cheaper, etc. — how to maximize both?
- Increasing dependent ridership is relatively easy. I’m going to propose that a greater expansion in the number of transit riders would be achieved by reducing the cost of ridership from relatively-low to zero than by a comparable reduction from relatively-high to relatively- or even absolutely low. Another way of putting it is to say that a significant number of potential riders are dissuaded by the presence of any fare at all. (Strictly speaking, a reduction of fees to zero would be a Pareto-optimal outcome, though this is true only if we agree to consider genuine concerns like increased crowding and greater systemic wear-and-tear from higher loads as externalities. Which, of course, they are not.)
- Maxing out the number of discretionary riders is a little tougher. What both dependent and discretionary riders have in common, though, is the requirement that network apertures be located in as close proximity as is practically achievable to origins and foreseeable destinations. And here’s where the argument arcs back toward the things we we’ve been talking about over the last week, because the transmobility system described accommodates just this desire, by forging discrete modal components into coherent journeys. Trip segments dependent on more finely-grained modes like walking, shared bikes or shared cars, primary at origins and destinations, are designed to dovetail smoothly with the systems responsible for trunk segments, like buses, BRT, light rail, subways, metros and ferries.
∴ That transit system is of most social and economic value to a region which fuses the greatest number of separate transportation modes and styles into a coherent network; which minimizes friction at interline and intermodal junctures; and which does this all while presenting a cost to the rider no greater than zero.
Fully subsidizing any such system would be expensive…inarguably so, immoderately so. But if my conjecture is right — and oh, how I would love to see data addressing the question, one way or the other — a total subsidy produces disproportionate benefits even as compared to a generous subsidy. Success on this count would be the ultimate refutation of the zero-sum governance philosophy that took hold in the outsourcin’, rightsizin’ States during the 1990s, and has more recently and unaccountably migrated elsewhere. (I say “unaccountably” because you’d think people would have learned from America’s experience with what happens when you leave things in the hands of a “CEO President.” And also because, well, there hasn’t turned out to be much in the way of accountability for all of that, has there?) Municipalities ought to be conceiving of transit fees not as a potential revenue stream, but as a brake on a much bigger and more productive system.
To me, this isn’t a fantasy, but rather a matter of attending to the demands of basic social justice. For all too many, bad transport provisioning means getting fired because they couldn’t get to work on time, despite leaving the house at zero-dark-thirty. Or not getting hired in the first place, because they showed up late to the interview. Or not being able to take a job once offered, because the added expense of an extra bus trip to put the baby in daycare would burn every last cent one might otherwise eke out of a minimum-wage gig. Anyone who’s ever been trapped by circumstances like these intimately understands cascading failure in the for-want-of-a-nail mode. (Not buying it? See if you can’t dig up a copy of Barbara Ehrenreich’s seminal Nickel and Dimed.)
I’ve recently and persuasively seen privilege defined — and thanks, Mike, for digging up the link — as when one’s “social and economic networks tend to facilitate goals, rather than block them.” As I sit here right now, my mobility options are as infinitely finely grained as present-day practices and technologies can get them: which is to say that my transportation network, too, facilitates the accomplishment of whatever goal I devise for it, whether that means getting to the emergency room, my job, the SUNN O))) gig, the park or the airport. What I’ve here called “transmobility” is an opportunity to use our best available tools and insights to extend that privilege until it becomes nothing of the sort.
Finally: How do I expect my friends at Snapper to make any money, if everything I imagine above comes to pass? Even stipulating that cost to user is zero, there are multiple foreseeable transmobility models where a farecard is necessary to secure access and to string experiences together, before even considering the wide variety of non-fare-based business use cases. And anyway, my job is to help people anticipate and prepare for emerging opportunity spaces, not to artificially preserve the problem to which they are currently the best solution.
OK, I’ve gone all SUPERTRAIN on you for umpty-two-hundred words now; I need a break, and I’m sure you do too. I fully expect, though, that two or maybe even three of you will have plowed all the way to the bottom of this, and are even now preparing to launch the salvos of your corrective discipline, in an attempt to redress faulty assumptions, inflated claims & other such lacunae in my argumentation as you may stumble over. Trust me when I say that all such salvos will be welcome.
We’ve been talking a little bit about what we might gain if we begin to conceive of cities, for some limited purposes anyway, as software under active development. So far, we’ve largely positioned such tools as a backstop against the inevitable defaults, breakdowns and ruptures that municipal services are heir to: a way to ensure that when failures arise, they’ll get identified as quickly as possible, assessed as to severity, brought to the attention of the relevant agencies, and flagged for follow-up.
And as useful, and even inspiring, as this might be, to my mind it doesn’t go nearly far enough. It’s essentially the lamination together of some entirely conventional systems, provisions and practices — something that already exists in its component pieces, something, as Bruce points out here, that’s “not even impossible.”
But what if we did take 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.
Provided that, we can 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.”
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 making them “addressable, queryable, and even potentially scriptable.” 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.
It’s true that this is overkill if all you need is a unique identifier. If all you’re looking to do is specify the east-facing traffic signal at the northeast corner of 34th Street and Lexington Avenue, you can do that right now, with barcodes or RFID tags or what-have-you. You only need to resort to IPv6 addressability if your intention is to turn such objects into active network nodes. But as I’ve argued in other contexts, the cost of doing this is so low that any potential future ROI whatsoever justifies the effort.
- 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 riced-out 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.
We should all be very clear, right up front, that this is a nontrivial risk. I’ll make it explicit: any such scheme as the one sketched out here presents the specter of warfare by cybersabotage, stealthy infrastructure attrition or subversion, and the depredations of random Saturday-night griefers. It’s also true that connected systems are vulnerable to cascading failures in ways non-coupled systems cannot ever be. Yes, yes and yes. It’s my argument that over anything but the very shortest term, the advantages to be derived from so doing will outweigh the drawbacks and occasional catastrophes — even fatal ones. 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 ROI, environmental benefit and TCO? Sure. But I think we should be buckling ourselves in, because first and foremost, read/write urbanism is going to be a blast.
I know I posted a brief piece about it when we first launched, but I’ve been meaning to get back to a fuller account of my work with Nurri on Do projects — what it is, what we want to achieve with it, where we want to take it, and what’s in it for you.
We first conceived of Do as a publishing platform, an attempt to reckon with what passionate-amateur production of visual and textual materials looks like in an age when such amateurs have access to professional-grade tools and distribution networks. Our desire to get our hands dirty grows out two parallel sets of frustrations: Nurri’s with the art world, and my own with publishing.
Hers is rooted in a fundamental problem with the notion of art object (and aesthetic experience) as commodity, and her longstanding desire to do something about the practical and social barriers that keep art an elite activity. There’s more to it than that, but I don’t want to put words in her mouth.
Mine has to do with my utter (and perhaps somewhat naïve) shock at how little my former publishers New Riders cared about my book as an object, from typography and graphic design to paper stock, and how little effort they were prepared to dedicate to marketing the book once published.
I’ve told this story before, of course. But even that piece doesn’t express fully how galling it was for me to give up control of the thing I’d created to an organization less competent, in the final analysis, than I was my untrained self. That Nurri and I, in our own clumsy and untutored way, could come up with something more appealing than the design I was essentially paying my publisher to execute on my behalf was a real wake-up call.
And that got us thinking about the space between. We’d seen what commercial publication all too often resulted in. At the other end of the spectrum, we knew people like Meejin Yoon and Craig Mod: genuinely talented, possessed of the right kind of eye, confident with materials and capable of producing gorgeous printed objects. We were acutely aware that we lacked these qualities, but we also had a certain faith that even our own limited talents could result in worthwhile results — and never once doubted that the content we were thinking of deserved aesthetically pleasant physical instantiation. Was there room for maneuver in between these two poles?
Do is how we intend to find out. As we explained it when we launched in December, some of our ambitions are to:
- develop words and images that make the people who encounter them re-see themselves and the world around them;
- find the most appropriate containers for our ideas;
- craft the kind of books that please their readers in the details of their conception, design and construction as much as in the things they say;
- and figure out what “do-it-yourself” might mean in an age when new production technologies, informational and logistical networks give the independent amateur producer unprecedented power to reach out and make things happen.
With Tokyo Blues, our very first release, we feel like we’ve already travelled some way toward answering those questions; true to our beliefs (and as will be the case with every Do project), in addition to offering the physical book for sale, we’ve made a full PDF version available for free download. As I’ve said before, you buy the book if you want the object; the ideas are free.
And that book itself? It’s as good as we currently know how to make it, the best quality we could practically achieve while still offering it at a reasonable, accessible price. The unexpected gift is that we’ve been able to use the momentum built up in seeing Tokyo Blues through from concept to shipped product to drive other efforts. As I’ve frequently had cause to say these last few months, there’s a reason they call it “fulfillment.”
We’re also beginning to feel our way toward using Do as a platform for other things, a vehicle for collective efforts beyond publishing. Some of these things will be events, like the Systems/Layers “walkshops” we kicked off in Wellington, and had such a blast doing; others may involve the creation of objects or spaces.
Whatever we wind up creating, though, will be inherently networked, in a deep sense of that word. Organizationally and practically, we’ve tried to imagine Do as a weave tight enough to enable effective execution, yet open enough to capture unexpected influences and energies beyond those we generate ourselves. There’s a block of copy we’ve been using in the datasheet we include with every release that speaks to this: “For the realization of this project, Do consisted of…”. Another way of saying this is that beyond the core of Nurri and I, the organization itself grows and shrinks with every new project, trying to find the size and shape most appropriate to the challenge presented by each particular undertaking.
And that means that as we imagine it, anyone reading this is a potential Do member/co-conspirator. We have a roster of things already planned for the balance of 2010 — a project called Emergency Maps, my own long-delayed book — but beyond that we want to hear from our friends as to what kinds of things they’d like to see us doing, including your own project proposals. At the heart of our conception of Do is the idea that the “company” exists to facilitate extension, inspiration and execution, and gets more capable as it makes new connections. Think of it as something to plug into, and let’s see what we can do together.
In the past, I’ve often enough described cities as being “all about difficulty“:
They’re about waiting: for the bus, for the light to change, for your order of Chinese take-out to be ready. They’re about frustration: about parking tickets, dogshit, potholes and noisy neighbors. They’re about the unavoidable physical and psychic proximity of other human beings competing for the same limited pool of resources….about the fear of crime, and its actuality.
If this is so, and I continue to believe that it is, are we compelled to accept it? Or is there anything that can be done about it? And especially, might the constellation of tools we’re just starting to wrap our collective heads around offer us any recourse in our struggle against this tangled welter of hassles and frustrations we call life in the big city?
Well. Some measure of friction is unavoidable in urban life — both endemic to any physical system anywhere near as complex as this and, truth be told, not such a bad thing. But there’s no reason why we can’t use our new capabilities to get on top of the roil, see what’s going on, and maybe even keep the less felicitous contingencies from solidifying.
Two services that I’m familiar with address this set of concerns, each representing a slightly different way of framing the problem: New York City’s 311 gateway to non-emergency services and, in the UK, mySociety‘s awesome FixMyStreet. There are others — many, many others — as well as roughly congruent resources facing other domains, but as far as municipal services are concerned these two are the best-known, arguably the most successful, and the most faithfully representative of their respective approaches.
As an official utility of the City of New York, 311′s stated mission is to:
- Provide the public with quick, easy access to all New York City government services and information while maintaining the highest possible level of customer service;
- Help agencies improve service delivery by allowing them to focus on their core missions and manage their workload efficiently;
- Provide insight into ways to improve City government through accurate, consistent measurement and analysis of service delivery Citywide.
…while FixMyStreet’s proposition is a little simpler: it allows its users to “report, view or discuss local problems.”
Despite the clear differences in aim and ambit, I think of both as frameworks for citizen responsiveness. Their essence is that some issue arises — a pothole, a fallen branch, an open fire hydrant or a wandering elder — 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. (We’ll get to the weakness of this last link in the chain in a bit.)
While it does provide an online point of entry, 311 is in my experience predominantly something you engage over the phone. It’s an easy number to remember, the city’s representatives have repeated the mantra “911 for emergencies, 311 for everything else” until it ought to be second nature and, nicety of niceties in this IVR age, your calls are answered by a human being. Every time I’ve ever had cause to engage it, my calls have been answered in seconds, not minutes.
In fact, this is the nicest aspect of 311. There’s a certain deep satisfaction in venting your frustrations to someone listening with (at the very least a convincing simulacrum of) empathy, and I’d imagine this has practical consequences, too — that a decent swath of incoming complaints are prevented from escalating via the simple expedient of hearing the caller out.
When navigating a beast like municipal government, though, even the best and most sensitive operator is unlikely to have all the answers at his or her fingertips. So 311 operators are coupled to a reasonably good search database, and from what I’ve seen they’re usually able to point you at the proper resource or department in short order, whether your problem is a registering a noise complaint, a shattered bus shelter, or tracking down the taxi driver who drove off with your briefcase.
But that’s where 311′s utility largely ends. Once this connection is made, the caller is deposited right back into the universal thicket of big-city bureaucracy. Worse, the categories into which the catching department will sort your issue are likely to be brittle, and there tends to be little provision for following up on the status of an issue — or for that matter, identifying the single team or individual responsible for resolving the complaint.
Similar things are true of FixMyStreet, which collects issues on its users’ behalf and then forwards them to the relevant department of government. Despite offering users a range of tools that 311 lacks, and which ought by now to be table stakes in the domain, like the ability to pinpoint issues on a map, or document them with pictures, you get nothing in the way of confirmation or response other than a terse notification that the complaint was “Sent to Kensington & Chelsea Borough Council 1 minute” after its entry.
So how would you close the loop? How would you arrange things so that the originator, other members of the public, the city bureaucracy itself and other interested parties are all notified that the 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?
In a talk I heard him give a few months back, technology entrepreneur Jyri Engeström suggested stealing a page from the practice of software development as a way of addressing shared problem spaces more generally. He pointed out that, during his time at Google, employees turned the tools developed to track open issues in software under development toward other domains of common experience, like the shuttle buses the company provides to haul them back and forth between San Francisco and Mountain View.
When hassles arose with the bus service, employees treated them just like they would known issues in some application they were working on: they entered their complaints into an existing bug tracker, which provided each case with a unique identifier, a space to characterize it more fully…and perhaps most importantly, the name of a party responsible for closing out the ticket.
The general insight Jyri derived from his experience got me to thinking. An issue-tracking board for cities? Something visual and Web-friendly, that’s simultaneously citizen-facing and bureaucracy-facing? Heck, that begins to sound like a pretty neat way to address the problems with systems like 311 and FixMyStreet.
You 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. You display currently open cases, and gather resolved tickets in a permanent archive or resource. You 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, routinely, perennially, perhaps you 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.
You assign tickets to specified agents.
Then, of course, you 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?
So. To reiterate. 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; and
- A layer of data analytics and visualization.
As is well-known, I tend to be skeptical when the replacement of human systems, however clumsy, with novel and untested technical frameworks is contemplated. I’m also acutely aware that the purpose of a system is what it does, and there may well be occult reasons why urban systems that appear intractably broken are allowed to remain that way, i.e. they’re actually functioning just fine in support of some agenda.
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.
I’ve always taught my students that if you scratch a New Yorker, you’ll find a committed urbanist — someone with intense and deeply-held opinions about the kind of trees that ought to be planted along the sidewalks, or the right way to organize bike parking, or ways to reconcile the conflicting needs of dogwalkers and parents with children in city parks. And the same thing, of course, is true of Mancunians, Singaporeans and Cariocas.
The point isn’t that all of their notions are going to be fair, practical, practicable or even remotely sensible, but that an immense body of pragmatic insight and — more importantly, in my view — passion for the city is going untapped. Pundits, bobbins and bureaucrats talk constantly about improving the efficiency of municipal services, but if improved information is a driver of that efficiency, why aren’t we even trying to gather all the incredibly rich data that’s just lying there, more or less literally begging us to use it? We have the tools, we have the models, we know what they’re good for and where they fall down. It’s past time to build on this experience and bring its lessons to bear on the places we live.
