Hidden Challenges of Developing a Mobile Service Part 2 – “How do you support all those handsets?”
This is part 2 of my little series of the Hidden Challenges of Developing a mobile service. We’ll take a look at what people use to access their desktops, primarily mobile devices like cell phones. We also see the mobile internet devices and surprisingly a lot of regular computers! In fact, over half of SoonR uses also tap into their remote PC and Macs using another computer. But I digress…
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. Here’s a snapshot of a little slice of time and the kinds of handsets people use with our service.
You can deterime 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).