iPhone and Palm Pre – the Obligatory Post

I’ve had my paws on the Pre, and while I have not, of course, gotten hold of a 3GS, it doesn’t really matter.

See, getting my hands on a 3GS might convince me it has a better hardware/software experience. And since the 3G already has a better hardware/software experience than the Pre, I’m going to call it a “gimme” for the new 3GS.

The Pre, for all of its clever conceits compared to most phones, is still clunky, hiccup-y, and jittery next to even the current iPhone model. The graphics aren’t as smooth, the UI is harder to use, the physical keyboard is marginal, and on and on.

On top of that, it is hard to overstate how important the app ecosystem is to this “competition,” and Palm doesn’t even seem to be trying (they’re still saying “real soon now” on the SDK).

No matter how many apps in the App Store are just fart apps, and no matter how beautiful the bundled apps on the Pre are, there is no contest because these guys are playing different games.

Apple has succeeded in making the phone a general computing platform in the mind of the public – something I argued for 3 years ago – and you judge a platform not by its internal specs but by what you can run on it. Palm doesn’t seem to get that. They’ve got a decent bundle of specs but there’s nothing to run on it and there may never be much.

So with Apple still killing in the UX department, and Palm leaving their A-game at home (if they ever had one) as far as the app/platform/dev community goes … is there anything positive to be said for Pre in this contest?

Only this: AT&T’s network is so egregiously ill-behaved in so many prime metro areas that Sprint could actually pull a few people across the line.

I am one these last folks: I would much rather replace my current phone with an iPhone, but the thought of another two years of dropped calls, missed calls, bars-but-no-coverage, data connection unusable half the time … and I’m seriously considering the Pre.

Say what you will about Sprint (I’ve used every major carrier and none is perfect), where they have coverage, the devices just work. You can make or take a phone call. Which, ironically given that smartphones are bordering on augmented reality nowadays, is still the sine qua non for a phone.

Android? Give Me a Call When (If?) Phones Go On Sale

In this era of cluetrains, agile, getting real, perpetual beta, and all the rest, I would have thought that FUDly tactics like announcing big game-changing vaporware just to assert your position couldn't be taken seriously.

Not that Google's Android phone software is vapor (you can download it today) -- rather, the proposition of a viable phone ecosystem (devices, carriers, software -- in short, something you can actually use) is vapor.

It pains me to write this. After all, I proposed an platform-oriented MVNO (which Google may become with its possible spectrum bid), and I also stated that, to change the game, Google should support J2SE (and more), which Android does. And Google's challenging the carriers, who are the big problem in wireless software.

But I gotta call it like I see it, and announcing a big platform initiative when the first real handsets are at least a year away is a movie I've seen before.

There's an ALP announcement like this every six months; Palm announced the mythical Cobalt (with SDK!) over and over; Motorola made a big deal about its Linux phones. To be fair, Moto does ship a number of phones running Linux under the hood. But they're not really open, and neither developers nor consumers have taken much note. In early 2006 we were told MIDP 3 devices would be shipping by, er, now. Oh, and Sun's magic wand is going to bring us JavaFX mobile devices.

It's old-school (bad!) tech marketing at its worst. At best, these announcements need a bogo-coefficient to convert, say, "Just 12 months away!" to "Just 36 months away!" ... but really it's best not to believe in anything you can't buy at your local Sprint store.

Producing the SDK for public consumption now is not necessary to provide development lead time (how long did it take developers to build apps for the iPhone?). Plus freezing APIs now just makes it that much harder to alter the them when unforeseen issues crop up closer to mass production.

Although Apple is famous for taking a haughty approach toward their developers and customers, there is something to be said for putting the hardware and carrier together first, releasing the phone second, and then when you see what people really want to do with it, release an official SDK to help them.

I wish Google the best of luck with 700MHz, the carriers, the handset makers, the FCC, and the public. I'm just not sure this is off to an auspicious start.

Yahoo! Go: Nice Product, Sorry Testimony to the Horrific State of Mobile Dev Standards

I finally got my Yahoo! Go on this week, when the client for my Samsung Blackjack became available. I had been watching this project because it's one of the more ambitious mobile initiatives in a long time. You wouldn't know from the press coverage, but that's because it's in the middle of the land of purple, a giant doing everything and nothing, well and badly, all at the same time.

Let's pass over Y! Go's features and design for a sec. In terms of software architecture, we're looking at a smart client app: its content and features are network-oriented (mail, flickr, search), but it also runs offline, saves stuff locally to make that work, and masks fluctuating data rates and request latency under a locally controlled UI.

It's effectively got an embedded web browser (although it looks like page transcoding is happening on the server side, to save bandwidth and reduce complexity on the phone) and server-side support for viewing PDF, Microsoft Office documents, HTML email, etc. This strategy is a lot like the Blackberry's server-side translation, with the exception that Yahoo's actually works.

So Yahoo has basically built a 1990s-era AOL client, a monolithic app that provides a controlled experience and mediates access to the Internet. And they've built it on at least four platforms (Windows Mobile, Symbian, J2ME BlackberryOS, J2ME/MIDP vanilla) with countless versions and quirks. Which is why even versions for "similar" phones have trickled out over the course of months.

Why would Yahoo do an AOL? Because they want to take over the world with their platform, and control where users go? Nope. They did it because they didn't have a whole lot of choice. The phone development platforms remain extraordinarily fragmented across OS, API, version, and hardware install (!), and the carriers are more of a hindrance than a help. The worst part is that within six months there will be enough new devices and OS changes that the entire QA cycle and maybe even dev will have to be at full throttle just to keep this app viable.

Most likely, the original mission was to bring Yahoo to mobiles in a more consistent and usable way than the old mobile web site. And most likely they looked at mobile web options before realizing that those would require nearly as much customization for different devices as rolling their own app (plus mobile web would lack critical offline/low-data-rate functionality). So they did what everyone has to do: build their own native application to serve as platform and abstraction layer over the other APIs.

Who wins in this scenario? It's not the Yahoos, Microsofts, or Googles, who would rather not rebuild, test, and maintain the same app over and over. It's not startups, who kill themselves trying what only GYM can really afford to do. It's not the carriers, who want to increase revenue per sub by selling data plans, and who need compelling network-intensive apps to do that. And it's probably not the hardware folks, who don't care too much what's happening four levels up the software stack.

No one wins this game of 52 Pickup. It creates "small value" in the short term, while stifling "big value" in the long term, the same way a tornado wrecking a town brings a bunch of contracting and insurance dollars in the short term, but doesn't make the town a creator of value in the long term, the way building infrastructure like fiber-to-the-curb, or a decent university extension campus might.

I built a push-mail system in Perl in 1998, the same year RIM started shipping the precursor to the Blackberry, and I started reading my Yahoo mail on my phone in 2000 via WAP. So we're nearly at 10 years of mobile productivity apps and the trend is still toward more chaos rather than less. So... how can we reign this in, hopefully still preserving some biodiversity in phone DNA at the same time?

Foleo is Foolish ... But Here's a Better Idea

I know, the Foleo is spelled with an "e" ... Either way, it's such a silly proposition only Steve Jobs could hype this thing enough that people might buy it. And if he did, the only benefit would be keeping the computer gene pool diverse by preventing people from buying a decently spec'd Windows laptop, for about the same price.

The interesting bit is that we do need optional larger displays for small computing devices so that we can get the most out of them as they continue to increase in power and connectivity. So what would work better than this non-laptop?

I worked with Tim Andrews at Viant in "Web 1.0" and one time he took us out of our way to look at the latest video goggles from Sony Japan. Ok, personal movies ... huh? I didn't get it. The goggles are going to be the video output for this, Tim explained, pointing at his Palm. Tim has spent much of his career thinking ahead, and this time was no exception. The 1999-era Palm would've taken 30 seconds to BlT a frame for these goggles. But now?

Let's see... Modern smartphone hardware can drive a VGA display or larger. And here are the visor displays: VGA for about $400, and SVGA for $1600. Like most hardware, the price is inverse-exponential with volume. That's a fancy way of saying these are expensive gadgets 'cause no one makes a lot of them. The price will drop drastically as they are produced in higher volume.

On the input side, there are old fashioned Bluetooth or more futuristic solutions and bear in mind: you don't always need big input and big output at the same time. Web browsing and document review can benefit from a big screen, but hardly need a full-sized keyboard. So there's no reason to fill your lap with another battery-chewing, airport-security-antagonizing monstrosity just to follow up on some links.

Small computing devices are about mobility and convenience. They are hardly "enhanced" by chaining them to a big dumb anchor. But the tech is here to take a smartphone-grade device and get a ton more productivity and value out of it by widening its human I/O bandwidth with these virtual keyboards and virtual big screens.