ture allows for better connectivity (functional proximity) between Los Angeles and New York than, say, Los Angeles and San Bernardino. So as the proximity to rivers, oceans, and shipping ports sparked commerce in the past, today proximity to cheap, plentiful, open bandwidth becomes the geographically specific interface upon which organizations rely to centralize their operations. This produces vastly complicated intersections of politics, economics, and social culture, both intensifying links between some territories and further disconnecting other regions. In this, the spatial career of software is entirely dependent upon large-scale architecture as its medium and force, and vice versa. It doesn’t displace the meta-interface of the city—it feeds it.
Information technologies and social systems of spatial formation, interaction, signification, emergence, and complexity always commingle and codeter-mine each other. Today software is an increasingly promiscuous substance. It intermingles with every object. It either animates that object (like a gasoline pump, a street light or an alarm clock) or it guides that object to us through various supply-chain interfaces (to a store shelf), or perhaps the object becomes known to us first as a digital representation of itself (via eBay) only later materialized to direct experience (via FedEx). Software is already everywhere, and computation is already pervasive, though not as pervasive as it will be. The real frontier of that ubiq-uity is, I surmise, not in talking appliances and smart gadgets, but in the deep, invisible logisti-
cal systems that circulate the massive distribution of objects and quasi-objects to their proper locations. To me, the magic of UbiComp is already apparent in the intensity of strategic intelligence brought to bear by suppliers upon the competitive array of shelf display space at Wal-Mart. The mind boggles.
Computation in the Wild Further, for most of the world’s citizens, their first owned, personal computer will not be a (hundred-dollar) laptop but a (ten-dollar) handheld device/ phone/PDA of some kind. This is a critical difference in the experience of world-software interactions. For the West, the scalar phenomenology of computing runs from large to small, from architecture to accessory, from building-scale mainframes to desk-scale PCs to lap-scale laptops to hand-scale PDAs. Similarly, our understood history of telephony is one that moves from fixed-line phones (where telephony was a fixed function of the architecture) to one untethered within the domain of domestic space, to finally one that we put in our pockets. Phones were “ de-architectural-ized”; they become an extension of our bodies, not our homes and offices. As the modern city was built around providing real and virtual proximity, shared space and centralized bandwidth, a new city is emerging that two billion people already carry in their hands. For most humans (the “we” that live in “ developing countries”), the personal experience of computational information media will start off as hypermobile, conversation-capable devices. For most, com-
putation will begin as a sort of remote control for the world, albeit one centered around synchronous P2P voice protocols (aka phone calls). Because of this, the really important applications in pervasive computing (those built on emergent social behavior around information, and those that enable the acceleration of informal economies to connect across urban, political divides) will more likely emerge from internet cafes and third bedrooms in Delhi, Dakar, or Dar Es Salaam than in VC-funded cube farms in Sunnyvale, Cambridge, or Chelsea. At least one can hope so, and for them to separate interface design into hard and soft touchpoints will be less meaningful.
Program, regardless of medium, is always a translation of possibilities in relation to a set of contexts, themselves never directly given, rather filtered, interpreted, interpolated by a design scheme in particular ways. What appears obvious or even universal in a point in time to one design logic in its translation of context to solve a particular “program” (library, school, house, etc.) is completely unintelligible and bizarre to another logic at another time or place. This is no different for the design of software or any other interface.
What would integrated look like? What is common language for this, a common language for the specification of soft and hard programs? Both disciplines are tasked with designing how complex organizations come in contact with their own people and processes, with external
May + June 2008
References:
Archives