Note: I’m not going to detail the various different names under which Palm has operated over the years, such as PalmSource, PalmOne, and so on. For the sake of clarity, I’m just referring to all of them as ‘Palm’.
In order to understand Palm, its origins, its history, and its philosophy, you really have to take a close look at just four products: the GRiDPad, the Zoomer, the Pilot 1000, and lastly, the Palm V. Not entirely coincidentally, these four products were all the brainchildren of Jeff Hawkins – founder of Palm.
Let me just throw all the cards on the table so hard they slice it in two: there is no single person who has had a greater and more everlasting impact on the mobile computing industry than Jeff Hawkins. His achievements include the first consumer tablet computer, one of the first PDAs, the first successful PDA, and the first successful smartphone. Not entirely coincidentally, as you read through this chapter, you’ll see that his philosophy on product design bears a striking resemblance to that of another industry heavyweight.
Much of the information in this chapter (specifically that related to Hawkins) comes from the following sources:
- Jeff Hawkins Oral History – a fascinating in-depth interview with Jeff Hawkins from 2002, covering his entire career up until that point.
- Hawkins video interview by Michael Chui – a recent interview, from November 2012.
- Short video interview with Hawkins.
- A talk by Hawkins on how Palm approached product design.
All of these are very interesting and quite entertaining. Definitely worth a watch and read.
GRiDPad
Jeff Hawkins already had a rather diverse education and employment history before he joined GRiD. After growing up with an adventurous inventor as a father, he earned a B.S. in electrical engineering at Cornell University. With that degree in hand, he was employed by Intel in 1979, where he took on several different roles over the years – among others, he worked on single-board computers and training and teaching others about microprocessor design (including the ambitious but ill-fated Intel 432).
He left Intel behind in 1982 to go work at GRiD, a startup at the time. GRiD had literally just invented the modern laptop, and Hawkins was responsible for putting together the training material for this device. In other words, from relatively early on in his career, he was involved in mobile computing. He also developed GRiDTask, a high-level RAD programming language.
However, his real passion was neuroscience. Before he joined GRiD, Hawkins had already tried to get into MIT with a research proposal concerning a big problem in neuroscience – namely, that despite everything we know about the brain, we don’t really have any idea how it actually works. Hawkins wanted to work on this problem, but MIT basically told him it was a waste of time. He didn’t drop the idea, though, and during his time at GRiD he kept working on the problem in the evenings.
After trying Stanford, which turned him down because they didn’t have any activity in the field he wanted to study, Hawkins ended up at Berkeley, where he was allowed to do an independent study. He took two years off at GRiD, but during those years, he didn’t make the progress he wanted – he started to doubt himself, so he decided to go back to work at GRiD “for a few years”, and maybe he could pick it up later. This was 1988.
It’s during this second stint at GRiD that Hawkins first gave the world a taste of what was to come. During his two years away from GRiD, and as part of his study into neuroscience, he also came into contact with neural networks, a field which spawned a number of companies trying to apply neural networks commercially. One of these companies was Nestor, which had developed a handwriting recognition system based on neural networks. They asked a million dollars for the system – something which surprised Hawkins.
I thought, “What? A million dollars for this thing that I don’t think is even very useful? I can do that.” So I went home that night and created my own handwriting mechanism software. I said, “If they can sell it for a million dollars, I can do it better.” So I did it without using neural networks, using some of the math I was doing for the brain stuff.
He wrote it in one evening, or so the legend goes. This is when the idea for the GRiDPad was born; he took his handwriting recognition engine to GRiD, and told them he wanted to build a tablet, with a stylus and everything. He would be responsible for the entire project – hardware, software, the whole thing. GRiD was a bit nervous about it, according to Hawkins, but they agreed.
And so, in 1989, the GRiDPad saw the light of day. It was the first tablet computer with pen input in a self-contained unit (the Linus Write-Top was released a few years earlier, and was very similar, but consisted of two separate units connected via a cable), and used Hawkins’ handwriting recognition system, then dubbed PalmPrint.
Hardware-wise, it weighed a hefty 2 kilograms, and ran on a Intel 80C86 at 10Mhz. It sported 1MB of RAM, two RAM card expansion slots, and a serial port. The display was a 10″ LCD with 32 grayscales, 80×24 text or 640×400 pixels, and the stylus was attached to the device. It ran MS-DOS 3.3, and was aimed squarely at vertical markets. The United States military and Chrysler supposedly bought quite a few of them, and GRiD claimed that 10000 were sold in 1990 – which is not bad for one of the first products in its category, and cost $2370 a pop.
Regular consumers couldn’t actually buy a GRiDPad – only businesses who needed dozens or more of them were eligible to buy them. Still, those that did use GRiDPads were fascinated by the device, and some of them told Hawkins – why don’t you make a smaller version of this? Something I could carry in my pocket, which holds all my personal stuff, and is a lot cheaper?
Click.
Zoomer
Hawkins knew what to do. GRiD wanted him to do it, but he was apprehensive about doing the product at GRiD, because it was an enterprise company, and in his mind, he envisioned the as-of-yet unnamed product as something for ordinary consumers. Hawkins mentioned his product idea to a lot of people, and some of them suggested he start his own company. He was scared about this at first, but after investors started coming to him, basically begging he’d go through with it, he did so. Tandy had acquired GRiD in 1988, and also decided to invest in Hawkins’ new company.
And so, in January 1992, Palm was born.
Still, it wasn’t until March 1996 that the Palm Pilot 1000 – the first Palm Pilot – was launched. What did Palm do in between? Well, Palm contributed to a product that looked a lot like a Palm Pilot in many ways, but was actually a complete and utter disaster. It was a design-by-committee hodgepodge of parts from different companies, neither of which seemed to have a very good idea of what Hawkins was trying to achieve.
This product was the Zoomer. Try to keep up, but the Zoomer consisted of Casio hardware, the GEOS operating system, Palm’s PIM applications and handwriting recognition, and Tandy marketing. According to Hawkins, they couldn’t agree on anything, and nothing got done. Worse yet, in comes Apple, out of nowhere, with the Newton. Apple hyped the Newton and the PDA concept into the stratosphere, and they managed to ship before the Zoomer could. “Everything is falling apart! No matter what happened, we would have failed. The Zoomer was a terrible product,” Hawkins reminisces about those days.
The Zoomer was slow, clunky, and unpleasant to use. There’s a great video on YouTube that shows wait cursors, the clunky handwriting recognition (with a dialog box!), slow redraw, and so on. To be honest, I didn’t think it was as bad as Hawkins describes it in later, more current interviews, but it’s still clear this is miles behind what we came to know from Palm OS.
Hardware-wise, the Zoomer ran on a NEC V20 processor – which was a bit of an oddball to begin with. It sported 1 MB of RAM, a 4MB ROM, a miniature RS-323 port, infrared receiver, and a PCMCIA slot (type 2). It had a 320×256 monochrome LCD, and had a promised battery life of 100 hours on 3 AA batteries. It cost a rather whopping $700.
The Zoomer became a market failure, but in a surprising turn of events, Apple’s involvement in the PDA market was a blessing in disguise for Palm, because the Newton was just as terrible as the Zoomer. Apple hyped the Newton to an insane degree, and Sculley claimed it would reinvent personal computing – this meant Apple got all the press and attention, but when the Newton turned out to be a dud, it also got all the flack.
Palm remained largely under the radar, which gave the company the chance to realign its goals. Nobody wanted to invest in the PDA category anymore, no company wanted to devote resources to it, which turned out to be another blessing in disguise: it meant Palm had to do everything on its own – software and hardware.
While the Zoomer was a failure, it taught Palm and Hawkins a number of very valuable lessons, and because of those lessons, it was still a very important product in Palm’s – and therefore the mobile industry’s – history. First and foremost, Hawkins realised that in order for a consumer product to work, you had to do both the software and the hardware (as Alan Kay already noted).
Secondly, the failure of the Zoomer prompted Palm to do something no other company in the industry had yet done: instead of guessing what consumers wanted, why don’t we just ask them? After talking to consumers, Palm came to a rather crucial realisation. Hawkins summed the survey responses up as follows:
I don’t want a complex thing. I was just trying to figure out a way to get my life organized. Today I use paper, and I’m always trying to coordinate with my assistant. And we can never keep calendars. We’re always printing things out. I’m just trying to get my life organized. All I really care about is calendars and address book and trying to coordinate with my secretary. All this other stuff? I don’t need all this other stuff. Just solve my basic organizational problem.
Palm realised that they didn’t need to revolutionise computing. They weren’t competing with computers, but with paper. They also learned that synchronisation should be a core part of the product – keeping things organised – and that it should be simple and straightforward.
With the blessing of Palm’s board, and the realisations from the survey in hand, Hawkins set to work. In one evening, he created a wooden model of what would become the Palm Pilot and its cradle.
Palm Pilot
After the failure of the Newton and the Zoomer, the PDA market – which had never gotten off the ground to begin with – was pretty much dead. GO had gone bust, and EO and General Magic were about to follow. Palm had no PDA products, and Apple was peddling the Newton which nobody bought (it was one of the first product lines Steve Jobs axed when he returned to the company). It was a failed market category, and nobody was interested in investing in it.
So, Palm had Hawkins’ model for the Pilot, and they knew pretty well what they wanted to build. Hawkins defined four core criteria the Palm Pilot had to fulfil:
- It had to be pocketable. You had to be able to carry it around without being bothered by it.
- It had to be the ideal price point: $299.
- Synchronisation with the desktop had to be built-in (as opposed to an aftermarket add-on as it had been treated as up until then).
- It had to be fast, without any wait cursors. Remember: it had to compete with paper, and paper is instant.
And Palm only had $3 million to do it, which is a laughably low budget for a complicated product like this. This lack of funds initially forced them to make some interesting decisions, like opting for a small, local, two-person low-budget design shop for the industrial design. Luckily, though, US Robotics was fascinated by the idea for the Palm Pilot, and decided to flat-out buy Palm, which provided Hawkins and his team with the required funds (3Com then bought US Robotics in 1997).
And so, with US Robotics’ funds, Palm managed to complete the device’s development, and meet the four targets it had set for the device. On 29 January, 1996, a press release was sent into the world, titled “U.S. Robotics launches breakthrough pocket-size connected organizer for PC users“, detailing the breakthrough new device.
The Palm computing division of U.S. Robotics today announced Pilot, a line of handheld electronic connected organizers designed to work as companion products to a desktop or laptop computer.Created by U.S. Robotics to be the first connected organizer, the Pilot family of products is designed to meet the needs of PC users who want to manage their activities both remotely and on their desktops.
The Pilot 1000 – the first model – used a Motorola Dragonball processor, a low-power processor based on the design of the 68000 family of processors, with a speed of 16 Mhz. It had 128 KB RAM built-in (512 KB for the Pilot 5000 model) and 512 KB of ROM for the operating system and applications, but this could be upgraded to a maximum of 12MB of RAM and 4MB of ROM via slots behind a plastic cover on the back of the device (in fact, the Pilot 1000/5000 could be upgraded to Palm OS 2.0 this way).
The display was a 160×160 grayscale LCD (no backlight), with the characteristic Graffiti input panel underneath. The input panel was flanked on both sides by permanent tappable shortcuts to home, calculator, search, as well a button to open the current application’s drop-down menubar. Underneath the display sit two scroll buttons (up/down), buttons to access the most important PIM applications, and a power button. The casing was plastic, and the device weighed 160 g.
It came with a cradle, which was connected to the PC via a serial cable. Place the Pilot in the cradle, press the HotSync button, and the synchronisation software would do its thing. It was compatible with all major PIM suites at the time, and more support was added as time went on and the product proved to be a hit. The desktop-side synchronisation software initially only supported Windows 95 and Windows 3.11 through Win32s, while version 2.0 added support for Windows NT. Mac OS 9 and Mac OS X support was added in later versions. Linux was never officially supported, but third party solutions existed.
The Palm Pilot 1000 and 5000 ran Palm OS 1.0, but we’ll get to the operating system later.
After the Pilot 1000 and 5000, Palm launched the upgraded versions, the PalmPilot Personal and Professional, in 1997. A year later, in 1998, they followed up with the Palm III. The Palm Pilot was a success – by 1 December 1999, Palm had sold over 5 million PDAs – and this attracted others to the PDA market. Most notably: Microsoft.
Hawkins had one last trick up his sleeve to deal with the Redmond behemoth.
Palm V
The success of Palm’s products got the attention of Microsoft, and the company pretty much announced it was going to crush Palm. According to Hawkins, Microsoft had a sales conference, where, at some point, a big target appeared on the projecter screen, with the Palm logo dead in the centre of it: “we are going to crush and kill these guys”, was the central message. Hawkins recalls that he got condolence letters after that, stating things like “Sorry Jeff. Too bad.”
Remember that in the late ’90s, Microsoft was at the very pinnacle of its power, and pretty much had the entire computer industry on a leash. BeOS a possible threat? Microsoft forced OEMs into not selling it preinstalled. Microsoft wanted to enter the PDA market? Let’s tell our OEMs to make a bunch of PDAs running our Windows PocketPC operating system, and we’ll surely crush Palm and own the market before Hawkins can say “what the…”.
Even though everyone assumed Microsoft would win, Hawkins devised a rather crazy-sounding and, at the time, controversial idea. This idea was based on how Hawkins viewed Microsoft: according to him, Microsoft simply didn’t understand why Palm was successful. Sure, they could throw lots of money around, and wield unimaginable amounts of influence, but at the of the day, they don’t build the entire product. Microsoft can only do the software, but for the hardware, they have to rely on others – and those others “just aren’t very creative”.
Microsoft was stuffing Windows PocketPC full of features. Palm OS was eclipsed by all the things you could do with it, and all the functionality that was packed into these PocketPCs. There was increasing pressure within Palm to try and match Microsoft feature-for-feature, but Hawkins realised that as a small company, Palm would never be able to do so. It would be a battle lost before it even began.
And I said, “No, we’re not going to add any features. Nothing. We’re going to make a beautiful product. They can’t make a beautiful product because they don’t make products. They just make software.” And if I tried to catch up to them on features, the reviews are going to be: “Palm tries to catch Microsoft features. Doesn’t do it.” If I don’t do any new software and I just make a beautiful piece of hardware, the reviews are going to be: “Palm does beautiful piece of hardware. Microsoft hardware looks ugly!” We had this big battle internally where I basically said: “We’re not going to chase after Microsoft on features.”
No new features.
A decade later, Apple’s Bertrand Serlet stood on a stage during WWDC 2009, to announce Mac OS X 10.6. He proudly proclaimed that it had “no new features“. According to Serlet, a move that was “unprecedented” in the PC industry. The audience clapped enthusiastically. The press ate it up.
But I digress.
In any case, this was the premise behind the Palm V: no new features, focussing entirely on the industrial design instead. Palm worked together with industrial design firm IDEO, and out of this collaboration the iconic and revolutionary Palm V was born. The Palm V was a huge leap forward compared to the Pilots that had come before, and it introduced an iconic shape that many will, to this very day, associate with Palm.
The Palm V was built out of anodised aluminium, and was only half as thick as its predecessors – a mere 10 mm. It was also smaller and lighter, but retained the same screen dimensions. Several other aspects were revolutionary too – it was the first Palm powered by a lithium ion battery instead of AAA batteries. The battery was non-removable, a ‘feature’ which sent ripples across the smartphone industry when Apple did the same for the iPhone eight years later. For aesthetic reasons, the device had no screws – the case was glued in place.
There’s an interesting story to this, actually. The manufacturer was very apprehensive about using only glue, and was afraid that the glue would melt if users, say, left the device on the dashboard of a car in the sun. The manufacturer wanted to delay the release of the Palm V by four months to redesign the product to use screws instead. Hawkins had to personally go down to the manufacturer and convince them the glue would work – Hawkins’ father was a prolific inventor, and Hawkins grew up with loads of different materials all around him in the house, including loads of different types of glues. In other words, Hawkins knew his way around product materials, including glue.
The Pilots that had come before were strictly utilitarian, focussed on businessmen and women instead of general consumers. The Palm V changed all this. Its shape would define the company’s products for years to come. It had smooth curved sides with a slightly wider bottom than top section, making it all not only look distinct and beautiful, but also very comfortable to hold. Whether you looked at other PDAs, smartphones, or mobile phones of its era – there was nothing else like it. Everybody else was building plastic monstrosities.
I personally never owned a Palm V (sadly), but two PDAs in my collection still sport the same general design – a Tungsten E2 and a Palm T|X.
The Palm V was a smashing success. For the first time, a mobile computing device was designed to be beautiful, and “it turned out to be very successful. We turned it into a personal artefact, or a personal piece of jewellery or something and [Microsoft] couldn’t compete with that,” according to Hawkins. Palm was riding high at this point, and the Palm V succeeded in keeping Microsoft at bay. Of all the PDAs sold between January 1999 an July 2002 (in the US), 68% were Palm devices, while Handspring and Sony (both Palm OS licensees), brought Palm OS’ PDA market share up to 90%. The remaining 10% was Microsoft, through Casio, Compaq, and HP (source).
In other words, Microsoft had failed to “crush and kill” the company.
Defining Palm
The four products discussed in detail – the GRiDPad, Zoomer, Pilot, and Palm V – have all played a crucial role in defining Palm’s success and brand. The GRiDPad made Hawkins realise what people really wanted out of a mobile computer. The Zoomer taught him how not to do it. The Pilot proved there was a market for a simple, easy-to-use, mobile computer. Finally, the Palm V made it clear that a focus on beautiful hardware formed the final piece of the puzzle in appealing to a wide audience.
During its heydays, Palm enjoyed the kind of dominance Android currently enjoys. However, unlike most Android device makers, Palm enjoyed Apple-like margins – in 2000, almost 40%. Palm proved that there was a huge, profitable market for easy-to-use, beautifully designed mobile computing devices – long before iOS and Android came along.
With the hardware handled, let’s move to software. Let’s talk Palm OS.
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