Four Thoughts on the WHAT, WHY and SO WHAT of Google App Inventor for Android

By Mark Sigal
July 12, 2010

There is something enticing about a software toolkit for non-developers; the concept that if you can articulate a workflow or algorithmic outcome, you can "meta-program" it without writing a line of code. 

That's why I think that there is some warranted excitement around Google's (still fuzzy on details) App Inventor for Android. It represents a holy grail and a myth at the same time.

I have four thoughts that I would like to put forth for assessing the "WHAT" (what is it), "WHY" (why do we need it) and "SO WHAT" (how is it materially better than current practices) of Google App Inventor for Android:

  1. App Builders like this face a classic 1.0/3.0 Conundrum: The question with such solutions is are they powerful enough to solve a REAL problem out of the box, versus merely facilitating a proof of concept. This is analogous to the distinction between a dog walking on its hind legs (impressive, but not compelling) and an organism that functionally walks upright to the point that it can reliably get between Point A and Point B, completing meaningful tasks along the way.  On this one, I hearken back to the Java Bean Box, another component-based model for non-technical users whereby you could pull objects into a runtime sandbox, define the hookup parameters between various methods, and build a finished app. The challenge was that while it was all impressive, in practice to solve a real problem, you needed to enter the bowels of the underlying code, which broke the connection to the Bean Box, meaning that the solution was neither compelling in 1.0, nor scaled to ANYWHERE useful in 3.0.  How does App Inventor for Android reconcile this one?
  2. History Suggests the Real Opportunity lies with ISVs, not Laypersons: The success of Visual Basic for Applications (on the Windows platform, which spawned many an ISV, while creating tremendous lock-in advantages) and HyperCard (on the Mac) shows that there is a need for Rapid Application Development tools that find the balance between facilitating specificity for a desired outcome and simplicity of implementation and subsequent refinement, while reconciling the practicality that in most cases, these efforts are 1-5 person efforts.  Dale Dougherty of O'Reilly/Maker cogently argued this same point in 'The iPad Needs its Hypercard.' Given Apple's proximity to so many media/content providers, its failure to move quickly and visibly in this realm presents an opportunity for Google to outflank them.
  3. Will Google 'Eat its own Dog Food' by Exposing Core Google Services to this Model? If Google really wants to prove out the efficacy of this model, the most compelling way to do so is by eating its own dog food; namely, but wiring core services such as News, YouTube, Search, Gmail and Maps to the Google App Inventor.  Why does this make sense?  One, the moral of the story from the PC era is that the potency of Visual Basic was not that you could create wholly new apps from scratch, but rather that you could harness and extend Microsoft Office.  Carrying this analogy to the present, extending Google Apps and Services is the most fundamental way to create a 1+1=3 relationship between Android, Google App Inventor for Android and core Google Services. Two, it forces the company to get better at usability and workflow around specific application use cases, as opposed to merely supporting generic workflows, a tendency that often pushes the company towards a fuzzy "NOT EXACTLY" bucket I railed on in 'Google Buzz: Is it Project, Product or Platform?' Three, such an approach pushes the company beyond its somewhat sanctimonious "Open-ish" position, where it pivots between being REALLY open in areas that it wants to commoditize (such as Mobile, Tablet and Desktop OSes) and quasi-open in areas that it sees as proprietary differentiators (Search and Advertising).
  4. Why Limit App Inventor to Android? I get it that the primary battle that Google is fighting today is against Apple's iOS platform of 100M iPhones, iPod touches and iPads, not to mention the mindshare battle with developers. Moreover, the App Inventor toolset and runtime are built in Java and tuned to Android's runtime dynamics.  But, if the Google credo is that open always wins and that what's good for the Web is good for Google, shouldn't such an initiative be structured to work great on any mobile device that is HTML 5 ready (i.e. outflank iPhone by making universal apps more/as compelling as native apps), not to mention for web designers, bloggers, micro-bloggers, Facebookers and the like? To be clear, the choice of the naming scheme that Google chose -- App Inventor for Android -- is suggestive of just such a conclusion.

As always, God is in the details (back to my 'Project, Product or Platform' pushback), but kudos to Google for pushing the ball in this direction.

Related Posts:

  1. Google Buzz: Is it Project, Product or Platform?
  2. Open "ish": The meaning of open, according to Google
  3. Decomposing Google News and Making it Social

You might also be interested in:

News Topics

Recommended for You

Got a Question?