Jon Rubinstein, Palm’s Chairman and CEO, took the stage in Las Vegas to recount where Palm’s been and tell us where Palm’s going.  Click on the video to watch the entire 50 minute presentation.

The follow are the key points:

Hot Apps Bonus Program

Katie Mitic, Palm’s SVP of Product Marketing, announced $1 million in prizes to be awarded to top webOS developers.  The prizes are open to both free and paid apps developed using Palm’s existing Mojo SDK.  The prizes are tiered as follows:  $100,000 each to the top downloaded free and paid app, $10,000 each to the developers of the next two most downloaded free and paid apps and $1000 each to the developers of the next 200 most downloaded free and paid apps.  The download period will be between February 1, 2010, and May 31, 2010.  Drop by the newly relaunched Developer Center to get started developing your app today.

3D Gaming Comes to the Palm Pre

The announcement that got the most reaction was the release of 3D accelerated games, made available by Palm’s new Plugin Development Kit (or PDK).  Joining Palm onstage to make the announcement was Travis Boatman, VP Worldwide Studios for EA Mobile, who introduced some of their new titles.  In all, twelve PDK titles are available in the App Catalog, including the much hyped Need For Speed Undercover, The Sims 3, X-Plane 9 and Tetris.  You can see a video review of Gameloft’s Ashpalt 5 on WebOS Roundup.

More important than the release of these twelve games, though, was the PDK itself.   The PDK allows for development of applications that work with webOS but that are developed with C and C++ — in other words, native applications.  One of the criticisms from some developers is that Palm’s Mojo SDK, based on HTML, CSS and JavaScript, is too slow for some types of applications.  The PDK, and the fact that Palm has been testing this with some partners possibly since the release of webOS, indicates that Palm was well aware of this and has a solution.

While we’re excited about the release of the PDK we’re not sure that the capabilities of the Canvas element have been fully realized by game developers.  As Frank Zammetti pointed out, there is a tremendous potential for applications developed with existing Web standards.  Particularly as we see technologies such as WebGL get included in webOS.  Further, battery draw from games that tap the GPU will likely be big issue.

The PDK is scheduled for release in March on the Palm Pre and a later date for the Pixi.  In case you missed the significance of the statement, the 3D games available today in the App Catalog are only available for the Pre, not the Pixi.  Those missing 80 pixels could be very significant indeed.

Video Recording, Editing and Sharing

Those of you who’ve been following the homebrew announcements knew that video recording is possible on existing webOS devices.  It was only a matter of time before Palm incorporated the feature into the OS.  Palm demonstrated their upcoming video recording functionality at CES.  What they also demonstrated was the integrated video editing and sharing capability.  With a few clicks, Paul Cousineau, Director of Product Marketing at Palm, edited a video he shot live at the event then uploaded it to You Tube.  After it was uploaded, he used another feature to share the video with his Facebook feed.

Many have criticized Palm for not having the feature available before now.  Hopefully, this very slick implementation will go a long way towards smoothing any ruffled feathers.  What’s more important is that this feature will be included with webOS 1.4, another free update available to all webOS devices sometime in February.  Although it wasn’t discussed, we hope that audio recording will also be included in 1.4.

Flash 10.1

It was confirmed that Flash 10.1 will be available soon.  According to Paul Cousineau Flash 10.1 will be available for download from the App Catalog.  This feature will open up the Web even further for webOS devices.  Some have pointed out that the recently announced SlingPlayer, being Flash-based, will work on webOS, allowing you to watch and control your TV on your Pre or Pixi.

The Pre Plus and Pixi Plus

Palm also showed off the Pre Plus and Pixi Plus smartphones at CES.  The Pre Plus sports double the memory and storage (512 MB RAM, 16 GB Flash) of the original Pre and sheds the center button.  The Pixi Plus adds WiFi and more storage and memory.  Both devices will ship with Touchstone compatible backs.  These two phones will be Verizon exclusives (see below).  No doubt the increased memory and storage will be important for applications developed with the PDK, as many users have noted that the 3D apps sometimes fail to launch with the dreaded ‘too many cards open’ message.

Another Verizon exclusive will be the ability to use the Pre Plus or Pixi Plus as a MiFi hotspot, allowing up to five devices to share the 3G connection.  All you’ll need to get your laptop online is the app and a webOS device on Verizon.  What was not disclosed is how much the data plan for that will cost.

New Networks

Palm announced two new network partners at CES:  SFR in France and Verizon Wireless in the US.  As mentioned above, Verizon will be getting an exclusive on the Pre Plus and Pixi Plus (at least in the US).  Verizon currently has about double the subscriber base of Sprint in the US so this opens up a huge market for Palm and app developers.  What remains to be seen is how Verizon will promote the Pre Plus and Pixi Plus.  If they are half as successful as they were with their Droid Does campaign then the more consumer-focused webOS devices will sell very well.

Analysis

It seemed that Palm’s announcements were targeted very strongly towards developers.  Palm realizes that in order to compete with Apple and Android its important to have apps.  The opening of the developer program, the freeing of the app distribution process, the Hot Apps program and the PDK all point to the fact that Palm is deadly serious about expanding its App Catalog.  Palm is actively courting developers and is making it clear that they embrace openness, even giving a ‘shout out’ to the homebrew community at CES.  This is very exciting news and this strategy will very likely bear fruit.

What a strikingly different out-of-box experience awaits those users whose first webOS device runs webOS 1.4 as compared to those of us who started with the first release of webOS.  Certainly the underlying OS that we all love hasn’t drastically changed but the power, features and available apps have grown tremendously.  Kudos to Palm for the customer focus and rapid updates.  This is clearly one area where Palm outshines Apple and Android.  Many Android devices are stuck on older versions of the OS and are unlikely to ever see updates and Apple’s releases are slow in coming.

Prior to CES we predicted a number of things.  We got most of them right.  We missed on seeing a non-Palm branded webOS devices and we didn’t have any clue about the Hot Apps program.  However, what was most important about CES is that Palm has again generated buzz.  They showed that Palm was not to be ignored in the smartphone wars of 2010.  They reinforced that they are committed to extending the functionality of their devices through more updates to the OS.  They showed they’re committed to reaching more end users.  We think 2010 will be a great year for Palm and a great year for webOS users.

Other Reviews of Palm at CES

All Things Digital agrees that Palm has shaken things up once again.  Slashdot has some coverage of the Hot Apps Program.  Ars Technica ha a writeup about CES.  PC Magazine has a hands-on with the Palm Pre Plus and Pixi Plus.  About Palm Pre has some interesting thoughts on Palm’s developer strategy that mirror our own.  And, of course, PreCentral has a lot of articles about CES.

CC Photo by {eclaire}

Welcome to the Wednesday News Roundup. This week marks the first Roundup shared with our new friends over at webOSroundup. This week the big story is Palm’s new legal woes.  After that, we’ll cover some news for webOS developers.  Lastly, we’ll cover the good news in the Roundup.

Troubled Waters for Palm

Legally speaking, it was a rough week for Palm:  Palm received notice of two pending lawsuits.  The first was filed by Artifex Software, a California based company that develops, among other things, muPDF, which Palm used in developing the PDF reader application included with webOS.  Artifex claims that Palm included their muPDF software without either purchasing a commercial license or complying with the terms of the GPL.  There is no indication that Artifex has approached Palm regarding this.  Palm acknowledges using the muPDF and has even made available the changes they have made to that and other Open Source projects.  The crux of the problem seems to be that Palm did not make their entire PDF application source available online.  Depending on how Palm is using the muPDF software Artifex may be correct that Palm has not fully complied with the GPL.  However, it seems like this is likely an oversight on Palm’s part and a strong-arm tactic on Artifex’s part.  Artifex is no doubt hoping to get some headlines and possibly coerce Palm into a commercial license.  Palm will not likely be able publicly to respond given that the suit has been filed.

Perhaps more troubling is the lawsuit seeking class-action status against Palm and Sprint over the recent loss of information stored in users’ Palm Profiles.  If you haven’t heard about it there is some information in this PreCentral article.  In short, Palm does not keep multiple backups of  information backed up to the cloud.  If the data on the phone becomes corrupted or the phone did not back up properly the data may be lost when replacing phones or upgrading the operating system.  For those who are concerned about data loss we recommend looking to third-party solutions for local backup, such as The Missing Sync (PC or Mac) or Chapura PocketMirror (PC only).

Although the data loss has apparently only affected a small number of people it can be devastating to lose any information.  Hopefully this push Palm towards developing a more robust system for protecting data stored on webOS devices.  We also hope it won’t unnecessarily line lawyers’ pockets.

Developers, Developers…  You get the idea

Two stories from the past week bode well for webOS developers.  First, mobile ad company AdMob (recently acquired by Google) has released an open-source SDK for webOS developers who want to use the AdMob network.  AdMob is one of the largest players in the mobile ad space.  This will allow developers to more easily integrate ads, which should translate into more free applications (or, ad-supported trial versions of paid applications) in the App Catalog.  Second, mobile application development tool PhoneGap announced support for webOS.  PhoneGap is a cross-platform tool that leverages Web technologies (much like Mojo development itself) to create native apps for multiple devices.  This should lead even more developers to look at webOS as a platform for distributing applications.

Roundup

PC Magazine (They still print magazines?  Who knew?) selected the Palm Pre as the most innovative new platform in their list of Best Tech Products of 2009.  It’s not surprising then, that Ellen DeGeneres gave away the webOS based Palm Pixi with the tech bundle she gave out on the first day of her 12 Days of Giveaways (see the video below).  Finally, if you’re interested in setting up Google Voice, PreCentral has an excellent article on setting up visual voicemail with webOS using the service.  Did you hear about something we didn’t cover?  Have some comments?  Sound off in the comments below or hop over to our twitter feed.

In the old days, in order to make HTML look the way you wanted, you used more HTML. Every element had to be individually styled, using ribbons of FONT and CENTER and B tags. Then CSS came along and gave web developers the ability to group elements into classes with similar display characteristics. The world heaved a sigh of relief, and developers started making more complicated websites, confident that site styling would not get in the way of functionality.

Then JavaScript and AJAX became popular, and suddenly it became commonplace for elements to have their classes modified by JavaScript, based on the results of AJAX calls from the server. When an element’s class changes, it is updated instantaneously to reflect the styles associated with the new class. That’s fine for some stuff, but sometimes you want the transition between classes to be a bit more, um, classy. Let’s say your site has a login box that remains hidden on a page until a user clicks the “log in” link. If you switch the box’s style from opacity: 0; to opacity: 1;, it will appear right away by default. If you want it to fade in, you have to write a JavaScript function that increments the opacity bit by bit until it reaches 1, and you have to call that function at the same time as you change the class of the login box. If you have a bunch of login boxes on your site, you have to attach that transitional behavior to each one of them manually. Because CSS doesn’t have the concept of transitioning through time, animation-heavy websites are stuck in the same place that pre-CSS websites were before CSS came along.

CSS transitions solve this problem by bringing styles into the 4th dimension. CSS transitions allow web developers to specify that if an element has its style modified, the browser should smoothly transition its appearance to the new style, rather than shifting it abruptly. They’ve been available in WebKit for about two years now, and just appeared in Gecko a few weeks ago. Since they’re not available in most browsers, webOS developers are among the privileged few who can take advantage of them. Here’s how.

The Basics

Suppose your login box is 300px wide and you want it to hide offscreen until a user clicks a link, at which point it should get the class active and appear onscreen.

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px;
}
 
#loginbox.active {
  left: 10px;
}

Here’s a version of that with transitions:

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px;
  -webkit-transition-property: left;
  -webkit-transition-duration: .5s;
  -webkit-transition-timing-function: ease-in;
}
 
#loginbox.active {
  left: 10px;
}

And here’s how it’d look if you wanted the box to fade in and slide in at the same time:

#loginbox {
  width: 300px;
  position: fixed;
  left: -300px
  opacity: 0;
  -webkit-transition-property: left opacity;
  -webkit-transition-duration: .5s .25s;
  -webkit-transition-timing-function: ease-in linear;
}
 
#loginbox.active {
  left: 10px;
  opacity: 1;
}

Here’s a brief overview of the three -webkit-transition properties used above;

-webkit-transition-property

A space-seperated list of the properties that should be animated when they change. You should only use numerical properties. “top”, “width”, “border-width” and “opacity” work, but “display”, “text-decoration” and “list-style-type”, for instance, do not. If this property is omitted, all the properties of an element will be animated. This is probably not what you want.

-webkit-transition-duration

A space-seperated list of the durations of the transitions of the different objects. “s” stands for seconds. This is 0s by default, so you need to set it.

-webkit-transition-timing-function

From the W3C Working Draft:

The ‘transition-timing-function’ property describes how the intermediate values used during a transition will be calculated. It allows for a transition to change speed over its duration.

“ease-in” starts slowly and picks up speed at the end. “linear” keeps the same speed all the way through.

And here are some things that aren’t supported in webOS (as of 1.2.1), but probably will be eventually, since they are part of WebKit 4:

-webkit-transition-delay

Allows you to set a delay before the start of the animation.

Events

Currently, there’s no way respond when a transition animation finishes, and this is the main drawback of the CSS approach to transitions. WebKit 4 lets objects listen for animation events, which will let you string a bunch of animations together without needing to call setTimeout() to activate each part of the animation.

In addition to the reduced code clutter, CSS transitions can speed up your app, since they are run from native compiled code, rather than from interpreted JavaScript. Don’t expect miracles, though — I’ve found that webOS can only handle a few animations at one time before things get choppy, and the size and complexity of the elements being animated also makes a difference. I was unable to animate a 320×480 image without choppiness. While there is no programmatic way to cancel the animations, they are smart enough to smoothly reverse themselves if an element’s properties change in the middle of a transition. If the active class is removed from our login box while it’s still sliding in, it will slide out starting from wherever it happens to be at the moment the class was removed.

For more on the basics of transitions, check out the W3C docs, and keep in mind that all the properties should be prefixed with -webkit- in webOS.

Advanced Tricks with -webkit-transform

There’s another advanced CSS property in webOS, called -webkit-transform, that, when combined with CSS transitions, allows for some neat stuff. -webkit-transform is…well, I think of it as a mini-CSS within CSS. It lets you apply transformations to an element after it’s been rendered. In webOS, The available transformations (to my knowledge) are translate, scale, rotate and skew. To scale an element to twice its height and rotate it 30 degress (something that’s been impossible in HTML until now!), do like this:

#myDiv {
  -webkit-transform: scale(2, 1) rotate(30deg);
}

The crucial difference between scaling a div with -webkit-transform and scaling by manipulating its width and height is that -webkit-transform will scale (or skew or rotate) the entire rendered div and its children smoothly. For more on -webkit-transform, see this post at Art of Web.

You can animate -webkit-transform by passing it to -webkit-transition-property. If you’re using a WebKit browser, hover over the card below to see an example.

#cardexample {
  -webkit-transition-property: -webkit-transform;
  -webkit-transition-duration: 1s;
  -webkit-transform: rotate(0deg) scale(1, 1);
}
 
#cardexample:hover {
  -webkit-transform: rotate(180deg) scale(1.5, 1.5);
}

Our games Word Ace and Card Ace use this technique for pretty much every animation in the game. It’s a lot of fun to describe the behavior of a class in CSS and have elements automatically move around when they’re changed. There were times when I’d forgotten that I had set transition properties on an element, and was surprised when it started moving around of its own accord.

Caveats

Advanced animations are tricky with CSS. For example, the timers in Word Ace and Card Ace use transitions. In order to start a timer countdown, the yellow timer bar gets two classes set: one to set the bar to “full”, and another that sets it to “empty” with a transition, so that the width of the bar decreases slowly. My first pass at the code was something like this:

// CSS
#timer-bar.full {
  height: 22px;
  background-color: yellow;
  -webkit-transition-property: width;
  -webkit-transition-duration: 10s;
  width: 100%;
}
 
#timer-bar.full.counting-down {
  width: 0%;
}

// JavaScript
function startTimer() {
  var timerBar = $('timer-bar');
  timerBar.addClassName('full');
  timerBar.addClassName('counting-down');
}

It didn’t work. The timer bar never went to “full”. After some research, I discovered a blog post explaining that changes to element styles are batched during an event, and are processed all at once after an event has finished, for performance reasons. In this case, WebKit sees that the classes I’m adding would set the element’s width twice, so it only bothers setting the second width — 0%. If you need to do a multi-step transition this way, you need to chunk the DOM manipulation into different events:

function startTimer() {
  var timerBar = $('timer-bar');
  timerBar.addClassName('full');
  setTimeout(function() {
    timerBar.addClassName('counting-down');
  }, 0);
}

Tricky, huh? This also applies in cases where you need to set a hidden element to display: block; before you move it around.

In Short…

CSS transitions make our games smoother, more lively, and easier to maintain. They’re not without their pitfalls, but once you master the basics, they’re an easy, elegant way to add a bit of zest to your UI. For more information (not all of which applies to webOS, unfortunately), see the Safari reference and the W3C working spec.

Dan Kurtz is the webOS developer at Self Aware Games, makers of Word Ace and Card Ace for the Pre and Pixi. Both are online multiplayer card games that make extensive use of the advanced JavaScript and CSS techniques available in webOS.