Software Everywhere — David Beers on Mobile Computing

Wayne Parrot thinks it's going to be HTML5. His work on WebKit for SWT aims to prove it:

We have implemented a bidirectional bridge that allows you to implement JS objects in Java and to interact with JS objects from Java. This feature has turned out to be very useful as we are leveraging the power of HTML5 technologies in a much more dramatic and efficient manner from Java now. This is a dev strategy that I have wanted to leverage for sometime. I'm so impressed by what is possible that I'll make a controversial claim that if you are a Java UI developer and are not paying attention to the advances in web UI technology then prepare yourself to be blown away in a very short order by much more capable and productive UI developers that understand how to use new killer web UI features on the desktop.

WebKit's growing dominance in the mobile space (iPhone, Android, S60 and now Palm webOS) as well as the desktop make this a pretty intriguing UI option for Java developers—more so than JavaFX, perhaps. I like JavaFX script, but it wasn't the first dynamic scripting language specifically designed to complement Java for the purpose of developing RIAs. That was JavaScript, which already has great mindshare and energy that shows no sign of flagging. One can't help but wonder about JavaFX while the very future of Sun itself seems so uncertain.

Speaking of RIA's, a call-out to Jo Ritter for his recent comment on RMAs—Rich MobileNet Applications. This application model, which spans mobile and the desktop by introducing the stackless Java stack, is finally hitting some mainstream handsets thanks to ProSyst and Sprint. But let's get serious: that can't possibly come to pass until there is an entry for Rich MobileNet Application in Wikipedia, guys! Get on it!

Just a quick callout to the budding open source Blinki project at Eclipse Foundation (formerly known as FireFly). What caught my attention:

the FireFly project will develop next-generation technologies and frameworks to support the creation of mobile web applications that look and behavior similarly to native applications and are able to interact with device services such as GPS, accelerometers and personal data.

It looks like Genuitec (of MyEclipse fame) is leading this initiative. The first thing that's they've released is an SWT browser widget that uses the WebKit rendering engine. From Wayne Parrot's blog:

The WebKit for SWT browser API provides all the basic browser use-cases that you would expect. Additionally the cool features of WebKit such as HTML5, CSS3, V8 engine, and other things are now accessible from Java.

V8 is the super-fast open source JavaScript engine that Google developed for its Chrome browser. It's worth noting that it's been optimized not just for x86 processors, but for ARM Linux. Think Android... or the Palm Pre with its webOS platform.

Last week I mentioned that Mobile OSGi (specifically the Sprint Titan platform) would be a great starting place for the open source community to create a knock-off of the Palm webOS mobile platform. Now that the bindings between a Java runtime and the WebKit HTML5 rendering engine are in place the community is quite a bit closer... and webOS isn't even in the wild yet. The beauty of the OSS version would be that developers could write code not just at the JavaScript front-end as the Mojo SDK will allow, but they could also write Java modules that run as services in the middleware tier—or even native Linux or Win32 modules encapsulated in OSGi bundles. For Palm fans who read my blog, think webOS (or something much like it) running not just on the Pre, but on the Treo Pro with Windows Mobile under the hood.

I'd like to think that developments like this will force Palm to release an SDK that opens its own middleware layer. For webOS to get the most traction in the market Palm needs to leverage the architecture's natural advantages as a service oriented mobile platform. Android's Achilles heal is the weak component model and attenuated, non-standard affordance for apps to provide services to each other (i.e. be "mashed up"). If Palm doesn't go after that weak point early in the evolution of webOS, it won't take long before others make the first move.

UPDATE: The new Blinki blog is here. Watch it.

Working at MapQuest for the last year and a half has been an extraordinary opportunity for me in that the mobile applications I create there are targeted to an audience of 40 million people who use MapQuest.com at least once a month. A slight downside of being associated with the top brand in online maps and directions is that I'm not as free to talk about my work as I am when the signature on my paycheck is my own. That fact—and being on a small team that does daily battle with outfits the likes of Google—helps explain why I haven't posted on Software Everywhere as often as I like.

This week we had a new release of the MapQuest4Mobile application that has been my main "baby" over the last year, and the marketing folks asked if I'd like to blog about it. I still can't say much about what's coming next (aside from "you're gonna like it!") but at least you can get a feel for what I've been up to during this "heads-down" period of time. Check out my post on the MapQuest blog, and if you've got a supported BlackBerry device, check out MapQuest4Mobile!

(Pay no attention to the name on the MapQuest blog entry—it's me. I guess the "author" of the posts in the blogging application MapQuest uses is always the name of the guy in marketing who pushes the "Publish" button.)

The sleeping giant of the mass market is finally waking to the realization that mobile phones are personal computers. Software developers have been waiting for this day a long time—longer than most expected—but the sad irony of the situation is that the mobile software opportunity is now mired in software itself. Application developers aiming to target this broadening swath of mobile users are spread too thin to innovate: they spend most of their time and resources reinventing wheel after wheel and porting their applications to platform after incompatible platform. In sharp contrast to the circumstance of developers on the Web where interoperability and shared componentry are the norm, mobile developers find themselves corralled and Balkanized by scores of incompatible languages, runtimes, profiles, browsers, rendering engines, and SDKs, to say nothing of the fragmentation that makes the same API feature in any of these "platforms" work differently on each of a handful of different devices.

Allow me to do some back-of-an-envelope math to underscore the magnitude of the predicament. Consider five hypothetical independent software vendors developing five applications—each different but sharing five features in common. Just to put us in the realm of the concrete, suppose the features are real-time location awareness, consumption of RSS, rendering of complex animated graphics, instant messaging, and network presence. Each ISV wants their applications to run on 100 handsets spread across five mobile platforms: iPhone, Android, S60, BlackBerry and Palm webOS. (The execs said no budget for Windows Mobile, MIDP, BREW, JavaFX, Palm OS, WebKit browsers, etc.) Thankfully, some of the platforms have proprietary built-in components that implement these features and a couple have SDKs in the same programming language. Even so, if you work out the porting permutations, the total amount of duplicated effort across these companies could easily outstrip the effort of developing the differentiating features by two orders of magnitude.

Let's face it: while this crushing fragmentation persists (cloaked in the excuse of "differentiation" and "personalization") mobile technology will not only lag behind web technology, it will hold back the Web itself.

Many have blamed the carriers' pursuit of differentiation-at-any-cost for this perverse state of affairs. So who would have thought that Sprint-Nextel would be the first to chart a course out of this mire, still less to blaze a trail for developers across two million mass-market and up-market handsets this year? That is the significance of the Sprint Titan platform, the first mobile environment built on the proposition that real mobile innovation comes not from herding developers into a better silo (even an open source one) but from enabling them tie many APIs together dynamically using a universal component framework. Titan is not a new operating system. It's middleware that runs just above the OS, enforcing Lego-like interoperability among components—even for code written in different languages—and providing a service-oriented architecture so any developer can offer their own APIs for others to build on.

I've started working with Titan a bit and I'm really inspired by the possibilities.

Technically, Titan is comprised of an unusually powerful Java ME runtime environment (CDC/FP), a dynamic component framework (OSGi), a remote device management agent (OMA-DM compliant), and a basic kit of service components, called "bundles" in OSGi parlance. A few words about what each of these is bringing to the table:

• Java ME CDC is a big step up from what's on most phones today. Critically for Titan, it supports Java Standard Edition features like shared libraries, custom classloaders, invoking native code, and rich APIs for graphics and UI.
• OSGi is the same dynamic component framework that has made the Eclipse development environment easy for developers and tool vendors to extend with hundreds of plug-ins. But OSGi didn't originate with desktop-class hardware in mind: it came from the world of embedded devices. OSGi bundles are written in Java, but they can include native code to expose special OS or device features. They can also implement bindings to other languages like JavaScript, ActionScript, or JavaFX, enabling code written in these languages to access the same features. Titan is not just another Java SDK. It's greatest potential may be as an extensible mobile RIA platform.
• Remote management is part of the OSGi Mobile spec and a key to making mobile software development more agile. Application updates on many mobile phones today are so disruptive to users that most companies are rightfuly afraid to impose updates more than twice a year. Combined with OSGi's unique capability of updating components without restarting the VM, remote management should enable no-touch updates of rich client apps of the painless sort usually reserved for web applications. The agility advantage of "release early, release often" may finally be available to mobile software shops.
• Service bundles are where Titan surpasses mobile Java platforms like MIDP (even MIDP 3) and Android. For example, if Titan is running on an OS with a native GUI toolkit like Windows Mobile or S60 (or a desktop OS, for that matter) it can expose that toolkit as a service using eSWT and the embedded Rich Client Platform bundles. I believe you could develop entire applications in native code with the thinnest of Java wrappers to allow install/start/stop/update lifecycle management by the framework to maximize performance. Still more interesting, Titan ships with an HTTP service that is a full-fledged Java servlet container. This enables applications that use the browser to render the UI but have JavaScript bindings into system capabilities that web applications can't normally access: local databases, GPS, Bluetooth, the camera, etc. Where mobile browsers usually render the Web as a pale shadow of their desktop counterparts, the mobile Web on a Titan handset can be combined with mobile phone capabilities in ways never seen in a desktop browser.

In it's 1.0 release Titan has been implemented for Sprint's Windows Mobile Pro handsets, including the Palm Treo Pro, slated for release on Sprint this weekend. It supports writing apps in Java with a native Windows GUI (eRCP) or multi-tier web UI apps that use the browser engine for the front-end and Servlets running on the internal HTTP service for the business logic and access to features like GPS location. But insiders are saying that this middleware will stretch very broadly across Sprint's handset portfolio as well as devices designed for the XOHM WiMAX network, so we can expect that bundles for additional application models are in the works. Flash Lite seems like an obvious candidate, as does LWUIT. I've seen a presentation that hints that JavaFX could be a frontend on some Titan phones that Sprint releases.

The beauty of it is that no one has to wait for Sprint to implement new bundles and start embedding them in the firmware. If Sun wants to package JavaFX as an OSGi bundle, developers could add JavaFX apps to Titan phones that had no such support when they were released. I've already suggested that Palm give serious consideration to implementing its webOS middleware as a collection of OSGi bundles for portability. But even an indy developer could mash up some open source and homebrew libraries, create a new application model for Titan and share it with other developers. I predict that a Titan phone will be the first to run a knock-off of Palm's webOS developed by the open source community.

Creating your own SDK may not sound like a very practical idea for the average mobile developer (maybe only slightly manic ones like myself!) but building apps using middleware bundles that provide easy access to popular web services from Google, Yahoo, Amazon, Facebook, AOL and Twitter will be an exciting proposition for any developer. We can guess those vendors as well as smaller web startups will soon be populating Titan's bundle ecosystem with plug-ins for everything from messaging to mapping in a bid to extend their reach, leveraging the creativity of third parties to build the apps they couldn't—or wouldn't think to—build themselves.

Beyond the technical capability Titan provides to build applications by mashing up components, the question of how components can be published and optionally monetized is key to the success of Titan as a driver for mobile application innovation. Vendors like the ones just mentioned are likely to offer free bundles to developers that want to build on their services. And open source bundles will surely abound—they already do. But what about a marketplace where developers can sell components they have developed to each other? Possibly even a payments service on the device to enable component vendors to implement monthly recurring charges or micropayments to monetize highly complex or valuable components. I hope Sprint is giving some thought to this, because creating a great business model for developing components will make the difference between Titan being disruptive or just deeply interesting. And I'm also interested to understand what security policies Titan will implement and how Sprint will deal with testing and certifying bundles that aren't themselves applications, but middleware services for other applications to consume. Trustability of components will be critical to creating a vibrant market and a new era for component-based mobile application development.

By the way, check out Jo Ritter's blog for one of the best sources of information about Mobile OSGi and Titan.

My favorite company in the industrial handheld hardware business is, like many of the rest of us, seeing some tough economic times. In their latest newsletter they have announced they're having to sell the company jet:



These guys are old friends and we haven't sent much business their way in a while, so after reviewing things with the CFO (who I'm sleeping with by the way*) I've decided that Pikesoft will make an offer on the Aceeca jet to replace one from our own aging fleet:



I hope Alex's jet has WiFi like ours do.

*Usually with a 50lb dog between us.

It was hard to know where to start in talking about all the exciting software development prospects for the Palm Pre and webOS. I began by speculating about an eventual Java SDK for webOS, which would be a heck of a left hook to follow the Mojo SDK's right jab. But I'm getting ahead of myself. Even just considering the JavaScript SDK they have already announced Palm has put themselves in an astonishing strategic position that I'm surprised no one is talking about. By building a system using de facto cross-platform standards like JavaScript, WebKit, Java and Jetty, Palm has made a great platform for creating companion applications that can run on any desktop—Windows, Mac, or Linux—leveraging the same code that runs on the handset. You won't see Apple being able to deliver iPhone applications to the desktop like that any time soon, at least not for the 90% of personal computer users that don't own Macs.

Palm has prepared us not to expect desktop synchronization via cable or cradle like what Palm OS users have been accustomed to since the beginning. But the Pre is among other things a modernization of the original Palm concept of having always-on-you personal information management, updated to the reality that much of people's personal information now lives in the cloud. The desktop is still going to be the command center for most people's digital life and Palm knows it. So gazing into my crystal ball, let me tell you how the desktop story will in fact unfold:

LAS VEGAS, CTIA Wireless 2009, Apr 1, 2009 - Palm, Inc. (NASDAQ: PALM) today announced the Palm Desktop Companion, an application that brings to the Windows and Mac desktop the same integrated calendar and contacts found on the Pre smartphone.... Desktop Companion uses [crystal ball is clouding a bit here] to keep your calendar and contacts synchronized automatically without the use of cables or cradles. [Did I make out the phrase "peer-to-peer" when the crystal hazed over in that moment? Or was there a faint trace about a "secure web service"? Oh well, the future is coming through clearly again now.]

SUNNYVALE, CA - May 15, 2009 - Palm, Inc. (NASDAQ: PALM) today announced that the Mojo SDK will not only enable third party developers to write applications for webOS devices like the Pre smartphone, but to deploy the same applications to the Palm Desktop Companion.... "The SDK enables webOS developers that follow some simple SDK guidelines to build applications that 'unfold' naturally on computers with larger screens for the extra ease and efficiency of the full desktop experience" says Palm's VP of Developer Services Horton Hooville.... [The image dimmed for a moment there... not sure I got that name right.]

MOUNTAIN VIEW, Calif - June 23, 2009 - Three days ahead of the scheduled release of Palm's Pre smartphone, Google, Inc. (NASDAQ: GOOG) announced the release of GMail and Google Docs for the Pre as well as for the Palm Desktop Companion.... This announcement brings Google's popular mail service to the Pre as well as instant access to all of your office documents at any time. When at their desktop, users of Palm Desktop Companion now have access to Gmail and the ability to view and edit documents, presentations and spreadsheets even when they are offline....

BARCELONA, GSMA Mobile World Congress, Feb 15, 2010 - Palm, Inc. (NASDAQ: PALM) today announced the Foleo Pro Mobile Companion... The Foleo Pro runs properly configured applications created for the Pre without modification, but with the same ease of use found in the Palm Desktop Companion application.

The unfolding UI concept would be the key to making application screens that stack on the phone to display side-by-side in the familiar "master-detail" layout seen in applications like the original Palm Desktop and Microsoft Outlook. I blogged some thoughts about this idea way back in Sept 2005 in one of my very first posts, complete with a lame mock-up to illustrate. It's simple, really. Many, if not most mobile applications provide a "master" or "list" view of the data from which the user selects an item and then navigates to a screen that displays the details of the selected item with additional options for manipulating it. If these master and detail screens (or "cards" as Palm now seems to like calling them) are identified as having this relationship in the code by using an API that binds the selection in the master view to what is displayed in the detail view, all it takes to spread the stacked cards across a larger surface so they are viewable side-by-side is a little CSS. Making a desktop version of a webOS application might involve no additional coding at all, just some care to follow certain design guidelines.

The main work for Palm would be to create a native application that hosts the webOS environment on each system they want to support and provides some hooks into system services so that things like calendar event reminders work from the desktop. From what I can glean from looking at the leaked screenshots of the SDK in action, most of the hard work of developing this desktop presence has already been done since it went into developing the webOS middleware already on the Pre. That's the main reason I'm optimistic that Palm could pull this off during this period of severely strapped resources.

They would also want to integrate their application store in the desktop companion app, since the desktop is clearly the easiest and most engaging way to search for and try out applications. Letting application shoppers try an application in a simulated Pre phone launched from the desktop app would be a great way to break down the natural resistance to trying something new. I also believe there are opportunities to make installation of the application to the phone slicker and smoother than we've seen on other platforms using a desktop companion app like this.

Of course, some mobile phone features that Pre applications could use like the microphone, camera, voicemail, SMS and GPS would not be natively supported on most desktop computers. But if Palm or a third party were to implement peer-to-peer communication between the Pre and "Palm Desktop Companion" it wouldn't be much of a stretch to make even these phone features usable from the desktop. While you're at your desk you could receive SMS messages, proxied by your phone, and answer them using the keyboard and mouse already at your fingertips. With that link to the phone in place, seeing voicemails show up in the inbox of the desktop companion and being able to listen to them there might be a modest effort that extends Palm's story about total integration of messaging and contacts one notch further. Desktop web searches or mapping applications could be localized by clicking a "near my current location" toggle that geocodes a GPS fix retrieved from the Pre in your pocket and adds the location data to the query.

What a spectacle it would be to see Palm show up out of nowhere as one of the players in the hotly contested cloud computing arena. And not just to show, but to conquer a niche because their AJAX APIs expose unique messaging, location, even voice and camera functions on the mobile that only their position as a mobile software/hardware integrator makes possible!

Am I getting carried away now? Perhaps a bit. I may have compressed the timeline for these developments to unfold. But my bet is that their webOS strategy gives Palm a long enough lever to move some surprising mountains, even in their current weakened state. If they share the vision I've described, the key success factor in realizing it will be a peerless commitment to enabling the success of third party developers so that Palm has a strong ecosystem to pass the baton to. Palm's success in the 90's was built on stellar developer support and it's revival today must be built the same way. Early indications give hope that Palm gets this.

If Palm declines to offer a C/C++ or Java SDK and loses some developers in order to focus their energies on getting webOS and the Mojo SDK a place on the desktop, it'll be hard for me to feel all that disappointed. For that, I'll brush off my JavaScript skills and get right to work.

BoyGeniusReport has leaked some screenshots of someone using what looks like the Palm webOS SDK, complete with revealing console output. (You should know that a normal person looking at that gallery would be admiring at all the pretty UI pictures, of which there are many, but I'm most fascinated with the debug console.) The console shows the JavaScript code making requests using a "luna://" protocol to a Jetty web application server running locally, which in turn uses file I/O to access files with .json extensions in a Linux-like file system. It's not a sure thing I suppose, but it's a pretty darned good bet that we're seeing something very close to what happens when a webOS application is running on a real device like the Pre smartphone. If that's the case we've learned quite a bit, and can guess even a bit more.

First, at least as far as the application framework is concerned, the software on a Pre looks an awful lot like a Linux web server and nothing at all like Android, ALP or any other Linux-based mobile platform we've seen. Second, the server code that is running in the development environment is Jetty, which is Java. That makes sense from the standpoint of enabling developers to use Mac or Windows workstations but maybe there's a native C/C++ server running on the actual device. I doubt it. I say there's a Java app server running on the phone, too, inside a nice Java runtime. Why?

Well first, why not? Java is secure, stable, runs on all kinds of processors and OSes, including x86 PCs and Macs and a billion or so mobile phones. Palm didn't have time to mess around with porting or reinventing the wheel. Second, as I pointed out back in Sept '07 when the Foleo was cancelled, Palm was hiring Java engineers for...

implementation of Java based mobile system software on new product development project. Responsible for all mobile development (design through implementation and release), working with other device engineers and design lead on overall system architecture and design.

There have also been ads for Java web services engineers, but ads like the one above told me to expect that Palm's new Linux system would be "Java based." And I'm more sure than ever now that it is.

Here's what else we know: it's not a J2ME MIDP environment on the Pre like the ones on most other phones. To run an application server it's at least a CDC environment with Foundation Profile, which means it's pretty beefy and has a lot of the power of the underlying Linux system available to it. That doesn't necessarily mean that Palm will be letting 3rd parties write applications that run in the Java runtime as opposed to WebKit, but they certainly could.

This is where I get really intrigued, though. See, Palm's first carrier partner is Sprint. Sprint has been on the forefront of an idea to make mobile devices first class citizens on the web by enabling them to run "desktop class" software. The way they are doing this is through a platform they call Titan released just last month. Titan puts a powerful Java environment together with a technology called OSGi, which is the special sauce. It's a service platform that enables developers to create software by plugging together software components. For example, Sprint's Titan platform includes a web server module to enable iPhone-like widgets (hmmm). Because the server is running inside the OSGi container, widgets can interoperate with other components in the container: components for GPS location, messaging, multimedia, etc (hmmmm!).

The novel service-oriented architecture of webOS bears more than a passing resemblance to Titan. And I can't think of a better way for Palm to have put it all together than with OSGi, just as Sprint did. Loyal readers know I've been waiting years for OSGi to go mainstream on mobile phones. There are so many good reasons, for it, especially for Palm:

• OSGi fixes some unfortunate limitations of Java ME: incompatibility with standard Java packages, no shared libraries, no long-running services, no loading of classes that weren't installed with the app, no intercommunication between applications, no app updates without reinstalling the entire application, etc. Seems like half the places you think there should be a door there's a blank wall.
• OSGi also solves many of the problems that motivated these limitations in the first place, mostly having to do with challenges of delivering high reliability, manageability and security in an open component-based platform, long a sort of holy grail for software development
• OSGi is designed for remote management. It would be ideal for performing firmware, software, or configuration updates over-the-air. Such updates could originate from Palm, from a carrier wanting to deploy a new service or app, a third party developer, or possibly an enterprise customer wanting to update an application or setting across all their users. This capability would give Palm one of the advantages that RIM has traditionally held in the smartphone market.
• OSGi is ideal for delivering the same service with the same code across multiple platforms. If Palm is serious about delivering web services and plans to keep their Windows Mobile smartphone line they can reuse the Java service components they develop for the Pre on their WinMo phones. This can be true even when OS-specific native resources are involved. For example there is a powerful framework called RCP for creating Java GUI applications that can run on Windows Mobile, desktop Windows, Mac OS or Linux--all with a native UI provided by the underlying system. RCP and OSGi are the technologies that enable the Eclipse development environment to run fast with native look-and-feel on Windows, Mac and Linux desktops. Let me be clear here: It's totally feasible with OSGi under the hood for webOS applications and any special services that Palm develops for the Pre to also run on Windows Mobile, and that Java apps with native Windows Mobile GUIs could be developed using RCP that leverage the identical service software. I'd think that would be a pretty compelling proposition for Palm.
• OSGi makes Android's IPC-based component model look slow, weak and restrictive. OSGi communicates with its bundles by ordinary method calls, a much better way to enable the kind of mash-ups that have made Android attractive to developers.
• OSGi is a mature, open standard with strong industry backing, a sizable catalog of mostly free plug-ins, and considerable buzz among developers

So what to make of this? Has Palm jumped on the OSGi train? There's no way to really know at this point. All I really know is that if I were going to develop a system like webOS I would certainly use OSGi, and that some pretty smart guys I know at Sprint (and Nokia, by the way) came to the same conclusion. Keep in mind, if Palm is packing some OSGi goodness it doesn't mean it will all be open to developers when the first SDK is released. If they allow third party Java components at all there will likely be a digital signing requirement. But the day an SDK is available for Java as well as JavaScript developers, and we can target both webOS and Windows Mobile smartphones, Palm will be in a superb position to build a developer ecosystem that draws deeply and broadly on the talent that powers Web 2.0 today.

Oh, and I'll be there, too, heh. With bells on.

I've been seeing a number of folks describing applications for the just-announced Palm webOS as "web apps." It's understandable given the name and some of the technologies mentioned at CES, but it's quite misleading. I posted an explanation of this on PalmInfocenter and figured I would post it here as well (with a few edits) since what Palm has really done is create an interesting new fusion between web and locally installed applications.

First of all, a web application runs in a browser, which is a piece of software that's optimized first and foremost for making requests to a server on the Internet and rendering the responses as a web page. Browsers have gradually been twisted or tortured with plugins to playback media, use cookies as local databases, and integrate with other apps on the machine, but to operate reliably and safely on the Internet they're necessarily somewhat crippled in using features of the system or hardware. Just because Palm said that webOS apps can be written with HTML, CSS and JavaScript doesn't mean they run in a browser or have the limitations of a web browser. Those are technologies for rendering a GUI that can--and have been--used outside the confines of the browser, and Palm is doing just that.

Secondly, people should understand that HTML 5 goes well beyond what we're accustomed to thinking of as HTML. It includes APIs for immediate-mode 2D drawing, video playback, offline databases, drag-and-drop--pretty cutting edge stuff. Palm is certainly the first company to release a mobile product based on HTML 5, and even modern desktop browsers only implement parts of the spec, often through optionally installed plugins like Google Gears.

As for JavaScript, it's a general programming language that is separate from the HTML document object model that it's most commonly associated with. Palm has already stated that they have extended that model to enable access to local databases on the phone and handling of notifications of system events, and there's no reason they couldn't expose much of the system API that way if they chose to. Sure, you're not going to be able to write hardware drivers in JavaScript but while some developers have good reasons for wanting to do such things a little sandboxing can a good thing on a device connected to the wild, wild Internet. A developer who partnered with Palm told the press at CES that "everything he did before in Visual Studio he could do in Javascript on the Pre." If he was much of a Visual Studio developer at all that means there's a lot more than the HTML DOM being scripted there.

Next, there's the complaint that JavaScript and HTML are interpreted and therefore slow. But remember, webOS applications aren't running in a browser, so there's nothing that says any of this need be interpreted. Palm knows all about compiling HTML applications into native code: they developed tools and APIs for doing this on the Palm VII back in 1999 and presumably own patents on it. They called these "web clipping" applications, and they displayed in the launcher and ran as first-class native applications on Palm devices, not as interpreted scripts in an HTML browser.

Now JavaScript may not be a lot of fun to code and debug, compared to a statically compiled language like Java or even C/C++. But let's remember that we don't have an SDK yet. Until we do we have no idea if JavaScript is the only API or if there are other ways to access more of the system APIs. Obviously there are other ways to access system APIs, which developers will discover on their own if Palm doesn't document them, but for now it's too early to say. I have a suspicion that a Java runtime is lurking in there somewhere and Palm didn't want to mention it yet for fear of comments about Palm being "late to the mobile Java party." J2ME, Danger, RIM, Android, JavaFX, Sprint Titan... the advance of mobile Java may be exciting for mobile Java developers but to everyone else a new Java SDK sounds warmed over, and Palm's had enough of that kind of talk.

If you watched any of the announcement you know that webOS is also intended for delivering a cutting edge web app experience, but that has to do with the browser they developed. It should also be clear that applications originally written for the web using JS/HTML/CSS (like GMail, BaseCamp, Facebook, etc.) should be easy to port to webOS and be enhanced to run in offline mode, due to webOS's HTML 5 support for offline databases.

All this starts to blur the distinction between "web apps" and "local apps," and that's where I think we're going with the mobile web. My friend Enrique Ortiz seems to agree. Nice to see good old Palm pushing out the frontier once again.

The consensus seems to be that Palm way outstripped expectations in their announcement of the new webOS and Pre smartphone yesterday. The stock soared from $3.40 to over $6.00 after the CES demo. Here's a taste of how the mainstream tech media responded.

I've always been of the mind that Palm had more fight in them than most were giving credit, but while I was expecting something pretty special... well, let's just say I was positively floored--especially by the new webOS.

Let me just dispense with all the customary caveats and qualifications that should attend opinions about a product this new and untried, because I think the folks at Palm deserve a standing ovation. To put it plainly, Palm just leapfrogged right over both Apple and Google. The Pre doesn't just have an elegant, simple gesture interface: it has the physical keyboard that Apple couldn't bear to let "mar" the iPhone's monolithic slabness. And word has it that the Pre is 4 times faster than the iPhone. Palm apparently still knows better than anyone how to get performance out of mobile hardware: you don't start with a desktop OS and whittle it down, you build for mobile from the ground up.

As for the Google comparison, webOS sounds a lot like where Google seems to be headed with Chrome, Gears, etc: a web-based operating system. Except Chrome, Gears, etc. aren't an OS yet and they don't run on mobile handsets in any case. Poll position to Palm for the first of a new breed of mobile web device, melding some of the best features of the browser with the hardware integration and I/O options only installed applications can deliver (a fusion not unlike one I predicted Palm would bring to market, based on various clues they gave back in 2007). Palm also has the advantage over Android that they build and tightly integrate the hardware with the system, something Google seems to show no stomach for doing. Hardware/OS integration is one reason why Apple lapped Microsoft so easily, so it's great to see Palm finally putting this to full advantage again.

I'm thrilled that webOS seems in places to be one of the earliest and best implementations of a UI concept that I've evangelized here and here: what I called uninspiringly "the mobile command line." Check out this part of the demo to see what I was talking about here, beautifully realized by the Palm designers and engineers. I love the simplicity, power and efficiency of text-based interaction on my PC, but it's on my mobile that it really brings the walls tumbling down. You're looking at the future of the mobile UI.

I will switch to Sprint and buy a Pre the day they hit the shelves, and I'm very interested in seeing the SDK.

Palm has their mojo back.

Mike Mace has written a piece titled Mobile Applications, RIP that seems far wide of the mark to me. He says that user-installed "native" mobile applications (as distinguished from web applications) have been so crushed by platform fragmentation and restrictive carrier certification requirements that the only remaining platform with a viable business model for mobile is the web.

Must be a Silicon Valley thing, because that's sure not been my experience. Nor it seems has it been Barbara Ballard's over at Little Springs Design, which has its foot in both the Java app and web app markets. She wrote recently:

This quarter is not particularly different from other quarters: we get far more work designing applications than designing web sites.

She goes on to explain why browser applications still aren't cutting it for her customers:

• Because they need to store some of their application logic and/or data locally
• Because the app or data needs to be available without the network
• Because the application would be dreadfully slow as a web app
• Because they are creating a push messaging client that needs more rich interaction than simple SMS (and better interoperability than MMS)

I don't think Barbara or I disagree with Mike about the challenges of fragmentation and certification, but I see things finally starting to get exciting for mobile developers, not dying out. Seems to me that all the really great new opportunities in mobile software involve applications that need access to the native hardware:

• LBS is finally taking off. (This is where I work these days and I get calls and emails asking for GPS apps all the time.)
• Mobile payments look poised to break out of Asia and into North America
• Companies are rushing to use QR codes to build the "Internet of Things", for which your mobile will be the mouse you "click" to gain access.
• Three words that make the above two items even more interesting: near-field radios.
• Multimodal user interfaces are finally looking ready for prime-time, so people can mix voice and button-clicks to create, search, and interact with their personal data and data in the cloud
• Best of all, mass market mobile phone users are starting to "get" the idea that their mobiles really can run applications and they're installing them to stay connected with their favorite social networks

Fragmentation is certainly not a reason for developers to retreat to the browser. The mobile web is incredibly fragmented, whereas Java ME fragmentation has been significantly reduced. And Java is looking like the new lingua franca of smartphones, too: RIM, Danger, Motorola, Google, and (rumor has it) Palm have all opted to make advanced (i.e. beyond MIDP) Java runtimes their primary smartphone application frameworks. A well-written Java ME application aimed at mass market feature phones is pretty easy to port to more advanced Java environments. The definition of "well-written Java ME application" will be a developer topic that I address very soon.

The carrier barrier does indeed make things tough—especially for "Long Tail" applications that address small niches. But we shouldn't forget that the carriers control the browser just as much as they do any other free-standing app. We know they are more than willing to control what parts of the web you can access without paying them a "toll." The only thing that's making web applications freer from carrier control right now for users who do pay that toll is that these apps aren't (yet) threatening any revenue streams or generating revenue from which the carriers can extract their pound of flesh.

Fortunately, as I watch the carriers struggle for ways to reduce subscriber churn and see widening cracks in the walls around their gardens, I'm more confident than ever that they will not be able to keep the forces arrayed against them out. That topic will have to wait for future posts. Suffice it to say for now that from where I stand there seems to be more good work for mobile developers today than ever. And I'm not talking about mobile web developers.

Thanks to all the folks who have been asking "where you been?" over the last five months. I go through periodic lulls in blogging and this probably won't be the last, but it has been one of the longest.

So where have I been? Why, right here, heh:


In August I took a position as a Senior Software Engineer at MapQuest, where I've had the pleasure of helping start a new mobile maps, directions and search project from the ground up: new dev team, new product and project managers, and a big, blank slate on which to build both product vision and technology.

It's been exhilarating stepping into the consumer mobile application space after years of doing vertical apps, especially doing so in an area that is so hotly contested right now: mapping, navigation and location-based search. Defending MapQuest's still commanding lead over Google and Yahoo, our closest competitors, is a huge challenge for a company of about 100 people, and ever since the iPhone the mobile front of that battle is becoming very important. It's been a while since I worked on a project where I would wake up on any given morning, think about the day ahead, and feel an adrenaline rush before my head even lifted off the pillow. It's kind of scary, totally stimulating intellectually, and a whole lot of fun!

I'm somewhat constrained in what I write about my work at the moment, but suffice it to say that the technical, creative, and team challenges at MapQuest have been so absorbing that I just haven't been able to keep the blog on my radar screen. That's not really changing—the heat is on more than ever—but I'm feeling once again the need to off-load some of my thoughts on mobile software here, if only to help sharpen some of my thinking about the interesting challenges I face in my current work.

For that reason the blog will probably have a little different focus for a while. I'm still thinking about the future of mobile computing and the companies that I see pushing out the frontier (including Palm, my favorite underdog). But expect more developer-oriented topics, perhaps some thoughts on mobile search and advertising which I haven't covered in the past, and definitely a new focus on agile practices as applied to mobile phone application development. I've had requests to comment on Android, SuperWaba, ACCESS and how the carriers will shape mobile development, and I'm flattered to be asked. But whatever small time I can make to blog these days is going to be occupied with stuff that's at the forefront of my mind that day, so please forgive me if I can't predict when I'll get around to these topics. I'm sure I will.

So you've no doubt read that Palm canceled the Foleo. A lot has been said about this and I could write volumes myself. But as you've noticed, time and energy for blogging has been very scarce of late. I did make a few comments on a couple of forums the day we heard about the cancellation and in the interest of time I'd like to piece them together into a coherent post that says some things I haven't heard said anywhere else—why Foleo was really canceled and what it means for Palm.

Foleo and its Linux OS were born at a time when Palm's founders were returning to the helm of a Palm that had been ravaged by poor management and divested of its own OS supplier. They looked at the successor to Palm OS 5 that PalmSource had built (Palm OS Cobalt) which had huge built-in risks because it was proprietary everything—kernel, drivers, middleware, UI layer...at one point they were even developing their own compiler. They looked at the fact that an independent PalmSource would have its own business priorities. They identified it as a potential acquisition target for their competitors. And when they finished saying "Holy crap!" they decided three things.

First, they would hedge their OS bets by talking to Microsoft about using Windows Mobile; second they would keep a sharp eye on any acquisition activity directed at PalmSource and be ready to defend against it; and third, they would have a backup plan in case they were unable to keep control of Palm OS. They didn't want to be in a position where Microsoft was the only way to go forward. Working on Foleo was a way for Palm to implement a back-up OS plan that would fold into product development no matter what became of Palm's relationship with PalmSource. If PalmSource for any reason failed to deliver a smartphone OS that satisfied Palm's requirements, they probably reasoned that the work and in-house expertise developing Foleo could become the basis of a new in-house Palm OS. Foleo was Palm's "Next Big Thing" and it was also an insurance policy for their bread-and-butter smartphone business.

That's probably how I would have figured it, too. But Palm didn't have the luxury of being dealt their best-case scenario. First they failed to keep PalmSource from being acquired when ACCESS made a $324 million bid that Palm knew its shareholders would not be willing to match. Now Plan B had to become Plan A because Palm needed to keep control of their OS destiny if they were to differentiate and survive. If I'm right, at that point the Foleo team was developing the OS that Palm planned to use on future smartphones as well.

The next problem was, well... we don't know, exactly. But I have pretty good idea.

I think we can surmise that when Palm made a big deal to the media back in March about bringing in Paul Mercer, a guy who is famous for architecting the iPod OS as well as that of some very slick iPod competitors from Samsung, there was already a big rethink going on at Palm. Mercer is the kind of guy you'd hire to be a lead in a new OS project, not to join one mid-stream where most of the big architectural issues had been settled.

Still more telling, Mercer's outspoken views on system design are quite a departure from the traditional Palm approach, which is to keep application code close to the metal for maximum efficiency. "This is a ridiculous notion that’s been left behind by history," he once said in an interview on Intel.com. "On a network device, you simply can’t afford native code." He founded Iventor in 2000 to develop a "high level runtime environment for deployment of advanced, dynamic user interfaces." That's certainly the direction that Palm's competitors have taken, with Microsoft and RIM moving away from C/C++ native application interfaces and toward virtual machines that execute "managed code" for greater security and reliability.

Sure enough, Palm has posted more than a dozen device software positions over the last two months that list Java experience as a requirement. One from July read in part:

Development engineer for implementation of Java based mobile system software on new product development project. Responsible for all mobile development (design through implementation and release), working with other device engineers and design lead on overall system architecture and design.

It looks very much like Palm reached a decision back in February that it would not be repurposing the Foleo operating system on its smartphones after all. Instead they would have a go at adapting Mercer's platform technology to the smartphone Linux OS and let the Foleo team finish out their work.

That's crazy on multiple levels. Ed Colligan admits as much when he explains the cancellation of Foleo as a way to refocus Palm's development efforts. Supporting two operating systems, with separate toolchains and SDKs is more than a company Palm's size can handle. But just as important, the Foleo is a smartphone companion: its applications should be source compatible, if not binary compatible with those that run on the phone so developers can create paired applications easily. And it's not like Palm has no need for urgency in shipping a new OS on its smartphones. What could have prompted a decision to make a fresh start?

Now, Mercer is a magician when it comes to coaxing stunning graphic effects and elegant, performant user interfaces out of resource-constrained devices. If you have seen some of his recent work you'll know to expect a beautiful UI on the next Palm OS. But I've spent some time with the Foleo operating system and it's a very nice piece of work, too. I'd go so far as to say that Palm's lightweight DirectFB windowing system sets a new standard of responsiveness and simplicity for mobile Linux. As far as I can see, it would have made a great smartphone OS. Given how far Palm had got with Foleo, there's really only one solid reason I can see for Palm pulling the plug on it.

That would be the wireless carriers.

I have some grave doubts that the carriers in the US are enthusiastic about releasing phones with a new, open native Linux platform. Sheesh, they're even twitchy about sandboxed Java MIDlets running on their phones. AT&T completely blocks access to the file system by a Java application. No files for you! There are mass market phones with native APIs, namely BREW, but getting an app onto those handsets is a little like mustering a siege on a well-fortified castle. Certifying a single BREW C/C++ application to run on Verizon handsets costs several hundred dollars and requires at least a couple months of testing by NSTL, often much more. Then if you tweak a feature or fix a bug, you must certify again. The carriers do not want support hassles, and it's the native applications, which are vulnerable to buffer overruns and security problems, that concern them the most. Dollars to doughnuts, more than one Tier 1 carrier came to Palm with a requirement that native applications would have to be digitally signed and undergo rigorous carrier testing to run on their phones. That would have thrown a huge bucket of ice water on Palm's developer ecosystem. It's even quite possible in my view that one or more carriers said "no native 3rd party applications at all" as I bet at&t said to Apple. "Why can't you bring us an OS with a nice Java runtime environment for applications like your competitor, RIM?"

Ouch. Was Palm faced with a choice between torching it's 3rd party ecosystem and torching the OS it had been working on for two or three years? I have a feeling they were.

So there sat Paul Mercer, "dreaming about a personal device that offered complete access to information and media" where he could put his eye-popping, secure mobile runtime environment to work.

And there went the Foleo OS.

Foleo will be back. I doubt very much that Colligan would have mentioned a "Foleo II" if he wasn't pretty darned confident he wouldn't suffer the embarrassment of a second Foleo cancellation. And when it does come to market Foleo will surely be running Palm's tweaked Linux kernel, just like the new Palm smartphones will in a year or so. But the evidence points to the high-level intefaces being some flavor of Java, not native C. (Don't worry, I'm sure there will be a Garnet emulator for backward compatibility—for a couple years anyway.) If you're a developer and next year you're able to write "Palm OS" applications that you can distribute without carrier testing and pricey digital signing, you'll probably have Paul Mercer to thank for that.

And if your apps start fast and are as snappy as the original Palm OS when they run on the phone, thank Ben Combee and the Foleo team for that. You'll know their work on the Linux underpinnings was not in vain.

I'm putting a good face on this. Frankly, the cost in time, money and reputation is awful. It's not just that we don't know when we'll ever see the Foleo again (and I do think the concept is important and viable). It's that there will be still more delay before we see a Treo running a new Palm OS—12 to 18 months, says Colligan now. On the (slight) upside, since it typically takes that long for a new smartphone with an existing operating system to make it through all the carrier testing and approvals, this actually means that Palm is pretty close to being done with the new new smartphone OS and has hardware ready to begin that process.

The ultimate decision to cancel Foleo "in its current configuration" was right, but the embarrassing debacle was avoidable. If I'm right about the change of course coming down to carrier requirements, Palm could and should have known its customers and seen this coming a long time ago.

Long time no post. It's been one of those crazy between-project times when you've got a dozen opportunities swarming around you like a cloud of gnats and, if you're like me, you can't wait to get back into the flow state, focused on one project. You'd think spending the day mapping the forest instead of staring at one tree would be conducive to blogging, but it's not. I have a theory, but I won't bore you with it.

In my last few posts I've been talking about mobile computing as the future of personal computing, with a lot of focus on Palm. I talk a lot about Palm on this site and before I continue I want to explain why. It's not because I'm completely bullish on the company's prospects—they've got a hard battle to fight in a market with some fierce competitors. Nor does my company make money from selling Palm devices (though we often recommend them to customers) and we create plenty of software for platforms like RIM, Windows Mobile and Java ME. I can't say that my interest in these guys isn't tinged by a bit of nostalgia. I cut my chops on developing for handheld devices on Palm OS. My first mobile application—a primitive blogging tool—was written, compiled and debugged with a stylus on a Handspring Visor during my commutes on public transportation to and from my job as a web developer in Houston. But that's not the reason I write about them in this blog. And, God knows, it's not because Palm is out on the bleeding edge of technology.

My interest in Palm is because they are still willing to listen to the guy with the most audacious vision for mobile technology around: Jeff Hawkins (to the shareholders' dismay) doesn't seem to care much about making smartphones iPhone-cool; he cares about a crazy idea of liberating people from their desktop and turning the devices in their pockets into their primary PC. For Hawkins (and to the gearhead's dismay) realizing that vision has more to do with holding products to a high standard of simplicity than adding features. In my view, Palm's greatest shortcoming in recent years has been a failure to simplify smartphones enough. The upcoming Foleo, to its credit, bears the imprint of the old Palm's focus on helping people do a few things simply and quickly rather than burying them with features that are hard or slow to access. This attitude looks like backwardness to some, but I agree with Hawkins that for people to start seeing their mobile devices as platforms for running useful applications the biggest challenge is not breaking technological barriers, but breaking down the barrier of "fundamental complexity" in computers. Any company can take a bunch of engineers and a big pile of carrier requirements and build a smartphone that's complex. How do you make mobile computers that people want to use as such? Whether they conquer that challenge or not, Palm takes it more seriously than anyone else.

But they're not alone in touting the vision of your mobile becoming the new PC. Not any more. Next post I want to talk about Nokia. It's still a little early to say, but there are hints that they have an idea very different from Palm of how this vision could come about, and I think the comparison is pretty interesting. Also, if anyone has a really long attention span and recalls me promising some wild speculations about how Jeff Hawkins might see mobile computing in a decade or so, well, I'll be getting to that, too, because I can't help myself. I think the Nokia/Palm comparison will be a good lead-in to that. Not trying to be dramatic... I just never have as much time to write as I need.

In my last two posts I offered an explanation for why Foleo sailed right over the heads of most of the technical media and why the vision behind it actually opens a major new front in the battle for the future of personal computing—one that puts the smartphone at the center of your personal computing universe rather than its current status as a wandering satellite. There are a number of objections to the vision behind Foleo—the fact that it hasn't been well understood by the techies being itself an indication of a problem for Palm. But I'm going to suggest here that most of these objections are challenges that are within Palm's capabilities to overcome. I hope Palm's new ownership configuration and John Rubinstein's hand in product development bring some sure execution on this post-PC plan, because I think it's a pretty compelling picture, even if it's crazy to be coming out of a company with the small size and somewhat faded reputation of Palm. Read my last post to understand why.

On to the objections:

Who wants to lug around two devices?

Foleo is for the millions of people who are already carrying around a mobile phone and a laptop, a mobile phone and a PDA, or most common of all: a mobile phone and a notebook or pad of paper. Most knowledge workers already carry multiple data tools with them when they move about the office or campus, take their work home, or take it on the road. Foleo is just a more integrated and functional pairing than the bag of tools they have today. The "two device" objection is something for marketing to address. Palm really needs to emphasize what you get to shed when you're carrying a Foleo with your smartphone. The heavy, fragile, slow-booting laptop, the binders of paper notes and reports, the novel you wanted to read when you got some down-time. That message will play well to the people for whom Foleo is designed.

I also think Foleo could have a decent market among people who don't even care to own a smartphone and just want a simplified standalone computer for writing and light Internet usage over WiFi. I've already talked with a surprising number of people who seem enchanted with it almost on sight, but it's difficult to know whether Palm can have success reaching these customers when their primary target audience is so different. They'd probably need to launch a specific model for this group, kind of the way they aimed the Z22 PDAs at (mostly female) users who wanted ultimate simplicity and basic PIM above all else.

Great, but what if I need Application X?

From what we've heard so far it sounds like Foleo has the same 80/20 mix of the most required features in MS Office and Outlook as you find on the Treo (assuming they have a synchronized calendar and contact list in there, which I'll bet they do by the time it ships). If the Treo is any indication, with Documents to Go you should be able review and edit Word documents, Excel spreadsheets, and PowerPoint presentations and save them in their native formats. In fact, MS Office support has long been better on Palm OS devices than on Microsoft's Pocket PCs. These applications are practically all of what many working people do with their PCs and if they can shed several pounds or several hundred dollars of the cost of making these applications both portable and ergonomic, a great many will be happy to do it.

But that phrase "practically all" is a sticky one for Palm. People do have other applications they like—or are required—to use on their PC and I agree with Michael Mace that there's a pretty insistent voice that says "well, I better carry a full-blown Windows machine, just in case." Palm obviously needs to do a great job supporting 3rd party developers to fill in as many gaps in the application ecosystem as possible, but they also ought to do something clever to quiet this nagging voice of resistance.

I think one thing that would help is to license a PC remote control product like pcAnywhere or LogMeIn and ship it with the Foleo. Make sure it's a native application, not something that runs in the browser and requires a site registration and a bookmark. Make sure users can tunnel securely through port 80 on the firewall (or partner with Cisco to line up a VPN client) so they can get to their office PC and control it with the pointer and keyboard from any place they're connected to the Internet. Then market this as a use case: "your office PC from anywhere."

I use a remote control application with an open protocol called VNC a lot, sometimes spending entire work days connected via a virtual private network to a workstation on the site of a client. It enables me to run Eclipse, WebSphere, MS Project, Office, a native CRM application, and so on, without having any of these applications actually installed on the computer I'm connecting from. Many businesses are uncomfortable with letting certain sensitive data live on hard drives that leave the building, and they see allowing this kind of remote access as the right mix between mobility and security. On a broadband connection you can almost (not quite, but almost) forget that you're working on a remote PC. I have a VNC client that I use to conduct remote PC sessions on my Nokia N800 tablet, too, but with the Foleo's big screen and keyboard this would be infinitely more practical. It's not a perfect solution (for one thing, the experience would suffer on a slow connection) but I think it would be enough to convince a lot of business users and IT departments to give the "what if" voice a rest and see that Foleo is finally a mini-laptop computer they can afford.

Foleo is a niche within a niche

I've read this objection a few times: "Smartphones are still a niche in the overall mobile phone market, so selling to some fraction of that niche isn't exactly a marketing plan for a disruptive product." I get it. And, yeah, it's a challenge for Palm. But I'm not convinced the math works out as badly as it sounds. 70 million smartphones is a pretty healthy niche, and one that promises to grow more rapidly with the splash from the iPhone and its competitors. Treo has been extremely influential (and profitable) in that market with a very small piece of that pie. And Foleo isn't just a Treo companion: it's designed (optimistically) to work with all of the smartphones out there. Personally, I think the "niche within a niche" characterization is a negative spin on a situation that's actually pretty good. I'm more worried about the next objection.

The micro-PC space is already crowded by formidable competitors

It's a pretty exciting time when experimental form factors that split the difference between handset and laptop PC are starting to get the muscle of Intel, Microsoft and Nokia behind them. It's also a confusing time for consumers, who are trying to figure out what these things are and whether they are cool toys or things that might solve real problems for them.

In my opinion, the UMPC-type devices are not going to drive a lot of adoption because they are too generic to present a real solution to users. Sure the prices will be coming down, but the problems they address are too diffuse for most people to say "hey that's what I need to do XYZ that is a pain for me to do now." Palm is right to highlight one thing that Foleo does really well and build the marketing message around that. The other use cases will flower up around it.

The problem is, once Palm gets through to someone with that vision, Foleo's physical similarity to a standard mini-laptop is crying out for comparison. The same techies who panned the Foleo as pedestrian and uninspired are going to be hyping new gadgets like the Intel Mobile Internet Devices, bringing peoples' attention back to feature lists, specs and shiny, fresh-looking hardware. It doesn't take long before a lot of folks who "get" the Foleo concept start thinking these other devices could be pressed into service on the same use cases. I know that it's not feature lists that sell products, but like a lot of folks I sometimes worry that even the best marketing pitch from Palm could end up selling a lot of non-Palm products. This can cut both ways, and with a new device category the last thing you want is to be small and alone in the market. But the resources arrayed against Palm are daunting and there are other visionaries out there.

The only thing I have to say on this one is that despite their apparent underdog status, the Palm guys really do get the value of simplicity in a way that I don't think Intel, Microsoft or Nokia will ever understand. No one out there has a more user-centric focus than Palm. The original Pilot followed on a long, long line of failed handheld computers, many of which had much better feature sets. It prevailed because it took the path of simplicity at every single fork in the design process. I don't know how Hawkins understood this back then, but he knew something that few technology product designers understand to this day: a product is defined more by what it leaves out than what you put in. Simplicity in technology is much harder to create than you think, but if you succeed, it sells. Add features after you've hooked people with it.

If Palm can deliver a full-screen mobile computing experience that exudes the same ethic of simplicity and instant response as the Palm Pilot, then get people's hands on it with a strong retail presence (partnered with the carriers and the Big Box retailers) I now think they have a fighting chance at a great third act. And they may very well play the pivotal role they have aimed at from the company's very inception: turning your mobile into your primary PC.

I promised some speculation about an even longer view for the Hawkins vision. That will have to wait for my next post.

[Updated Jun 17, 2007]

Yesterday I wrote that Palm's recent product announcements, especially the Foleo (which was really a pre-announcement) are indicative of a bigger, more disruptive vision than most people give them credit. The strategy I see Palm taking is one that opens a new front on the battle between the two prevailing visions of computing today, the one that puts your PC at the center of your computing life and the other that sees "the network as the computer," commonly known as Web 2.0. First, I'll take a look at what that battle has been about and then show why and how I think Palm is trying to change the game. In my next post I'll look at some of the obstacles Palm needs to overcome for this vision to become a reality, and add some foolish musings about a fourth act in the remarkable drama that Jeff Hawkins is writing and producing.

Why do people care whether their data and the software they use to work with it live on their PC or on an Internet server that provides a rich AJAX browser interface to it? A lot of people don't, which is one reason why web-based applications (often but not always free) are leading the software adoption landscape today. But if we wanted to really analyze this shift we'd want to look at the relative virtues of native PC versus Web 2.0 applications along several dimensions that people care about. Since I have a penchant for the pompous I'll call them the "Eight Computing Virtues." (Hey, just be grateful that "The Noble Eightfold Path" had already been taken.)

The Eight Computing Virtues

• Richness. Short for feature-richness. What input and output options are available? Many computing features come from a computer's operating system, so what kind of access is there to the OS?
• Capacity. How much stuff can you store for any given cost?
• Security. How safe is your stuff from being lost, stolen or corrupted? How easily can your computing environment be hijacked by the bad guys?
• Privacy. How safe is your stuff from prying eyes? How easily can you have a computing session that's private from other people in your home or office?
• Availability. Is your stuff at your finger-tips wherever you go? How reliably?
• Sharing. How conducive is your stuff to being shared with others? Does it enable you to tap into the "hive mind?"
• Simplicity. How easy is it to learn all the things you can do? Can you do them with minimal effort and thought? Is your environment free of clutter from things you don't care about or that demand frequent maintenance?
• Responsiveness. Does your software respond instantly to your every gesture? Does your computer jump to life instantaneously when you need to interact with it?

Using these virtues as dimensions for comparison, I would map out the relative benefits of natively installed PC applications and web applications like this (closer to the edge of the circle means a higher rating along that radius):

It's subjective, but qualitatively I think most people would agree that the big attraction of web applications has been the enhancement of sharing and the fact that your apps and data are available from any PC with an Internet connection. People are more mobile than ever, and they have more PCs in their lives—office, desktop, laptop, the PC in the hotel lobby, the client's office, the best friend's house—so it's quite liberating that their web applications and data are "on" all of them. I'd also contend that many web applications have gained traction because of an ethic of simplicity among Web 2.0 developers. And I may have exaggerated the security benefit, but I do think a lot of folks see Google as being a safer place for their data than their PC hard drive, even if it doesn't relieve them of the pain and uncertainty of securing their PC from malware.

What still holds people back from using Google or Zoho in place of Outlook and MS Office? Native applications are still more feature-rich, more responsive to input, and they live in a box where (for now) your storage dollar goes a bit farther than on the web. They also can run off-line, a partial compensation for the fact that their attachment to PC hardware rather than "the cloud" makes their accessibility inferior under many common circumstances. APIs like Google Gears may be eroding that advantage (some say they are game-changing) and AJAX is making inroads on the rich, responsive UI. Still, it'll be quite a while before we have something like Photoshop or immersive 3d games running in a browser.

But I think one of the biggest factors that will inhibit adoption of web applications is privacy. The companies that hold our data on their servers simply have too strong an incentive to peer into that data and too little accountability for lapses or active violations of our privacy. This week, Google, the company that has more of our data than anyone, was rated as the worst privacy offender on the web. And too few months seem to pass between revelations like AOL's exposure of personal data of 650,000 of its own users.

So what's this got to do with Foleo?

I've read a number of comments from folks who watched the Foleo announcement and thought that Palm's "bigger picture" for the device was (or should be) running web applications. I think Opera 9 will be a capable AJAX-compatible browser for such use, but Hawkins and his team have their sights set higher. Others, myself included, have said that Foleo in and of itself is really a new take on the PC and that Palm should just come right out and say this. But this isn't it either, really, despite the fact that Foleo is attractive to people who are looking for a simpler, more portable PC.

For Hawkins, it's the smartphone that is the new PC. The Foleo is just the piece that completes the vision.

Here it is in his own words, from the "Experience Foleo" Flash video on palm.com:

When we started this company in 1992 it was based on a very simple vision: that the future of personal computing would be mobile, that over time more and more of your personal computing needs would be satisfied by a device that fits in your pocket or purse.... We want to make the computer smaller and smaller, and we can do that. We can put more memory in it, we can put more data in it, we can put movies and pictures and so on. So we thought about the future, and we said, well, in the future people are going to have these very powerful portable computers in their pocket. But, they have these two limitations: there are times when you need a large display, and there are times when you need a large keyboard.... In our mind the future of mobile computing has and always will be small devices that are in your pocket, that contain all your data, access to the Internet and so on. And there is a need for a large screen experience..... We believe [Foleo] is really a beginning of a whole new wave of finally and truly making the mobile device that's in your pocket your primary PC.

This makes a hell of a lot of sense, and it's only going to be making more sense as storage gets denser and cheaper. Also as wireless gets faster and more affordable. For a lot of PC users today, the two to eight gigs of Flash you can affordably put in the SD slot of a smartphone is already enough to hold all their data. If you're a heavy media user you need a lot more, but the ability to access your full media library speedily over a high-speed wireless connection is fast closing that gap. There's really not much left that keeps you from having everything you care about in your pocket wherever you go. Palm may very well have correctly identified the last piece of the ideal personal computing setup for a lot of people.

Let's look at this in the light of the Eight Computing Virtues.

Nothing is more available or private than what's on your mobile. You can't beat it for instant-on responsiveness, either. While even the best cellular wireless networks still introduce more latency in the use of the mobile web than a PC connected to fixed broadband, WiFi is highly available in a lot of the use cases that Foleo is targeting, and WiMax is just around the corner. The factors that bring people back to their PC more than anything else are its immersiveness, ergonomics, and seemingly unlimited capacity. While Foleo is not an always-on-you device like your phone, it shows great potential for making that fuller PC experience a lot more portable, responsive, and simple. No one is saying it's going to replace your PC, but supplemented by Foleo, your smartphone could start to occupy a lot more of the time you once spent at your PC, as well as expanding your digital life with some new use cases you probably never thought you cared about.

I'm guessing it will take a couple of generations of this product, coupled with attendant growth in smartphone and wireless data adoption and solid execution by Palm, for it to break into the mainstream (more on this in my next post). But Foleo is a very carrier friendly product because of its expansion of the utility of wireless data and the fact that the value it adds to a smartphone doesn't necessarily come from installing 3rd party software on the phone. The latter is something that the carriers still have reservations about and that hasn't in any case taken off with consumers as many had hoped. The carrier angle gives Palm a potential leg up when it comes to marketing and should expand Foleo's retail footprint well beyond what they could do on their own. The fact that it could work with almost any smartphone on the market is also big. The idea that little Palm would be taking a run at the PC itself is still totally audacious and sounds more than just a little crazy, but I really think there are a number of important stars coming into alignment here, and it's going to be exciting to watch what happens. Much more exciting than you might think from the cool reception Foleo received in the blindered technical media.

In my next post I'll look at some of the objections and challenges to this vision. Plus I have a few musings of a more speculative nature to throw out there just because they're too tantalizing for me to resist. There's a lot to discuss here!