posted by Thom Holwerda on Mon 11th Mar 2013 14:51 UTC

The Palm operating system

How do you describe an operating system whose ideas, concepts, and approaches have pretty much defined the entire mobile computing industry? This question has been running through my head ever since I decided to write this article. A device's operating system and the user interface it employs are what you interact with on a daily basis; if the operating system and you, as a user, click, you form somewhat of an emotional bond with it over the years.

This hasn't happened on many occasions with me. Regular OSNews readers know that I have such a connection with what I consider the best operating system ever made, BeOS. QNX, back when it was possible to run it as a desktop operating system with its quirky PhotonUI, also has a special place in my heart. And that's about it.

So, what about Palm OS? You might think, after an article like this with more than 23000 words or so, that I have somewhat of a special connection with it. In reality, though, not really. I respect it for what it represents and for how it has defined the industry to this very day - but as a former Palm OS user, my memories of it aren't always fond, especially not when you take off the rose-coloured glasses of nostalgia. To further complicate matters, back in the PDA heydays, I kind of preferred the dark side.

This is not going to be a complete, thorough, 100% description of Palm OS and its architecture - I'm going to cover a number of lower-level aspects that I find fascinating, after which I'll move on to the more user-visible parts of the operating system. Let's start with the kernel Palm OS used.


The kernel

I had always assumed that Palm OS used a homegrown kernel, but as it turns out, that's only partially true. From version 1.x to version 4.x, Palm OS used the AMX 68000 kernel, one of the many kernels available for the AMX Real Time Operating System from Kadak. The AMX RTOS uses many different kernels depending on the target platform, so you have kernels for 8086 real mode, PowerPC, MIPS, ColdFire, and so on. Since Palm devices used 68000-based Motorola Dragonball processors, they opted for the AMX 68000 kernel.

However, Palm didn't use this kernel as-is. They only used the specific parts that they really needed, and ditched everything else. AMX 68000 is a preemptive multitasking kernel, but since there's no user-facing multitasking on Palm OS, there's little to no need to expose the more complex features of the kernel that make this possible to developers. In addition, Palm wanted to prevent the kernel from becoming too complex, since they wanted to retain portability (this turned out to be a very smart decision) for everything that ran atop the kernel.

"The palmOne, Inc. Palm OS does not provide access to the underlying AMX 68000 Multitasking Kernel," Kadak explains on its website, "Instead, it provides a preconfigured collection of AMX tasks and AMX compatible device drivers which manage the Palm device. The Palm OS then provides an application API which offers the range of services needed by most developers to extend the functionality of the Palm device into a particular application area."

Jim Schram, while working at PalmSource in 2002, provided some more details on a Palm developer mailing list. "The Palm OS uses AMX tasks, timers, semaphores, mailboxes, and signal groups. Nothing too complex," he stated, "We wanted to keep it simple to enable easier porting to other kernels (which we've done in Palm OS 5) and because at the time AMX was chosen, there was no need for more sophisticated features."

Up until the Palm OS 4.x series of releases, Palm continued to rely on the AMX 68000 kernel. However, it became clear right around the start of the new millennium that the Dragonball architecture was no longer competitive. As such, Palm switched to the ARM architecture with the release of the Palm Tungsten T in November 2002, which opened the platform up to a whole slew of new possibilities, such as improved multimedia support, higher screen resolutions, and so on.

Switching to a new architecture meant choosing a new kernel. While Palm could've opted for the AMX 4-ARM kernel, the company decided to 'go custom' and create its own kernel. Therefore, the first version of Palm OS 5 includes an entirely new and custom kernel, written by Palm, affectionately called 'MCK' after its author. Sadly, I was unable to find out who these initials (?) refer to.

For its initial version, Palm decided to - again - keep things simple, and implement more or less the same functionality for MCK as the old AMX 68000 kernel provided, meaning that the same third party developer restrictions still applied. Still, Palm did have plans to expand the functionality - just not for its first release. "Support for additional background threads, timers, etc. is being added in a future version of the Palm OS. However, in v5 we thought it better not to bite off more than we could chew," according to Schram.

It's clear that Palm did indeed have at least some ideas about and plans for structural improvements to the lower levels of the operating system - just how serious these ideas and how far along the plans were will most likely remain a mystery forever. The ill-fated Palm OS 6 Cobalt (which I'll get back to later in the article) may provide some answers to this particular question.

The switch from Dragonball to ARM didn't just necessitate a different and/or new kernel; Palm OS also needed a method to ensure that the huge existing collection of applications written for Palm OS 4 and earlier would still run on Palm OS 5 and its different architecture. Palm's solution to this problem was the Palm Application Compatibility Environment ("Professional Palm OS Programming" is a great book on Palm OS' internals), or PACE.

For any call to a Palm OS function made by an application compiled for 68K, PACE executes the ARM equivalent of said function. This normally creates a lot of overhead, but the ARM processors were so much faster than the Dragonball ones that 68K applications actually ran faster using PACE than running natively on a Dragonball device. It was also possible to create a native ARM code module, which could be linked into a 68K application - this was especially important for applications that did a lot of number crunching.

PACE also took care of a more exotic problem arising from switching between the two architectures - endianness. Since I don't want to butcher this, I'll just refer to the description found in "Professional Palm OS Programming".

In addition to handing 68K operating system calls off to their native ARM counterparts, the PACE converts 68K data structures into their ARM equivalents. Unlike the big-endian 68K architecture, ARM stores multibyte integers in little-endian format. ARM hardware also requires that 4-byte integers be aligned on 4-byte boundaries; such integers need to be aligned only on an even boundary in the 68K architecture. These differences in data storage mean that Palm OS structures, such as those used to contain information about a form, differ significantly between 68K and ARM.

The end result of PACE was that the transition from 68K to ARM was relatively transparent for users. I can't recall ever encountering any issues running 68K applications on ARM Palm devices, but then again, that doesn't mean they didn't exist. The only complication I can recall is that Palm OS didn't provide support for fat binaries, and as such, you had to choose between a 68K and an ARM version when downloading an application.


There is no file

I'd like to cover how Palm OS handles files, because it has a rather peculiar way of handling them, as unlike most other operating systems, it doesn't actually make use of a file system. We're going to get quite technical here, and to be honest, this goes a bit over my head, but I do believe I grasp the general gist of what's going on.

Very crudely put, a conventional file system does not edit information stored in a file 'in place'. Instead, the file (or the relevant part of it) is loaded into a memory buffer, where it is read and/or altered, after which it's written back to disk, including the changes. However, Palm OS uses RAM for both dynamic and storage purposes, and (especially earlier in its existence) had limited quantities of either. As such, Palm OS' engineers took a different approach.

Instead of relying on the concept of files, Palm OS uses 'records' and 'databases'. Records are chunks of memory, which are stored in databases. A database, then, is a list of memory chunks and a bunch of metadata about the database as a whole, the database header. The header contains a number of fields such as name and version, but the most important of these fields are type and creator. The former tells the system if it's an application or a data database, while the latter makes it possible for the system to associate various databases with one another.

It vaguely reminds me of application bundles in systems like RISC OS, NEXTSTEP/GNUstep/Mac OS X, and others.

Records that need to be edited are not loaded into RAM first; instead, they're edited in place by Palm OS' memory manager and data manager APIs. In other words, chunks do not have to be loaded into dynamic RAM, meaning you need less of it, while also eliminating the overhead associated with moving data between dynamic RAM and storage. Because of this, application developers are not allowed to directly interact with records, because they might screw things up; they must use the memory manager and data manager APIs, because if they edited them directly in a manual fashion, they might damage them, which is particularly problematic due to them being edited in place.

Other than RAM and performance improvements, this approach also has a few other benefits, the most important of which is that databases' records can be intermingled with one another (i.e., it doesn't matter where a record is stored). This means that adding, removing, or deleting records does not require other records to be moved around, further reducing overhead.

When you transfer Palm OS databases to a regular file system, they get the file extension .prc or .pdb. That's why when you download a Palm OS application from the web, it often comes with the .prc extension. "The PRC file, then, is simply the flat file representation of a Pilot resource database," Theodore Ts'o explains, "When the PRC file is loaded into the Pilot, it is converted into a resource database using the Palm OS routine dmCreateDatabaseFromImage()."


Single-tasking (but not quite)

Conventional wisdom: Palm OS cannot multitask. You can only run one application at a time, you can't have applications or services running in the background, and opening an application will kill the current one. This conventional wisdom is true, but not entirely. There's a few details about how the Palm OS handles running applications that are quite fascinating, and which, at times, reminds me of Android's Application Components and activities.

Theoretically, the situation on Palm OS is quite straightforward. There can be only one application running at any given time. An application is closed when another application is launched. Interestingly enough, this includes the actual application launcher itself - so, unlike, say, iOS or Android, where respectively Springboard or your-launcher-of-choice continue to run even if another application is running, the Palm OS launcher is actually terminated every time another application is opened.

Technically speaking, the home button on a Palm OS device doesn't take you back to the launcher, it actually launches it. For some reason, I find this quite fascinating. Alternative launchers also existed for Palm OS.

On a more technical level:

Palm OS Garnet and earlier versions of Palm OS have a preemptive multitasking kernel. However, the User Interface Application Shell (UIAS), the part of the operating system responsible for managing applications that display a user interface, runs only one application at a time. Normally, the only task running is the UIAS, which calls application code as a subroutine. The UIAS doesn't gain control again until the currently running application quits, at which point the UIAS immediately calls the next application as a subroutine.

This all seems fairly straightforward. However, as with just about anything in life, nothing is as simple as it seems. Palm OS actually contains a number of mechanisms which allow for some rudimentary forms of something that could be classified as multitasking. It's not quite the kind of multitasking you can do on your octocore Windows 7 box with 32GB of RAM, but the capabilities still somewhat question the conventional wisdom about Palm OS.

I'm going to discuss three of them: launch codes, notifications, and helper notifications.

The first of these mechanisms in Palm OS is the concept of launch codes. As their name implies, launch codes launch applications. The most basic launch code is sysAppLaunchCmdNormalLaunch, which instructs the application to do a full, regular launch and display its user interface. Tapping an application's icon in the launcher (or pressing one of the hardware buttons) generates this launch code.

Launch codes can also be used to instruct the application how to behave. There are quite a number of standard launch codes the operating system provides, and, when necessary, application developers can define their own launch codes as well. For example, sysAppLaunchCmdGoToURL launches an application and tells it to pass a URL, while sysAppLaunchCmdFind finds a text string.

Furthermore, launch codes can be accompanied by two types of information (as per the Palm OS Programmer's Companion):

  • A parameter block, a pointer to a structure that contains several parameters. These parameters contain information necessary to handle the associated launch code.
  • Launch flags indicate how the application should behave. For example, a flag could be used to specify whether the application should display UI or not.

The cool thing about launch codes is that they can also be generated by applications to launch each other without actually switching applications from the user's perspective. I.e., if application Abc uses a launch code to launch application Xyz, application Abc's UI remains visible to the user. From a technical standpoint, application Xyz is now the current application (and thus has access to storage), but from the user's standpoint, Abc is still the current application because its UI is still visible (one a side note, there's also SysUIAppSwitch - which does exactly as the name implies. It will close your application and launch another one, including its interface).

There are countless ways this system can be useful. For instance, a mail client can use launch codes to instruct the address book application to find a specific phone number and return the results - without actually opening the address book. Many launch codes are sent to all applications at once, but only relevant applications will respond. This means that when you are searching for a phone number using a launch code sent to all applications, the music player won't do anything because that obviously wouldn't make sense.

The second mechanism I want to discuss in light of pseudo-multitasking are notifications. You are forgiven for thinking I'm talking about these things, but I'm not. Notifications, in Palm OS parlance, are sent by an application or the system itself to an application, instructing it to do something (or not).

The difference between launch codes and notifications it that while launch codes can only be sent to and received by applications, notifications can be received by any code resource, like shared libraries and system extensions. In addition, an application or resource will only receive notifications it has specifically registered to. In other words, they're more efficient than launch codes, which are often sent to all applications.

Furthermore, notification clients (the receiving ends) can add to the notification upon receiving them. For instance, the Palm OS Programmer's Companion notes the antenna on the Palm VII (a truly intriguing device in and of itself); a client could set the handled flag for the sysNotifyAntennaRaisedEvent notification to true to inform other applications.

Every client can also add its own information to a notification, so it can actually collect data on applications. A potential use for this - inspired by modern mobile operating systems like Android and Windows Phone - is the creation of a share menu. You could send out a notification asking which applications can share a photo, and every relevant application would add itself to the notification, through which the share menu could then be populated.

As a side note, Palm OS does actually have 'notification-notifications', i.e., what you most likely think of first when you hear 'notifications'. There are three related frameworks in Palm OS - the Attention, Alarm, and Notification Managers - that deal with these, and Palm OS provides support for dialogs, beeps, sounds, LED blinking, a subtle indicator in the top-left, and vibration.

The third and final mechanism related to pseudo-multitasking are helper notifications. These are used when one application wants to request a service from another application. The Palm OS Programmer's Companion gives the example of the Address Book application requesting that the Dial application dial the phone number the user has tapped. Palm OS also included other services through helper notifications, such as emailing, texting, and faxing. Remember that in the pre-smartphone/pre-wifi era, many of these services also required bringing up BlueTooth and making a connection to a separate phone. Crucial, of course, is that application developers can define their own services to use with the helper notification framework - and surprise, they can.

Of course, applications could query what other applications supported. It could ask an application for a list of services that it provides, request that the application make sure it can perform the service, and, finally, the actual request to perform the service. The benefit of this system over, say, launch codes is that launch codes require that the application developer knows the actual launch codes and the ID of the application it wants to launch, whereas with helper notifications you're using a standardised framework that doesn't require any application-specific knowledge.

None of these mechanisms constitute true multitasking by any stretch of the imagination. In essence, all of them are examples of inter-application communication which can perform some of the tasks that would otherwise be done through traditional multitasking (on, say, a desktop computer). All this is not done because Palm OS is inherently incapable of multitasking.

On a technical level, Palm OS is capable of multitasking just fine; in fact, during syncing, the Sync application starts a second task (the first one being the UIAS) to handle communication with the desktop computer (as far as I can tell, this is the only official case where multiple tasks are running - and even then, this second task is running at a lower priority to maintain responsiveness for the UI).

Even on the user interface level, there's provisions for multitasking: tapping/pressing and holding the home button opens a menu of recently used applications, ordered by last used. This way, you can quickly switch applications, and thanks to Palm's incredibly quick application loading (generally, zero lag), it feels like multitasking. To further add to the illusion of multitasking, Palm OS applications can save state.

Combine all these things, and Palm OS offers a surprising amount of options to developers with which they can create a pretty convincing illusion of true multitasking. Add to this the fact that developers get to define their own launch codes, notifications, and helper notifications, and you can envision some pretty advanced stuff. In fact, the screenshot application I used for this article uses helper notifications to 'run' in the background.

Not bad for a single-tasking operating system.


Graffiti

That long-winded first part of this article wasn't for nothing. It's impossible to talk about Palm OS without addressing what arguably is its most recognisable feature: Graffiti, its handwriting recognition system.

Before the Pilot, the Zoomer already came loaded with Palm's handwriting recognition, then dubbed PalmPr, which recognised a user's natural handwriting, and you could write anywhere on the screen. However, recognising a user's natural handwriting is hard, and quite prone to errors. So, when working on developing the Palm Pilot, Hawkins had an epiphany - instead of trying to get the computer to recognise a user's natural handwriting, why don't we create a simple, easy-to-learn alphabet that's much easier to recognise (remember the key takeaway from the Stylator)? Sure, users had to learn a handwritten alphabet, but hey, users need to learn to touch type, too, right?

And so, Hawkins developed the Graffiti alphabet. Graffiti was simple, and, quite ingenious in that it consisted entirely of single strokes, which made it much easier to write with the stylus. Since I can't resist writing this one down: it was a stroke of genius.

During that one faithful evening when Hawkins mocked up the wooden model for the Palm Pilot, he also came up with the idea of having a dedicated writing area. Up until then, PDA-like devices had you write anywhere on the screen, from left to right. This posed obvious problems, problems that I can personally attest to when playing with whole-word write-anywhere input methods: you run out of space. The displays and digitisers are usually not sensitive enough for small handwriting, so you tend to write larger to ensure proper recognition. The consequence is that more often than not, you have to cut off mid-word because you just reached the bezel.

Hawkins devised the concept of writing everything down per letter, one atop the other. The single-stroke Graffiti alphabet made it possible for the system to understand that whenever the stylus was lifted from the screen, a character had been completed. The writing area was further refined by dividing it up into two areas: one for lower case, one for numerals. The area on the dividing line between the two areas was used for upper case.

Graffiti was a success even before the first Palm Pilot was released. Palm also released Graffiti for the Newton, and it was the default handwriting recognition system on GEOS-based portable devices like those from HP or devices running Magic Cap. Combined with selling synchronisation software to HP, this allowed Palm to get some income in between the failure of the Zoomer and the arrival of the Palm Pilot.

Sadly, the '90s computing industry wasn't free of patent lawsuits. Xerox claimed it had a patent on single-stroke alphabets, and successfully took Palm to court (in 1997) over Graffiti (even though the single-stroke alphabet in the patent bears little resemblance (page 5) to Graffiti, but alas). While the case went back and fourth a few times, Palm had to eventually pay Xerox $22.5 million in retroactive licensing fees in 2004.

In response to the then-ongoing lawsuit, Palm had to alter Graffiti to circumvent Xerox' patent. So, in 2003, Palm unveiled Graffiti 2, which, for the most part, they didn't actually develop themselves. They licensed Communication Intelligence Corporation's Jot handwriting recognition system, improved it, and labelled it Graffiti 2. It shipped in Palm OS 5.2 for ARM devices and Palm OS 4.1.2 for 68K devices.

The biggest change was that, in order to circumvent the single-stroke nature of the original Graffiti, a few characters now consisted of two strokes. This made the characters look more like their regular, written counterparts, but at the same time made them more error-prone to write. To this day, I often fail the dual stroke characters.

ACCESS, Palm OS' current owner, actually provides Graffiti for Android. Weirdly enough, this is Graffiti 1 - I'm guessing the licensing fees paid to Xerox covered non-Palm OS implementations (or the original patent has expired).


The user experience

Now that I've covered some of the lower level aspects of Palm OS that I found interesting, I want to talk a little bit more about the user experience. Unlike the technical details that I've covered so far, this is a more esoteric subject matter, and relies more on personal experiences, interpretations, and expectations, and is, probably, coloured by nostalgia. Just like with the lower levels of the operating system, I'm not going to cover everything, focussing instead on a few things that stand out to me.

First and foremost, the most defining characteristic of Palm OS - at least, in my view - is the sheer speed of the user experience. I've already offered a few glimpses into just how far the Palm OS engineers were willing to go for speed, and of course into how vital this was for Hawkins. He wanted the Palm Pilot to compete with paper's instant nature, and they managed to do just that.

Despite the archaic hardware Palm OS ran on - compared to today's massive smartphone beasts - almost everything you did was almost always instant. It often feels as if Palm OS responds even before you tap. Of course this isn't the case, but that's how it feels. I know of only one operating system that is as responsive as Palm OS is, and that operating system ironically ended up in the same place as Palm OS did.

My 'primary' Palm OS test and play device is a Palm T|X - the last true Palm PDA, which has all the bells and whistles, and runs the latest and greatest release of the operating system, Palm OS 5.4.9. It's running an Intel XScale PXA 270 at 312 Mhz (don't be fooled - that's ARM) with 32MB of dynamic RAM, and everything you do in Palm OS is instant. Even though this is technically the latest and greatest PDA Palm ever built, its processing power pales into insignificance compared to the quad-core powerhouses we lug around today. The fact that our modern smartphone operating systems actually need all this power and still aren't as responsive as Palm OS is telling.

That's all fine and great, but what happens if we take a step back in time and specifications and leave ARM behind? I've got a Sony CLIÉ PEG-SL10 running Palm OS 4.1, which uses the old 68K architecture, a Motorola DragonBall VZ 33 MHz to be precise, with a mere 8 MB of combined dynamic and storage RAM. On this device, too, Palm OS is instant. In fact, the operating system responds so well that the display becomes a bottleneck; the PEG-SL10 is equipped with a 320×320 monochrome display, but it's not TFT - it's STN. STN has a slower response time than TFT, and it shows; it just can't keep up with Palm OS.

As a Palm OS user, you expected stuff to be fast. You could spot a non-native application from a mile away, and not only because it looked different and didn't follow Palm OS conventions - non-native applications didn't adhere to the as-fast-as-paper mantra, and thus, were slow and far less responsive. I honestly believe that my almost militant desire for consistency between applications on an operating system stems partly from my days as a Palm OS user (and partly because of BeOS, of course), because something that looked out of place was probably going to be slow and cumbersome.

Palm OS wasn't only fast according to today's standards; it was also fast compared to its contemporary competition. Windows PocketPC (Windows Mobile) was Palm OS' primary competition through much of its lifespan, but when it comes to sheer speed and responsiveness, PocketPC was a laughable joke compared to Palm OS. As I've already hinted, I was a heavy PocketPC user, and I actually happen to have an iPaq with almost identical hardware as the Palm T|X (same processor), but it's a frustrating mess of loading times and spinning wait cursors.

It wasn't all unicorns and sunshine, though. Later in its life, you could see that Palm started to experience more and more problems with trying to extend the functionality of the operating system. Wifi, for instance, always felt like a bolted-on hack; connecting to the network was incredibly slow, and in order to preserve battery, it disconnected and turned itself off every time the device went to sleep. Very cumbersome.

The browser situation on Palm OS was a complete disaster, too. The browsers available were generally quite slow, and even when they were current they were terrible at rendering websites. Basically anything that required a direct internet connection through wifi was slow - whether it be loading a web page or checking for and downloading new emails.

It's easy to explain why: when Palm OS was originally conceived, the web and wifi were in its infancy, so they were never a core consideration during most of the development of the operating system. When it became clear that both wifi and mobile browsing became important for mobile devices, Palm had already spun off Palm OS development into a separate company, which turned out to be a complication for the further development of Palm OS (we'll get back to post-5.4 Palm OS later).


Zen of Palm

The last aspect of Palm OS that I'd like to cover in detail is what Palm itself referred to as "Zen of Palm". Zen of Palm is a core part of the operating system and its applications, and is one of the prime reasons why the platform became so successful in the first place. It defined every nook and cranny of the operating system, from its focus on speed to the design of applications themselves. Let's take a look at what this means.

One of the design goals for the original Palm Pilot, and all Palms that came after it, was that instead of competing with a regular computer, Hawkins realised it had to compete with paper (like a paper diary, address book, and so on). Other than meaning that the system had to be fast, it also meant it had to be simple, straightforward, and task-focussed. All this combined was governed by a set of design philosophies called 'Zen of Palm'.

The most important aspect of Zen of Palm is that when it comes to handheld computing devices, more features usually isn't better. I could spend a lot of words on trying to explain why, but just look at the 'spiral of doom' below.

In the world of regular computers, more features generally means better. Related to that, faster hardware generally also means better. These two forces strengthen each other: if you pile on more features, you're going to need faster hardware. If you create faster hardware, developers will pile on more features. Lather, rinse, repeat. Our current desktops may be sporting quad cores with 3700 kajiggers, but do they feel any faster than the machines you had a few years ago?

Palm realised that in order to make a handheld device that people wanted to use, it needed to break with the convention of the time that more equals better. So, Palm made two very bold decisions. First, it would only implement a very small set of features that it believed customers needed. Second, and related to this, Palm actively deemphasised the importance of specifications like processor speed and amount of RAM.

By not trying to keep up with the features and specifications race, Palm could focus on what it believed to be the 'essence of handhelds', distilled down into five core tenets:

  1. Handhelds excel at perceived speed. The obvious one: a handheld must be fast and responsive. Users don't care about the technical specifications, but only about if they can quickly get it out, find what they're looking for, put it away, and continue with whatever they were doing. Your handheld can have a quad core processor with 2 GB of RAM, but if it's slow and unresponsive, the user doesn't benefit from the fast specifications.
  2. Too many features frustrate customers. Speed suffers from having too many features in more ways than just overtaxing the hardware. Too many features also distract from the core features the user is most likely going to need because they get in the way.
  3. A handheld must be free to roam about. A handheld user shouldn't have to worry about battery life. Adding in lots of hardware and software features will only tax the battery more, causing the user to constantly worry about battery life, and if he'll make it through the day. Modern smartphones have piled on the features and specifications, but battery technology hasn't improved all that much. We all know the end result.
  4. Handhelds must be wearable. A handheld must be small and light. Loads of features and hefty specifications will require a bigger battery, making the device less pleasurable to wear. There's no such thing as a universal 'correct size', though. Take the Galaxy Note devices - they tend to be more popular with women than with men. The reason is simple: many women carry a purse to put the Note into. Men don't.
  5. Handhelds are about the user. This last one is a philosophical combination of the other four. Simply put, adding too many features degrades the user experience of a handheld device.

In the form of two simple graphs:

Palm even provided a version comparing Palm OS to Pocket PC.

When Microsoft put that Palm logo in the centre of a crosshair and vowed to kill and crush the company, they thought they could do so the only way they knew how. Microsoft was a PC software company, so they figured they could crush Palm through more and more features, and better and better specifications, user experience be damned. This tactic worked for Redmond in the PC business, so why wouldn't it work for the handheld market?

Palm knew why: it wouldn't work because usage patterns on handheld device are exactly the opposite of those on PCs. Handhelds are used very frequently, but in short bursts to quickly perform small tasks. PCs, on the other hand, are used less frequently, but the user sessions are much longer, and the tasks tend to be more complex and demanding. Palm OS was designed for the handheld usage pattern; Windows Mobile was not.

Because of all the boatloads of features Microsoft haphazardly shoved into Windows Mobile, the user experience was slow, complex, and frustrating. OEMs tried to solve this by faster hardware, but this significantly harmed battery life. In response, Pocket PCs got bigger batteries, making them heavier and more cumbersome. Windows Mobile had entered the spiral of doom, and there was no way back. The end result was that Palm OS dominated the handheld market.

Palm urged application developers to adopt the Zen of Palm approach to application design. I'm not going to detail all the advice Palm gave out, but there are a few nuggets that stand out and that I'd like to highlight. I urge you - especially if you are a mobile application developer - to read the whole document, since it's just as relevant today as it was ten years ago.

The most crucial question is probably how you go about limiting the amount of features your application has. First, Palm urges developers not to think in terms of trying to find ways to squeeze a desktop application's feature set onto a mobile device. Second, developers also shouldn't start with a desktop application's feature set and then try to remove features that might not make sense on a handheld. Instead, you should start from zero, and then add only those features that improve the user experience. "You don't pare down from 100 percent," Palm notes, "You start at zero and work your way up. Start with nothing, and add only essentials - one by one."

This leads to a second question - how do you determine what these essential features are? According to Palm, you identify the problems, find the simplest solutions to each problem, and get rid of everything else. In doing so, it's often best to limit yourself to using only proven and mature technologies, and not use technologies just because they're cool - only use them when they address a legitimate problem.

While you can ask your customers what they're looking for, Palm does note that they "do not always understand the limitations and consequences of the technologies they ask for. They don't realize that getting exactly what they ask for can be quite unpleasant." If you can't implement a feature in a satisfactory fashion, don't implement it. Or, try to find an alternate solution using mature technologies. In other words, don't think about what users say they want; think about ways to solve their underlying problems.

Palm also cites the well-known 80/20 rule - focus on what users do 80% of the time, and ignore the other 20%. This will, of course, harm fringe use cases, but it does allow you to focus on the things that matter to most of your users. "Pressing the Date Book button takes you to the current date," Palm notes, "Why? Because 80 percent of the time, users want to see what they have scheduled for today."

In keeping with the application-centric speed-focused design of Palm OS, it's also advised to break your application up into smaller, more focussed applications wherever possible. Several Palm OS devices shipped with DataViz' Documents To Go, which was a monolithic mobile office suite with a text processing, spreadsheet and presentation application all rolled into one. I personally never understood why DataViz didn't just provide three separate, smaller, and faster applications, using the faux-multitasking mechanisms cited earlier to allow them to interact. Documents To Go was a clear case of not applying Zen of Palm.

Once you do have your feature set nailed down, your application's UI should keep the amount of steps needed to perform common tasks to an absolute minimum, and lesser-used and power user-oriented features should be hidden in preferences and the application's menu bar. Palm also urges developers to adhere to the user interface guidelines (hallelujah!) so that users can apply the knowledge gained from one application to the next. Lastly, you're supposed to 'delight' the user, but Palm doesn't really detail what this entails.

Palm's Graffiti is actually a perfect example that encompasses almost all of the aspects of Zen of Palm. While the market was asking for full natural handwriting recognition (i.e., recognising any user's own handwriting), this required massive amounts of processing power and RAM, and thus, a bigger battery - so the devices became bigger but were still slow as molasses, and generally, the recognition still sucked (I'm looking at you, Newton).

Palm understood that instead of "how to get natural handwriting recognition to work", the real problem was "how to input text on a handheld". To solve this problem, you really didn't need natural handwriting recognition at all - a simple, single-stroke alphabet that was easy to learn was a far better solution, since it required far less processing power and RAM, which in turn meant better battery life and smaller devices. Since the recognition system only had to work with a small set of possible variations, it was also a lot faster and more accurate.

Despite the superior input method, Palm still focussed on tapping with the stylus as the main input method to use the device. The Newton, by contrast, included very cool features like recognising written-down times, dates and keywords to trigger the creation of appointments or to bring up contacts, but combined with the crappy handwriting recognition of the Newton, this was far less optimal than just tapping away with the stylus, and required more processing power to boot. By focussing on the underlying problem instead of the coolness factor, Palm arrived at a superior, if less flashy, solution.

I've only scratched the surface of the whole idea behind Zen of Palm - there's a lot more in there, and if you are a mobile application developer, you owe it to yourself to give it a read. It may be geared towards the dead Palm OS platform, but most - if not all - of its concepts are perfectly applicable on other platforms like Android, Windows Phone, and iOS.

Speaking of iOS, you have undoubtedly noticed that many of the ideas in Zen of Palm seem to have found their way onto the iPhone. I don't think this is a coincidence: I am convinced that the original designers of the iPhone and iOS were very much aware of Zen of Palm, and of the Palm OS in general. Reading through the iOS human interface guidelines, you'll encounter many of the same ideas, concepts, and approaches to application and operating system design.

Let me make it clear: this is not a bad thing. In fact, it's quite the opposite - Zen of Palm even specifically explains that studying your competitors' products is a good thing to do, because not only can you learn from what they do wrong, but also from what they do right. Palm OS/Pilot has a lot in common with iOS/iPhone not only in operation, approaches and design philosophies, but also in their respective roles in establishing a new category of devices and shaking up the entire industry.

I would have been more surprised if Apple's engineers hadn't taken a lot of cues from Palm OS, the Pilot, and Palm's philosophies. Palm was, after all, one of the most successful handheld companies of all time. Palm didn't create a market; they perfected it. The iPhone didn't create a market; it perfected it. The similarities are legion.

That being said, the differences are clear, too. Whereas Palm OS strived for user interface consistency, iOS never really cared about that. In addition, iOS' (in my view, childish and condescending) analog design (yes I will hammer that term into common parlance instead of "skeuomorphic") would never have passed Zen of Palm; Palm would have considered it useless fluff that would only worsen the user experience (Palm OS sits on the other end of the design spectrum: almost strictly digital).


Palm OS' legacy

So, what is Palm OS' legacy? What mark did it leave? How did it influence the industry?

Palm OS showed the industry what a mobile operating system for the average consumer should look like, how it should work, and what it should - and more importantly, should not be capable of. Consumers didn't want MS-DOS with a stylus input overlay. Consumers didn't want the confusing notebook metaphor GO and Apple used. Consumers didn't want a desktop operating system's interface shoehorned into a small screen. Consumers didn't want to have to deal with managing multitasking and the associated complexity. Consumers didn't want slow and bulky natural handwriting recognition.

They wanted a minimalistic, single-tasking operating system that allowed them to focus on a single task, and do so fast, without having to wait for programs to load or go through endless confusing dialogs and setup screens. Users wanted an operating system with a graphical user interface that was designed specifically with its primary input method in mind. They wanted an operating system that didn't require all the manual fiddling that the desktop operating systems of Palm OS' day required. They wanted an operating system that didn't drain the battery in a few hours. Users wanted an application-centric device.

Add all of these together, and 15 years ago, you got Palm OS.

Despite the improvements made to mobile hardware, today's mobile platforms still struggle with the same kind of trade-offs as Palm originally had to contend with, and they still make different choices. Remember that curve I showed you earlier, comparing Palm OS with Windows Mobile? I edited it a little to make it current.

It's clear that iOS and Windows Phone are closer to Palm OS in stressing user experience over features, while Android is much closer to Windows Mobile in stressing features and versatility over user experience. Note, though, that this is not necessarily a bad thing - it's just a trade-off. While Android is often a bit messier and less polished, its large feature set and incredible versatility more than make up for it. And sure, iOS and Windows Phone don't have all the features and versatility of Android, but this does make them feel more polished. You decide for yourself what matters to you - and so far, people overwhelmingly choose flexibility and features.

Which is interesting, because they didn't use to, because Palm OS dominated the market. I already hinted at my personal preference for Windows Mobile when it comes to PDAs, and this may seem weird considering everything I've written so far. However, I preferred Windows Mobile exactly because of its versatility and many features; I took the suboptimal user interface and battery life for granted, because I mostly used them at home anyway (also, I cheated - I used Palm OS while on the go, and Windows Mobile at home).

I'm sad that Palm OS is dead. I've done a lot of studying and investigating for this article, and I've encountered so many cool things that have made me realise that Palm OS was far less outdated and inflexible than I originally thought. Did Palm OS really have to die? Was it really at the end of its wits at version 5.4.9? Or was there life in the old girl yet?

We'll get to that in a minute. First, I want to discuss a subject I have yet to touch upon: Palm OS and licensing, and what non-Palm hardware makers contributed to the platform.




Table of contents
  1. Introduction
  2. History of handwriting recognition
  3. Palm's hardware
  4. The Palm operating system
  5. Miscellaneous
  6. I'm ready to wallow now
e p (14)    80 Comment(s)

Technology White Papers

See More