Pre-lude

I’ve been spending a while catching up on the news of the Palm Pre (not just the video they posted but also the tidbits that have surfaced so far), and since I am most likely six months (or, most likely, a year) away from trying one myself, I’ve boiled it all down to five things worth keeping in mind until then.

For the sake of argument, I won’t get into inane stuff like the removable battery, standard Micro-USB connection, physical keyboard, etc., because, quite frankly, all of them are pretty much non-issues – they simply come with the territory, like all hardware features do for a developer.

Software-wise, however, there is quite a bit to be said.

1. The UI Metaphor Is Better

For a given value of better, of course, which will vary according to the reader.

This may come as a shocker to those who (wrongly) equate this site as being pro-iPhone (or who missed my phone of the year pick for 2008), but I think that the Pre’s UI metaphor is better than the iPhone’s.

It’s not just about the (very well thought out) ability to multi-task and juggle contexts or tasks as if they were a deck of cards. It’s little things like the non-obtrusive notifications, the way they compress free time on the calendar, etc.

But from a strict interaction and usability perspective, they had me when they demoed leaving a draft e-mail message to refer to information on another – something you can’t do on the iPhone at all (or as easily on the Blackberry, even with its one-key task switching).

Because, you see, the trouble is not just that you’re doing things in a mobile context (and hence more likely to accept some sort of compromise in terms of functionality) – it’s that you are quite likely to be trying to achieve more than one task at once, even if not exactly at the same time.

So yes, cut-and-paste and moving data between apps is great. But what I really liked was the apparent ability to put stuff on hold (by leaving the “deck” open) and getting back to the apps later. Like Mobile Safari does with tabs today¹, but for any app.

It’s an entirely different paradigm as far as applications are concerned. Actually, the whole thing kind of reminds me of the old days on the Mac, when Switcher (and then “MultiFinder”:Wikipedia:MultiFinder) came along – except that now it’s all about mobile and touch screens.

In a nutshell, the card metaphor is neat, elegant, and something I would have expected Apple to come up with².

Much is sure to be written regarding the Synergy moniker, especially regarding the unified contact and messaging approach.

Of course, being a Quicksilver aficionado, being able to find anything on the device via text input (regardless of how good/bad the keyboard turns out to be) makes me want one, now.

But I think there are deeper issues there. For instance, one of the questions I (and a few others) have is exactly how one would go about writing a data provider for it – for instance, could I integrate my Twitter contacts there and have it as a standard IM-like transport? Can I replace an existing service provider (such as Facebook’s) with another? Disable the ones I don’t want?

Either way, I think the multi-modal approach solves a problem I already have now: Building a sort of unified timeline of my interactions with people, but on the device (where I alone have that information and can have ready access to it) rather than on separate services.

There are plenty of ongoing efforts to achieve a similar effect – and you can get a feel for it if you use a BlackBerry with a unified message view – but I liked what I saw, and wished other devices followed suit.

3. SDK vs Business Model

This is, in my view, the bit that will take longer to figure out and that has the most profound impact, not just on the Pre’s success, but also on the overall approach for mobile development (it is also where I think Palm can make a sizable dent on its competitors).

Now, it’s pretty obvious to anyone with half a brain that there are less and less standalone mobile apps. Pretty much everything that you want to access on a phone these days (except most games) is, in one way or another, tied to some form of online service, and developing stuff to work against online services is on a lot of people’s minds (including my company’s, although that is not the point of this article or something I’ll go into in detail – I’m just stating the obvious here).

And both Android and the iPhone have a steep learning curve – even if you’ve done MIDP or Objective-C development in the past, you’re still facing an uphill battle against new APIs and runtimes.

But the language is the first hurdle.

And even taking into account that JavaScript is, by and large, hopeless for truly structured and/or complex programming (at least the way most folk code), it should be a significantly lower one.

So if the Pre SDK requires little more than HTML and JavaScript to create apps that are “first class citizens” (with access to all or most platform functionality) and the ability to tie in to any online service with as much hassle as crafting a JSON API or a new browser flavor for the UI, I’d say Google and Apple have a problem here – even if, realistically, the best developers will keep flocking to the most profitable platform³.

Going a bit further in depth, I think we need to know:

1. What kind of sand-boxing mechanism Palm has implemented around HTML and WebKit.
2. How much low-level (phone, network and hardware) functionality is exposed via the SDK.

My current take (which is likely to change as details on the SDK emerge) is that developing for the Pre will have pretty much the same baseline restrictions as the iPhone – no direct hardware access, explicit user consent for location and personal data access from third-party apps, etc., except that you’ll have multi-tasking and a few more system services available (like the ability to send SMS messages or, hopefully, to use Bluetooth for data transfers).

There has to be a line drawn somewhere – any sane mobile OS needs to have a degree of integrity protection to avoid having a rogue app trash the system. Add to that the focus on JavaScript, and I’d say that if you want to do some specific stuff (like streaming, doing audio processing – “Shazam”:AppStore:Shazam, anyone? – or implementing a specific non-HTTP protocol) you’d need to have some kind of lower-level access SDK.

Then again, perhaps not – maybe there’s nothing else. Which, realistically, wouldn’t prevent people from coming up with perfectly usable front-ends for online applications.

Still on the realistic side of things, it bears remembering that yes, Palm had, at one time, hundreds of thousands of applications written for their platform, spawning a big cottage industry that gave rise to a multitude of online application stores – but then two things happened:

1. Most of the apps you could find for your Palm were (statistically) of pretty dubious quality – that isn’t to say that there weren’t some amazing ones, but let’s just say that before we had a gazillion Twitter apps for the iPhone, there were entirely too many currency converters and enhanced task lists for the Palm…
2. They had no grip whatsoever on the market. The whole ecosystem flourished largely despite their efforts – and no matter what Palm says today about openness, I remember the times when people complained about lack of support and documentation for some of the original Palm OS APIs.

Yet, nothing much has changed. Sure, Apple “went pro” and started selling apps⁴ on iTunes, they crafted a working business model (Phil Schiller did mention, during the last keynote, that Apple has 75 million credit cards on file), but despite the approval processes, I think there is widespread consensus that there are entirely too many fart apps and Twitter clients…

Apple has one sizable advantage, though: Compared to Palm, they’re selling iPhones and iPods like hot cakes. And Palm has, traditionally, focused on the US, paying varying amounts of lip service to a handful of countries.

I have trouble imagining them building a sizable footprint⁵ outside the US, and they’d have to get things like international input right – the iPhone has no physical keyboard limitations in that regard, and makes it easy to switch between English, Portuguese and Mandarin text input.

So physical footprint is also an issue here. And that’s why, in the long run, you have to balance the SDK’s openness with the prospective market. Even if Palm relinquishes control of the business model for app distribution and gives away its SDK for free, it won’t matter (at all) if they don’t have a global strategy – and that, in “Europe“European, means taking on Nokia.

But I digress – it’s far too early to do more than educated guessing. For all I know (and I wouldn’t tell you if I did know), they may already have a global strategy.

Anyone who owned a Palm and kept track of the way the platform evolved is more than a bit curious about WebOS from both a platform and business sense. Since Palm once spun off a “subsidiary”:Wikipedia:PalmSource just to manage Palm OS, you have to wonder what they’ll do with something that is largely based on completely open standards.

For instance, what if (gasp) Palm tried to make a business model out of licensing WebOS?

I realize this sounds a lot like the ‘Apple should license Mac OS X!’ crowd, but there’s a point to that – and my point is, that at least for now, the same arguments against that also apply to Palm – they are sure to want to retain full control of both the hardware and the platform, since either depreciates significantly if parted.

Even if the mobile environment is completely different from the PC hardware quagmire, it has been showing signs of coalescing around two or three sets of chipset manufacturers and integrators, so the prospective revenue they’d get from something like that would be hard to fathom.

And yes, Android was a disruptive force in that regard, but I don’t think it has cornered the market (far from it, actually).

Anyway, one thing’s for certain. Regardless of whether or not the Pre succeeds, Palm made a splash, and are back on the radar.

Let’s see how things pan out.

—

¹ And, hopefully, without the cards reloading every time you go back to them.

² Technically, they have pretty much no excuse considering that the iPhone runs a stripped-down Mac OS X with perfectly good process handling. Either way, they lose.

³ Learning curves are the least of an experienced developer’s problems when the prospective market size of something like the iPhone – which is already globally available – is infinitely larger than the Pre’s – which isn’t even out yet.

⁴ Somehow, nobody ever remembers the original iPod games, nor how closed that business model was…

⁵ I’m not trying to draw comparisons with Apple’s retail footprint (which, incidentally, is still pretty much zilch outside the US). I’m more worried about localization and local distribution in “Europe“European, or lack thereof.