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.

12 responses to “Every user a developer: A brief history, with hopeful branches”

  1. Daniel Reetz says :

    Google-grade

    Google-garde

    (for better or for worse).

  2. Michal Migurski says :

    The Lego Analogy makes baby jesus cry.

    I think Apple’s always been pretty clear about the consumer option for application development, and it’s none other than the world wide web. Developers near-universally derided the idea that Webkit is a sufficient application development platform, but I’ve always been a strong believer that the web is the proper modern heir to Hypercard, in contrast to ghettoes like Visual Basic or Google’s new thing. The kit of parts you describe is pretty clearly the earth-spanning featureset of your basic web browser, and despite Apple’s other failings it was at least clear from the beginning that they introduced the novel idea of a browser that fits in your pocket and isn’t total shit.

    The only question is whether the Javascript execution environment allows for access to device API’s like location or address books – Palm’s WebOS is probably the most convincing jump in that direction.

    I guess my response boils down to: what you describe is happening, and has been for a few years, now. The recurring Lego Analogy is a case of moving goal posts, where simplicity is continually redefined as whatever isn’t easy *yet*. If you can resist that particular strain of utopianism, you’ll find that there isn’t a whole lot of substantial difference between what you can do as a real programmer, and what you can do as a Javascript doodler.

    • AG says :

      I guess my response boils down to: what you describe is happening, and has been for a few years, now. The recurring Lego Analogy is a case of moving goal posts, where simplicity is continually redefined as whatever isn’t easy *yet*.

      I hear what you’re saying, but I don’t actually see this process happening — if it is, it certainly hasn’t handed me the kinds of tools I’d need.

      I mean, I know we shouldn’t design for ourselves and all, but isn’t that a pretty good indicator that development tools aren’t nearly accessible enough, if I can’t trivially put together the sort of things I want and need? I’ve been immersed in the development of interactive technologies for over a decade, and I wouldn’t know where to begin developing something I could use, let alone something useful enough that I’d want to pass it on to other people.

      I might more-or-less agree with you if HTML5 wasn’t so clearly turning into a multicar pileup, as well. That I can see, we have many, many years to go before ordinary users can expect anything like real-world process control in the browser, consistently across browsers. Other people will be far better informed as to the chances of that happening than I will, but from what I can see…well, I’m not holding my breath.

    • Michal Migurski says :

      It’s hard to reply to the “not for me” objection, without some sense of what it is that you actually want and need. I’ve used visual programming environments before – Max/MSP was the only game in town for audio and video control for a long time, and it really did the thing. One of its core strengths was that it eschewed any notion of “process control” much the way that browser technologies traditionally have, in favor of a declarative, physical computing metaphor. If you wanted two of something, you had to actually copy and paste.

      This ends up being a really important distinction among development environments: the idea that data-is-code-is-data and stack-based recursion means that things can get hairy very quickly, in spite of the best efforts of visual environment developers. There’s a point not very far down the road where the difficulties of input (remembering what code to type vs. clicking and dragging boxes) are subsumed by the irreducible difficulties of thinking like a computer. This is why I’m suspicious of the Lego Analogy: programming will never be as easy as playing with legos, except for those situations where it is, and those situations are largely being addressed through technologies such as HTML and Javascript.

  3. Wayne says :

    In the countless blogs I have read comparing the iPhone and Android experiences, the enduring argument against Apple’s superiority in numbers of apps has been “How many Fart apps does any one person need?” The detractors have a point. The Apple App Store does host an inordinate number of redundant, useless and otherwise unexciting apps. This situation developed using tools for app creation that have a fairly steep learning curve for the uninitiated. What will Android’s new collection of apps look like, I wonder, if the price of admission comes so cheaply? There will, no doubt, be exceptions, but I think these new, homebuilt apps will act as so much noise; making the discovery of the worthy apps all that more difficult.

    • AG says :

      I guess that’s kinda my point, Wayne: at that point, if you can’t find an “app” (or constellation of functionality, really) that does what you want…you build it yourself.

  4. Thomas says :

    The balistic trajectory of that change, as pointed, does not only come from simpler tools and their underlying ecosystem, be it HTML5.
    It is closer to a dual process in which both that change in the eco-system AND the increase in algorithmic literacy play a role in the move towards the potentially ‘ideal’ situation you describe.

    So maybe we could rephrase this as a quantitative question: where are we on that trajectory? One could propose indicators of that change and maybe we’ll be able to learn from what is happening and avoid fetishizing the tools at hand, be it Google’s.
    we could maybe grasp the gradual change and avoid these threshold artifacts that are the appearance of a new tool:

    The average age for developpers on phones might be one of these indicators (in particular below 18), the percentage of the population per developement done an other one.

    Maybe this is a relatively short list that would constitute the begining of an indicator for a reason to be saddened or pleased. What would you add/remove from that list? Even more important, where could be the tipping point for critical mass?

  5. Rachel Hinman says :

    Adam – Thanks for your thoughtful post. I couldn’t agree more. The notion of apps becomes brittle in the mobile context. A relational UI where content truly becomes the interface is the future.
    http://www.adaptivepath.com/blog/2009/06/10/discovering-the-chiaroscuro-of-mobile/

  6. Joe Hughes says :

    Adam, I’d encourage you to take a look at Android’s Intent system, which makes it relatively easy to connect an Android app to functionality from other apps.

    For all of Android’s other flaws, it’s an impressive attempt at solving the OpenDoc-style composable functionality problem. The Android designers benefited from the simplifying assumption that on a phone, you can devote the entire screen to one task at a time, so you have fewer of the usability problems that come from trying to integrate a bunch of disjoint UI elements from different authors on the same display.

    The thing that really drove home how powerful this could be was Marcel Dopita’s OpenWatch for Android. OpenWatch does all the dirty work of talking to bluetooth watch hardware, and then exposes a few simple intents which make it easy to prototype interesting wearable applications that can respond to buttons on the watch or push stuff to a wrist display with a few simple lines of code. Since OpenWatch doesn’t have to care what’s generating the intents, you can even hook it up to SL4A and drive things from simple Python scripts.

    It definitely still falls short of your pervasive vision, but I think it’s further along than you may have realized.

    • AG says :

      That sounds really interesting, Joe, and I’m sure you’re right. One of the perils of the trade is that people in some universe right next door might be working on just the kind of thing I’d like to see, and I’m so head-down I never hear about it.

      I’ll check it out on your say-so. I’m still quite a way from feeling like I’d be comfortable in the Androidosphere, but I’m starting to feel like Steve’s garden of pure ideology might not be for me either in the long run. (Weird, huh?)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,068 other followers