Palm Pre, FastFigures and powerOne

I have had a steady drip of requests since the Palm Pre launched for a webOS version of our software. I wanted to take the opportunity to talk about the platform, what I think Palm is doing right and wrong, and relate that to our own software products FastFigures and powerOne.

First, let me say that I like what Palm is doing with the Pre from a developer perspective except one major flaw. A year ago I wrote a post on the recipe for beating Apple and highlighted three things that the company needed to do. Palm has nailed two of the three:

  1. Build a beautiful, touchscreen device.
  2. Make it synchronize with web-based applications.
  3. Focus on offline use of web-based applications.

Palm is flubbing #3.

Palm has built their platform so that all applications are written in CSS (the page style), HTML (the content) and Javascript (the interactivity), the core languages of the web. But these three languages are intended to handle the user interface, or client, side of the equation.

What’s missing — and what Palm insists it doesn’t need — is the underlying technology that handles the business-side of web applications. Developers use a multitude of server-side technologies to do this, including Ruby on Rails, PHP, .net, and Python. Most mobile platforms use either C or Java to handle the business logic.

Palm insists it doesn’t need anything. And this is a major mistake.

Our software requires the business language to run the engine that performs all the calculations. Javascript won’t do primarily because of security and speed issues. In addition, insisting on using Javascript for business logic flies in the face of everything I learned about how to do web development.

Palm’s perspective is that applications that need business logic should interface with the web, such as Google’s search engine. Except an application like ours works best when the calculation is resident on the device, not because the calculations are better but because our customers don’t trust the Internet connection with their devices. There are just too many holes.

So what do our customers do when it comes to the Pre? They can either use the Classic emulator, which we don’t officially support but seems to run our software without a problem according to customers who have tried it, or use the web-based version of FastFigures at http://www.fastfigures.com/mobile. Either way, if you want our products on Pre, please drop us an email so we know.

And hopefully in the future, Palm will realize their mistake and give us a business logic language to work with. For now, though, I won’t hold my breath.

Rating Mobile Platforms for Development

So I need to make a business decision about which platforms to develop for, and that decision almost always comes to how many potential customers versus the cost to develop and distribute for the platform. I’ve broken each down based on recent events.

Potential Customers

The first step is to see what the potential revenue is based on the number of people buying a platform and likely to buy one in the future. The numbers of unit sales are readily available. Of course, this doesn’t actually tell you the number of users since those who stick with a platform tend to buy into each subsequent generation of products. In the smartphone space, this number is easy since most users stick with their current device for the duration of their contract. Of course we never really know how many people are new and how many people are buying the next generation.

Given all this, it is just the baseline. If there aren’t enough units sold and those customers don’t seem to be the kinds of customers that would want to buy my products, then I’m not going to develop for it. The real decision point comes once the cost components are analyzed. How do I view the major platforms (from within North America)?

  1. Hot: Apple iPhone/iPod Touch, RIM BlackBerry
  2. Simmering: Microsoft Windows Mobile
  3. Cool: Nokia Symbian, Google Android

Surprised? Remember, I am looking at units sold and the kinds of users being attracted to the platforms (relative interest in my products). Symbian devices have not made much of a dent here in North America and Android is too new. An International discussion would be completely different. But I believe if I can’t make money in my home country then I can’t make it overseas, particularly given the added costs of product localization and foreign distribution. As for Microsoft, they always seem to be there but that’s it. People buy their products but no one seems to love them. It’s a real shame.

Distribution

The next major decision point is distribution. Generally, I only care about distribution in terms of costs to reach customers. I don’t really see distribution as a means of getting to the customer — that’s what marketing is for. Instead, distribution is all about product delivery. How easy is it for people to find my products once they want to buy them? How easy is it to purchase, download and install? And how much is it going to cost me as the company to do it?

This is where the wheels have started to fall off the bus in the mobile business over the past 6 years. Costs have been through the roof (67% of product price in some instances) and it hasn’t eliminated any of my install and reinstall issues.

And then comes Apple. Charging 30% and eliminating all install and reinstall issues in the process, we finally have a channel of interest. On top of that, Apple is doing a ton to raise the interest and awareness of third-party applications, a huge added bonus.

And Apple started an avalanche: Google and now RIM have announced their own stores, and Microsoft is rumored to have one in the works. All have roughly the same terms (20-30% of retail price) and the same promise.

So how do the major platforms shake out?

  1. Hot: Apple, Google
  2. Simmering: RIM
  3. Cool: Nokia, Microsoft

Until those rumors play out for Microsoft and Nokia, they will stay on the backburner when it comes to distribution, at least. As for RIM, the devil is in the details. Some we know (20% cost to developers) but many more we don’t (how will partners be treated, will it be on the devices, will anyone care).

Development

This is where mobile computing development gets really hard. Every platform takes its own custom development. Fine, they all are either C-based or Java-based, but every user interface is different. The costs to develop for a subsequent platform are staggering, particularly when the size of smartphone software development companies are taken into consideration.

I have been hearing a lot of noise in dev communities about Android lately. These old-time developers, who developed in C on Palm and Windows Mobile, are now faced with moving their applications to Java on RIM and Android. (iPhone and Nokia are C-based.) Even if all devices used only Java or C, it would still be a daunting task to redevelop the user interface layer of the application for every device.

The other big announcement in the previous weeks is RIM’s support for Google Gears. Google Gears allows a web site to be used even if there is no web connection. So as a developer, we can hypothetically write a web-based application and then run it locally (without an Internet connection) on supported platforms. With RIM’s announcement, that means that RIM, Android, Windows Mobile, Windows, Mac and Linux systems all support Google Gears now.

Hot, simmering and cool? I can’t rate them. Every platform takes custom development still. At some point, hypothetically, we could support iPhone native along with BlackBerry, Android, and Windows Mobile with Gears, but not today. Today, the other factors have to be considered first.

Conclusion

If I’m a developer today, I am looking very hard at iPhone (as we are). They have the distribution channel and unit sales to be exciting. If I came from the Palm world (as we did), I also have some code that can translate over. It’s still a custom development job, but at least not a complete one depending on how much back-end programming has to be done.

My next decision is harder: do I leverage my C code base and develop for Microsoft’s multiple variations of Windows Mobile or do I jump to the hotter platform with better distribution promise in RIM? And my answer to that one is: follow your customers.

Is Google Gears A Mobile Development Game-Changer?

Google Gears could be a major advancement for third-party, mobile developers.

RIM announced last week support for Google Gears on future devices, Windows Mobile devices already support it, and I’m sure Android devices are not far behind.

Why’s that such a big deal? Because the promise of writing once (for the web) and running everywhere is actually coming to fruition. And for developers, this is a big deal. One of the major cost factors in mobile software development is picking which platforms to write for. If we no longer have to make that decision and we can write for all platforms without having to re-write for all platforms, we will finally be freed to make a profit. What a novel idea!

On top of that, as I noted in my article regarding how other mobile companies can beat Apple, I spoke about how a company that enables web developers to write local applications easily for their device will have the inside track. Is someone at RIM listening? I hope so because Apple will be better for the competition.