Angelo Taylor is a University of San Francisco student who took my App Inventor course last year. He has created this video about our App Inventor course. Great work Angelo!
My O’Reilly Webcast on App Inventor and its future is now archived (it was given Sep. 2, 2011). I talk about some success stories with App Inventor, what’s going to happen as it transitions to MIT, and how the language might be developed further. I even tell a really bad App Inventor joke. Check it out.
App Inventor team’s initial impetus was education. But when it was released on July 12, 2010, thousands of people showed up to the party. some were experienced programmers who love how easy it is to develop apps and prototype, some were web designers who suddenly could create something other than static web pages. Still others were creators/entrepreneurs who had found a way to prototype and create marketable apps, to take part directly in the development process.
Nobody really knows what to make of them because they are a new social group, a new phenomenon made possible by App Inventor’s low barrier to entry. Hard core programmers scoff at them and say they’ll ruin the Android market with trashy apps– they don’t want them at the party. The business world doesn’t even realize they exist. Its like we needed a Malcolm Gladwell to come in and make sense of a new social entity.
Anyway, this group has been ignored somewhat in the discussion concerning App Inventor’s closure, with most of the focus on educators like myself. Many of them have worked incredibly hard, taught themselves programming and app design, started businesses, and contributed greatly to the advancement of the language and Android in general.
Like teachers, this new technological group will have the carpet pulled from under them if the transition to open source doesn’t go smoothly. Its a shame because our society needs more creative people with the skill to create not just blog posts and web pages, but interactive media, i.e., apps.
I guess this is, in a nutshell, why Google is closing its labs and focusing on fewer projects– they just aren’t able to fully support and promote the very cool projects they had. Perhaps in the transition to open source, with more organizations having a chance to contribute directly, this new group of software developers can be nurtured as they should be.
Google quietly announced the discontinuation of App Inventor, effective end of the year. They plan to transition the product to a non-profit organization, the goal being that, for App Inventor users, only the URL will change come December 31st of this year. They will also open source the project.
There’s some good in this announcement, but it’s mostly bad and ugly.
Will I still be able to access the apps I’ve built and create new ones?
This question is especially important given that your work lives on the corporate servers. If Google shut App Inventor down today (they won’t), you would have no way of accessing the existing apps you’ve created.
Google has promised to keep the current version of App Inventor running until Dec. 31, 2011. The plan is to turn the system over, at that time, to a non-profit organization. If things go smoothly, you’ll be able to access your apps and App Inventor on Jan. 1, 2012 just as you do now, just at a different URL. Update 8/12/11: Karen Parker, the App Inventor Program Manager, notes that legally, Google can’t transfer user data– your apps– to another site. So there may be some download/upload on the part of developers to get their apps to the new system. The key, of course, is that the new system can upload apps created by the old system.
The “if things go smoothly” is the kicker, of course. There will be uncertainty unless Google pledges that a smooth transition will occur, which I believe they should do.
Until then, it’s a matter of trust. I’m optimistic, based primarily on my experiences with Hal Abelson, Mark Friedman, Karen Parker and the rest of App Inventor team. They put their heart and soul into the project, they want to see it succeed in the new form, and they feel responsible to the community they’ve created. I trust them to get the job done.
App Inventor is being open sourced. Isn’t this good news?
There are two separate things going on here. Google is discontinuing App Inventor, which is bad. They are also open sourcing it, which is good, even if it does come packaged as damage control.
First the bad. As of January 1st , App Inventor will no longer be administered by Google. The 5+ wonderful engineers on the team will no longer be fixing bugs and adding great new features. Perhaps a non-profit with equally great engineers will take over and provide a seamless transition, but this is uncertain. All we know at this point is that the greatest tech company in the world won’t be running it.
It is a good thing that App Inventor is being open sourced. An open source App Inventor means that developers and researchers can make use of the App Inventor code base to build new tools. We could see an App Inventor for building iPhone and iPad apps, for building cross-platform apps. In the long run, it could spur innovation in visual programming.
But make no mistake: these are potential benefits for the future, and really are not helpful to App Inventor developers and educators in the near term. The truth is that a closed source App Inventor, supported fully by Google, is far and away better for App Inventor enthusiasts. This announcement is a blow to the many kids, students, educators, and newly empowered software developers who love App Inventor, and will at the least slow the momentum of the project.
I’m a teacher planning to teach App Inventor in fall 2011 and in the future. Should I abandon this idea?
Teachers hate uncertainty and don’t have unlimited hours to prepare a course and learn new tools. But my advice is to stick with App Inventor. I believe its a revolutionary tool for teaching beginners and non-computer-geeks programming. It combines a visual blocks language proven successful with Scratch with the motivating force of mobile computing. Young people are fascinated by the little computers they now carry around with them and they are blown away when they realize they can actually create software for them, actually control them.
There is risk here and there will no doubt be issues. But as I mentioned above, I trust that the App Inventor team will come through. For me, the rewards—a bunch of highly motivated students in my class—are worth the risk.
Did Google behave poorly by cutting App Inventor?
Can you expand on that?
I’m a mild mannered professor. I don’t know beans about corporate politics and even less about the best way to make money. But I’d say the following is probably good policy:
Don’t start initiatives to inspire, empower, and educate, then indiscriminately pull the plug.
I understand the Google Labs closure: focus more on fewer projects. And Google has every right to cut Google labs projects– users of such tools should be aware of the risk.
But in the case of App Inventor, the decision effects more than just your typical early adopter techie. It hurts kids and schools, and outfits like Iridescent, who use App Inventor in their Technovation after-school programs for high school girls, and Youth Radio’s Mobile Action Lab, which teaches app building to kids in Oakland California. You’ve hurt professors and K-12 educators who have developed new courses and curricula with App Inventor at the core. You’ve hurt universities who have redesigned their programs.
I don’t want to over-dramatize this: these groups will be fine, especially if Google makes good on transitioning App Inventor. My melancholy is more about what could have been had Google truly supported and actually promoted the tool, and about the loss of momentum for this wonderful project. We really need more programmers and inventors, and App Inventor can have a profound effect. If President Obama knew about App Inventor’s potential to inspire a whole new generation of engineers, he’d be really pissed at Google for this move.
Even looking at it from Google’s perspective, I find the decision puzzling. App Inventor was a public relations dream. Democratizing app building, empowering kids, women, and underrepresented groups– this is good press for a company continually in the news for anti-trust and other far less appealing issues. And the cost-benefit of the cut was negligible—believe it or not, App Inventor was a small team of just 5+ employees! The Math doesn’t make sense.
Let’s end with Clint Eastwood
As a teacher, I like to end things on a positive note, on the Good. The App Inventor project has shown that ordinary people, not just computer geeks, can program the mobile computers we all now walk around with us. It provided a glimpse of a world in which people don’t just use phones and tablets but take control of them, customize them for their personal use.
It fired up a bunch of kids, college students, and tinkering adults, empowering them technologically beyond their dreams (click on the pics below for just a few of the success stories). It drew the interest of young women and demonstrated a way to lure more of them into computing. Larry Page may not get it, but his tiny group of 5+ engineers created something revolutionary. In the long run, the ideas and design behind the App Inventor project will live on and fulfill their great promise, Google or not.
In closing, I encourage Google to do the right thing, to support those 5+ engineers in the transition, vigorously fund the non-profit entity that takes over, and most importantly, make a firm pledge to the App Inventor community that the transition will occur seamlessly. If they do, the ugly will turn to beautiful, the bad to good, and App Inventor will outlive the Spaghetti Western.
Just a couple of the many App Inventor success stories….
Here’s a collection of articles about App Inventor and where it fits in the world. Know of others? Please add to comments.
Howard Wen, The Ascendance of App Inventor: David Wolber on why App Inventor isn’t just for novices, O’Reilly Rader Interview.
Hal Abelson, Mobile Ramblings, Educase
Clive Thompson, Coding for the Masses, Wired Magazine.
Igor Lansorena, Man Proposes using Harry Potter app ceated with app Inventor, EITB news
Hal Abelson, Hal Abelson Q&A, Code Quarterly (see near bottom for discussion of App Inventor)
Articles Near time of App Inventor Launch (July 2010)
Steve Lohr, Google’s Do it Yourself App creation Software, NY Times.
Jason Kincaid, It’s Alive! Taking Android’s App Inventor For A Spin Tech Crunch
Mike Loukides, App Inventor and the Culture Wars, O’Reilly Radar.
Article not directly about App Inventor but related
Clay Shirky, Situated Software (discusses situational software that has utility for a single person or group).
How many great ideas get left as just that, some jotted down notes on a dirty napkin in an even dirtier bar? Especially with software and mobile app ideas, most get dropped with, “if we only knew a programmer.”
App Inventor changes things by lowering the barrier to app development– just about anyone, with little or no training, can take an idea and build a working Android prototype for it. Even if it’s not the most refined, complete, or beautiful app, an interactive app can convey an app idea better than a power-point presentation or dirty napkin.
Here’s an example. Daniel Finnegan was a student in my App Inventor class last spring. Daniel is a really sharp, creative guy, a creative writing major who I’m sure spends more time thinking about the human condition than cell phone apps. But with a few hours focusing on app development he came up with a great idea. He had read about the dangers of texting while driving– incredibly, something like 28% of accidents involve a phone. For his final project, he came up with an app that tries to help by eliminating your urge to text back. The app, which Daniel coined, “No Text While Driving,” auto-responds to any arriving text with a response message such as, “I’m driving right now, I’ll text you back later.” You turn it on when you start your drive and all your friends and colleagues know why you’re not there for them. The app even lets the user change the response for different situations—say if you’re going into a meeting or a movie– and we’ve written versions that speak texts aloud and even send the driver’s current location as part of the auto-response.
Daniel’s idea struck a chord with people and when App Inventor launched in July, Daniel’s app was cited on the App Inventor About page. Because the app was also a nice example of the powerful Android features you can program with App Inventor, I also developed it as a tutorial for the App Inventor site, and created a YouTube screencast on how to build it.
A few days ago, we were excited to see that State Farm Insurance had launched “On the Move”, an Android app that is quite similar to “No Text While Driving”. State Farm distributes it free to anyone as part of State Farm’s updated Pocket Agent® for Android™ application.
“It is our hope that this widget will prevent crashes and save lives,” said Laurette Stiles, Strategic Resources vice president at State Farm. “This new service will help drivers manage the temptation to read or respond to text messages when they are behind the wheel. We wanted to make this widget available free-of-charge as just one of the ways we’re working to keep our roadways safe for drivers.”
I don’t know that the State Farm app was inspired by “No Text While Driving”, but its quite possible. In pondering this, I realized the incredible nature of it–an app created in an introductory computer science course, by an English major who had never programmed a computer, possibly being the inspiration for a now mass-produced piece of software! And one that saves lives! As soon as I finish this blog, I have to email USF President Stephen Privett!
If Daniel had written a term paper on his idea, I wouldn’t be blogging about it possibly being the inspiration for the State Farm app. But because App Inventor made it possible for Daniel to transform his idea into something tangible–well, virtual– an interactive app, it is a distinct possibility.
So cheers to Daniel, and to the App Inventor team– you have built a tool that opens up app development to a huge new pool of creative people!
You’ve got a real-world problem that could be solved with software, but none of the pre-canned solutions you find quite fits your particular needs. Wouldn’t it be great if you could take something that almost fit and tailor it? And wouldn’t it be great if you could do it within hours and without hiring a programmer. This is the promise of App Inventor, and the promise of an open source where the “source” is actually decipherable.
I recently received a series of emails from a couple who needed an SMS Texting broadcast hub to organize a community event. They tailored one of the App Inventor tutorials I wrote, BroadcastHub, to solve the problem. From Myles Byrne:
My wife and i are respectively a cancer scientist and a bioinformatician who moved from San Francisco to Helsinki last year. We’re working extracurricularly with a local arts organization to try to lift a central neighborhood to a more creative and inclusive plane, especially regarding the growing immigrant population. So there is at least some relatedness to the mission of FrontlineSMS.
So we’re organizing events from now till 2012, when Helsinki is World Design Capital. The first such event is Saturday, and we’re trying to get broadcastHub working in this way:
- a cell number on an Android (HTC wildfire) receives SMS’s from people who want to be part of the event
- each SMS receives an auto-response reply
- each number that sent in an SMS receives several more messages over the next few days – simple text broadcasts
I was planning to learn App Inventor at leisure. But hours of searching for commercial SMS providers doing what broadcastHub does (for Helsinki users) turned up nothing.
A few days later I received this:
Our community raising event in Helsinki went off really well. About 1000 people came.
(almost entirely in Finnish)
We needed SMS broadcast capabilty for up to a thousand people over a few days. We looked at FrontlineSMS, Clickatell, and others – nothing had the right fit. Then I got my invitation to App Inventor, looked at the broadcasterHub tutorial, and realized with a shock this was the perfect solution. In a few hours I was able to modify the broadcastHub tutorial app to fit exactly our needs:
Any SMS’s sent to my phone number with the app running received an autoreply: “Text ‘beatroot’ to this number to sign up for our message list.” Any numbers sending an SMS to me containing ‘beatroot’ or ‘Beatroot’ were added to the broadcast list. But because our event was in Helsinki, the broadcast messages needed to be in Finnish. So instead of writing them myself, I told the app to take any messages sent to me from Heta and Jon, the Finnish organizers of the event, and automatically re-send it to all the numbers on the broadcast list.
It really was incredibly fast and easy to modify the broadcastHub app to do only what we needed. The app worked perfectly and can be easily re-used, modified, and shared. Having the capabilities of an android phone plugged into a graphical programming environment is an amazing experience. You’re not just learning logic, you’re learning it in the context of the social world connected to your phone.
Thanks David and Google for bringing the next level, again.
We will be using your tools for more ambitious (but still local!) projects in the near future.
- Myles Byrne
: Punajuuri (Beatroot)
Check out their event page at http://www.punajuuri.org/
and you’ll see the invitation for people to join their broadcast list:
Elävä musiikki alkaa viiskulmasta ja jatkuu
Pursimiehenkatua pitkin kankurinkadun kulmaan.
Send “Punajuuri” SMS to +358 50 415 6799 to get live SMS updates
Cheers to Myles and team, and cheers to the App Inventor team!
David Pouge gave a poor review to App Inventor in his New York Times article, D.I.Y. Tool for Android Needs Work . Because of pre-beta glitches, he and his son were unable to complete the tutorials. I think his frustration led to him making some off-base conclusions about App Inventor. The conclusions he came up with after a day certainly don’t mesh at all with the experience I’ve had teaching the tool for the past year.
“But make no mistake — this is programming. You can’t do it unless you’re a programmer, or have one nearby.”
He is correct in that App Inventor app development is indeed programming. But he is wrong in that you– someone who has never programmed before– can do it! Learning to write apps in App Inventor is significantly easier to learn than a traditional text language (more on this later). It lowers the bar dramatically. There are limitations, and some will be able to do more than others. But all of my students, with no prior programming experienced, got to the point that they could create apps without aid. David’s sentence is misleading, and I hate to see it dampen people’s enthusiasm for this great tool.
App Inventor programming vs. textual programming
“is there really such a huge difference between having to type out ‘AccelerometorSensor1.XAccel,’ as in real programming — and dragging a block bearing that name?”
This is a great and fair question, and to look at it clearly I think it really helps to be a programmer and to have taught beginners. From that vantage point, the answer is emphatically YES! In practice, there is a huge difference between typing commands and choosing from pre-defined blocks. Many of a beginner’s frustrations come from syntax errors– trying to instruct the computer with a textual language and being barked at with indecipherable messages when there’s something wrong. Of course the complex logic they face later is another barrier, but its the “syntax” frustration that turns many, many beginners away from even getting to the more fun logical problem solving. If App Inventor just gets people past that first hump, it is a great tool.
Another key is that App Inventor is an event-handling language, meaning events are first-class objects. You can directly drag out a button.click event block and then place the response to the event inside. Seems logical, and you’d think after all these years it wouldn’t be such a big deal. Unfortunately it is– you can’t even imagine how much conceptual understanding you must have to do the same in Java or Python.
David should ask a programmer who has never programmed the Android to write a Java program that prints out the readings from the Accelerometer. Hell, he could even ask one with some Android experience. See how long it takes the programmer. He’ll find that that single Accelerometer block will be replaced not with a single line of code, but an import statement, an object creation statement, manifest files, etc. The App Inventor team has done a lot of work to package a bunch of ugly stuff inside those blocks. You have to think of it as a great code library, specially designed for beginners, and transformed into visual blocks language.
For more thoughts on why App Inventor works, check out my previous post.
No Fundamentals Mentioned
David didn’t mention any fundamental issues to back his negative conclusions about App Inventor. In a reply to a comment concerning this, he mentioned only one thing:
“I explicitly let Google off the hook for the aspects that are related to the early stage of the software, and critiqued ONLY the fundamentals. For example, this business of needing two different apps to do your development, switching back and forth. That’s not going to change when the software is final.”
In my experience, the switching back and forth between the component designer and the blocks editor is barely bothersome to most when they begin, and completely forgotten by all soon thereafter. There are plenty of fundamental issues with learning to program, but this is not one of them.
David’s article is interesting and provocative, but my guess is that the start-up glitches and his anti-hype feelings had an undue influence on his opinions. Start-up glitches often do this– we all know the importance of first impressions. Google probably should have made sure more phones “worked” with App Inventor out of the box. Its scary to think that if David had been using a Nexus One on a Mac, his critique would have been completely different.
In any case, I’m inviting David and his son to San Francisco– I think given a day I can change his mind!
Sharon Michaels wrote a great review of App Inventor and like many lauds its visual, drag-and-drop interface. In teaching App Inventor for a year, I’ve seen that it does work for non-programmers and I’ve thought a great deal about why. Here are the key features of the language:
No syntax — The blocks language eliminates the need to remember and type code. When I teach beginners textual languages, their biggest pain is syntax, the blank page, and the cryptic error messages that Python/Java/etc. provides for them. Most beginners quit because of the frustrating experience of syntax errors.
Events at the top level — Traditional programming languages were designed when the best metaphor for a program was “a program is like a recipe– a set of instructions”.
Since the advent of the graphical user interface, programs have not been recipes, but sets of event-handlers. “When this happens, the app does this. ” is the correct conceptual model.
With App Inventor, an app is a set of event-handlers. I know this is amazing, but you can say, “when a user clicks this button, ” by dragging out a block. Compare this with Java, which requires you to understand classes, objects, and listeners in order to express an event-handler. Even if App Inventor were a textual language, its 1st order events would dramatically ease the development task.
Choose from a set of options — The components and functions are organized into drawers. You program by finding a block and dragging it into the program. You don’t have to remember how to enter an instruction or refer to a programming manual.
Only some blocks plug-in — Instead of chastising the programmer with cryptic error messages, App Inventor’s blocks language restricts the programmer from making mistakes in the first place. For instance, if a function block expects a certain type of parameter, you aren’t allowed to plug in a different type. This doesn’t eliminate all errors, but it sure helps.
Concreteness — You program components, not abstractions. When you drag out a component, an object is created and function blocks created for it. This is a problem in terms of code reuse and program size, but the concreteness is a boon for beginners and is pretty nice for experts as well.
High-level components — The app inventor team has built a great library with simplicity the main goal. There are months of programming expertise embedded in the components.
What excites me is the prototyping capabilities of App Inventor. Suddenly you have an electronic napkin for sketching out app ideas. Having a semi-working, interactive app is huge in terms of formulating ideas and getting them across to others. Like new terminology and abstractions, it gives people a way to talk and riff on ideas.
In a broader economic sense, it enables a bunch of smart, creative people to get involved in something that they’ve pretty much had to leave to the programmers. Consider two twenty-somethings sitting around in their kitchen drinking a beer. They start talking and come up with a great idea for an app. One dude says, “We should really do it!”. The other says, “but who would we hire to program it.” The first dude takes a chug of beer, “Oh yeah, forget it.”
Now envision a world with App Inventor. The idea comes up and now the second dude (actually a dudette) says “this is cool. Let me get my laptop and we can build a prototype for it TONIGHT.” They stay up building the prototype and in the process refining their ideas and getting EXCITED. Their wild idea has manifested itself into something tangible (well, virtually tangible). Not a complete, perfect app, but something that will spur them on, something they can show others and get feedback on, something they can show to angel funders!
They live happily ever after. Dudette even asks Dude to marry him, if he’ll stop working on the computer so much.