Every user a developer, part II, or: Momcomp

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.

From so many sides of life’s disciplines and studies, I’m seeing some really smart people ask for what you put here as the type of innovation that needs to be happening around us. I think personally, that my own dissension with media and what passes as new/innovative is the opposite of what you seek to address here.

Reading your PDF, and smiling as there are just too few companies and developers who see things as point-and-do, I too wonder when we’ll get to a point of “programming” being less a matter of code and tools, and more a matter of “give me the data and I’ll make out of it what suits my needs best.”

I’m not sure if you’ve ever looked much at the Python programming language, but one of its top-line features is “batteries included”, shorthand for the idea that the standard library should address pretty much any data format or common external technology you’re likely to encounter. If you want to work with XML or encrypt stuff, Python’s developers have got you covered.

What’s stands out in your MomComp proposal is that the utilities you describe aren’t really code problems at all, but data problems. They require a third party to be present: road networks, traffic conditions, train schedules, and parking availability are needed in just the minimal example you’ve put together. It’s an interesting political twist, taking the tired, old question of whether code is open to all or just an elite priesthood to enlightened developers, and flipping it around to make data availability the core question. How could those lego blocks possibly work, if NJ Transit wasn’t interested in making the schedules available?.

To me, code is no longer the relevant frontier of openness and availability: open source basically won this fight about ten years ago, and I can think of no professional interest group more motivated to make their skills and tools widely available and useful than programmers. The current frontier is data, most precisely the universe of privacy and safety concerns around information from governments and public authorities. It’s been a few years since Sean Gorman had his thesis classified and transit providers at the very least are warming to the idea that making schedules available in a useful format isn’t a terrorist threat, but the idea that data is the public good is only slowly gaining acceptance over today’s dominant application-centric mentality.

The critical path for MomComp is not a lack of programming tools, it’s availability of relevant data and some higher-level sense of how they fit together.

I like that Adam doesn’t use the wire metaphor. In the electronic sound manipulation world, connecting up different gadgets with virtual cables was fun at first, but it gets tedious. Ableton Live’s effects chains can be a lot more coherent.

Well, Apple’s Automator isn’t so different from what Adam’s proposed here, down to the rebus-style filling in of the details in some cases. If Automator exposed a couple more things (get the user’s current location, for example), you could string a few of these steps together there. (Automator’s continued to get better every OS update, btw, some really cool things in there now, like being able to make Printer plugins).

Adam, I was excited to see your mockup, though I was disappointed that we didn’t get to see a concrete picture of your rebus text editor.

As someone who once built a boxes-and-lines visual programming environment, in the end I’m not sure how easily the average “mom” could be led to think with the rigorous logic of a programmer, no matter how much the task is dressed up using English-like statements, appealing bricks, or lovingly simulated patch cable physics. Specifically, the layperson needs to climb up a steep learning curve to even have a clear understanding of what they could reasonably ask of such a system.

Is that why systems like Automator, Pipes, Popfly, and the mothballed Google Mashup Editor never seem to have caught on? Maybe they were still too abstract for a layperson, and yet didn’t provide enough flexibility for developers.

Perhaps LittleBigPlanet was more successful at getting people to play around with simple logic in a less threatening environment, and yet the existence of a few savants building dizzyingly complex mechanical calculators still doesn’t make it a success at democratizing programming.

If it were that easy, would we still have a whole industry of people who charge thousands to make your home entertainment center do what you want it to in a few button presses?

This all sounds more negative than I’d like, because I genuinely would like to believe, like you, in a future with less of a need for the technical priesthood. And yet in the decades that we’ve been talking about visual programming, I’ve been disappointed in the lack of substantial progress towards something that laypeople would enjoy using regularly.

To address the “backend” part of your mockup, I agree with Michal that this is largely a data availability problem, which is to say, a cultural/organizational problem. Given what we’ve accomplished in public transport over the past few years, I’m more optimistic about this part.

Coincidentally I’ve been mocking up a few personalizedwidgets like your momcomp use case recently, and I’ve run into the galling lack of APIs that could give you predigested functionality for actions like “compute the estimated drive time with traffic delay between A and B”, “generate the list of next times at which I can take this specific combination of transit routes between A and B”, and “buy me a ticket for X”.

This makes me wonder: what do we need to build to induce these pieces of the puzzle into existence?

I love the discussion and I know you acknowledge there are still big holes to be filled, but… isn’t the red part in your pdf the hard part? I hate to be the one to switch metaphors from lego to food but to put it another way the PDF is the equivalent of a list of ingredients and a picture of a finished dish. Where’s the recipe?

Maybe you’re saying we need to make the ingredients so simple (pizza base, jar of sauce, grated cheese, sliced pepperoni) that assembling the finished result is trivial?

As Joe points out (and he would know) right now the predigested* functionality is rarely if ever available. Massaging the data for general purposes – to the point where anyone can recombine it into a useful tool – is the only thing harder than writing the specific code yourself in the red box.

It’d probably be worth looking at what the specific (not generalized) code looks like for this kind of problem. Paul Hammond’s minimuni offers one view into this http://minimuni.paulhammond.org/about/ – since he made it, the data became available so the bulk of the scraping code is redundant. We are moving in the right direction!

Honestly, Tom, I think they’re all hard parts. But I don’t think what happens inside the black (or in this case, red) box need be as mysterioso as all that if the objects themselves are characterized usefully.

To me, that is the real paving-the-world-in-soft-soft-leather aspect of this scenario. If anything’s implausible, it’s getting to scale with agreed-upon interoperability standards for object description (and object-descriptor editors, etc.). I’ve watched with interest how initiatives like Microformats have struggled uphill, for even relatively circumscribed and simple cases like calendar events, so don’t think I haven’t reckoned with the complexity of usefully describing fire hydrants and parking lots and apartment buildings.

But like you and Joe both point out, things are moving in the right direction, and doing so swiftly. In a mere eighteen months or so, I’ve seen the conversation evolve from simply calling for open data to helping institutions be savvier about what that implies, even toward a recognition that (in Usman Haque’s words) “it’s not about making the data public, it’s about the public making the data.”

So while I’d never make the mistake of thinking any of this will ever be easy, neither do I think it’s by any stretch of the imagination impossible. To me, ever since I started giving the domain any thought, in 2003 or so, it’s seemed inevitable that something like a Universal Object Descriptor format is going to have to come into existence, with however many classes are necessary to account for the range of object types we encounter in everyday life. And that any such format would have to be designed so its specified attributes have the appropriate semantic hooks, so other systems can grab onto the data encoded in each. (I guess you could think of this as providing for ad-hoc APIs, if that’s not crunked-out babble from a well-meaning amateur.)

I’d rather these descriptor specifications be written by a community that has user experience and something resembling the Momcomp use case very much in mind, so whatever “UOD” comes into existence is as covered with hooks as burdock. Then things in the world recombine, densify, “can’t help but make infrastructure.”

That’d be my hope, anyway, and perversely enough it’s something I think is worth working for. I get how much I have to learn here, how naive a lot of this sounds. But sometimes — sometimes — naivete means not having to take as givens the things which hold the good back.

Second, we might be able to side-step some of the technical complexities underpinning a system like this by involving people instead of relying entirely on machine learning. What if we built a game on top of it?