Competing with "Free"

My company has spent the last two and a half years developing what we think is a kick-ass publishing tool (authoring tool) for apps in general, and school book apps in particular[1]. About a month ago iBooks Author was launched by Apple, with no cost for the product itself.

Having a competitor launch a free product, aimed right at the niche where you have invested thousands of hours, is seldom good news. And when the competitor is possibly the world's most admired for innovation (I for one find it absolutely stunning that they still grow almost like a startup and with profits the size of Google's revenues!), and at times the most valuable company in the world, is all lost? As it turns out: No.

I will freely admit that I was nervous before the product launch, given the rumours (which were true). And five minutes into the launch video, I was scared. But five hours later, some analysis helped calm the nerves. I created this little matrix, you can click to enlarge it, showing that the lunch was clearly not free this time (either):

So for the time being, I see the launch as positive. The product and the marketing around it clearly highlights the need for innovations in apps for school books (and maybe broader in learning) and with the product's current shortcomings, it is not that hard to still try to sell "an expensive alternative". But if iBooks Author's output products ran smoothly on Android with no restrictions on the content produced, I would probably go back to being scared. Or maybe just work even harder on the online-collaborative angle. Go David against the innovation Goliat!

[1] - This sketch, again click to view larger version, shows the principle of how the system works:

A more technical version is that the core is HTML5-based. When building the app we pull out the HTML5 content, wrap it with a set of native extensions (using PhoneGap) and build for the relevant iOS (mostly iPad, but also iPhones for books for children) or Android platform.

The response of a potential customer being shown it live in a meeting previous week was "Magic!". I smiled.

Adobe acquiring PhoneGap - for better or worse...

I just wanted to write a really short note on the news two days ago that Adobe is acquiring Nitobi, the makers of PhoneGap.

I have been using and talking PhoneGap for about a year and a half now, building a rather powerful authoring tool that uses PhoneGap with some native extensions to build apps for iOS and Android.

Anyway, I am thrilled with the prospect of one of the industry giants, with excellent track record on the tool side, supporting PhoneGap. I also feel this gives a certain approval of PhoneGap as a serious tool. On a related note, I have had clients that I held presentations for about cross platform mobile development in 2010 come back the last months and say "we were wrong, there is actually a use for PhoneGap". Since it is hard to plot a graph safely from a random subjective data point or two, having Adobe "stamp the whole chart right there" - saying there is room for this technology for sure, was really a energy boost for me.

On the other hand, I am slightly skeptical based on Adobe's (lacking) track record on mobile devices. As I have noted before, I feel that the really great mobile platform from Adobe has been only months away since I tested an early Flash Lite edition in 2002. I am also not sure if I view the split with the ASF taking care of the OSS version as a good one. Does this mean there will be a split of versions and functionality also in the core product and APIs? For me, that would be a huge disappointment (while I find it perfectly fine that the PhoneGap Build service will be developed as a closed proprietary Adobe product and of course that tools like Dreamweaver and Photoshop gets export wizards and whatnot!). And damn, PhoneGap is a better name than Callback. :-)

In any case it is exciting times for mobile apps development in the space, literally, between HTML5 and native apps.

And on a day like this I cannot end without (even though I am not generally a fan of throwing around either "R.I.P." or "awesome" all the time): R.I.P. Steve Jobs, AWESOME innovation legacy you leave behind - and you changed a generation's view of product development and importance of design in innovation.

Vintage Code on a New Canvas

I wanted to do a small experiment with the HTML5 Canvas. To do it, I found some Java code I wrote in 2001[1] and ported it to gwt-canvas (thus compiling a Java subset to JavaScript). It uses a naive redrawing technique[2], but the point of this test was not to optimize performance or create production quality code[3].

Anyway, you can see the result here: CanvasPairs (external link). Try it and see how fast you can find all the pairs!

I did this and a few other, more graphically intensive, experiments to test canvas performance on a few devices (iPad, iPhone and Android-based phones mostly) and feasibilty for doing casual games or minigames inside edutainment titles using technology such as PhoneGap with the HTML5 canvas. The results were somewhat mixed, but for the iPad I have high hopes that IOS4 will improve performance in the Safari browser and on even the not-so-new 1.5 version of Android on a medium spec'ed phone, it was relatively impressive.

My feelings about the technology is ambivalent. On one hand I am excited about what will soon be possible to achieve in all browsers without plugins, but on the other hand the maturity feels a bit like Java applets in 1998 or Flash in 2003. At least I am sure progress will be much faster this time around.

[1] - This summer I visited Moet&Chandon and IIRC, 2001 and 2003 where the last years of vintage produced. I won't go as far as saying no good code has been written since 2003 :-), but the reunion with the code from 2001 was not that bad.

Rewriting it in GWT proved to be a little more work than I thought at first, but I am always (too) optimistic... The rewrite included just skipping a few parts (highscore lists, double buffering, keyboard input for pausing etc.) for now and reimplementing others (for instance a basic preloader to replace the ImageObserver and a string drawer based on drawing segments of an image of symbols, since text on canvas seems to be a bit shaky at the time of writing).

[2] - Basically it redraws the whole canvas for each and every frame. While this (minus some background caching, maybe) might be needed for more advanced games, this particular one might have gotten away with a bit of Image or DIV flipping, I guess - but that was not an option for the platform which it was originally developed in 2001.

[3] - One might also argue that the simplicity of the sample would have made it possible to do it without any canvas (HTML, Flash or Applet based) at all. Again, that might be true - but the main point here was not to implement the specific functionality of the game itself.