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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
Anyone got a link to the PDF?
Seriously, I’ll read the article later when I have some time
I kinda like the experiment. Let’s get rid of the shitty ad based culture – which I don’t see anyway as I use an ad blocker, who does?? – and get back to paying people for making content.
I hope Adam gets a slice too for hosting the site.
You will get my money Thom
Edited 2013-03-11 16:16 UTC
I agree with you. I will purchase as well, I would like to support this, and the ad driven model just promotes views with incendiary headlines.
The ads on osnews aren’t annoying at all, I’ve deactivated my adblocker here.
As long as these 2 points (no annyoing ads and good content) are valid I don’t see any need for an adblocker.
I bought the PDF. I’d like to see more long article with deep insight in history, development and decisions of a company. Maybe also some (technical) interviews with developers (e.g. with Jolla / Mer people)?
I can’t disagree more. The whole idea of advertising is to brainwash you to buy something or to buy a specific brand.
Clearly this brainwashing is working else advertsing would have stopped a very long time ago…
To me it seems that every year humans become more and more a consumer, someone you can sell something to, an economic resource rather than a fellow traveller of life.
I also don’t buy into the argument that else ‘many sites would disappear as you deprive authors from an income’. Before 2000 most websites including OSNews -still is- were a labour of love, content was good, web design often bad geocity anyone??. After the commercialisation of the net, it’s often a dime a dozen.
Just take a look at technology sites: engadget, theverge, ars technica, pocket lint, boy genius report, anand, pcpro uk, wired, slashgear, etc etc.
Now surely they look slightly different and all have a slightly different angle but by large they review the same products. Often their existence is to make money from product announcements by showing (bucket) loads of ads beside the products AND to sell browsing stats to companies (the verge has EIGHT trackers listed by Ghostery).
IMHO it would be extremely welcome if we lose some if not most of these sites, rather sooner than later…
Edited 2013-03-12 13:24 UTC
I don’t use an ad blocker – if some site has irritating amount & style of ads, it’s a good reason to not visit that site.
And OSNews is not among such sites, it respects its readers (but you wouldn’t see that, running ad blocker everywhere)
Blocking ads has nothing to do with OSNews or obtrusiveness.
If you allow ads, you allow yourself to be willfully manipulated. We are manipulated enough anyway in this world.
Better to pay for the content upright rather than by ads.
PS my other post got stamped into the ground, but I did actually pay 5 euro and have countless subscriptions on Zinio.
No, not really. Subliminal messages and brainwashing with ads are in the same category as astrology, energetic bracelets, fairies and most “alternative” therapies. Starting with the fact that one of the pioneers in subliminal advertising manipulated his results, because his experiments didn’t really work the way he expected. Today, this ideas are very discredited. Yes, every now and then an article appears, that suggests that this messages may have some influence, but a very limited one. And of course, isolated studies don’t mean much.
So, no. At best this is all pseudoscience. If you want to buy into it, be my guess, but pretend it is a fact.
Sure, subliminal ads are highly dubious.For instance they tried to put a frame of a coke bottle into some frames of the movies. Too fast for the rational mind to spot but maybe it would subliminally be picked up.
I think that failed.
But we are not talking about subliminal advertising here, we are talking about ‘in your face’ advertising. There is no way the mind can ignore what it sees on the page.
That advertising works is clear: Google makes billions out of it and we haven’t stopped advertising since 1900.
If you’re so paranoid about the influence of advertising on you, you must not leave home much… (after all, ads everywhere); also, don’t watch any films (product placement).
Articles can also be manipulative (such as this one, suggesting that alternatives to WebOS are better). OTOH, ads can be informative (just the other day one brought a new mobile network to my attention, with good offer; earlier, a new band ad on last.fm)
TL; DR
Joke, didn’t read because it’s 5 dollars.
The online version is free, as always on OSNews.
I know, it’s just I rarely get to complain about this site.
OSnews sold out!
Dividing auditory in two – peasants get no picture version, while rich get premium content.
Edited 2013-03-11 15:55 UTC
I bought a copy, even though I don’t really care for dead tech companies all that much. I just like trolling this site, hence the show of support.
It would be nice if you offered a couple of full-colour preview pages, though. Especially useful since $4.99 would seem a bit much for people raised on $0.99/$1.99 mobile purchases.
I know Gumroad offers some sort of a preview feature for sellers, so maybe you should look into it.
Edited 2013-03-12 13:03 UTC
Just wanted to congratulate you, Thom, on completing this opus amoris magni. It’s inspiring to see tech histories like this that weave diligent historical research with a competent understanding of the technical side. And might I add more plainly that I really enjoyed the article. Bravo. (Looking forward to paying for the PDF!)
Yup, I haven’t had the time to read it yet, but want to thank you for the time it took to pound the monster out. I’m sure it will be interesting reading.
Thanks guys!
Thom, congrats!
If you add Maemo/Meego/Moblin to your OS lists, would be greater yet!
I just skimmed over it, but I’m surprised you didn’t mention psion
Psion and Symbian is all reserved for the next article! Collection of data has already begun – shopping for devices is the next phase.
So hops hops, buy the article
.
Regarding Symbian, I advise you to have a look into
http://www.developer.nokia.com/Develop/Featured_Technologies/Symbia…
for the technical stuff.
The site is probably the only information still available online about how Symbian works.
Couldn’t care less about Palm, cry me a river PalmSource. They bought a mermaid princess and locked her away in the basement, where she eventually died. They could’ve went all Red Hat Enterprise and stuff, like making OpenBeOS platform free software and selling specialized professional applications with it, but noooooo. They had goods on the hands and they screwed the pooch. We all know the rest of this story – Apple won, Jobs was ill, but proud daddy king and had a blast destroying everyone else with machinegun. Including Palm.
A great article that brings lots of memories to life, i really enjoyed reading it. Thank’s for the excellent work you made.
Ever thought about getting a Flattr account? There are already outstanding Flattrs on your Twitter feed, that you just need harvest. I think it’s a pretty neat system and the sum of small contribution surely adds up for a great site like OSNews!
Buying before I even read the online version, definitely want to support your work Thom. Hopefully the PDF doesn’t look too small on the Kindle (if the PDF was designed for A4); could I ask for an ePub version though?
I tried to create an EPUB version, but I came to the conclusion that the format has been designed by morons. It’s basically just an HTML container, but every reader renders it in its own special way. After days and days of headaches and completely broken formatting on every reader, I gave up
.
I’ve look at the format too, and it is indeed crap. In my ideal world All eBooks would be regular HTML5 and all eBook readers would use a WebKit or Gecko engine. The reason ePub breaks so much is because vendors keep munging into something custom other than good-ol-reliable-HTML5.
What tools were you using to write the article / convert it? For Word Documents, I’ve found Aspose.words to be by far the best at producing something sane and usable from MSWord.
Raw semantics are the way to do it. I’m thinking of extending ReMarkable to publish to ePub so that I can use a markdown syntax to write and ensure the simplest possible HTML output.
I used Pages. Works great for everything except EPUB, or so it would seem (I want to marry Pages – god I love that software).
Thanks for buying, by the way
.
Try saving as MSWord, then run it through Aspose.Words in Windows, that’s always worked on my Kindle fine (though you will need to set the correct title / toc bookmarks, but I can help with that)
Seriously?!
… Why?
Say what?!
You are not doing much web development I imagine.
In the world of ebook readers, having a plain web-browser engine to do the rendering is *incredibly* reliable compared to the neither-a-browser-nor-a-text-layout-engine renderers that most readers use. Use of CSS on these arcane static renderers is a complete dark art.
Faire enough in that context I imagine then.
In my ideal world, eTexts would also be available in pure ASCII text-only format & all eBook readers would be able to import text files. Then you could do whatever you want with it & read it using whatever software you want.
In fact Thom, is yours available in text format? I’d love to support this kind of article, but formats like PDF are pretty useless to me. I found it a facinating read & would love to see more of this kind of thing. It doesn’t even matter if I agree with everything that’s written. The important thing is, you got it out there & it can spark a whole load of interesting discussion.
Well done!
(I can’t wait for the Psion/Symbian one)
Well, you could download the HTML source and strip it
.
In all seriousness, I’ll be sure to add a .txt version to the next article’s .zip. Small effort.
What about .mobi? That’s the native file format for the Kindle anyway (except that Amazon ebooks are wrapped in DRM, but inside of this, there’s just mobi)
I tried doing direct-to-mobi conversion with MobiPocket / Calibre, but the process just didn’t function right.
I spent about five days working on a process to convert a Pages document to Kindle in a way that actually worked. Software out there is unbelievably broken. The format is broken, the converters are broken, the readers are broken.
The only process I found that actually worked was Pages (or any other format) > MSWord > Aspose.Words > ePub > KindleGen = Mobi file
FictionBook (fb2) is another option: https://en.wikipedia.org/wiki/FictionBook
This is why I’m reading OSnews.
I still have IIIxe and Centro and I used them until recently. My Centro in laying in shelf, 4th day on 0% battery and still working.
Wow. I can’t believe you claimed WebOS killed Palm. WebOS was the only BRIGHT SPOT of Palm. I owned Palm Treo’s and Pilots and I HATED THEM. When I got the first Pre and used WebOS I was in heaven. WebOS is literally the best mobile OS experience I’ve ever had and I think Steve Jobs was nervous at first. So much so they changed iOS to have kinda multitasking. They couldn’t copy the flow of WebOS because it was patented so they did their own bit that was okay but still wasn’t anything close to WebOS. Android the same issue. Why go to a dumb task manager box to select which program you go to. Having the Card minimized, but still running WAS BRILLIANT.
I wish we could see WebOS running on the newer 1gb of ram phones with dual core processors. The OS is amazing and for you to gloss over it and even claim it’s the reason Palm died is ludicrous and I hope NO ONE buys your PDF because WebOS wasn’t the problem. The hardware the OS was operating on was the problem. Sorry you were late to the game on WebOS, but if you really studied it and looked at Android and iOS. NO mobile operating system could compete with it. I would even say if you put WebOS out today on a beefier phone that didn’t crack when you dropped your bag at work it would definitely beat Windows phone and BB phone and give it time might compete with the big two.
HP didn’t know what it had. They bought it and then when they couldn’t understand what exactly to do with it they killed it. Except now it lives on LG TVs. So another reason your assumption of WebOS is CRAP is that if it was such crap then why is it still kicking around on HP Printers and now LG TVs?
Like, say, the TouchPad?
The TouchPad is no phone, but it gives a glimpse into what to expect in terms of performance. As a TouchPad owner I can assure that at least performance-wise Android 4.x is running circles around WebOS.
Sadly, I agree that Android (CM9) boots and runs great on my Touchpad, where WebOS was a bit slow and clunky.
I still have a soft spot for WebOS though, even if I don’t currently use it. The card UI paradigm was awesome and far easier to use for task switching and management IMO.
Thom didn’t claim that. Read again: “… it is my view that Palm was already long dead before webOS ever even arrived on the scene.”
For me webOS was a real gem, so I was a bit disappointed to read that it failed to impress Thom. But on the other hand we had a different mobile history and Thom’s view was invaluable on the history of mobile computing.
You are right on the spot. webOS had great potential, but had some delusional masters. In my point of view it was a victim of great mismanagement, which unfortunately doomed it forever. I hope I’m wrong, but I don’t see a bright future for the open source version of webOS.
You are right about PalmOS, but wrong that WP or iOS copy it. They don’t have the inter-app comm paths or the rest. I’m not sure about WP but iOS is on the left side of the sweet spot. Crippling is not simplicity. They still don’t get the Zen of Palm – you must allow anything which enhances the experience.
You didn’t mention the Kindle, but were it opened it would be at the sweet spot.
Yeah. PalmOS is “there you have it”, where iOS is “there you go”.
Palm OS 5 did support fat binaries, almost all applications with ARM support were. I think you had to get a special compiler from ARM themselves to make ARM-only applications. For CodeWarrior or GCC, you wrote a 68k application and linked in resources of ARM code (known as “ARMlets”). These had full access to the ARM CPU, but calling back to PalmOS was awkward and all the UI code was still done with 68k code.
Sorry to hear that webOS didn’t impress Thom. It can certainly be sluggish, the browser sucks (I could also lay those charges at my Nexus 7, which is oddly frustrating to use at times despite excellent hardware), and I have to carry around spare batteries etc, but I’m keeping my Pre 3 until I find something, anything, that comes close to offering me the same experience. I adore the thing. Never having owned a Palm OS anything, I can’t compare, but – after coming late to the webOS party – I have the same feeling of regret and grief you feel for BeOS. BB10 may come close to filling the void, but there’s something characterful about Palm’s flawed little OS that can’t be reduced down to whiz, or features, or specs, or even the card ui; using it just makes me happy.
Edited 2013-03-11 20:59 UTC
Here’s my ‘review’:
* For those reading via PDF, a _lot_ more images would have been appreciated as 1) hyperlinks were not working on my Kindle and 2) without tabbed-browsing using hyperlinks are painful on an e-reader
* For the PDF, an A5 format would have been better. Most e-readers are small form-factor and scaling from A4 to A5 just makes the text hard to read. I had to read in landscape mode
* An ePub / Mobi format would have been preferable to some. Whilst very difficult to do, it is kindest to embed the text of external content as footnotes in an eBook, so that offline reading is possible and the hyperlinked text in the main article can be followed and its context learnt
* Reading as a book, I actually felt as if the article was too short! I was enjoying it very much and felt it was all over a bit too soon. If you intend to do “offline” versions (i.e. PDFs) of articles in the future, please bear in mind the use-cases of such offline content and expand your writing to state what you are subtly inferring behind your choice of hyperlinks, which are easy to understand on a desktop device, but much harder to grok between-the-lines on a mobile or e-reader device
* The various model names brought back a lot of memories. I used to work at a consumer electronics superstore in 2003, a period when the hardware was getting pretty powerful (300+MHz ARMs) and WinMo was edging past Palm thanks to HPs range of devices. It was a time where it was just becoming obvious at the consumer end that the PDA and the phone were about crash into each other. Most PDAs had some kind of Bluetooth or WiFi option / expansion and though the cost of data plans limited such access to corporate users, I could see that all the complexity and fiddliness of owning and configuring PDA+Bluetooth Adapter+Nokia Phone was going to get blown away by something that put it all together. That’s why the XDA was such a big thing (I think it needs a brief article of its own). That’s what killed Palm as a viable platform IMO. The XDA+PocketIE was to Palm as much as iPhone+Safari was to WinMo
* I’m glad you didn’t go into WebOS; I don’t think it’s at all relevant to Palm OS and would have only detracted from the article
* Overall an excellent read, thanks
Edited 2013-03-11 23:58 UTC
Thom, I’d really love to buy it – but I normally don’t keep my credit/debit cards within reach. Is there any chance Paypal might be in the future? I have everything connected to that.
Either way though, been reading for years and I’ll support you with this when I figure out where I left my wallet!
MCK = Mike Chen Kernel. While discussions were going around what to license in the port from 68K to ARM, at some point everyone realized the home-grown kernel was just fine.
LETS DO THISSSSSSSSSSSSSSSSSS
http://www.palminfocenter.com/news/8493/pilot-1000-retrospective/
http://www.palminfocenter.com/graveyard.asp
and can’t wait to read it later on today. Making me seriously nostalgic for my Palm IIIc; pretty much took all my lecture notes on that with the fold out keyboard.
I started with a Palm Pilot Pro and had a couple of cradles. It fitted really nice in to one, creating one object. Too bad I never got it to synch with Linux, but it did with Windows. I carried it around in a leather case. My Psion 3a was a much superior computer, but the Palm was more fun to use due to it’s stylus input and size. It was also more sturdy. The Psion always gave me the feeling it would shatter if dropped.
Later I bought a Palm Vx (8 MB vs 2 MB of the V). It sleek looking device. I synched it with AvantGo, which was a bit like an RSS service, synching news sites in to a mobile version readable on the Palm. My train travels become more fun reading news and playing Hearts.
My last Palm was a Palm T|X. Now I had a color screen, which was very cool. It had Tomtom navigation and even a web browser. On holidays I roamed the streets with it looking for open WiFi so I could synch AvantGo.
I still have all 3 Palms, although the Palm Vx has an alternative launcher which, for unknown reasons, keeps forgetting its settings. Rather annoying.
I can hardly wait for Apple to implement Ted Neslon 50 years old ideas in their “walled garden” and than to read, all over internet, how Apple rip of Ted Neslon (as they rip GRID, GRAIL…)
btw
good article thom, especial that history part!
Tried to buy via IE and it failed – after pressing “Ik wil dit” nothing happens. Had to switch to Chrome to do the actual purchase. Will start reading now!
I think I’ve clicked at least 10 URLs (in the PDF) that failed to open, mostly because of typos. Bad!
It’s not typos – I *just* found out PDFs don’t accept # in links, for some reason. I’m currently checking every URL – again – and fixing them. I’ll push out an updated version ASAP (I can send out a quick email to everyone who bought the PDF).
My apologies!
The updated version – v1.0.9 – with fixed links has been pushed out. You should be getting an email about it.
Thanks for pointing it out to me, jal_, this was crazy! My heart was racing as soon as I found out a few of the links were mangled
.
At the end of those Thom could probably publish a (compilation of writings) book about phone OS history.
Should consider this.
It’s easy to self publish on Amazon and others.
Edited 2013-03-12 12:48 UTC
“That faithful day in the company boardroom, when they all agreed to spin off the Palm OS, Palm sealed its fate.”
Surely you meant “That fateful day”? But then you would be repeating “fate”…CONUNDRUM
I had an original palm pilot. It was not as quick as you describe. However, I was running it with a later version of palmos than it shipped with that might be the reason? Not sure really, but it could be slow & laggy at times.
The cpu on those was also just too slow to do things with the serial port. We ported our software to it, but it would take ~30 minutes to transfer a 2 mb file compared to the 5 minutes it took win ce. The arm based palms were too late for us to consider using. At the time it was trivial to take code for desktop windows and have it run on win ce/pocket pc regardless of the cpu.
I disagree with the conclusions about the palm pre’s. The software was ok, the hardware was not. I almost went with a pre2 instead of a samsung galax s as I wanted a hardware keyboard. But it turns out, not having a keyboard is better than a crappy one :/
Its okay, I want to but a motorola too, but they keep screwing me over with their hardware ( locked bootloader, no sd card, no removable battery, etc). I think the next phone will probably be a google-moto.
Damn, those 16 years went by fast…
Thom, I had a Pre 2 and did not experience the horrendous battery life you’re referring to. It must be related to your test device being old and the battery already being worn out.
As for slowness, I also couldn’t complain. At the time it came out it wasn’t cutting edge but it also wasn’t slower than similarly priced Android models (remember, the Pre 2 was priced budget/mid-range). Many operations were significantly faster than on Android (at the time) — Just Type vs. Google Search to search the contents of the phone, for instance, was a lot faster and had a much better UI. Task management was certainly a lot faster/better. Other than that, the only slowness I can recall related to issues with the mobile internet connection being flaky and maximum EDGE speed — this was due to being a U.S.-targeted tri-band phone being used in Europe (which admittedly was really annoying and ultimately the reason I moved on). But for pure UI interactions I don’t recall too many issues, at least not after the first couple of firmware versions… You just need to remember how old the Pre 2 is by modern standards. At the time it came out, for the price, it was perfectly capable.
Also, regarding quality of the hardware I never found it to be lacking. It didn’t have quite the polish of an iPhone, sure, but it felt great in the hand and the keyboard was above-average IMHO. The only issue I had was that I accidentally hit the Return key all the time while typing SMS’s, but a simple patch remedied that.
I guess you really need to have lived through it at that time, and to have believed in the future of the platform, to understand what was so great about the OS. It’s easy to forget how techy-targeted and obtuse the Android UI used to be in comparison, and how limiting iOS was without multi-tasking and notifications (it still is today, but to a lesser extent). In contrast to today’s fast and pretty Android phones it’s easy to write WebOS off as unimpressive, but at the time it came out there was nothing else like it.
Edited 2013-03-12 18:17 UTC
An entertaining article that rekindles fond memories.
There were a couple of omissions to Palm history that are important: 1) the Lifedrive and 2)NAND.
Palm introduced the $400 Lifedrive to much fanfare. It was meant to compete with Apple’s iPods of the day. I recall meeting a Palm rep who was showing it off at one of those electronic stores that has since closed. It relied on a 4GB hard drive as storage and memory, to my best recollection. This memory arrangement had bad effects. Many complaints surfaced about frequent freezes and lockups. Although it was a beautifully designed machine, but with a rather poor, blue-tinted screen (something Palm was notorious for) it was a failure.
After the Lifedrive Palm started to bring out their phone line they switched to NAND flash memory. Palm touted this “feature” by stating that users would no longer loose their data if the battery ran dead. Unfortunately, as the hard drive had done in the Lifedrive, the NAND introduced other problems such as instability and lack of instant speed so valued up until then. Software utilities soon sprang up which were needed to flush the cache.
The best Palm-made non-phone device has been acknowledged to be the T3, a device with a decent screen that I bought used. The second best was the Tapwave, which is another company with a sad story. The Tapwave had many digitizer screen problems and joystick controller issues. I had to return mine 3 times before I got one that function satisfactorily. Neither of these units use NAND and are still going strong. The Tapwave was to have been a new gaming platform. Unfortunately, it was released right before the PSP.
As far as Sony’s later offerings they were uniquely designed on the outside but woefully underpowered and way overpriced. I think the UX50 ($500 or $600?) and some others used Sony’s proprietary CPU which only reached a speed of something like 125khz. Sony never advertised the speed, of course.
I looked at the UX50 when they came out. Sony shrank the screen to fit the device so it was smaller than competing Palm screens and darker. The keyboard buttons were completely flush with the wavy designed base and made it hard to type. This is another case of form over function I am afraid.
Once Sony left the PDA business Palm was doomed partly because it had no competition to push it forward. By that time the cell phone revolution started.
Edited 2013-03-12 18:29 UTC
I had the choice between the LiveDrive and the T|X. I went for the T|X because it was cheaper and it was part of a bundle that included Tomtom navigation.
At the time I remember that the LifeDrive was a very nice and interesting device, at least in theory. Apparently it wasn’t so nice in real life use.
If the LifeDrive didn’t have its flaws it may have become successful enough to give Palm some extra hit points.
I’ve not read it yet and I’ve paid up. This is such a great idea Thom. I hope it gets the support it deserves.
Hey OSNews and Tom
I have been lurking on OSNews and reading your articles and comments ever since 2002. I registerred just to say that I purchased the PDF. Thanks a lot for your work and keep it up! I will support OSNews.com, it has given me a lot of insight over the years.
// DragonFlyBSD fan and Debian user
I know a complete Palm. WebOS part is too little, and where is Hwkins now?
Thanks for the detailed article. I mostly read the section on Cobalt, since that is primarily what I am familiar w.r.t. Palm, and I thought I could add a few things to the information you have.
Ultimately, there was very little of traditional BeOS in PalmOS Cobalt. The main technologies that came from Be were things that were under development for the “next generation” BeOS that was being driven by Be’s focus shift to BeIA from a desktop OS. The foundation for that was the Binder system which, after Cobalt went away, was ultimately open-sourced as OpenBinder and I have archived at http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.h… for reference.
Nothing like the OpenBinder software was ever used in BeOS — the implementation in Cobalt and ultimately open-sourced was the third iteration of the design, which was a complete redesign and rewrite from the binder system that was implemented (and barely shipped) in BeIA. However a lot of the implementation of the original OpenBinder code and higher-level frameworks was done on top of BeOS, until there was a sufficient environment to work on it in the core code that would ultimately become Cobalt.
There were a bunch of higher-level parts of the system built on top of Binder for Cobalt, such as a distributed view hierarchy / UI toolkit / windowing system, the media system, etc. These were by and large implemented after Be was acquired by Palm, by mostly ex-Be engineers working at Palm and then PalmSource. The “rich graphics support” was also largely the result of a rendering engine implemented by ex-Be engineers while at PalmSource. Many of these engineers had also been deeply involved in the design and implementation of BeOS, and were taking the lessons learned there to create improved designs for Cobalt. For example, the BeOS rendering system was extremely primitive compared to the new one implemented in Cobalt; the Cobalt system was actually much more like what we expect now on these devices, with full anti-aliased 2d path-based rendering and rich alpha-blending (and not incidentally designed with expectations of being able to take advantage of OpenGL-based GPUs in the future).
The graphics marketing material is actually kind-of funny. That whole “screen sizes of up to 32000×32000 pixels” thing? Yeah, well, all that is based on is the fact that pixel coordinates where 16 bit integers. Which is of course *stupid* because by this point using 16 bit coordinates is pretty stupid — it’s just for compatibility reasons, and in fact 32000 pixels is not a lot once you start thinking about scrolling through large data sets. If I recall right, this came about because some marketing people came to us wanting to know about the maximum screen resolution the new system would be able to support, and what do you really say to that? Well the maximum range of a coordinate on screen.
The initial Cobalt implementation was a transition from the old to new PalmOS. Everything under the hood was an entirely new OS with a much more advanced object-oriented application model, UI system, and other features. However, to get the first product out, there wasn’t time to finish all of those pieces, so they were only being used to implement a compatibility layer that sat on top to provide the traditional environment for existing Palm applications. I believe all of the applications you see in the simulator are traditional PalmOS applications (on top of the compatibility layer) — at this point in the new framework there were basic widgets (buttons, check boxes, etc), simple view layout managers, and a lot of other infrastructure, but it was still missing some final higher-level pieces (like list views) and the API was still too in-flux to be able to write complete applications on top of it.
A *lot* of work was put into that compatibility layer. Many engineers grumbled about how much time was being spent on it and taking away from time to flesh out the New Hotness.
It wasn’t just old PalmOS in a compatibility box — all the original PalmOS drawing primitives in it were re-mapped to the new path-based renderer, each form the application made was mapped to a formal window object in the new underlying Cobalt architecture, etc. This allowed us to expose a lot of the features of the invisible new architecture to the old application model, such rendering fonts with TrueType and a new rich 2d drawing API that can be used along-side the traditional Palm APIs, or the status bar slips which were implemented by running a limited Palm API compatibility box to allow the developer to put a traditional form UI in this separate screen area. Plus there was still PACE running, so it could run your old 68k Palm applications inside of PACE on top of the traditional Palm ARM API compatibility layer on top of the new Cobalt architecture. Thinking about this too much would make your head hurt, but ultimately it all worked quite seamlessly.
As far as the lack of manufacturers picking up Cobalt, there were a number of reasons I saw for this:
– At that point device manufacturers still didn’t appreciate the importance of software (hardware was the primary focus, then software), and so didn’t see any reason to buy it when they could as well build it since they were already creating the main part, the hardware, anyway.
– Device manufacturers were and still are very aware of what happened in the PC industry, where one platform provider came to dominate it and turn all of the hardware into a commodity. They didn’t want this to happen to them, so were not only deeply suspect of Microsoft, but of any other company that looked to be trying to become a Microsoft in their world.
– This was a very transitional phase in the industry: PDA style devices were frankly fairly niche compared to the mobile phone market, mobile phones were rapidly getting more advanced and becoming more PDA like, and the Palm-style stylus-based UI did not seem like something that would be much more than a niche compared to traditional phone UIs.
– It was a huge investment for a company to ship their first PalmOS Cobalt product because the entire platform was unique and so needed custom driver work for every piece of hardware on the device. This was part of the motivation for the later switch to adopting Linux as the kernel. (It was also a significant part of the reason for Android building on Linux, which worked out very well there. Linux is entirely sufficient as a kernel for a mobile OS, it’s the stuff that is normally taken on top in user space that will kill you. Which kernel is being used for a device is basically irrelevant for the user’s experience.)
– As far as Palm not adopting PalmSource, I didn’t have enough interaction with them to be able to more than speculate. There was definitely a lot of bad blood with the Be acquisition, where Palm engineers saw the platform they had been working on for years being thrown away and replaced with something new (though not with BeOS in any real sense, just with new software designed and written primarily by Be engineers while at Palm/PalmSource). Many of the engineers who were most unhappy with the upheaval in the software at PalmSource moved back to Palm to continue work there on the old PalmOS platform.
One thing I don’t think that had anything to do with Cobalt’s adoption was Apple. If nothing else, the timing just doesn’t work out: during the time from when Cobalt was done and available to manufacturers until Apple first showed the iPhone I was involved with implementing a large part of a completely new UI design based on the new frameworks in Cobalt, watched that get dropped, left the company for Google and, starting at pretty much ground zero of a raw Linux kernel, worked with a small team to build an entirely new operating system that was well on its way to being done. Cobalt was being shopped around in early 2004; Apple didn’t acquire FingerWorks until 2005. Even way later when Android was being shopped around it was hard to get interest in that (even with it being open source!) due to the same issues with manu
Whoops, got truncted; here is the rest:
One thing I don’t think that had anything to do with Cobalt’s adoption was Apple. If nothing else, the timing just doesn’t work out: during the time from when Cobalt was done and available to manufacturers until Apple first showed the iPhone I was involved with implementing a large part of a completely new UI design based on the new frameworks in Cobalt, watched that get dropped, left the company for Google and, starting at pretty much ground zero of a raw Linux kernel, worked with a small team to build an entirely new operating system that was well on its way to being done. Cobalt was being shopped around in early 2004; Apple didn’t acquire FingerWorks until 2005. Even way later when Android was being shopped around it was hard to get interest in that (even with it being open source!) due to the same issues with manufacturers and their relationship with software. In fact, the introduction of the iPhone I think was very good timing for Android since it finally burst a lot of bubbles about the (lack of) importance of the software platform, and here Android was basically already ready to provide a similar software platform for other companies to use.
As you hint, there were indeed actual PalmOS Cobalt devices that were under development, in conjunction with the software work on the platform. There was one major company that PalmSource worked with for quite a while and was close to shipping, and then that company canceled the project. (I heard later that standard practice for this company was to have a bunch of devices under development at the same time, and then towards the end kill all but a couple that they thought had the most potential. I don’t however have any idea what the actual circumstances were for this, just that it came as quite a shock to the engineers because we thought things were going well.)
I mentioned above about another UI design built from Cobalt, which I didn’t see mentioned in the article. This was actually shown publicly — http://www.mobileread.com/forums/showthread.php?t=4153 is a reference to it that I found with a quick search. This was much more than a concept; this was the new modern PalmOS that was built directly on top of the new frameworks that were hidden away in Cobalt, and had a significant amount of working implementation. A big point of it was to provide a UI that works *without* a touch screen, because the traditional PalmOS design requiring a stylus touch screen had actually been a big stumbling point for getting interest from phone manufacturers. And there actually was significant interest from at least one manufacturer, who ended up in a bidding war with ACCESS over PalmSource because they wanted to get the Rome platform. (That said, I think PalmSource would have many of the same troubles trying to license the software to other manufacturers, for many of the same reasons Cobalt had trouble.)
Finally, I would like to say the design of Android actually took a lot of inspiration from Palm. Many of the core engineers on Android came from PalmSource (most having arrived there from Be), and saw Android as an opportunity to do what PalmSource was trying to accomplish in an environment that was more likely to succeed. For example, Android’s Intent system is actually a greatly evolved version of PalmOS’s sublaunching, based on a lot of ideas in the Rome architecture. I find it amusing reading that linked article about examples we had shown of what Rome was doing, which have a direct lineage to things like Android’s sharing and other Intent-based features. Or another example is Android’s initial design to support different density displays (created long before Apple’s whole Retina thing), which came directly out of our experience with how PalmOS was dealing with different densities and how we could make that so much better if we baked that concept into the platform from the start. You can actually trace an evolution from Palm’s original attention manager, to the status bar slips in Cobalt, through the notification facility in Rome, to the notification system that has been part of Android since it first shipped. And Android’s application model based on a single foreground application that must be able to save and restore its state as you leave it and return has a strong lineage from work at PalmSource on how to add multitasking to Palm’s original single tasking model.
thanks for more details.
what does a “distributed view hierarchy” means? does it means that some views can run in different processes?
Can critical components (e.g. flash) run in a different process and render into a local view? Or was it that way that view and component are one unit running in a different process? thanks for the nice insight btw!
Yep, it allowed you to have process boundaries at any points in the hierarchy, and one of the significant motivations was indeed for dealing with things like flash content. Basically the entire UI was one single distributed view hierarchy, rooted at the display, with the window manager sitting at the top owning the display and the top-level children there. If you know about OpenBinder, a short description is that in the design every View was an IBinder object, so it had binder interfaces for accessing the view allowing these to go across processes. In particular there were three interfaces:
– IView: the main interface for a child in the view hierarchy.
– IViewParent: the interface for a view that will be the parent of other views.
– IViewManager: the interface for managing children of a view.
These interfaces also allowed for strong security between the different aspects of a view. For example, a child view would only get an IViewParent for its parent, giving it only a very limited set of APIs on it, only those needed to interact with it as a child.
You can look at the documentation on the binder storage model at http://www.angryredplanet.com/~hackbod/openbinder/docs/html/index.h… to get a real-life flavor for a similar way to deal with objects that have multiple distinct interfaces with security constraints between them. In fact… the view hierarchy was *also* part of the storage namespace, so if you had the capability to get to it you could traverse down through it and examine it, such as from the shell!
Many of the fundamentals of this design were carried over to Android. Android dropped the distributed nature of the view hierarchy (switching to Dalvik as our core programming abstraction with Binder relegated to only on dealing with IPC lead to some different design trade-offs), but still we have our version of IViewParent in http://developer.android.com/reference/android/view/ViewParent.html and the basic model for how operations flow down and up the hierarchy came from solving how to implement that behavior in the Cobalt distributed view hierarchy.
Find that pretty interesting stuff!
I don’t quite understand why switching to Dalvik made you drop the distributed nature of the view hierarchy though.
Looked into OpenBinder before. As one part of my PhD project I look into how the behaviour of an application can be changed at runtime (basically by rewiring components). For the prototype I used many ideas from OpenBinder and especially pidgen to generate the base object binder code. However, I mixed in a bit of qt’s thread safe signal/ slot semantic to make it easier to make stuff thread safe (http://qt-project.org/doc/qt-4.8/threads-qobject.html).
Is there actually something you miss from the Cobalt platform (binder related) that is not in Android?
Part of this is that a lot of those features in OpenBinder were based on creating a dynamic nature as part of the core binder design. When we went back and started on a new platform based on Dalvik, we already had a language with its own dynamic nature. Just taking what had been done for OpenBinder would leave us with these two conflicting dynamic environments. We even ended up dropping the basic ability to have multiple binder interfaces on an object because that didn’t map well to the Java language. (In theory you can still implement such a thing on Android based on the native binder framework, but not in Dalvik where most of the interesting stuff happens.)
There was also just a practical issue that we couldn’t take the OpenBinder code as-is for licensing reasons, so we needed to re-write it for what we shipped in Android. The development schedule for Android was pretty tight, so we needed to be really efficient in building the system, and reproducing all of OpenBinder and the sophisticated frameworks on top of it that weren’t open-sourced would have been a lot of work that was hard to justify vs. what we would get by going back and doing something slightly different that leveraged a lot more of Dalvik.
And ultimately it was a different team that built Android — yes some key people were from PalmSource with the experience with Cobalt, but there was a lot of influence as well from people coming from Danger, Microsoft, and other places. Ultimately ideas from all those places were mixed together by picking and choosing those that seemed best for the project.
I also think that from a development perspective building most of our system services on top of Dalvik has been a good thing for Android. The Dalvik environment is just a much more efficient development environment than C++; with all of our very core system services like the window manager and package manager written in it, we can move much more quickly in evolving our platform and more easily triage and fix bugs. (Given a crash report from someone’s device, you are very often going to be able to identify and fix the problem when it happens in Dalvik far more quickly issues than in native code.)
Oh if you have a decent understanding of the apk and process design of Android, it may be entertaining to read the process model documentation of OpenBinder: http://www.angryredplanet.com/~hackbod/openbinder/docs/html/BinderP…
A *lot* of the ideas there appear in Android, transmuted for the new environment they find themselves in. Keep in mind that this process documentation is describing a core foundation of the code that was running PalmOS Cobalt and then Rome. We hadn’t quite gotten the full security and process model in place that we wanted for third party applications, but you can see the comments at the bottom there leading to very similar concepts in Android — signing to determine where things can run, permissions, etc.
It seems there is little or no reason provided to explain why Palm failed on the market.
And no, i’m not talking about the “WebOS” part, which is there, but which is “no longer Palm as we know it” in my opinion, but “another kind of Palm”, Palm 2.0, or Palm ReBorn if you wish.
But the previous lines of PDA, the one which was dominant with 90%+ market share and insane margin, how come it finally died ? I would love to hear some explanations on this one.
Wow, this article took me a little week to read entirely, bit by bit, but it was certainly worth it. You took your research work quite far and did a good job at making it interesting !
I’d gladly buy it just for the sake of saying “I am ready to pay for such articles”. But for this, I’d need some other payment methods, since I can’t bring myself to trust banking cards. Could you please try a billing service which accepts Paypal payments on a future article?
Edited 2013-03-14 15:21 UTC
I still have my Palm 5000, and my Kyocera 7135 flip-phone. I also owned the Treo 650 and the 700p.
And last but not least, the Treo 755p, which was retired just 3 weeks ago for a generic LG L9 Android phone.
I avoided the Centro because of its tiny screen. Today there is no phone that matches the 1/4″ font size used in the address book of my Treos. Not one. They all use tiny fonts on megapixel screens that my tired eyes can’t read without glasses.
Most of all, I miss the terrific Treo keyboard that no other phone could rival (and I tried them all). When I got my 650 I gave up Graffiti instantly, and I never looked back.
Until today, when I installed Graffiti for Android, just to get away from that annoying touch keyboard. It all came back in a rush. Entering text without looking at the screen! Without a stylus! Yippee! I’m FREE!
Your article was so perfectly timed for me, letting me know for once and for all that it was time to let PalmOS go.
But not Graffiti.
Thanks.
Edited 2013-03-16 03:20 UTC