Stealthy, slippery, crusty, prickly and jittery redux: On design interventions intended to make space inhospitable

From Mitchell Duneier’s Sidewalk, 1999. The context is a discussion of various physical interventions that have been made in the fabric of New York City’s Pennsylvania Station:

On a walk through the station with [director of "homeless outreach" Richard] Rubel and the photographer Ovie Carter one summer day in 1997…I found it essentially bare of unhoused people. I told Rubel of my interest in the station as a place that had once sustained the lives of unhoused people, and asked if he could point out changes that had been made so that it would be less inviting as a habitat where subsistence elements could be found in one place. He pointed out a variety of design elements of the station which had been transformed, helping to illustrate aspects of the physical structure that had formerly enabled it to serve as a habitat.

He took us to a closet near the Seventh Avenue entrance. “We routinely had panhandlers gathering here, and you could see this closet area where that heavy bracket is, that was a niche.”

“What do you mean by ‘a niche’?”

“This spot right over here was where a panhandler would stand. So my philosophy is, you don’t create nooks and corners. You draw people out into the open, so that your police officers and your cameras have a clean line of sight [emphasis added], so people can’t hide either to sleep or to panhandle.”

Next he brought us to a retail operation with a square corner. “Someone here can sleep and be protected by this line of sight. A space like this serves nobody’s purpose [emphasis added]. So if their gate closes, and somebody sleeps on the floor over here, they are lying undetected. So what you try to do is have people construct their building lines straight out, so you have a straight line of sight with no areas that people can hide behind.”

Next he brought us to what he called a “dead area.” “I find this staircase provides limited use to the station. Amtrak does not physically own this lobby area. We own the staircase and the ledge here. One of the problems that we have in the station is a multi-agency situation where people know what the fringe areas are, the gray areas, that are less than policed. So they serve as focal points for the homeless population. We used to see people sleeping on this brick ledge every night. I told them I wanted a barrier that would prevent people from sleeping on both sides of this ledge. This is an example fo turning something around to get the desired effect.”

“Another situation we had was around the fringes of the taxi roadway. We had these niches that were open. The Madison Square Garden customers that come down from the games would look down and see a community of people living there, as well as refuse that they leave behind.” He installed a fencing project to keep the homeless from going behind corners, drawing them out into the open [emphasis added]. “And again,” said Rubel, “the problem has gone away.”

This logic, of course, is immanent in the design of a great deal of contemporary public urban space, but you rarely find it expressed quite as explicitly as it is here. Compare, as well, Jacobs (1961) on the importance to vibrant street life (and particularly of children’s opportunities for play) of an irregular building line at the sidewalk edge.

Further to notes on a diagram of Occupy Sandy

Yes, enumerate the carriage parts — still not a carriage.
When you begin making decisions and cutting it up rules and names appear
And once names appear you should know when to stop.

- Tao te Ching, tr. M. LaFargue. (For the record, I prefer the Stephen Mitchell translation, but this seemed more pointedly relevant to the work at hand.)

On the iPhone 5 form factor

I think someone took the old cliché about the mobile phone being “a remote control for your life” a little too seriously.

On tools, their use, and how to avoid fetishizing them

The other day I got mail asking me to contribute to something called usesthis, a site that asks a (frankly fairly homogeneous) selection of creative workers to describe their “setup” — or, in other words, the combination of hardware and software they use on a daily basis — as well as their ideal such arrangement.

I’m always happy enough for a prompt to think in this direction. Although usesthis isn’t really (no pun intended) set up to examine these issues, the whole question of a relationship between creative output and one’s choice of tools is inherently interesting, and is kind of an ongoing preoccupation of mine. As a good connectionist, I’m bound to believe that the artifacts we use mediate or allow us to approach the world in certain specific ways. It follows from this that our selection of one particular tool over another conditions the kind of relations we’re able to enter into — but also, that if the tool is functioning properly, we’re ordinarily unaware of its operations, or of this potential it has to constrain or to open.

If we’re inclined to examine that potential, a rigorous accounting for the intermediators we choose can help us rise up out of the usual, unconscious relation we have to them, and restore the sense of interested inquiry Heidegger (at least) calls presence-at-hand — see Peter Erdélyi’s foreword to The Prince and The Wolf for a particularly pungent version of this.

There’s a lot to say, too, about the determinisms implicit in our selection of specific tools. Very often, particular methods and tools tell in the finished work; it’s not simply, then, that mediating artifacts shape our own ability to act in the world, it’s that they indirectly condition the experience of everyone who comes into contact with the result of that action thereafter. (I’m put in mind of Matthew Fuller and Usman Haque’s prescient comment, in their Situated Technologies pamphlet Urban Versioning System 1.0, that “[i]t is often possible to determine, admittedly more so in a building than in a neighborhood, whether it was designed using AutoCAD, Microstation or Vectorworks.”)

I think it’s relatively easy to see what this means for creative domains like fashion, music, or (as the Fuller/Haque quote implies) architecture. Take the work of Issey Miyake, for example. We can trace the very different ways in which A-POC and the superficially similar Pleats Please line are perceived (by the wearer, by the observer) to specific techniques used in their creation, observe that the material qualities of Pleats Please garments result from polyester fabric being subjected to a particular heat-press process. The way the garment drapes on the body is the direct result of the cloth’s having been shaped by a particular regime of temperature, constraint and pressure — a regime which is in turn brought into local being by a highly particularized set of tools. If you’re interested in understanding why the Pleats Please line tends to appeal to women d’un certain âge, some consideration of how the designer’s understanding of the body is mediated to the body via the deployment of those tools seems indispensable.

Similarly, albeit in a rather different register, it strikes me as being very difficult to discuss Stephen O’Malley‘s work without understanding at least a little something about drop-tuning, .68-gauge strings and the performance envelope of the Sunn Model T amplifier. The unique somatic (SOMAtic?) experience of a SUNN 0))) gig is contingent on these elements — these things — being present, assembled and wielded in a particular way. The affordances and constraints of the objects yoked together in the act of production are directly relevant to the phenomenology of the finished product, even if that “product” is a ten-minute excursion in dronespace.

Casting light on the mesh of associations that bring a Pleats Please garment or a SUNN O))) cut into being does tend to construct creativity a little bit differently than we have traditionally been used to, and I think that’s entirely legitimate. Instead of positioning creation as the act of a lone genius, this way of looking at things suggests that the ability to bring novelty forth is, instead, something that’s smeared out across a network of heterogeneous participants, both human and non-human. This is certainly a decentering of the individual designer, but by no means do I necessarily think of it as an insult. It merely suggests that in those domains where creative production does require the enlistment of such ensembles, exceptional designerly talent ought properly be understood as the specific genius of knowing how to activate, and enable the operations of, such an ensemble — something more akin to orchestration than anything else. In this light, there’s still a great deal to be discovered by poking into the specifics of a given ensemble, and asking how each is brought to bear on the task of creation.

For those of us who work primarily in the medium of words, though, the case isn’t as clearcut.

It’s not as if at least some descriptions of the writer’s toolkit aren’t of interest. Here’s John Brunner, in the final words of his 1968 Stand on Zanzibar:

“This non-novel was brought to you by John Brunner using Spicer Plus Fabric Bond and Commercial Bank papers interleaved with Serillo carbons in a Smith Corona 250 electric typewriter fitted with a Kolok black-record ribbon.”

This was a good McLuhanite, speaking to the formal concerns of the Pop moment. That invocation of brands carries along with it a certain zazzy quality, a sense of liberation experienced in and through commodities I associate with Warren Chalk’s 1964 Living City Survival Kit. (In 1968, as four years earlier, you could still plausibly argue that this was fresh and revelatory.) In this case, as it happens, more specific yet is better. So not just any Smith Corona 250, but John Brunner’s Smith Corona 250. It adds something — something ineffable, and if you know anything about Brunner’s life, ineffably sad — to your appreciation of his oeuvre to read what’s on the Dymo-tape labels he affixed to this daily working tool.

But that has more to do with the object as environment, and only invokes the Smith Corona 250′s material properties and other affordances in the rather attenuated sense that its front affords a surface on which to stick a label. This, of course, is a quality it has in common with a great many other objects that might have occupied the same space on Brunner’s desk. And this begins to get to the crux of what I find a little curious about asking writers about their “setup.”

For me, anyway, focusing on getting things just-so is very little other than a way of delaying the moment I actually settle down to do what I need to. Most of us have some such ritual; Matt Jones memorably describes this process of lining up one’s pencils and notebooks (in preference to actually using the former to write in the latter) as “shaving the yak.” I’ll admit that I also find it a little unseemly, at this point in history, to mention specific named brands and commercial offerings. I’m not Warren Chalk, this isn’t London in 1964, and I’m not performing a swingin’ly post-austerity self through my consumption of Canadian Club and Miles Davis sides. So while, yeah, sure, I use such-and-such a text editor, under a given operating system, running on a particular model of laptop, you won’t learn that much about me — or more to the point, develop any particularly salient insight into the structuration of the argument I’m trying to make — by having these specifics revealed to you. The blunt truth of things is that I would almost certainly be expressing these same sentiments were I working in Microsoft Word on the kind of thoroughly generic, commodity Windows machine the “wrong people” use. From this perspective, the ideal setup of tools is nothing but the one that most readily dissolves into intention. ‘Nuff said, yeah?

You lookin’ at me?

I confess to being both heartened and frustrated by John Geraci’s new post on “the user experience of New York City,” which you should go take a look at. The “heartened” part is easy: I’m delighted that John raises the issue of the Passenger Information Monitor — the touchscreen interface mounted on the rear surface of a New York City taxicab’s protective partition — because it’s something that I’ve been thinking about for a very long time. The “frustrated” part has very little to do with John or his admirable optimism, and much more to do with the fact that, well, I have been thinking about this precise issue for a very long time, as have a great many designers more talented than I, and not all our efforts combined have been able to alter the badness of the taxi-passenger experience one whit in all that time.

As far as I’m concerned, the primary problem with the PIM is that it provides real-time GPS mapping and other situational information to passengers — but not the driver. This gives rise to an informational asymmetry that only exacerbates whatever issues of mutual mistrust and class, ethnic and linguistic-cultural tension may be latent (or explicit) in the encounter between the two parties.

Anyone who takes cabs in New York City with any frequency whatsoever will surely have noticed that a very large number of drivers are not merely recent immigrants but recent immigrants from Pakistan or Bangladesh. This, of course, is not a neutral pattern of fact, in either the American imaginary or the reckoning of the various Federal agencies charged with enforcing immigration law and upholding homeland security. Drivers from the Subcontinent, particularly, do absorb the suspicion and hostility of a post-9/11 public, and therefore may have some justification for a belief in otherwise hard-to-swallow conspiracy theories about the “real” reasons for the in-vehicle deployment of locational technologies. (How do I know they hold such beliefs? I know this ’cause I ask drivers for their opinions on the PIM whenever I get the chance, and the notion that DHS or some similar entity is tracking their personal movements through in-car GPS arises spontaneously about a third of the time.)

Even absent this specific consideration, the placement of the screen carries along with it a not-so-subtle implication that the driver is out to screw the passenger, and if left to their own devices will surely do so. The particular message of the PIM is that the driver needs to be supervised, their microbehavior monitored and their choices (e.g. of routing) verified from moment to moment. Compare this to the dashboard-mounted GPS navigation systems used by cab drivers in, say, Seoul, which are more clearly there to assist the driver in their negotiations with the cityscape — a primary use of such screens which does nothing to prevent their also being used to coordinate agreement between driver and passenger as to appropriate courses of action.

Finally, as John points out, and in what has to be reckoned an extraordinarily clumsy and hamfisted way of undermining any common feeling between the person in the front seat and those behind the partition, the PIM screens run ads. These are predictably loud and irritating, they load automatically and continue running unless manually shut off, and they generate revenue for the taxi operator every time they are viewed. (The passenger is provided with an Off button, but it is designed so as to be relatively obscure and hard to engage.) The cab driver is therefore incentivized to tolerate a system behavior that’s clearly detrimental to the experience of the paying customer.

These are design decisions. There is nothing inherently wrongheaded with choosing to site a passenger interface on the back of a taxi’s partition, nor is there necessarily anything wrong with providing the passenger with information that will reassure them as to the wisdom of the driver’s choices. But in each of the above cases, as a result of bad design, the interests of driver and passenger have been allowed to become uncoupled from one another, with terrible repercussions for their ability to trust and feel comfortable with the other — both locally to this specific ride, and across whatever rides take place in the future, for as long as this particular envelope of technological and design decisions remains intact.

I share John’s hope that this and the other moments that constitute stumbles in the user experience of the city can be rectified by design — I hope obviously so, given my investment of time, effort, reputation and life savings in a company intended to do just this. But I can’t help but note that we New Yorkers appear to live in a place, a time and a culture in which considerations of design are all but invariably shunted to the back of the line when budgetary and other resources are apportioned. In situations like this, I’m so often put in mind of Stafford Beer‘s observation that “the purpose of a system is what it does.” If, in all the years since Vignelli, New York City and its institutions have mostly failed to produce high-quality citizen-facing design, it’s difficult to conclude anything but that on some level, and from some party’s perspective, this is an intentional outcome.

A rough road ahead for the would-be designer of good urban user experience, then — but a clarion call to greatness, as well. Tomorrow’s Vignellis surely have their work cut out for them. But should you succeed in such tasks even partially, you’ll know that your intervention is improving the texture of someone’s life tens of thousands of times a day, every single day. By my lights, anyway, there are not a whole hell of a lot of things on Earth more worth the effort.

Fear factor

I really want to recommend to you this Olivier Thereaux post about broken bus systems and how they might be fixed (and not just because I happen to be taking the MUNI a great deal lately).

What Olivier absolutely nails is the expression of a thought I’ve come back to again and again over the years: that buses and bus networks are by their nature so intimidating to potential users that many people will do just about anything to avoid engaging them. I don’t mind admitting that, depending on the city, the language in use, and my relative level of energy, I’m definitely to be numbered among those people. When buses are effectively the only mode of public transit available, that “just about anything” has occasionally meant laying out ridiculous sums on taxis; more often, it’s resulted in my walking equally absurd distances across cities I barely know.

“Intimidating,” in this context, doesn’t need to mean “terrifying.” It simply implies that the system is just complicated enough, just hard enough to form a mental model of, that the fear of winding up miles away from your intended destination — and possibly with no clear return route, not enough or the right kind of money to pay for a ticket, and no way of asking for clarification — is a real thing. There’s a threshold of comfort involved, and for quite a few categories of users (the young, the old, visitors, immigrants, people with literacy or other impairments) that threshold is set too high. People in this position wind up seeking alternatives…and if practical alternatives do not exist, they do without mobility altogether. They are lost to the city, and the city is lost to them.

The point is more broadly applicable, as well. You know I believe that cities are connection machines, networks of potential subject to Metcalfe’s law. What this means in the abstract is that the total value of an urban network rises as the square of the number of nodes connected to it. What this means in human terms is that a situation in which people are too intimidated to ride the bus (or walk down the street, or leave the apartment) is a sorrow compounded. Again: everything they could offer the network that is the city is lost. And everything we take for granted about the possibilities and promise of great urban places is foreclosed to them.

If you understand things this way, there’s a clear moral imperative inscribed in the design of systems like bus networks and interfaces. Every incremental thing the designer can do to demystify, explain, clarify, and ultimately to lower the threshold at which a potential user decides the risk of climbing aboard is worth taking does a double service — if the Metcalfe’s law construction of things rings true to you, a geometrical service. You are simultaneously improving the conditions under which an individual lives his or her life, and contributing materially to the commonweal. Not bad for a day’s work, if you ask me.

This is personal for me, too, and not just because I’ve occasionally found a route map overwhelming, or decided to walk from Bloomsbury to Dalston instead of chancing the N38 and winding up in, who knows, Calais. What I’ve come to understand, in these last few years of intense concentration on issues of urban design, is that my fascination with cities grows not at all out of ease or comfort with them, but the opposite. I’m an introvert, I’ve never been comfortable approaching strangers with questions, I’m twitchily hyperaware when I’m inconveniencing others (e.g. holding up a bus by asking questions of a driver) and my gifts for language are not great. Above all, I don’t like looking vulnerable and confused any more than anyone does, especially when traveling.

I’ve gotten better on all these counts over the course of my life, but they’re still issues. They can pop to the surface at any time, and, of course, are more likely to do so under conditions of stress. Taken together, what they spell for me is a relatively circumscribed ability to get around and enjoy the things the cities I visit have to offer — relatively, that is, compared to other able-bodied people my own age and with similar levels of privilege. Even this limitation, though, makes me acutely aware of just how difficult getting around can be, how very intimidating it can all seem, and what both people and place stand to lose each and every single time this intimidation is allowed to govern outcomes.

This is why I believe Olivier is absolutely right to focus on design interventions that reduce user stress, and, with all due respect, it’s why I think people like this Speedbird commenter, who understand cities solely as generators of upside potential, are missing something in the empathy department. There are an awful lot of people, everywhere around us, in every city, who have difficulty negotiating the mobility (and other) systems that are supposed to serve their needs. As far as I’m concerned, anyway, it is the proper and maybe even the primary task of the urban systems designer to work with compassion and fearless empathy to address this difficulty. Only by doing so can we extend the very real promise of that upside potential to the greatest possible number of people who would otherwise be denied it, in part or in full, and only by doing so can we realize in turn the full flowering of what they have to offer us.

Reinventing Reinventing the Automobile

I’m halfway through Reinventing the Automobile at the moment, which I figure represents the final comprehensive statement of Bill Mitchell’s thinking about urban mobility. As you’d imagine, it’s a passionately-held and painstakingly worked-out vision, basically the summation of all the work anyone with an interest in the space has seen in dribs and drabs over the past few years; it’s clear, for example, that this is what all the work on P.U.M.A. and MIT CityCar was informed by and leading towards.

In outline, Reinventing presents the reader with four essential propositions about the nature of next-generation urban mobility, none of which I necessarily disagree with prima facie:

- That the design principles and assumptions underlying the contemporary automobile — descended as they are, in an almost straight line, from the horseless carriage — are badly obsolete. Specifically, industry conventions regarding a vehicle’s source of motive power, drive and control mechanism, and mode of operation ought to be discarded in their entirety and replaced with ones more appropriate to an age of dense cities, networks, lightweight materials, clean energy and great personal choice.

- That mobility itself is being transformed by information; that extraordinary efficiencies can be realized and tremendous amounts of latent value unlocked if passenger, vehicle and the ground against which both are moving are reconceived as sources and brokers of, and agents upon, real-time data. (Where have I heard that before?)

- That the physical and conceptual infrastructure underlying the generation, storage and distribution of energy is also, and simultaneously, being transformed by information, with implications (again) for the generation of motive power, as well as the provision of environmental, information, communication and entertainment services to vehicles.

- That the above three developments permit (compel?) the wholesale reconceptualization of vehicles as agents in dynamic pricing markets for energy, road-space and parking resources, as well as significantly more conventional vehicle-share schemes.

It’s only that last one that I have any particular quibbles with. Even before accounting for the creepy hints of emergent AI in commodity-trading software I keep bumping up against (and that’s only meant about 75% tongue-in-cheek), I’m not at all convinced that empowering mobile software avatars to bid on road resources in tightly-coupled, nanosecond loops will ever lead to anything but the worst and most literal sort of gridlock.

But that’s not the real problem I have with this body of work. What I really tripped over, as I read, was the titanic dissonance between the MIT vision of urban life and mobility and the one that I was immersed in as I rode the 33 bus across town. It’s a cheap shot, maybe, but I just couldn’t get past the gulf between the actual San Franciscans around me — the enormous, sweet-looking Polynesian kid lost in a half-hour-long spell of autistic head-banging that took him from Oak and Stanyan clear into the Mission; the grizzled but curiously sylphlike person of frankly indeterminate gender, stepping from the bus with a croaked “God bless you, driver” — and the book’s depiction of sleekly silhouetted personae-people reclining into the Pellicle couches of their front-loading CityCars.

Any next-generation personal mobility system that didn’t take the needs and capabilities of people like these — no: these people, as individuals with lives and stories — into account…well, I can’t imagine that any such thing would be worth the very significant effort of bringing it into being. And despite some well-intentioned gestures toward the real urban world in the lattermost part of the book, projected mobility-on-demand sitings for Taipei and so on, there’s very little here that treats present-day reality as anything but something that Shall Be Overcome. It’s almost as if the very, very bright people responsible for Reinventing the Automobile have had to fend off any taint of human frailty, constraint or limitation in order to haul their total vision up into the light. (You want to ask, particularly, if any of them had ever read Aramis.)

Weirdly enough, the whiff of Gesamtkunstwerk I caught off of Reinventing reminded me of nothing so much as a work you’d be hard-pressed to think of as anything but its polar opposite, J.H. Crawford’s Carfree Cities. That, too, is a work where an ungodly amount of effort has been lavished on detailed depictions of the clean-slate future…and that, too, strikes me as refusing to engage the world as it is.

Maybe I wind up so critical of these dueling visions of future cities and mobility in them precisely because they are total solutions, and I’m acutely aware of my own weakness for and tendency toward same. I don’t think I’d mind, at all, living in one of Crawford’s carfree places, nor can I imagine that the MIT cityscape would be anything but an improvement on the status quo (if the devil was hauled out of its details and treated to a righteous ass-whupping). But to paraphrase one of my favorite philosophers, you go to the future with the cities, vehicles and people you have, not the ones you want. I have to imagine — have to — that the truly progressive and meaningful mobility intervention has a lot more to do with building on what people are already doing, and that’s even stipulating the four points above.

Bolt-on kits. Adaptive reuse. Provisional and experimental rezoning. Frameworks, visualizations and models that incorporate existing systems and assets, slowly revealing them (to users, planners, onlookers) to be nothing other than the weavings of a field, elements of a transmobility condition. And maybe someone whose job it is to account for everyone sidelined by the sleek little pods, left out of the renderings when the New Mobility was pitched to its sponsors.

Bottom line: this book is totally worth buying, reading and engaging if you have even the slightest interest in this topic. Its spinal arguments are very well framed, very clearly articulated, constructed in a way that makes them very difficult to mount cogent objections to…and almost certainly irrelevant to the way personal urban mobility is going to evolve, at least at the level of whole systems. And that’s the trouble, really, because so much of the value in the system described in these pages only works as a holism.

Like my every other negotiation with Bill Mitchell’s thought, including both engagements with his work and encounters in person, I want to be convinced. I want to believe. I want to be seduced by the optimism and the confidence that these are the right answers. But ultimately, as on those other occasions, I’m left with the sense that there are some important questions that have gone unasked, and which could not in any event have been satisfactorily answered in the framework offered. It may or may not say more about me than it does about anything else, but I just can’t see how the folks on the 33 Stanyan fit into the MIT futurama.

The overarching vision

One of the responses I often get after a talk is that, while I may have offered a critical take on existing and emergent trends in ubiquitous interactivity, I’ve failed to frame an affirmative vision of what I believe such interactivity ought to look like.

To be honest, I’m not sure this is entirely a fair cop. Sometimes the duty of an observer is simply to point out that a given situation is unfortunate, unaesthetic or undesirable, that one or another emperor is prancing around the block all buck-nekkid. This is an especially important thing to do when consensus might otherwise seal around the essential OKness of something that is really, truly Not OK.

But there’s another sense in which the complaint is not without a certain justice. There’s nothing less fair to the working designer than some dilettante, someone without any skin in the game, second-guessing their decisions — especially when the sideline sniper hasn’t had to squander their hope and energy along the nigh-endless gantlet of compromises, arguments, negotiations and endless meetings that constitutes the contemporary corporate development experience. Somewhere inside, I do feel that if I’m going to make a decent chunk of my living taking the efforts of others to pieces, it’s only right and proper that I throw something of my own on the table, to expose my own notions to the rigorous vetting I demand of any other. Some part of me feels like I should be sketching some kind of overarching, affirmative vision.

It was only liminally intentional, at best, but it’s now clear to me that over the last few months, I’ve been setting forth the building blocks of just such a thing here on Speedbird. For a variety of reasons, I’m not so hot on grand Statements of Intent at this point in my life, so it’s nowhere near as coherent as a purpose-built manifesto like this…but if you string the following (mostly rather wordy) posts together, the outlines of my stance ought to become pretty clear.

In 2010, anyway, this is my own personal vision of informatic technology at the service of the full range of human desire and complexity. Not a word of it is intended as a “solution” to what are inevitably and correctly local social or political challenges…but it is intended to give people everywhere better tools with which to join such struggles. I hope you find it useful, and invite you to subject its claims and assumptions to the same skepticism I’ve applied to other visions of ubiquitous technology.

Context

Understanding, first, the complexity of the environment in which any intervention will take place, and what kind of disciplinary tools might be useful in framing sensitive interventions.

- Toward urban system design

Frameworks for citizen responsiveness

Using ubiquitous informatics to reinforce a sense of public life and one’s own agency. Inviting new urban actors to the stage.

- Part I
- Part II: Toward a read/write urbanism

Transmobility

Using the envisioned frameworks instrumentally, to help people manage what is all-but-invariably among the most vexing challenges faced by citydwellers: getting around.

- Part I
- Part II
- Free mobility, social mobility…transmobility: Part III

Every user a developer

Arguing that the true gains will be made not by offering people powerful tools, but the ability to make their own tools of equal power.

- Part I: A brief history, with hopeful branches
- Part II: Momcomp

Respectful interfaces

Arguing that, while entirely new technical possibilities ultimately demand interface metaphors that convey the full measure of their power, they should also be designed in recognition of the environment in which they’ll be deployed.

- What Apple needs to do now
- jnd: An emergent vocabulary of form for urban screens

Every user a developer, part II, or: Momcomp

I wanted to take up a challenge Mike Migurski inadvertently laid down in comments the other day, in his response to my piece on the ongoing democratization of development for interactive systems.

I get where he’s coming from, especially his point about the moving-goalpost definition of “ease of use.” But I’m not convinced that there isn’t a whole lot further we could take tools like App Inventor toward making them painless for ordinary people to use, and I think — if you’ll forgive me, Mike — he’s mistaking my point about alternatives to the app paradigm. (It’s a little inside-baseball, but in brief: I acknowledge that the contemporary thrust of development is about things that happen in the browser, and that many “apps” are essentially specialized browsers. I just happen to believe that, despite the relative accessibility of tools like Apple’s iOS SDK, this whole model is still unnecessarily intimidating, and based on paradigms most users simply won’t get.)

So I thought I’d try a little thought experiment, to see if I couldn’t do a better job of getting my point across. I thought I’d start with a real, non-technically-inclined person, my mom, and a real challenge she used to confront on a several-times-a-month basis. And then I tried to imagine a toolkit which would allow her — as she is, and with little or no additional training — to build a custom module of functionality that would help her address this challenge, that she could use on an ad-hoc or near-realtime basis, and that would effectively lower the net frustration she experienced.

I have to say, right up front, that what I came up with is heavily, heavily dependent on circumstances which might never come to be. It posits a world in which there are widely-shared specifications for the description of networked objects we might encounter, whether those objects are people, places, things, or other kinds of system resources. And, of course, the open, shared, widely-adopted interoperability frameworks and standards that would allow us to bind these resources together and animate their interaction in useful ways. This, to put it mildly, is not the world we live in today. But it’s a world I’d like to see come to life, and if the best way to predict the future is to invent it, well: here’s my shot.

This is the use case. My mom lives in the Princeton, NJ area, a reasonably typical sweep of American suburbia that’s almost entirely predicated on automobility. Somewhere between two and five times a month, though, on a not-always-predictable basis, she has to drive to the nearest New Jersey Transit station, Princeton Junction, and there catch the train into New York City. Between the routine congestion of the area, the vagaries of the NJT timetable, and the hassle of finding parking at the station, she’s generally hugely stressed out by having to predict from among the available options the routing that will get her to the station in time, let her find a place to park, buy a ticket, and catch a given train. Our meetings in New York are generally subject to a back-and-forth flurry of last-minute phone calls: which train is she aiming for? What’s the traffic situation on Route 206? How about Route 1? Which train did she actually make? It’s not much fun, on either end, and yet something like this is how a great many people go about suturing their lives together, even in an age when information about most of the particulars here (time, location, traffic, timetable) exists, and is readily accessible from the device she has in her pocket.

Now my mom is not, in the slightest, a stupid woman. She just doesn’t like “technology.” And although she’s comfortable with (even delighted by) the iPhone UI, like a great many people she’s not the kind of person who’s going to switch back and forth between a Google Maps app and a New Jersey Transit app and whatever else she needs to come up with a relevant answer. So not only do I want to give her a single tool that offers her just the information she needs, and nothing else, but I want to give her the power to build that tool herself, so it speaks to her in something approaching her own voice.

What you see in this PDF, therefore, is a schematic representation of a constellation of plug-and-play objects she’d be choosing from and fusing together to make her ad-hoc service. Each of these objects is represented by a graphic icon and each is characterized under the surface by an arbitrary number of attributes and (inherent, dynamic and relational) attribute values. By selecting high-level, self-describing objects relevant to what she wants to do, and then using an enhanced text editor to compose what is effectively a rebus providing operators for these arguments, someone like my mom — with no technical background, or interest in or inclination toward acquiring one — can make herself a highly useful module of functionality, suited to her immediate and particular needs. She could even bundle it into a wrapper and upload it back to the network, either for someone else in nearly-identical circumstances to use as-is, or for others to deconstruct and rebuild according to their own requirements, given objects more relevant to their own local conditions.

Is it “an app”? No, not really. It’s something more, and less. It’s “just” a natural-language, textual interface layer to some reasonably complicated multivariate calculations running in the background. And in this telling of things, anyway, she built this layer herself, from available modular components fused together in an exceedingly lightweight, “intuitive” development environment. (You, Mike and the baby Jesus will have to forgive me: I’ve represented these components as something resembling Legos.)

Now I’m always a little concerned, when pushing something like this out, that I’m making myself look like that grizzled guy we’ve all encountered, wedged into a booth at All-Nite Donuts, guzzling serial cups of black coffee and scrawling his incoherent Grand Unified Theory of Everything across a stack of sweat-wrinkled legal pads. Nobody is more aware than me that there are holes in this schema you could drive a Northeast Corridor commuter train through. But I think it does a better job than I’ve yet been able to manage on two counts:

- It makes a better case than I was able to previously, regarding how easy the composition of complex functionality can and ought to be;

- And it lays out in black and white just what geomorphic feats of heavy lifting need to be taken care of in the background before any such vision could come to pass.

The things which I’ve painted as trivial here are admittedly anything but. But they are, I sincerely believe, how we’re going to handle — have to handle — the human interface to this so-called Internet of Things we keep talking about. Each of the networked resources in the world, whether location or service or object or human being, is going to have to be characterized in a consistent, natural, interoperable way, and we’re going to have to offer folks equally high-level environments for process composition using these resources. We’re going to have to devise architectures and frameworks that let ordinary people everywhere interact with all the networked power that is everywhere around them, and do so in a way that doesn’t add to their existing burden of hassle and care.

Momcomp, in other words. It’s an idea whose time I believe has come.

***
I hope you enjoy the PDF I ginned up to illustrate my above contentions. You’re free to take and use and rework it in any way you want and for what purpose you will, just so long as the use is noncommercial and you identify me as the source author. You can find the full terms of the Creative Commons license under which it’s provided to you here.

I’m shutting down threaded comments, by the way; regrettably, this otherwise-lovely theme doesn’t handle them particularly well. This has the particularly irritating consequence of rendering existing threaded discussions all but incoherent, for which I apologize. I’ve written to the theme author to see if there may be a solution. In the meantime, please try to make do. Thanks.

Every user a developer: A brief history, with hopeful branches

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.