Oh, did I say tremendous? I meant really, really confusing. 

Fractured Branding

The first thing that confused me about Google Music was that, when I clicked on a link in a tweet to visit Coldplay’s Google Music page, the resulting page didn’t have the words “Google Music” on it anywhere. Like, anywhere. It’s 100% Android Market-branded, which I found strange, because I was fairly certain that the Android Market was only for, ya’ know, Android things, like apps. It took a little digging to discover that, oh yes, they are in fact part of the same product, the branding is just divided between the two. Interesting.

So then I decided, “alright, let’s be fair, I can’t criticize this until I create an account and try it out.” The first thing it had me do to get my music into Google Music was download a Google-authored Java app called “Music Manager.” OK, that’s fair, downloading an app makes sense, but why is it called “Music Manager”? Why not, say, “Google Music.app”? Or you know, something to differentiate it from other music management apps in my list of applications.

Google Music, Android Market, Music Manager. Not the most confusing, I suppose, but that’s still three “brands” to keep straight, in a sense. The most confusing part about it is the Android Market, because a) I don’t own any Android devices, and b) it’s an established brand that’s used for something entirely separate, so I don’t understand why I should have to leave the Google Music “umbrella” just to buy more music. Yes Google, I get that you want to continue to solidify the Android Market brand, but by doing that you’re only degrading the experience of your other products. Look at the Apple product ecosystem: yes, technically it’s the same backend that powers all content you purchase from Apple, but it’s called the iTunes Store for music, movies, and TV shows; the App Store for apps; the iBookstore for books; and so on. Each type of content gets its own dedicated store, which provides a better, more deeply-integrated experience at the small cost of the word “iTunes” not being plastered everywhere. Newsflash: Android is popular. You don’t need to shove its name down our throats.

Fractured Experience

Alright, so you use Google Music to play and organize your music, Music Manager to upload it, and Android Market to buy new music. Think I’ve got that under control. Let’s try it out.

I started by uploading a selection of music from my Mac into the Google Music system using Music Manager. That at least made it clear why Music Manager isn’t just called Google Music: the app itself does nothing but upload music. Of course, that makes sense — Google could make a native app for music playback, but that just isn’t their thing. It’s all about the cloud and whatnot. Fair enough, stick to what you like.

Thus, I then headed over to Safari to listen to some of the music I’d uploaded. Nothing life-changing, but it’s an entirely pleasant convenience, I love the idea of being able to access my music library from anywhere. I supposed “it’s only proper, then, that I christen my library with a bit of new music to celebrate the occasion,” so I clicked on the “Shop” button and was redirected to the Android Market.

I loaded up my cart with a few songs, and clicked “Buy.” Oh. I have to sign-in again? And I don’t mean just confirm my password like in iTunes, I mean my Android Market and Google Music accounts can actually be separate. Well then, at least the branding accurately reflects the experience.

So now that I’m done with all that, I can probably head over to Google Music in Safari on my iPhone to listen to music. Oh, I can’t? Mobile devices get a native app? OK, that’s reasonable. Oh, but there’s no iOS app available yet? OK, then. Really not doing a great job at taking on iTunes then, are we? Or Spotify, for that matter.

Necessary Digression: The Cloud

It’s no secret that I think that Google gets “the cloud” wrong, and it just boggles my mind because there are probably very few other companies in the world with the same potential to get it unreservedly perfect.

Google is a proponent — nay, the veritable poster child — for the idea that someday in the future, everyone’s day-to-day computing experience will take place inside a web browser. They believe that people don’t want or need native apps, and that the web is more than good enough. They envision a world where people open Google Chrome at the start of the day, and never touch another application, using web apps for all of their computing needs. And they’re so very wrong.

In my opinion, Google makes the mistake of confusing the technologies with the interaction model. Web technologies like HTML5 are phenomenal, and the idea of leveraging the cloud to allow users to have access to their content wherever they are is a solid, and I dare say inevitable, vision. But just because we access websites in the web browser doesn’t mean that the web browser is the only place we can take advantage of web technologies.

And what is a web browser, really? It’s a native app. A very generic, very flexible native app. If you look at it as Google will have you believe, it’s kind of a meta-app in a way, a platform for running other apps. But my question to that is, why? Yes, it’s entirely possible, but since when has an added layer of abstraction between you and a particular service been a good thing? Why would you voluntarily take a loan from a middle-man? Why would you buy food being resold through a third-party when you have the option of buying it directly from the source?

Web apps are a fantastic thing of convenience: they’re a great way to provide a service to a large number of users without having to worry much about what kind of device they may be using to access your product. That’s the only real problem they’re called on to solve, though — web apps are not, despite popular belief, the panacea to having your documents with you wherever you go. Except for convenience (by which I mean convenience of the software engineers, which is the worst kind of convenience to indulge), there is no reason at all that makes web apps more suited to the “roaming user” than native apps. In my opinion, iCloud is a prime example: each of iCloud’s supported services provides a web app for user convenience, but the primary method of interacting with iCloud services is through natives apps built-in to devices, like Mail, iCal, Address Book, and so on. iCloud treats the cloud as an information conduit, not a workspace. It leverages the cloud to provide an enhanced user experience, not to pursue an ideological agenda, and not to solve a problem that no one actually has.

Never build a solution until you actually understand the problem. No one’s asking for there to be a web app to replace all of their native apps, they’re asking for a way to use their existing apps no matter where they may happen to be, without having to save their data to a flash drive (or equivalent). Web apps are an answer to that problem, but they’re not the only one, and they’re sure as hell not the best one.

On Integration

Perhaps the biggest problem with Google’s attitude toward the cloud is that it very much eschews the idea of platform integration. I know I’m a fanboy, but I’d like to submit, for your approval, the case study of Apple as a champion of integration.

When you’re listening to music in iTunes — be it on your Mac, or your iPhone, or anything else really — you’re afforded a lot of conveniences. You can use the media keys on your keyboard to pause and skip tracks. You can use AirPlay to play your music through other speakers. You can sync with your iPhone or iPod, even wirelessly.

You can’t do any of those things with a web app. Some would argue that the solution is to add APIs to the web browser that enable that interaction, and to a degree that’s fine, but that’s a very dangerous road that leads to nothing but heartache. Bloating the web browser with the technological equivalent of pork-barrel legislation does the ecosystem more harm than good over time. The solution is not to pervert the web browser into doing things it was never intended to do, but rather to start with a web browser and trim down the features you don’t need (read: practically all of them), and then build your own native client from there. When software and hardware are designed to work together, harmony ensues. It’s why the Mac, and the iPhone, and a vast majority of Apple products are so great, and why an app designed to run inside another app can never quite obtain the same level of creature comfort.

Conclusion

Let me be perfectly clear: with regards to Google Music, I’m nitpicking. Hardcore. But that’s the point.

It’s not like Google Music is a bad offering, it’s absolutely not. It’s a pretty darn cool service. It’s not even that the drawbacks are big enough to make me not want to use it, they pretty much all boil down to instances of “fair enough” or “that mostly makes sense” or “sure, I can live with that.” But people don’t say those things about great products.

When I say “Google is doomed,” I do not mean they are doomed to fail — that would just be silly. No, Google will always excel at their bread-and-butter, their search, their advertising, even Gmail. Even their less intoxicating products like Google Docs and now Google Music are pretty darn good. But Google is doomed: they’re doomed to mediocrity, to produce one “pretty darn good” product after another, and never achieve anything great from anything more than a purely academic standpoint. And it’s all because they just don’t get user experience.

It was last summer on a bright, sunny day in Cupertino (aren’t they all?). I was walking back from Caffé Macs with a coworker, and we were discussing the changes we wanted to make to some mock-ups we had been working on earlier in the week. We got to the door, where, as is customary at Apple, we reached for our badges to badge in. But before we could, the man in the black long-sleeve shirt and jeans walking ahead of us turned around, smiled, and held the door open for us.

The demanding head-honcho himself, the stickler for details that some simply called “feisty,” the man with whom you supposedly never wanted to find yourself on an elevator, just turned, smiled, and held the door open for two interns.

That’s what I’ll always remember about Steve.

The final product is simple: you register for the application, and whenever new grades are posted to your account, you get a text message and an email. You can even reply to the text message, and the app will call you and read your grades to you (for privacy reasons, we don’t put your grades in the text message). In spite of (or perhaps, because of) its simplicity, the architecture behind the system is — in my oh so humble opinion — a work of genius.

We had two major goals when implementing the system that we knew couldn’t be sacrificed: Fort Knox-level security, and a distributed, scalable workflow. For those interested in learning more about the internals, follow along with the code on GitHub.

The Workflow

Brown uses Banner for its grades, and as anyone who’s ever used Banner can readily tell you, it’s… slow. And very broken, in many ways. For that reason, among others, we decided early on that having a single server querying Banner for grade information wouldn’t suffice, especially since we wanted to give Banner a little breathing room between requests from the same IP address so as not to frighten it. We decided, therefore, to use a distributed architecture that looks a little bit like this:

How it works in a nutshell: a user from the Interwebz visits our website to sign up. When they do, the web server makes a short request to Banner to verify that they entered a valid username and password, then stores their credentials and contact information in the database. It then kicks our internal manager application to tell it that a new user has joined, and should be inserted at the front of the worker queue. Finally, it displays a “Congratulations” message to the user, and they’ve been registered.

The manager application, meanwhile, is where the action really happens. At server start-up, it creates a queue of all of the users registered for our application, sorted from least- to most-recently-updated, which is automatically restacked every hour (users will also be inserted on an ad-hoc basis immediately after sign-up). Worker nodes, running on separate machines (we’re currently utilizing a separate web server, a Mac Pro, and a laptop on the side), then ask the manager for a new user every 10 seconds or so. If there are still any users pending in the queue, the server peels them off, and hands the username and password to the worker.

It’s then the job of that individual worker to talk to Banner, check if there are any new grades published, and alert the manager of the results. The manager then updates the database, and if there are new grades, emails the user with a grade report, and makes a call to the fantastic Twilio API to send the user a text message. If at any point a registered user texts something beginning with “g” to the assigned phone number, Twilio will inform the manager, and the manager will then instruct Twilio to call the user and read them their grades.

The beauty of this architecture is that any number of worker nodes can be running on any number of machines in unison, all pulling users from the queue. With a single worker, we can handle a load of about 120 users and still provide hourly updates to all of them without ruffling Banner’s feathers. With just 5 workers, some of which can be running on the same machines, we can handle up to 600 users, and it scales easily from there. Five lightweight virtual machines each running 10 worker nodes could theoretically gather grades for the entire Brown undergraduate population once each hour. With VMware Fusion or similar, one physical machine could run the entire operation.

Making it Secure

We knew that if we wanted to legitimately ask our users to give us their Banner login information, we needed to make the system secure. Like, really secure. And really secure we made it. Let’s walk through the workflow again, but this time with security details.

When someone visits our website to sign-up, they’re switched over to SSL right away. At the advice of our friendly security guru and cohort Neal Poole, we sucked it up and spent the money for a real, honest-to-goodness SSL certificate from GeoTrust, not just a cheap-o self-signed one. The benefits: a little green lock icon in Chrome (and a blue badge in Firefox, and a grey lock in the top-right corner of Safari). Win.

Beyond the added user comfort, this ensures that all traffic between the user and our front-facing web server is encrypted end to end, which means it’s very, very difficult for anyone to eavesdrop on the connection. AES-256-CBC with a 2048-bit key. Ye-ah. We use the same SSL encryption scheme when the worker nodes phone in to the manager application, and also use SSL when communicating with Banner and Twilio.

Once a user’s username and password have been validated during the registration process, the password is encrypted using the server’s private key before being stored in the database. In order for a worker node to be able to use the credentials it receives from the server, it must be manually bestowed with the server’s public key. This also means that we (as administrators) can look at the database, and never actually see anyone’s password in plain text.

For added security, in order for a worker node to even be allowed to request credentials from the manager, it must identify itself using a mechanism very similar to SSH public key authentication. Whenever we setup a new worker node, we generate a public/private key pair specifically for that worker. We then store a copy of the worker’s public key on the manager server, and associate it with the worker’s unique ID number. Each request from the worker to the server must be signed using the worker’s private key, and is verified by the manager before being processed. The requests and signatures are also timestamped, which helps to prevent replay attacks (which would be useless anyway, because the credentials are encrypted, and therefore useless to anyone but a valid worker).

So let’s sum it up: public/private key encryption on the passwords, public/private key signing and authentication with each worker, replay attack resistance, and it’s all done over an encrypted SSL pipeline. Not to mention a randomized password on our database, which itself is behind a firewall, and not listening on any Internet-facing interfaces.

Needless to say, we put a lot of work into the security.

Sidebar: Caller ID Spoofing

Since the application has the capability of communicating via text message and phone call, we also had to take a number of other security issues into account. For one, the “phone on the desk” scenario. We decided not to put your grades in the notification text message itself, because we didn’t want a situation where your phone goes off across the room, your friend leans over to look, and just says “man, sorry about chemistry dude.”

Thus, in order to get your grades by phone, you can have the system read them to you, privately. That does raise the issue of caller ID spoofing, however.

One of the original models we explored was one in which you could simply call the phone number dedicated to the application, and it would fetch and read your grades to you. However, this would be vulnerable to caller ID spoofing: if I knew you had an account on our app, I could spoof your caller ID, and have your grades read to me.

We solved the problem by only providing meaningful information in outgoing communications. When you text “g” to the application, it will call you, and read you your grades. This is immune to caller ID spoofing: let’s say I’m being nefarious, and I spoof Josiah Carberry‘s caller ID on a text to the application. The application will call that number back (if they’re a registered user) and read the grades over the phone, as expected. The caveat is that that call — regardless of the origin of the text — will go to Josiah Carberry, because it’s his phone number that made the request! Foiled again, caller ID spoofers.

What We Won’t Do

I feel like this is an appropriate time to make a statement about the future direction of this project, since people have made a number of suggestions already: we will not, under any circumstances, at any time adapt the tool to allow the pushing of information to Banner. That means that we will not turn this into an automated course registration system. This tool is a convenience, and nothing more; giving it more capabilities could give its users a competitive advantage over other students, which is not only against Brown’s Acceptable Use Policy, but very much unethical.

We also at this time do not have any intentions of deploying this tool for other schools that use Banner. Our code is, however, open source, so if someone at another school was interested, they could use it for inspiration. It will certainly need some modification, though: our source is not published for the purpose of use by others, but rather as an act of transparency to make our users even more comfortable.

Conclusion

As side projects go, this was a fun one. And as Xzibit would say:

To this day, I have yet to teach a single person how to make a website. So I started trying to figure out why.

This evening, a conversation over a wonderful dinner with my friends Meagan and Hilary inspired me to start reexamining my desire to share knowledge. When I talk about software and computer-y goodness, I get excited, and I want other people to get excited about it, too. But it’s not just that I want other people to become nerds like me, that’s not what it’s about.

Any science, when done well, becomes an art, a thing of beauty. That’s how I see technology, and I don’t believe it’s just because there’s something terribly wrong with my mind (which is a point that in and of itself is open to debate). I believe that beauty isn’t just in the eye of the beholder: everything has some form of inherent beauty, and for some people, it’s just more challenging to find it in some things than others.

I, for instance, happen to think that most German-designed sports cars (most Mercedes models excluded) are exceptionally beautiful — not because of what they represent, or how they perform (which is exceptional in its own right), but because some individual or group of individuals put a part of themselves into each design. When I see a Cayman R drive by (which, granted, is rare ), I see love: somewhere, some industrial designer put more thought into every contour of that car than you or I could possibly imagine, and they made damn sure that by their own personal standards, it’s perfect. At the end of the day, it doesn’t matter what Porsche thinks, because that designer left the workshop satisfied.

And it occurs to me that that’s where true beauty comes from: humanity. Beauty in any contrived object comes from its human attributes, or rather, what some live person put into it to bring it to its present form. Would anyone be moved by the Starry Night paintings if ol’ Vinny had felt like he was just slapping oily crap onto a canvas? Just as van Gogh infused his paintings with emotion, you can be sure that the design team behind the Cayman did the same.

John Maeda (the president of RISD) speaks about technology becoming progressively more human, and that the job of computers should not be to alienate us from our workflow, but rather embrace our mindset, and adapt to our needs. To me, technology is human in a very real way, and this is where its beauty lies. I put a piece of myself into every piece of software I write, and that’s what I want to show people. To self-servingly quote myself in an IM conversation earlier this evening with my friend Sarah:

I want to take a group of people who either don’t know much, or might be a little frightened of technology, or maybe know how to do things but not why they work that way, and show them something beautiful about my job, in a unique way.

But I digress. More than a little. (See what I did there? I put the real subject of my blog post after my self-indulgent rambling, so you’d have to read it to get to the good stuff; kind of like putting the day’s weather report after the story about the cat beauty pageant on the news).

The Experiment

It dawned on me that the biggest impediment to my ill-fated agreements with others to teach them how to make a website is time. People barely have enough time to do what they need to do in their lives, and “I want to learn how to make a website” gets relegated to the low priority scale of the life-calendar, along with “someday, I’ll learn how to play the guitar” and “I’ve always wanted to visit Iceland” (to all you guitar-playing world travelers out there, we salute you). Often, the problem is more perceived commitment than anything else. So I have an idea, and I call it The Blurb Experiment.

The idea is simple: teach something using daily “blurb” lessons, each one not more than a sentence or two, combined with a link to a live example, or more resources for people who want to learn the subject more in-depth. Each lesson should be no more complex than a Facebook status update (we already read dozens of them on a daily basis, what’s one more?) — in fact, I’m debating actually using Facebook statuses as the format for the course. The goal is that after reading a sufficient number of these status updates, someone will have learned something.

The concept comes from comic strips, in fact. I make time to read Cyanide & Happiness every day, because it only takes a few seconds, and it’s fantastically irreverent, and usually makes me smile, or think, or both. It’s low-pressure, and easy to catch up on if I miss a day or two. I figure, why couldn’t someone learn something that way?

The challenge, of course, is making the blurbs (as I’m calling them) engaging and focused enough to keep people’s interest. For that reason, I’ve decided not to start with web development, but rather do a test run of the format with a course I’ve been kicking around in my head for a year or two now: the thought process an interaction designer goes through when making an app, or in other words, the steps someone like myself takes to psychoanalyze a user I’ve never met, and probably never will. It’s low-pressure (because the reader doesn’t have to do anything except read), certainly entertaining, and just might change the way you use your computer (if you know what I’m thinking when I make a program, you’ll be able to figure out how to use it that much easier).

I’m thinking I’m going to get started on this in a week or two. We’ll see how the format works, and if it’s successful, I might just try a Blurb-based Web Development course.

If that’s not the tune you started humming when you read the title of this blog post, then either you’re out of touch with your rock ‘n roll legends, or you’re far more magnanimous than the majority of the Internet-using, gasoline-consuming, taxpaying public.

If you’re a web developer, or an even slightly more than decently competent computer user, chances are you’ve grown to hate Internet Explorer; if you’ve been following current events even a little, it’s equally likely that you’ve developed a healthy dislike for oil giant BP (and by healthy, I mean anything ranging from passing disapproval to standing on a street corner with a sandwich sign proclaiming them as the devil).

I wouldn’t dare suggest that a major multi-billion-dollar corporation is in need of our sympathy. I would, however, argue that a general lack of understanding of a situation can result in some vilification that just simply isn’t deserved. Let me explain.

The other day I was having a conversation with a few of my coworkers at [redacted]. The subject of web development came up, and as graphic designers and web developers on lunch break, the conversation eventually rolled around to the inevitable lambasting of Internet Explorer, the “scourge of the Internet.” If you’ve never taken part in one of these conversations, let me tell you, they get vicious enough to make a 19th century sailor uncomfortable. Usually I have no problem taking part in a little good natured IE bashing, but this time, I played devil’s advocate. The following is a glorified version of what happened that makes me look like a hero.

“You know,” I said to the crowd of nerds and non-nerds alike gathered around me, “I disagree. We’re being entirely unfair to the Internet Explorer team and its accomplishments.”

General laughter ensued, but my face stayed serious.

“I’m not kidding, guys — have you ever stopped to think about the enormous challenges that that group of engineers has had to deal with?” The table grew quiet for a moment. “That’s what I thought. You know, when we use our shiny WebKit-based browsers like Safari and Chrome, it seems pretty easy to make fun of Internet Explorer for how far behind it is when it comes to web standards. The fact is, though, Safari and Firefox and all of the browsers we celebrate were introduced with phenomenal standards support from day 1. When Internet Explorer was introduced, the web was still a toddler.”

A kind of inquisitive tension hung in the air, so I decided to continue, a bit more boldly. “And I know it’s hard for us to admit, but Internet Explorer? Yeah, they still have greater than 50% marketshare by most estimates. That’s a lot of people, and honestly, most of them don’t give a flying fadoodle about web standards; they care about being able to visit the websites they want to visit without any hassles.”

“Safari, and Chrome, and Firefox, and Opera — they have the freedom to push web standards because honestly, their target audience is both more technologically savvy, and much smaller, than Internet Explorer’s. Internet Explorer has to cater to the lowest common denominator, both in terms of users, and in terms of websites that were specifically designed to rely on Internet Explorer’s ‘looseness’ with the standards.”

“Go download the current preview of Internet Explorer 9, and visit an HTML5-heavy website. Is it perfect? Absolutely not. But is it awful? No, it isn’t, and that’s more than you can say for IE 6, or 7, or even 8. In fact, there are some areas where IE 9 surpasses even Safari 5 in standards support. The team has been working obscenely hard, and has been fully transparent about it the entire time. It’s true, there was a time in Microsoft’s past when they didn’t care one iota about web standards, but that time is long gone. The fact that they’ve been able to make such a giant leap forward in modern web standards support, combatting 15 years of old code and negative philosophy, and all with minimal breakage to existing sites — baggage that neither Safari nor Firefox ever had to deal with — is nothing short of astounding. I have nothing but the utmost respect for the Internet Explorer team, and they don’t deserve our bitching.”

Glorified as it may be, I actually did say those last two lines, and call me a sappy nerd, but I said it on the verge of tears. The thing that we forget in all this mess is that behind every corporate façade, there are real people — and not just real people, but real people who actually really do care about their work. Just as I put a part of myself into Bowtie and the other projects I work on, there is love in Internet Explorer, and I’m sure lots of blood, sweat, and tears to go with it. It’s not something people stop to think about, but I don’t believe it’s a perspective that should be ignored.

And that brings us to BP. Earlier this evening, I was talking with one of my roommates about the oil spill. I made a comment that I thought the amount of time it had taken BP to simply stop the leakage of oil from the pipeline was completely unacceptable. “Well…” replied my business major roommate, “for starters, it’s a mile underwater.” As he continued to speak, another side to things became clearer. I am not an expert on oil disaster recovery, nor is most of the world’s population; the people working on the project for BP? Well, they are. As much as we may not like to accept that big business is actually giving a damn, the fact is, it’s entirely possible that the problem is just not as simple as we’d like to believe: many of the challenges BP is facing in containing the issue live in uncharted territory. There are a lot of firsts going on here.

Does that make the fact that the oil spill occurred in the first place any more excusable? Not in the least. There are things that every party involved did wrong, and it’s quite probable that people higher up in the company knew that something like this could and would eventually happen. But just because management and corporate history is full of “business as usual” for an oil company, that doesn’t mean that the people actually tasked with fixing the problem, the ones facing the problems head on, don’t care. It’s probably an unfair analogy to compare the Internet Explorer team to the disaster response team at BP (though I’m doing it anyway), but you can’t deny the similarities: what the teams have been able to accomplish to this point may seem like a classic case of too little too late, but when taken in the context of the challenges that needed to be surmounted, the progress really has been truly impressive.

I’ve said it before and I’ll say it again, I’m not an expert on oil disaster recovery. It’s overly audacious to call myself a web standards expert, too, but I’d dare say I qualify in most senses as a web technologies professional, and recent developments on the Internet Explorer team have shown me that, in business like in life in general, there are two sides to every story. And that’s enough to make me think twice about how BP — the people at BP, not the faceless corporation — is handling the spill.

So the next time you turn to vilify a corporation for its misdeeds, have some courtesy, have some sympathy, and some taste. The fact is, you may not understand the problem the way they understand the problem, and in all likelihood, the real people working on fixing the problem care about it just as much as you do.

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!