Mine were not the only suspicions that were confirmed: a number of people posited that this device would excel primarily as a mechanism for content consumption. To be fair, I have created a number of shmancy Pages documents on it so far, but consumption is indeed where this device shines. And it’s bleeding my wallet dry. Here’s why.

Let me first note that a small part of the reason iPad is draining my bank account is because Hulu has yet to get their shit together and start offering iPad-compatible content. On one occasion, out of sheer laziness more than anything, the absence of Hulu has caused me to buy an episode I could have otherwise watched for free on my Mac, from my iPad on the iTunes Store. Hulu, please, I’m begging you: get it together. Don’t whine about it being hard (or let other people whine on your behalf), just launch the subscription model we all know you’re working on, and give us a nice, industry-kosher locked down app, and we’ll be happy.

There is something inherently beautiful about touch computing: it very clearly embodies what John Maeda has referred to as “humanist” computing, that is, machines bending over backwards to adapt themselves to humans rather than the other way around. (Incidentally, if you haven’t read his latest book, The Laws of Simplicity, do so ASAP, it’s a must for anyone who creates software or UI). Not only does it feel more comfortable and less “forced” than using a keyboard and mouse (for most tasks), but it encourages curiosity and exploration because it removes the fear of imposition — a phrase I just coined to mean “when something seems difficult or imposing, people are afraid to ‘play’, and refuse to explore and learn on their own.”

There’s a sense of overwhelmingness that is often created by many complex user interfaces, and a good chunk of that is instantly mitigated on the iPad by the fact that you’re holding the interface in your own hands: it gives the user a sense of control, like he or she really has power over the application at hand, rather than acting as a slave to its obtuse mandates. For that reason, usage directions almost become a thing of the past with touch interfaces. Sure, there are some interaction patterns that are a little confusing for first-time users, but the beauty of touch is that most users won’t be afraid to press buttons and try things, and will very quickly learn the ropes through discovery rather than instruction; and as we all know from experience, you remember the things you figure out on your own much better than the things you’re taught.

This kind of inherent childlike wonder that the platform has the potential to inspire is indeed why the iPad is deserving of the term “revolutionary,” at least from the standpoint of content producers: play your cards right, and you actually have the power to make people want to buy your content. The revolution in the iPad isn’t the device itself — let’s be honest, it’s far more a thoughtfully constructed evolution than it is a technological revolution — it’s its ability to actually excite people about using a computer, even a generation frightened by the very thought of computers (seriously, give your grandmother an iPad and watch in amazement). But once again, I digress into disgusting fanboyishness.

For my example, I’m going to use the iTunes Store and the iBookstore (the App Store is excepted for two reasons: a) it’s by necessity the primary mechanism for installing software on the iPad, so it doesn’t really count; and b) I’m actually not a huge fan, it’s kind of just a supersized version of the iPhone App Store). In just the past three weeks, I’ve already bought two books, two full albums, a Palladia concert film (iTunes link), two music videos (something I’d never actually consciously bought on iTunes), and a very large handful of individual tracks. Don’t get me wrong, I am ordinarily a regular patron of the iTunes Store, but it’s quite rare that I would have spent nearly $70 using just my iPhone and Mac in such a short period of time. What makes the difference?

The simple fact is that I had more fun on the iTunes Store on my iPad than on any of my other devices. The combination of the device itself and a brilliantly-adapted storefront encourages exploration on a whole new level — for instance, I never knew Palladia posted their concert films on the iTunes Store, which further led me to find a set of “making of classic albums” films that look terrific, and some cool music documentaries I’d (somehow) never even heard of. It’s like the “Wikipedia effect” for music, and it’s incredibly powerful.

When I say “Wikipedia effect,” I mean that thing that we all do when we’re bored: visit an article on Wikipedia, click a link in the body text, and 10 minutes later, you’ve made it from “American Top 40″ to “Catenary wires” (it’s possible, I just tried it).

There is incredible potential in the iPad, and that’s the ability to engage users as intimately as on the iPhone, for a much longer period of time, simply because of the physical comfort of the device itself. It’s not marketing, it’s intelligent design (not that kind), and I would argue that it’s even more effective. I think Apple picked up on it, too: I’ll be very curious to see what they do with iAd. If it’s anything like the experience I’ve been having with my iPad, they may have struck gold.

You have a great opportunity at your doorstep. With a single decision, you have the ability to propel the web forward into a quasi-eutopian society in which audio and video content are delivered without the use of non-native third-party plug-ins. You can make true native HTML 5 standardized media delivery a reality.

But if you don’t support H.264, we will forever be encumbered by Flash video streams.

I personally have a strong dislike for Flash, but it’s not fair to simply ignore its achievements: arguably, Flash is single-handedly responsible for bringing motion content to the World Wide Web. Flash was capable of delivering interactive experiences literally years before anyone even got close with JavaScript and other modern web technologies. In fact, it’s fair to say that, even in 2010, Flash has some legitimate uses for delivering motion content.

Motion content and video content, however, are two very different animals. While much of what Flash was once used for can now be easily replicated with JavaScript and a combination of SVG, Canvas elements, and CSS 3, it’s still a viable platform for immersive motion experiences. Flash was never intended, however, to deliver video and audio: rather, it was a stopgap for the sake of compatibility — most user agents have support for Flash, so it made sense as a reliable platform for delivery, regardless of how inconsistent the result.

Nowadays, however, the browser can do so much more than its counterpart of yesteryear. HTML 5, therefore, brings forth native user agent support for video and audio, and the Internet community is embracing it readily: quite frankly, most content producers don’t like Flash, and have no problem moving to a more native means of delivery. The question is, what codec should be used for HTML 5 video?

Mozilla’s decision to use Ogg Theora and Vorbis for video and audio (respectively) is certainly admirable: personally, I would love an open codec to gain widespread industry notoriety and usage. The fact is, however, the production industry has already standardized on H.264. Nowadays, H.264 is perhaps the most common codec for Internet-distributed video, with the exception of Flash, much of which is encoded in H.264 anyway!

Content producers love H.264 because it works with their existing workflow tools, and there’s widespread hardware-level support for H.264 on a number of devices, including the iPhone and Android-based phones. The benefits brought by a switch to Ogg Theora — if any even exist — are vastly outweighed (for most content producers) by the time and effort required to make such a switch, and quite frankly, most producers don’t want to be serving up both H.264- and Ogg-encoded content.

As a result, this is what I’ve been hearing from a lot of content producers:

“I’ll encode my video as H.264: I can display it natively for browsers that support it, and deliver a Flash player for all the rest.”

Once again, people are resorting to Flash, not because it does video better, but for compatibility reasons, just like they did back when Flash video players first appeared on the web. The startling thing is, unless Mozilla decides to implement H.264 into Firefox, Firefox is going to be one of the browsers getting served content in “compatibility mode.”

There was a time when Firefox was known for its high level of standards-compliance, and was generally seen as a symbol of fostering a standard-compliant web. However, even though it’s unintentional, if Firefox doesn’t add support for native H.264, it will be holding the web back from making a move to truly native video on the desktop. Firefox users — which account for the largest chunk of non-IE web users — will still be served Flash video.

Mozilla, you have an opportunity to move the web into the future with native browser support for audio and video. However, if you refuse to provide some mechanism by which H.264-encoded video can be played using HTML 5-standardized methods, you run the risk of returning the web to the Dark Ages of format wars. You don’t need to abandon Ogg, you could even open the video element up to third-party codec installation like Safari (as long as you make it easy to find/install a third-party H.264 codec) for all I care; at all costs, though, you must make H.264 video natively playable in Firefox.

Don’t let Firefox become the browser that content producers mutter about under their breath.

Sincerely,

Matt Patenaude

When Apple announced the iPad a little more than two months ago, it wasn’t them saying “hey, looky at this cool tablet we made”: it was Apple saying “this is what the personal computer is going to look like 10 years from now.” The iPad is so much more than the coolest tablet device ever created, it’s Apple’s vision for the direction of computing for decades to come.

Are they right? Personally, I happen to think so, if only because they have a history of being right about these sorts of things. You’ve got to admit, though, whatever you think about the device itself, there’s something downright (to steal Apple’s buzzword) intimate about being able to interact with the digital world using your fingers. It’s a direct, part-to-part connection of space and cyberspace, and it’s a Good Thing.™

The question is, what happens next? If Apple has their way (in my interpretation), the innovations (or perhaps “evolutions”) found on the iPad migrate upstream to their computers, and then pass by osmosis to every other major computer vendor in the market, with Microsoft playing catch-up to match the software with the hardware the whole way. Apple’s sure to have an advantage in this market, because reliable touch computing really does depend on intimate hardware/software integration, as shown by the introduction of the Apple A4 processor.

Technology changes fast, though, that’s nothing new. The big change here is how this will profoundly shape the landscape of computer users. The iPad is brilliant in the way it makes “complex” computing tasks dead-simple for the not-so-technologically-inclined. If this thing permeates the market, we’re going to find more and more people using their computers/iPad-type-things to do cool things without being intimidated. For the first time ever, computing is going to be accessible in a truly relatable way.

So what happens to the developers? This is the question that, for the first time ever in relation to an Apple product, scared me. The Mac and iPhone development community is vibrant, alive, and well. With the exception of iPhone newcomers, however, even given the incredible diversity of the community, it’s striking how many developers share a common background: at a young age, they were fascinated by things that beep and light up, and something in their mind snapped (some would argue “broke”) and made them want to figure out how it all worked on the inside. We were no longer content with knowing that things “just worked” — we needed to know why.

That spirit is what creates a good developer (as opposed to a dead-end-job code monkey who hates his/her life). The iPad has the potential to sincerely inhibit the development of that spirit.

Today, in 2010, we the developers work in Xcode on shiny Macs, and we love it (for the most part). As Mac developers, we got started by poking around on the very same machine we used for our day-to-day computing: as a relatively open platform, Macs (and PCs) are easy to explore, easy enough to break, and fun to fix yourself (yes, being a developer is a sickness of the mind). So what happens when your day-to-day machine becomes something that resembles the iPad?

The iPad is a closed platform, which from a usability standpoint, is absolutely fantastic. As a developer with experience on the Mac, I wouldn’t have it any other way. However, if I was a new developer, only having experience on my iPad-type device, it would really piss me off, because I’d have no real way to experiment with the thing. With the experience I have, I know that the underpinnings of my Mac are actually very similar to the underpinnings of my (eventual) iPad, and I know how to make it do crazy — if unauthorized — things if I want it to. That zeal for experimenting in a new developer, however, might be very quickly replaced with a feeling of futility, when they see that the tools that I’m used to using are no longer available (or at least, they don’t look anything like the modern computing landscape as of 2030).

Now, being more realistic, this is all a bit of FUD: one would hope that if Apple moves this kind of intimate user experience to their Macs, they’ll have the good sense to keep the platform just as open as the Mac is already today; as non-portable devices, we really have no good reason to expect otherwise. Still, it’s a scary prospect.

So what does the computing landscape look like going forward? I suspect we’re finally approaching an environment in which everything “just works,” and people don’t have to worry about the little annoyances that created technophobia in the first place. It might be beautiful. We can only hope that as my generation becomes one of the last to learn to use a conventional keyboard and mouse, the spirit to tinker doesn’t die with the GUI.

I’ve been awfully restless lately. Fair warning: this is a highly self-indulgent post. Read on at your own risk.

I belong to a tortured class of individuals you might refer to as “creatives;” I have a passion for making, for producing. It’s really more of a sickness than anything else, especially combined with my self-imposed and -appointed “profession” of software engineer, another incurable disease.

There comes a time in every creative person’s life — indeed, it’s a nearly monthly phenomenon; consider it the Menstrual Cycle of the Imagination — where you’re struck with the desire to go make something awesome, or beautiful, or useful, or just neat. This phase is, in almost every case, accompanied by a complete absence of anything that resembles inspiration. It’s a kind of restlessness of the mind, and it’s downright depressing.

Sometimes, it’s not even a lack of inspiration that’s the problem, but rather a lack of resources to execute. When I sit here and look at my {13bold} Dropbox folder, I see no fewer than 29 folders, each representing a project we’ve started, many of them even dating back to before Laurent started working at Apple. So let’s see: {13bold} has released all of two software products (three if you count Bowtie for iPhone); that leaves roughly 26 projects unattempted. Sadly, there just isn’t enough time in a day to work on all of them.

I find ways to keep myself entertained, of course: when I come off from working on a large project (like Bowtie), I’ll usually bang out a couple of mini projects with varying success. Quite frankly, though, it always ends the same: a boredom that only creation can fill. Perhaps it’s time to try something different.

Incidentally, if you didn’t chuckle or at least groan when you read the title of this article, go back and reread it a few times until you get the pun (spoiler alert).

Note: this article is part of a series of articles on my real-world App Store experiment: App Power: An Experiment, App Power: The Submission, and App Power: The Reveal.

I woke up this morning to find an email from appFigures containing yesterday’s sales reports and figures; with that, I officially have data for my first full week of Bowtie for iPhone sales. And the numbers were… somewhat depressing.

Now don’t get me wrong, I’m not really complaining: I don’t do this for the money, I do it because I love it. I had, however, hoped to use my App Store profits to visit a friend in Europe. While I may eventually earn the money to do that from the sales of my app, I’m fairly certain it won’t be in time (she’ll only be there for about three more months). Either way, it looks like there’s a little more to succeeding on the App Store than meets the eye.

The Results

I’ve always believed that graphs are incredibly useful, so allow me to present my week-one sales graph:

As you can see, sales started pretty promisingly: 170 downloads on day one, 202 on day two. Since then, however, sales have been steadily dropping as they look about to converge on 0. Yesterday, a mere 22 people downloaded Bowtie, netting me a grand total of $14.70 (accounting for conversions from other currencies, etc.).

So what does it all amount to? In all of week one, I made (estimate by appFigures) $454.78.

Now don’t get me wrong, that’s not a bad sales figure or anything — if it was an average weekly sales figure. If trends persist, though, it looks like my average weekly sales figure will be somewhere between $40 and $70, if even that, which is hardly the goldmine I was expecting or hoping for.

Surprises

I ran across a few things that were a bit more than surprising during this first week. The first was that Windows users really don’t read. On day one, I received over 1,200 downloads of Bowtie Remote for Windows, an application whose sole purpose is to control Bowtie for iPhone. That would imply that each download of Bowtie Remote should be paired with a purchase of Bowtie for iPhone roughly 1:1. I was ready and willing to discount 30% of those downloads for stupidity, but not greater than 90%. As many of my friends (and Twitter followers) will tell you, I can now use this as anecdotal evidence as to why there are so many viruses on Windows: Windows users will download anything. In fairness, a couple of days after release, I changed the description on the Bowtie website to make it considerably clearer, and downloads have slowed (the rate is still considerably higher than the iPhone app download rate, however).

The other surprise was just how plain unreliable App Store reviews are. I’ve been very closely monitoring every review that gets written about Bowtie on the App Store: they range from one-star reviews calling the app “too limited to even be worth 0.79€” (translated roughly from Italian), and others alleging that my app is responsible for problems it simply couldn’t possibly cause; to glowing five-star reviews heralding Bowtie for iPhone as the Messiah of iPhone Apps. Personally, I don’t think either extreme is merited — I’m most fond of the four-star reviews, personally, many of which contain valuable feature suggestions (though I do appreciate two separate five-star reviews that say “this app solves a problem I didn’t realize I had;” that’s always the goal ). Anyway, I digress: I “grew up” in NewEgg culture, where the reviews aren’t just reliable, but they’re (in my opinion) some of the best indicators on the Internet of the quality of a tech product. On the App Store, that just doesn’t appear to be the case. It’ll certainly make me reconsider opting not to download the occasional two-star app that looks pretty cool.

What’s Next?

For starters, the app is really cool, but also very feature-light (mostly by design). People want more, and the biggest request is some sort of search feature that allows you to switch playlists or albums from your computer, rather than just skip forward/back and play/pause. That one’s already in the pipeline; it’s slated to be released with Bowtie 1.2 (Bowtie 1.1 will be out either today or tomorrow, with fixes for a number of bugs that cropped up during the first week) and Bowtie for iPhone 1.1. You’d be surprised how hard it is to design a good music chooser.

Also, as a part of my experiment, the only “advertising” I did was via my websites, my blog, and my Twitter: any third-party advertising that occurred (like a feature on Mashable) was on a completely voluntary basis, often unrequested by me. The fact is, that doesn’t generate enough exposure: I would have loved to believe that the App Store magically put your app out there for everyone to see, but it doesn’t appear to be the case. As soon as Bowtie/Bowtie for iPhone get a solid search capability, I think I’ll start pursuing some more conventional advertising routes.

Probably the most important thing I learned though (for next time) is that Bowtie for iPhone is still too niche. Certainly, the app isn’t quite as niche as Signals is, nor is it even as niche as TuneConnect is (my older, free app for Mac-to-Mac iTunes remote control, rather than Mac-to-iPhone like Bowtie). Regardless, not everyone wants to be able to control their iPhone’s music player from their computer; the app simply lacks the universal relevance that would cause it to become an “overnight app sensation.” If I ever really want to make money off of an iPhone app, it’ll have to be something considerably more appealing to a broader volume of users (or at least more entertaining).

Anyway, I’ll keep plugging away at making Bowtie for iPhone as awesome as possible, and we’ll see if it changes sales figures in either a positive or negative direction.

What about Bowtie 1.0? How’s that doing?

I’m so glad you asked! Downloads of Bowtie 1.0 have actually been going considerably better than those of Bowtie for iPhone. As of this writing, Bowtie 1.0 has been downloaded 14,158 times (7,497 by automatic update, 6,661 by manual download). That puts me only about 5,000 downloads short of the all-time download numbers for the first beta of Bowtie (though I still have quite aways to go before I catch up with beta 2). Either way, I’m fairly certain that this is the fastest I’ve ever hit this number of downloads with one of my apps, and I’m definitely very pleased with the results.

If you’re interested in keeping track of Bowtie downloads, you can view our public Mint. All of the files that make up the current version of Bowtie’s downloads (currently 1.0, will be 1.1 as soon as it’s released) can be found on the “Watched” tab of the “Files” pane.

Anyway, thanks to everyone who’s either downloaded Bowtie or purchased Bowtie for iPhone, and to everyone who’s been so supportive of this endeavor. I’ll continue to keep you all posted as things change. Until next time, enjoy Bowtie!

Note: this article is part of a series of articles on my real-world App Store experiment. The first one was App Power: An Experiment, and the second was App Power: The Submission.

Just moments ago, I revealed to the world — at long last — just what this super-secret iPhone app I’ve been developing is. What is it, you ask? Why, it’s Bowtie for iPhone, of course! And it’s coming out in tandem with the final release of Bowtie 1.0 this Saturday.

The app, which will be available on the App Store for just 99¢, will allow users of Bowtie to control the iPod application on their iPhone or iPod touch (or iPad ) from their desktop. Windows user? We’re releasing an app called Bowtie Remote for Windows, which gives you the same level of control (without the themes).

Once the app goes live, all that’s left to do is wait. I’ll post a summary article here as soon as I have some sales numbers. ’til next time!

When you initialize an object with its -init method (or equivalent), the default NSObject implementation initializes all instance variables to nil, as a convenience. However, whenever you declare a variable elsewhere, this auto-initialization does not occur: rather, like with any C variable, it creates a block of memory in the stack sizeof(id) big. If you don’t initialize that pointer with a value, it still points to that address in memory.

So let’s take a relatively common example:

// ... exciting code ...
if (myData)
	[myData release];

Assuming myData is an instance variable (and every other time you release it, you set it back to nil), this should go off without a hitch. If the value referred to by myData is a non-false-evaluating quantity, release it.

Note: this is usually superfluous, since it’s safe to call -release on nil — it’s safe to call anything on nil, it always returns nil. As long as you’re good about nil-ing out your instance variables after you release them, you don’t need to check if they’re non-nil first.

Now let’s modify the example slightly:

NSData *myData;
// ... exciting code ...
if (myData)
	[myData release];

In this snippet, myData is a local variable rather than an instance variable, and believe it or not, this will possibly cause an application to intermittently crash. The reason is that we didn’t initialize myData, which was assigned an address anyway. If we were to insert a few lines of code in between the variable declaration and the conditional, that space could become filled with something else. Something else that might not belong to you. And we all know what happens when you try to dispose of memory that doesn’t belong to you.

The correct way to write this would be:

NSData *myData = nil;
// ... exciting code ...
if (myData)
	[myData release];

It’s a simple fix, but it’s one that’s easy to forget, especially since it’s not a problem you need to worry about with auto-initialized instance variables.

This particular one caused me some massive headaches, because it was being called on the return trip of a Distributed Objects call, so the debugger wasn’t able to pinpoint exactly where the problem was occurring. And for that, NSLog (and selective commenting) is now, and always will be, your friend.

This part of my application has three potential entry points, and two “endgame” states; I broke up each “chunk” (many represent subroutines) onto a separate index card, marking entry routines with an arrow in the corner, and endgame routines with “#END#” at the bottom. Now, I just trace execution from each entry point with every possible environment permutation. If they all eventually hit an “#END#” card, my logic is sound. Don’t you love index cards?

Note: this article is part of a series of articles on my real-world App Store experiment. The first one was App Power: An Experiment.

So, a mere 14 days after I proposed my idea to enter into this real-world experiment, the application is done: today, it heads off to the App Store for approval. Barring any delays, it’s slated for release mid-February, with the formal announcement of exactly what it is coming a few days before.

A few days ago, I sent the application out to a select group of private beta testers to get some feedback, and it was generally pretty darn positive. Here are a few soundbites:

“woooooo – you’ve got a winner on your hands, Mr. P – I will gladly buy this app for everyone I know ” Elle Wong

“I am yet to experience any network lag or any bugs within the application. It responds well to furious clicking on the desktop client too. So far so brilliant!” Tim Davies

“Only this app can prevent forest fires!” Smokey Bear

Stay tuned for more updates!

Update (1/28/10): Just received word from Apple that the app has been approved for sale on the App Store! You’ll hear more from us on a release date (already scheduled in the App Store admin section) within the next couple of weeks.