Soonr is in the Top 10 in Apple Store!

The Apple application store is a wonderous thing. I remember the “old days” when you have to hire a marketing firm or do a lot of analysis to understand how your product was being received. Companies were created that charged hundreds of thousands of dollars to measure the effectiveness of an offering or a marketing campaign. The folks at Apple have solved a lot of very hard problems with the application store.

When initially introduced some complained that the 30% fee that Apple was charging was a bit much. Clearly these folks didn’t understand what it takes to create:

• A seamless marketplace
• Easy installation experience on a handset
• Commerce engine
• Alleviate credit responsibilities
• Creation of a website to sell an application

What Apple has done is truly remarkable. Oh yeah, and our application is free. So we pay Apple 30% of $0.00.

Hundreds of thousands of dollars of value for free. I love the internet and I love the Apple application store.

Thanks to all the users supporting us by trying out Soonr! Let’s see how far we can move up the scale!

SoonR has been used on more than 600 different handsets from over 160 countries around the world. With a vast array of hardware, OS, and carrier configurations, how do we create software the will run on all those phones and then adequately test it? The answer is, we don’t. We don’t require software on the phone. By leveraging the built in browsers and data connections, we can adapt the web pages to the kind of phone a user owns.

When a phone browser makes a request, the header code contains hints about the manufacturer, the browser, and sometimes the model of the phone. Our servers roll up that information and we get charts like the one below.

If you take snapshot, you can determine that we see more Nokia phones than anything else. As it turns out, each manufacturer of phones shares a lot of common characteristics, especially amongst their particular product lines. Some of the things we find are common LCD screen sizes, memory, fonts, and navigation schema. We can quickly map the requesting handset to the most common characteristics for that class of phone. For our example, let’s take a look at how you can adapt a PowerPoint for any variety of phones. The dependency here is screen size and color depth.

When you choose to make a PowerPoint available for remote access, the SoonR desktop agent will begin to render versions of the document in 3 sizes. One is for phones with small screens (like a RazR), one for phones with medium screens (like a Smartphone), and one for nice big screens (like an iPhone). These rendering end up being about 8K, 20K, and 60K respectively. Each of these renderings are made available very quickly and put into your SoonR account in the datacenter. When a user logs in with their phone after sharing a 4MB PowerPoint, they are often shocked that they can see the slides within seconds! The secret is that they are actually looking at a cached version of the slide. SoonR servers send the optimized images to their phone and the user experience is preserved. If you have a phone with a small screen, it’s only moving about 8K bytes! So the result is that it appears very fast. The user is happy. The same principle is applied to other aspects of the phone such as font size and JavaScript support, etc. This is the same principle that Google uses for searches. You can’t rerun a search of the Internet and return a result in less than half a second each time some types a query!

When we come across a phone that doesn’t respond well to the “class” definition, we give users the option to override the settings and store it. When we see a lot of people with the same phones changing the same settings, we know to establish a new class of phone. Those of you who are particularly astute have probably realized that we are learning a lot from our user’s experience. This is the beauty of a Web 2.0 web based beta service. We can release a version and in very short order learn from the collective user base. They help us make a better service and we get more happy users. It’s a virtuous circle and it also ensures we get great testing coverage on new releases.

Isn’t Native Software Better?
Naysayers will tell you that native software is always better. You have direct access to the OS and you can provide more fancy animations and interactivity, generally a better UI. That used to be true in the past, but that’s rapdily changing as handsets get more powerful, bandwidth improves, and mobile Ajax is supported in phone browsers.

One of the seldom understood requirements of native software that carriers introduce is “signing”. Basically an application cannot run without permission on a phone unless it has been approved by the carrier and “signed”. Sounds easy huh? Did you know that signing is a process that takes weeks to accomplish and thousands of dollars to submit to the signing process? Did you know that you have to sign for each phone and then re-sign with each release of new software? Not only that, handset manufacturers roll out new handsets lines about every 6 months. Do the math, it’s impossible to keep up. This is why most companies who create phone software end up supporting certain platforms (J2ME, Symbian, Java, WM, etc.) and can’t offer their apps on all phones. It would be very difficult to be compatible on over 600 handsets if we had to deal with this. Here’s a comment from a blog about this challenge on Mobile Development from Simon Judge.

Ah, so what can we do to leverage the cool features of each phone? I mean if you know the phone type, browser, etc. you can create all kinds of great UI eye candy right? If only it were that simple.

Next up… Doing fancy UI things on fancy handsets (i.e. iPhones and Ajax).