Linked by Thom Holwerda on Thu 2nd Jan 2014 19:31 UTC
PDAs, Cellphones, Wireless

The Verge has an interesting story up detailing the various hardware and software prototypes that could have had a future hadn't HP botched pretty much every aspect of its Palm acquisition. Both in features as well as design, the next version of webOS, codenamed 'Eel', looked quite promising, and the hardware designs certainly stand out too.

Sadly, as I stated in my detailed history of Palm, webOS was, at its core, simply not a Palm product. As I wrote:

A cool UI doesn't hide the fact that it's slow and unresponsive. A cool UI doesn't hide the fact that the underlying system is unoptimised. A cool UI doesn't hide the fact that it sucks battery like a there's no tomorrow. A cool UI doesn't hide the fact that the hardware was of appallingly low quality.

A cool UI doesn't hide the fact that the operating system has absolutely nothing to do with what Palm is supposed to stand for.

WebOS probably looked like the bee's knees to someone used to the version of Android and iOS at the time, but having had a long history using PalmOS products, webOS was a total and utter letdown. WebOS was a badly sewn together set of compromises, unfinished parts and shortcuts - and it showed. From The Verge's article, I get the impression that Eel slapped on a new coat of paint and new user-facing features - but that the lower levels and core of the operating system were still very much the same unoptimised mess.

I'm definitely curious what LG's webOS TV is going to be like - it looks nice - but if it's anything like Palm's and HP's webOS products, it won't light any of my fires.

Permalink for comment 579840
To read all comments associated with this story, please click here.
Android as an evolution of PalmOS
by hackbod on Fri 3rd Jan 2014 20:04 UTC
hackbod
Member since:
2006-02-15

I could actually make something of an argument about Android being a spiritual successor to PalmOS. There are actually many aspects of Android's design that can either be traced back to the development of a next-generation PalmOS at PalmSource, or are greatly inspired by PalmOS.

Android's Activity and Intent design has some of its roots in work at PalmSource, inspired by a desire to have something like PalmOS's sub-launching facility in a modern, protected-memory operating system. In fact the whole concept in Android of separating applications into distinct components, using Intents to launch the desired part, can very much be seen as a formalization of PalmOS's sublaunching facility and the kinds of things it was growing to do.

The way Android approaches multitasking is very much inspired by PalmOS, with the focus on there being a primary foreground application, which saves its state when you leave it so that when you later return it feels something like it had remained running. In Android we adopted this model, formalizing it more with clearer support for the "save and restore state" model. On top of that, we added the facility to keep these applications running in the background, which has its basis in thoughts back in PalmSource for how to introduce multitasking into such a user model.

(Fwiw, when people talk about webOS's multitasking being superior to Android, my impression is that this is because webOS explicitly keeps applications you launch running and under the user's control for when to stop them. This is actually much more like the traditional desktop multitasking model, which I would argue is less appropriate for mobile devices. The approach taken by Android is a very explicit decision, to avoid serious negatives to a more explicitly multitasking design -- which requires the user to manage what applications are running, and is an especially serious problem on mobile devices where there is no swap so hitting RAM limits due to running too many apps causes serious issues with the overall system's behavior.)

Android was also greatly inspired in PalmOS in its support for different screens, especially screen densities. It was clear to us from experience with PalmOS that different screen densities is important, and it is important to design for them from the start or else you end up in the bad situation PalmOS had when it came to need to do anything besides even multiple scaling. Experiencing these troubles with screen densities and the seriously limitations imposed on the platform by applications defining UIs through absolute layouts lead fairly directly to Android's approach of using density-independent pixels and layout managers. (Ironically, iOS has ended up with the same issue PalmOS had, where there was no original thought for screen densities in the platform, so doing an even multiple scaling such as 2x goes okay, but there is no flexibility to support any other densities without serious compromises.)

And there are many other examples: Android's notification manager and UI was designed with the help of a lot of experience of the utility and limitations of notifications in PalmOS, there is Android's alarm manager which is basically the same functionality as the corresponding API in PalmOS, etc.

Reply Score: 2