Those of you who know me, know I love my iPhone! Even more than that, I am known to fire up Touch DJ and spin a few tunes while out and about. Well there’s a new piece of hardware out for the iPad that looks to blow this out the water. I’m not too sure on the faux records, as I prefer a waveform to look at. Needless to say, this looks promising!

Algoriddim, the makers of the popular djay application for Mac, has ported djay over to the iPad, taking full advantage of the new iOS 4.2 audio features.

Algoriddim djay iPad Application Features

Full access to iPod library
Multi-tasking: you can run djay in Automix mode and listen to a continuous, seamless mix running in the background while you surf the web, play games, etc.
AirPlay: you can wirelessly stream your mix to your Apple TV or AirPort Express station in real-time.
Fully leverages accelerated CPU extensions (SSE-like) for high-quality audio processing and analysis
Very low latency (< 3 msec)
Background audio playback (multi-tasking support)
Pre-Cueing (via mono/stereo adapter)

What do you think? Will this further kill vinyl or even dare I say it CDJs? It surely has put a final nail in the coffin of Tonium’s current Pacemaker.

A week ago, we received a pleasant surprise. Apple had featured our ebook, "Rabbit and Turtle's Amazing Race" in the iTunes App Store. The publicity came with an immediate 3-5X pop in paid downloads of our book, pushing it to the #12 Top Grossing Book for iPad.

"Rabbit and Turtle's Amazing Race" is a children's rhyming book with illustrations, quirky interactions and sound. It's "pop-up book meets the iPad." That's the design goal, at least.

I would love to tell you that building a book was a straight path from concept to storyboard to launch and inevitable success. The truth, however, is a bit more complicated.


In the paragraphs ahead, I will try to give you a sense of how we built our book, the mistakes we made, the discoveries, course corrections, and how it all worked out for us. If I miss something integral to you, please follow up in the comments.

Fragmentation lives: Building for iPhone, iPod Touch and iPad

At my company, Unicorn Labs, we have now built 13 apps for Apple's iOS Platform. Eight of them are optimized for the iPhone and iPod Touch. Five are built for iPad.

From a technical perspective, I can say that developing for the platform is not a simple matter of write once, run everywhere.

That is not to say that the experience building iOS Apps and plugging into the iTunes App Store has been unfavorable. Quite the opposite. I am very proud of the productivity that we have realized, the global, automated reach and distribution that we have been afforded, and the goodness of frictionless billing/payment.

But, I would be less than intellectually honest, and strategically dumb, if I failed to underline that that matrix that I talked about here is upon us.

One small example of this is that the newest version of the platform is iOS 4.x. The new OS gives you some wonderful capabilities, such as video capture services, multi-tasking and of course, taking advantage of functionality like Retina display on iPhone 4 and the new camera on Gen 3 iPod touch. Simply put, it is a case of a really solid system just getting better. Don't even get me started on how experientially enhancing iOS 4.2 is on iPad.

However, the point is this: once you call certain functions or use certain libraries that iOS 4 gives you access to, you pretty much no longer will run on iOS 3.x devices.

While this issue will be resolved later this month when Apple rolls out it's unification release for iOS across all devices (the aforementioned 4.2), the other truth is there's now a feature matrix that one can access as a developer to varying degrees, such as camera, telephony, video capture, audio, and photos.

Deciding which of these functions to use, abstract or ignore exposes you (as a developer) to all sorts of reach, performance and support complexity challenges and tradeoffs.

Moreover, in building our family of apps, we have leveraged two different development platforms that are complementary to Cocoa Touch. They are Ansca's Corona and the Cocos2d middleware. Even here, actions like plugging into Facebook and interfacing with native Cocoa Touch functions are slightly different in each of these realms.

Android devotees, I hear you snickering. Before you do so, know that these complexities are materially worse in the Android world, where not only do you have to contend with these same challenges across far more device types, but also the meta-platform "forking" decisions of different handset makers and carriers.

Nothing is free, but the cost is relative to not hopping aboard the greatest rocket ship ride since the advent of the web, and the rise of the PC before that. The apps lifestyle -- aka "There's an app for that" --- is the real deal. The mobile age is upon us.

What exactly is an ebook, anyway?

I have written in the past about where I think ebooks are headed ("Rebooting the book"), but the essence is this.

The advent of sound in motion pictures transformed not only how films were made, but what they were and the economics behind same. This is the rapidly approaching future for the book business and print media in general.

The current state of the ebook business is nominally better than a PDF stuffed into a bookish-sized reader. Think: Amazon's Kindle. It's mostly text, devoid of sound and/or interaction.

By contrast, in iOS an ebook is an app, and there are few limits to what an app can do. Touch, interact, be read to, savor high-definition art and stereophonic ambient sounds and special effects.

"Rabbit and Turtle's Amazing Race" was built in Corona, and we're happy with the decision. Our next book, scheduled for release in time for Christmas, is also built using Corona. In fact, the Play-Doh-like qualities of Corona enabled us to almost simultaneously come out with both full (paid) and lite (free) versions of the book on both the iPad and iPhone/iPod Touch.


Finally, a non-trivial benefit of Corona is the fact that porting to Google's Android is straight-forward, closer to a compile option than a re-architecting.

As noted earlier, we looked conceptually to the pop-up books from our youth for inspiration in cobbling together a book that has a solid story (a re-envisioning of the "Tortoise and Hare" fable) but is also packed with lots of cool sounds and visual interactions.

Now that I built it, will they come?

Here's the rub. The App Store model is hugely competitive. It's got around 300,000 apps, and the ease of development and distribution means that clone versions of your app are coming.

Worse, pick the wrong category, and your chances of being discovered by your target audience get lower.

For example, the Games and Entertainment categories are fiercely competitive. Choose Photo instead. Many iPhone categories are seemingly saturated. Their iPad counterparts are in an earlier stage in the product innovation lifecycle, albeit targeting to a much smaller base than the combined base of iPhones and iPod touches.

So how do we approach this from a go-to-market perspective? For one, we committed to iterating the book. Over a few different releases, we added new features, fixed bugs, and generally improved the product based upon user feedback and proactively monitoring usage data.

This turns updates into pseudo marketing events. And who doesn't like a solution provider that is committed to making their products better for its users?

The idea of marketing events brings to mind the indelible truth that with apps, the initial launch date is such a significant milestone that there's a tendency to underplay events like product updates and market validation news. Don't fall for that trap.

Similarly, we baked social sharing into all of our products. We live the medium by Facebooking, blogging, micro-posting, and tweeting. It's the ultimate drip marketing methodology.

We also assembled a media list and reached out to the folks that we hope will be advocates for our products. We customized, tweaked and tested messages and media kits. Obviously, the product has to deliver.

Finally, We approach app building like a shark that has to keep moving to keep alive. It's exhausting and exhilarating at the same time.

Related:

Rebooting the Book (One Apple iPad Tablet at a Time)
Apple, the Boomer Tablet and the Matrix
Apple's segmentation strategy, and the folly of conventional wisdom
iPhone economics and lower barriers to entry
The expanding influence of apps and mobile

There's been a ton of criticism, including from me, over Apple's restrictions on the App Store. How it restricts the freedom of developers by blocking applications users definitely want to use, or yanking apps that fail to meet a changeable standard of appropriateness or legitimacy. I originally thought I would never buy an iPhone because of that policy alone, and I felt like quite a hypocrite when I decided to buy one anyway. As many people have pointed out, the iPad, if successful, will further extend Apple's control over the code its users are able to run.

One of the main pitches for Google's Android platform, in contrast, is that it is more open, freer, more consistent with the principles that the open source world (and this blog, and I) espouse. For the code, and applications running on it, that certainly seems to be true. I can go to source.android.com and download the Android source. The Apache license applied to most of the project is very liberal in the use of that code. As a developer, I can publish applications for Android at www.android.com/market, where, Google says, "developers have complete control over when and how they make their applications available to users." How much more free could you get and still call it a platform? The Android stance is nearly 180 degrees from the iPhone's. One is free and the other is closed.

And yet, I don't think the contrast is as clear as that. Freedom means different things to different people. Hence Richard Stallman's quip, "Think free as in free speech, not free beer." While there's no question the code is much more free on Android, I think Steven Levy's point in his piece on the iPad is worth repeating:

While Apple wants to move computing to a curated environment where everything adheres to a carefully honed interface, Google believes that the operating system should be nearly invisible. Good-bye to files, client apps, and onboard storage -- Chrome OS channels users directly into the cloud ...
Funneling users to the cloud means storing their data for them, on Google-owned and controlled servers. And Google is at least as restrictive about the data on its servers as Apple is about the apps in its App Store -- maybe, I think almost certainly, a lot more restrictive.

Google has long taken the stance that users should trust it with their data (famously enshrined in the company's "don't be evil" motto). And indeed, Google has taken stances I believe are favorable to users' interests, including fending off subpoenas from the U.S. government for search data when other search companies did not, and, last week, advocating for better privacy laws (meaning, privacy of Google's data from government demands).

Google often seem to take those admirable stances, though, when users' privacy interests coincide with Google's business interests. When they don't, Google sometimes argues for its business interests above users' privacy interests. For instance, see Google's arguments for the benefits of log retention, which as the AOL search data case showed, can certainly be harmful to users' interests. In these cases, the protections -- that is, the freedom offered by Google -- is limited to "trust us."

I'm not just spouting off, here. At my company, we promise users what we call the "Data Bill of Rights," which states in very plain language the control our users retain over their data. We also recently released an open source server framework that helps "cloud" applications responsibly store user data. If Google wanted to make promises to users about data that were as strong as the freedoms it offers around the Android code, it could, and it doesn't.

I have no hard evidence that Google is untrustworthy with my data, but nor do I believe that the emailed report I got from my doctor's office in my Gmail account was completely removed when I hit "delete." I've had conversations with Google engineers that have creeped me out to no end and made me reluctant to use its services, as good as they are, and I feel like quite a hypocrite when I decide to do so anyway. Likewise, I have no hard evidence that Apple wields its control any more or less responsibly than Google does.

I disagree with calls both companies have made with their respective points of control, but in general I believe both are trying to create fantastic products in a responsible way. And the guarantee I have that that is true for either company? None. Apple can and occasionally does abuse its control over the App Store to further its business interests Google can and occasionally does abuse its control over hosted data to further its business interests.

What brand of freedom do you prefer? I find myself undecided. I don't like either brand, since neither really seems free to me. I'm sure, though, that saying Apple is an overly restrictive platform and Google/Android is a free and clear platform is a false dichotomy.

My Dad sent me this video today. Apparently it's been doing the rounds since 2009 but I'd not seen it. The video is from the TV show Ukraine's Got talent and contains eight and a half minutes of astounding 'sand animation' by Kseniya Simonova.

Take a little break and watch the performance of 'The Great Patriotic War' here. Link to large size video, which I recommend. 8:30 long.

There are three exceptional things about this video. One — it's great art — enthralling performance, emotional themes, beautiful imagery. Secondly, the performance itself is technically amazing, yet, apparently the artist has only been doing this for one year. Finally, all of this is being achieved with some plain sand on a flat (backlit) surface. The tools for art don't get much simpler.

And yet…this is exactly the type of real-time, subtle, organic, sensual and fast art I always imagine computers could be capable of. Unlike many swooshy multitouch demos, this is not art for art's sake, instead the animation covers very human topics; one of every four people in the region died in WWII's Eastern Front. And she's using every last creative aspect of sand, from brushing, to finger and palm painting, throwing sand and scraping with the edge of her palm.

Two Hands are Better Than One
So this is how great it can be with some sand. How about some silicon? Matt Gemmell wrote a great piece on iPad application design I enjoyed. On the topic of the iPad's large, multitouch area, he writes…

The important point is that there are other, more obvious ways to accomplish these things; the two-handed input features are conveniences and power-user features. They’re useful and time-saving and possibly discoverable, but they’re not the only way to accomplish those tasks. We’re only just beginning to come to terms with the possibilities of dual-handed input; essential functionality shouldn’t require it yet.

You can see in the video that Kseniya rarely uses two hands. My stopwatch recorded only 1:15 minutes of two-handed use in the eight-and-a-half minute performance. That is, she only uses two hands simultaneously in this performance — 15% of the time. When she does, it's to do something quickly like clear an area. She also seems to use two hands when she's wants to draw symetrically, like the hair at 3:43.

 The matter is not that simple though. Many times she switches hands in the performance because she wants to draw on the far left (she appears right-handed) or because she wants a particular shape, or needs to approach from a particular side. 

Sometimes she switches for speed, and artistic effect; alternating left and right throws.

 

Just the Tip(s) of the Iceberg
I love this video because of the richness in the interaction. It's an encyclopaedia of gestures, from a single finger-painting, to multi-finger dabbing, parallel lines with thumbs and middle-inger. French-curve arcs with a palm, broading erasing strokes with the whole hand and intricate air-brush effects with sand released from above. I agree with Matt: we are at the beginning of this whole wonderful adventure. I'm going to keep Kseniya performance in mind as something to strive for. This is a great interface. 

 

A lot of tech commentators seem disappointed that the iPad feels more like an evolutionary step than a revolutionary step. For one group of technologists, though, the iPad is an opportunity for revolution, to take center stage in creating experiences users will want, and even want to buy.

The iPad is all about consuming content, but most of the conversation about that content has seen it in traditional silos:

Audio, through iTunes
Video, also through iTunes
iPhone apps (and now iPad apps), through the App Store
Books, through iBooks
The Web, the most open of these options.

The last of those options, however, can incorporate all of the rest - even the iPhone applications. Given the space on the iPad screen and the reported speed of its A4 processor, web design is actually the easiest way to create applications for the iPad.

Web design? On the iPad? Wasn't that the bad idea Apple originally had for the iPhone, before they were overwhelmed with requests for a real SDK?

Well, yes. The early iPhone development environments felt maybe too sandboxed. A lot of features now available in Mobile Safari were only starting to develop, and key tools for connecting to features of the iPhone not typically found then in web browsers (vibration, accelerometer, geolocation) didn't exist. Learning Objective C made sense at the time.

Today, things have changed. With support from tools like jQTouch, it's shockingly easy to create apps that feel like they belong on the iPhone using HTML, CSS, and JavaScript. With PhoneGap, you can reach out to features like vibration, accelerometer, geolocation. What's more, PhoneGap lets you target your application to multiple platforms, including Android and Blackberry, so you're not even locked into Apple's tightly-controlled universe.

For a quick tour of how this works, see Bill Peña's tutorial. For a lot more detail, though still 160 pages, see our recently released Building iPhone Applications with HTML, CSS, and JavaScript. Despite massive rust on my web skills and no experience with iPhone development, I was able to create a functioning, if basic, iPhone application in three hours, and have it running on the iPhone Simulator in twenty more minutes.

Moving to the iPad shouldn't be difficult. As the PhoneGap folks tweeted:

for those unsure, iPad is @phonegap compatible out of the box.

There are, of course, ways Apple could make this difficult. They could have locked web-based apps into the iPhone size, but fortunately that doesn't seem to be a problem. They could also block PhoneGap based applications from the App Store, as they once did, though they seem to have
gotten over that a few months ago. Even if they were to cause trouble, however, it would just block one possible revenue stream - the web browser itself would still be open for business. I don't think even Apple can close that down.

Apart from the joy of being able to say "I don't have to learn Objective C", the web approach has tremendous advantages for probably 80% of the applications people the iPad seems built for. The layered approach of HTML, CSS, and JavaScript makes it easy to pour content into templates, decide how those templates will look, and what interactivity they will have. Done right, it's a much more maintainable approach as well, making it easy to change the look or add interactivity without having to break into the underlying content again. Adding content or reaching out to content elsewhere on the web is easy. Toolkits already make the shift from traditional web browsers to device development easy. We've come a long long way since the first glimmerings of a slow and creaky Dynamic HTML appeared on the landscape.

I expect music and to some extent video to stay in iTunes or similar venues. Terrified book publishers who want their DRM will likely stay in the iBooks zone, though hopefully Apple will let braver publishers in there without DRM. Customers will expect to find "books" there. It's also clear that there will always be applications, notably games, which demand native code - Objective C on the iPad - to achieve the fastest possible response time, draw intricate graphics, or bind tightly to iPad features. There's a future for all of those things, in their particular venues.

But for "content", especially content that combines text with audio, video, pictures, and interactivity, web-style development has a tremendous advantage.

Arise, web developers! Our time has come to dominate!

Why the iPad may be just what we need for Digital Inclusion. Chris Thorpe: “It may not be a Jesus phone, a Moses tablet or something that lives up to hype and hyperbole, but if it does something for the digital inclusion agenda it might live up to Steve Jobs saying it’s the most important thing he’s ever done.”