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.