techno.blog("Dion")

Ben and I were chatting about interviews after hearing some horror stories from a friend. He made a jape about how bizarre technical interviews can be, and how we often ignore some really important factors… like a portfolio. A portfolio in this case answers the question of “what exactly have you created?”

I will pick on Google as it is the brunt of the “holy crazy interviews batman” trade, which is made more fun now that my sister-in-law is a recruiter there. I like to tease her. She knows that I am a fan of Google and think it is a fantastic place to work. I would be honored to work there again one day for example. Anyway, she doesn’t need my help in hiring… you have all heard about the food ;)

So, feel free to substitute Google for other high tech companies in any story below.

Imagine if Google interviews painters or artists in the same way that they hired engineers. Michaelangelo would show up, and would be hammered on questions about how he exactly makes and mixes his paints. Why does he use that particular kind? Why do those mixes chemically end up with the result that he desires. “If you were on a dessert island with 3 paints, what would they be and why?”, “Discuss the difference between RGB and CYMK”.

This may feel strange. A natural first step when you talk to an artist to see if they are any good is…. see what they have done! “Can I take a look at some of your pieces?” The artist will then probably show a variety that show a broad range of abilities. Some of you have probably had this experience hiring a wedding photographer.

Now, it isn’t that the process doesn’t matter. You want to chat about that side of things too. The right paint may result in a longer lasting piece. The right technique may result in you not getting annoyed by the photographer at your wedding. But, it is probably secondary to seeing what the person has actually done.

Google of course does a fair amount with art. The Doodles for example…. they have competitions for those, and the tools used may or may not play a factor.

Now, you may argue that the portfolio focus makes much more sense for art than other genres, including programming. You can tell a lot from seeing that art, and it is pretty static in time. Programming though, has to be maintained. It has to live. The “how” matters so much more. Maybe it is more like architecture than art. An architect can be known for his amazing looks, or building experiences, but the building better be structurally sound. You would still look at the portfolio of an architect first though, versus peppering them on structural engineering questions.

You do need to test the portfolio. It is one thing seeing that Bob Harris created an amazing website, a top 10 iPhone app, and contributed to a popular open source project…. but what exactly was the contribution. Projects have many folks involved. This is why you need to test the interviewee. Write some code with them. Talk through a real problem that they would actually have to solve on the job (shock horror). Do you *really* think that they will be implementing bubble sort on the job?

Interviewing itself is an art. It is hard to quickly make a decision on if someone will be a fit. Not only does there have to be a technical match in expectations, but there is the social match that is oh so important when a person joins a collective :) I have already talked about how the current process of hiring is like a shotgun marriage and broken but I definitely feel that in a constrained world there are three things that I favour when interviewing a candidate:

• Understand their portfolio (ask the candidate to come ready)
• Test the candidate to make sure they match with their portfolio (work with them on what they will be doing. E.g. pair on code)
• Talk to key people who know the candidate and learn from them about the person

Steve Jobs didn’t hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out “stupid keys” (print screen, F keys, and the like) and swore a lot.

We love to paint with broad black and white brushes these days don’t we? Whenever I hear people talking about Google being “evil” or not…. I sit back and think about how interesting it is that companies become “people”, especially in this country.

It makes sense when you look up Corporation:

Corporations are recognized by the law to have rights and responsibilities like actual people.

That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn’t a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.

I have been thinking about this ever since the recently surprise court decision the other day that “allows corporations and unions to pour unprecedented amounts of money into elections.”

Lawrence Lessig had some interesting commentary:

The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.

Fun aside

My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on “the mind”.

The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.

Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn’t just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren’t solely based on profit. They want to create a different kind of legacy and company.

That being said, I think it is quite easy to fall into a trap such as:

If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!

Google will sometimes do things that could be considered “evil” by some. That is life.

The good news with Google is that their search and ads business deals in a trust economy. It doesn’t take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.

Not all corporations are profit driven

I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make …. you think of the mission.

It was interesting to work there knowing that I actually wouldn’t want Firefox to be a 90% browser. You can fall into the similar trap as above and think:

We are mission based! If we had that domination we would use it for good!

But, not having that power in one hand is even better. Imagine working somewhere thinking “in my wildest dreams, the market would be shared somewhat evenly with the competition.” The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can’t move as fast as a dictatorship, but there is a reason we don’t want dictatorships in our government (even if the trains run on time!)

And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn’t dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.

I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don’t want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can’t Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.

I don’t want to “kill” these other platforms as they offer competition and spur on the industry. I just don’t want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?

Erm, no.

And thus I find myself torn. I really want to go out and by that iPad……. but when is it “too late”. Surely I have a few years right? I can enjoy the shiny new toy? :)

Remember the first dot-com boom when people started to think that creating a company was just about creating a website? They would register a domain before they had a business plan? Crazy days of sock puppets and and people renaming themselves as dot com versions. Behind the craziness was the reality that to a large extent you did have to have a website. A website was table stakes, and this continues to be the case.

With the iPhone another gold rush occurred. The initial rush is over and you can’t just throw an application into the appstore and hope to make a fortune. You actually have to create something compelling and differentiated to make hour mark. Imagine that!

The “quick buck” allure isn’t there and we are onto the next level of maturity. Having an experience for iPhone users has become table stakes for some too.

So, now you have created your website, and iPhone app, do you go to an Android app? Facebook? One for a new 3D TV? :) It is starting to get daunting.

Walking around at CES the consumer in me gets very excited to see the proliferation of devices. Everything is connected, everything has an API.

Then the developer in me wonders how this is going to scale and how we are going to deliver great experiences to all.

My hope is that the Web can become a great unifying platform. It isn’t easy to build Web apps that will just work anywhere. I just talked about the issues and fun of developing for devices and we are going to be getting a lot more form factors out there.

It has been a very different holiday season as everyone got ready for CES this year. This is my second time at the show (first time was having the honor to pick up an award for the Gears team) and was a very different experience.

It was great to come out with some good news today: from Verizon, to video recording, to Flash, to 3D games. From a consumer point of view the Palm Mobile Hotspot is pretty sexy. Tethering has been a pain, and I was eyeing up a MiFi when I got to learn that devices will be able to become MiFi hotspots. Awesome.

All good stuff, but I am obviously most excited about the developer side of things. This year it turned out that we got to turn on the full developer program today in conjunction with the other CES news. A ton of work went into this first launch of the full program and there is a lot packed in there:

New developer portal

When you work with Ben, you quickly learn that things should be as polished as possible. He really lead the charge on making a great new developer portal with a spruced up look and feel throughout, and some good new content. There is a lot more in the works and the community has been coming together nicely to provide some fantastic documentation too. We now have a good foundation to move quickly on, and to really help developers.

PDK: On-ramp for native code via Plug-in Development Kit

One of the things I love about the Web is its diversity. It isn’t just One Community. It has sub communities galore. On the server-side you have Java and PHP and Ruby and Python and [insert every other platform] camps all at home on the Web. Even on the client-side, despite the ubiquity of JavaScript, you see many different types of developers.

I am really happy that we are providing the Plug-in Development Kit (PDK) that will enable a path to native code on the platform enabling a role that we have seen on the Web via Flash, Gears, QuickTime, RealPlayer, and on and on.

The goals of the PDK are:

• Easy porting of C/C++ applications to webOS, including those that use OpenGL ES 1.1 or 2.0
• Easy integration of C/C++ components to enhance the capabilities of webOS applications

Read more about the PDK.

Flash 10.1

Flash 10.1 fits into this picture too. I am glad that we have a path for Flash developers to get their content to our users. Adobe has been working very hard to make their engine work on mobile. This has got to be a tough problem given the nature of it (event loop etc) and they are doing great. Can’t wait to see the finished product.

Hot Apps

We want to put our money where our mouth is, and want to reward developers in a fair way, so we decided to offer $1 million dollars in cash bonuses to webOS developers through our Hot Apps Program.

Contests are interesting, but having been involved in a few myself, they get very subjective and judging can be difficult. This is why this time around we wanted to try to let the market do its thing and reward developers based on downloads and how many devices have installed their application.

Some high level info:

The Palm Hot Apps Program will reward developers of the hottest webOS applications with a total of $1 million. The top rewards of $100,000 will go to developers as follows:

• The developer of the free webOS application that’s downloaded the most between February 1, 2010, and May 31, 2010 will receive a $100,000.
• The developer of the paid-for webOS app that generates the most revenue during the same period will also receive $100,000.

Developers of other top free and paid apps will also receive cash awards, as follows:

• The next 20 apps in each category: $10,000 each
• The next 200 apps in each category: $1,000 each

To qualify for an award, your app – either free or paid – must be available to webOS users via Palm distribution programs between February 1, 2010, and May 31, 2010. In addition, the following criteria apply:

• The app must have been developed using the Palm webOS Software Development Kit or the Ares Integrated Development Environment. Since the Palm webOS Plug-in Development Kit is not widely available, applications utilizing this development kit or any APIs not in the Palm webOS SDK are ineligible.
• Apps must be available for download through an official Palm webOS distribution program (App Catalog Distribution, Web Distribution, or Beta Distribution). Apps distributed through non-Palm methods do not qualify.
• Apps developed by Palm employees or their direct relations are ineligible for awards.

What do you think of this approach?

GitHub Palm Repository

I am a huge GitHub fan and I am really glad that we have opened up our Palm GitHub account with some goodies. We have various projects that contain sample code that go from ye olde hello world app, to Mitch Allen’s great news app from his book to the indispensable stylematters app that our great HI put out to show you how to make beautiful, usable applications.

I hope that this is just the beginning and that you will see more and more projects on GitHub to fork! Speaking of projects to fork….

Project Appetite

One of the new projects is Project Appetite which is an open source project showing how you can interface with the Palm application feeds that come out of our full catalog.

Early partners have already built sites using the feeds: PreCentral App Gallery, webOS App Catalog Viewer, the House of Palm, and on FreshMeat.

Now you can integrate the feeds yourself. There are a lot of different pieces in that one project, and I need some other posts to go into details on the front end code (some fun CSS transforms if you are in Safari on Mac and hit Ctrl-F!) as well as the backend (using Java, node.js and lots of good stuff). There is still a lot that we want to do to help people and this is just the beginning of that project.

Phew. What a way to start the new year. Thanks for joining me on this journey and I can’t wait to see what folks come up with (including us!)

I have been having a great time hacking on code that let’s me do interesting things on my device. With webOS you get to use your old favorites (HTML/JS/CSS and Web APIs that you know) and now you are ready to take Web applications that you may have even already written, and make them work for the mobile form factor.

The two biggest challenges I have found so far on the design side have been dealing with the real estate available (screen size) and the touchy feely-ness of the device.

We have been trained on the desktop, thanks to the mouse as our pointer interface, to click lots of buttons. The tactile feedback that we get is the button looking depressed, but that is about it. The mouse has a lot going for it. The fact that I have a set of states due to the fact that there is a difference between having the cursor located somewhere, and having a click on that location is useful. It can be especially useful for discoverability. As a user mouses around you can unveil information “hey, if you click this button X will happen mate!” It also has the nice side effect that your hand can rest on it.

The infamous Minority Report interface looked great, and spawned many “look how we can do this now” prototypes, but try holding your hands in front of you for 10 minutes, let alone 8 hours :)

The mouse has a lot of drawbacks though. It is a level of abstraction. You aren’t touching the objects, you are touching a device that takes your input and does the real touching. This of course leads to touch screens and bypassing that abstraction. Watching my son tap and drag and manipulate a touch screen has been great to see. It matches the physical world a lot more. He tried to touch my laptop screen at first too.

Since you are mimicking the real world more though, you get into the uncanny valley problem. If you drag something…. it SHOULD drag! One of the interesting design choices that iPhone made was to allow you to drag things even though some folks would say “don’t let them do that, there is nothing back there”. You then saw studies where people were taking their browser screens and dragging them around just for fun. Crazy :)

Applications started to take advantage of this. iPhone started with many buttons. The back button is the classic one that is all over the shop. On webOS there is a gesture area that trains you quickly to swipe back whenever you want, like going back a page. It is fun to watch a webOS user try to swipe when using an iPhone. You get used to it, you like it, it feels more natural.

Applications like Tweetie 2 groked this too. They took away the refresh button and added a draggable notion. You drag the list down and let go to spin it into action. In many ways this is more work than a simple tap and is a touch less discoverable, but it has the benefit of “feeling nice” and once you know about it, there isn’t a darn button in front of you all the time. The UI can get out of the way.

The Newsroom feedreader app on webOS does a really nice job here too. You flip and drag and move throughout most of the interface. After awhile it feels like you have a large virtual space and you are just moving the view port around to see what you want to see. It feels nice. I strangely find that it makes me want to use the application much more than an app with buttons and simple taps. Maybe I am just strange.

I find that I really enjoy the horizontal scroll. I wanted to build a simple HorizontalScroller component for webOS, but first I will detail the low level side of using a Scroller webOS component to get this effect.

The code for all of this is in my HorizontalScroller GitHub repo.

A simple way to build a horizontal scroller is to have a div that contains all of the pieces of content (pre-loaded, or you can lazily load by adding nodes to this div). It extends wider than the 320px viewport size of the Pre/Pixi and contains other elements that are each 320px. We have a view that contains this, and a controller that sets it all up:

The View

Here is how we setup the component with 3 items:

<div x-mojo-element="Scroller" id="scrollerId">
    <div class="scrollerContainer">
        <div class="scrollerItem" id="scrollerItem:1">first</div>
        <div class="scrollerItem" id="scrollerItem:2">second</div>
        <div class="scrollerItem" id="scrollerItem:3">third</div>
    </div>
</div>
</div>

and we style them:

/* A scroller needs a container element */
.scrollerContainer {
    width:  960px;
    height: 400px;
    border: yellow solid 1px;
}
 
/* An item that is viewable in the scroll pane window */
.scrollerItem {
    float:     left;
    width:     320px;
    min-width: 320px;
}

The Controller

The code that turns the divs into life lives in the controller.

this.controller.setupWidget("scrollerId", {
                   mode: 'horizontal-snap'
               }, this.model = {
                   snapElements: { x: $$('.scrollerItem') },
                   snapIndex: 0
               }
        );

The key is the “horizontal-snap” mode that make the drag physics feel right and ties to the snapElements which are the DOM elements for the inner divs. The widget takes care of snapping to those elements for you!

Of course, you can use this base to do a lot. The afore mentioned Newsroom styles the divs so it looks like switching cards.

Next up: I will get the HorizontalScroller component done and dusted to make life even easier.

Conclusion

It is enjoyable to use the constraints of screen size and the natural feeling of touch and put them together to make great apps that live with you in your pocket. I thought screen size would be a huge issue, but in some ways it has been nice to have that constraint. It means you focus on the core functionality. Dealing with the touch vs. mouse issue is an interesting one too and will have you ending up with a very different interface if you embrace the feel.

What have you found enjoyable about using mobile apps vs. desktop ones?

I am having fun taking my Web skillz and applying them to mobile with webOS. It is obviously important that I learn about the platform. I want to understand the limitations, and get a feel for the SDK so I have opinions on where to take it (Fortunately, the community gives us great feedback, keep it coming!).

As I develop applications I quickly see repetitive tasks that fit into my workflow. You can quickly iterate when you are developing your application and when I am testing in either the device or the emulator I find myself repeating the following cycle:

This maps to the command line tools that come with the SDK.

palm-package

The application packager palm-package prepares an application for installation by converting the files in the application directory to an .ipkg file that can be consumed by the emulator or device.

palm-run takes the given directory to package up, or “.”.

palm-install

The palm-install tool installs a packaged application on the device or emulator.

palm-run uses the -d option to specific device or emulator. The default is “tcp” which means emulator. Use -d usb to send to the device.

palm-launch

The palm-launch tool launches (or closes) an application on the emulator or device.

palm-log

palm-log displays log messages from an application on the emulator or USB-connected webOS device. The log output is simpler and easier to read than the output in /var/log/messages, and the timestamp is the local time instead of GMT. You can also use palm-log to display the installed applications, which is useful for getting the ID of the application to log.

So, palm-run is on GitHub. Fork away and share what you do in your cycle.

Usage

palm-run [-d DEVICE] [-L] [-o DIRECTORY] [directory]

-d DEVICE: Defaults to installing to the emulator. Use 'usb' for device
-L : By default the palm-log command is run. This suppresses that
-o OUTPUT: By default the ipk is generated to /tmp

Examples

palm-run ~/myproject # deploy from /tmp to emulator
palm-run -d usb -L -o /packages ~/myproject
palm-run # use the current directory and all the defaults

I am so excited for the Ares team at Palm today as we launch Project Ares a web based IDE for the mobile web.

The full experience packs a lot into the browser: visual designer, code editor, visual debugger, log viewer, source code integration, drag and drop file upload, built-in app preview, and the ability to run your app directly in the emulator or even the device!

I talked more about the details on Ajaxian and the Ares site has more.

I am so jazzed to see this out there. At Mozilla we saw the Ares team building this great product that uses Bespin right now for the code editor, some of the server side, source control and debugger (the first sighting of Bespin debugger!)

The team has worked incredibly hard since then to build what you see now in public beta form.

This also shows how awesome the web platform it is. Because webOS builds on the web we are able to have features like the “preview” feature that shows you how your app will look without even having to go to the emulator or device.

The performance of the app says a lot too. It is incredibly responsive for me, especially since there are a lot of features packed in there. The layout system is really well thought out too and is a dream when you compare to CSS fun. I can’t wait to see what the community has to say about Ares, and I want to hear features that they would like. After using this, I want to be able to build all kinds of web apps from it ;)

I also want to say thanks to my Bespin team mates and community as well as the new friends I have made at Palm. Matt, Scott, Steve, Frankie…. you guys are awesome and it is amazing to see what you have done in short order!

“If you squint, Chrome Extensions and webOS applications look similar” — a wise friend

Having now written webOS applications and Chrome Extensions I have been struck by how similar they are, and could be.

It may seem weird to see similarity in a browser extension mechanism and a mobile application runtime, but when you look at it, there is plenty to share at a high level:

Breaking out of the sandbox

Both worlds need to break out of the web browser sandbox. Extensions can’t be restricted to the same limitations and Chrome Extensions have various API that relate to UI elements in the browser, as well as getting access to more.

On webOS we have exactly the same issue. When building native applications on webOS you can’t have the same restrictions and thus new APIs, UI widgets, and services.

This issue goes beyond even these too worlds, and is one of the big challenges for Web runtimes in the near future. I expect my runtime to be able to do a lot more and to get access to my data not just through third party server side services, but locally too. This all brings us to…

Permissions

The Web needs a permissioning model. The sandbox doesn’t give us enough, and although people quickly talk about security (which is critical) we forget what happens if the user can’t do something through the Web. They often will download an .exe to their local computer and will just run it, not knowing anything about what it does.

A big challenge for us is to come up with a model that doesn’t Do A Vista and drive our users nuts. We have to balance the desire to not ask the user for something all the time, while making sure the user knows what is happening. For power users at least, I favour the idea of showing me what is going on. Even if I grant an application a lot of power, if I could see when and what it was doing it would help. Of course, being able to restrict access to APIs is fantastic, especially when you get to layer social trust on top of the technical security. The Mozilla team talked a lot about just this and I look forward to more of their ideas and implementation.

(You can see an example of how Chrome does permissions with Cross site XHR.)

Application Bundle Info

The permissions and other metadata need to live somewhere. We have a appinfo.json file that has you declare info on your app. Chrome has a manifest.json.

On the Web we don’t really have this. You hit a URL and you bootstrap from there. The HTML5 manifest does tell the browser which files are in scope for caching and the like, but that is about it. Applications and extensions can tell the system much more. You have ids, versions, pointers to update, icons, main launching points or not…

Headless Chickens

You don’t often think of a headless web app. You can think of headless applications and extensions though. How many services are running on your computer now that have no UI? On webOS you can noWindow away and still provide value through the various services that we offer, the obvious being the rich and varied notification styles. Background apps are nicely supported.

Chrome Extensions have the notion of a background page as a way to manage a long lived lifecycle. Your background page is a singleton:

In a typical extension with a background page, the UI — for example, the browser action or page action and any options page — is implemented by dumb views. When the view needs some state, it requests the state from the background page. When the background page notices a state change, the background page tells the views to update.

In webOS and the Mojo framework we have a rich MVC system with a detailed lifecycle as well as the simple ability to define models, views and controllers.

And on

The more I look at these worlds, and others like them (e.g. Jetpack) the more I hope we come together. There are similar needs, and when you look from Chrome Extensions to Chrome OS, you can see a potential progression if done right.

The Chrome Extensions team had a press event tonight to go over their extensions beta launch that I unfortunately couldn’t make at the last minute. I wanted to be there to see old friends and the good work they have been doing, and support them.

Aaron, Erik, and the team have done a pretty great job with their extension model. They wanted to allow Web developers to develop extensions. Who better to do that than folks who are a) Web developers and b) have written extensions (e.g. Aaron is an old time JS hacker, author of Greasemonkey, and much more since then [Gears etc]).

Of course, over at Mozilla the same idea had been hatched with Jetpack and other equally talented folk are working on that (Aza and Atul and more).

Some of our best Web engineers are on the case, which is great.

Before these new age extension models the world of extensions was tough. On IE you would be mainly a C++ hacker to do anything. Mozilla really raised the bar with its original Add-Ons but even though you could do a lot in JavaScript, there was still a lot of XPCOM and a huge API set since you basically were given the entire Mozilla platform to work with. This was great from a “you can do whatever the crap you want to do” perspective, but it was awfully hard to dive in and get productive.

Thus, most Web developers stayed inside the browser window. We develop applications in our area, and others do the extension thing.

That has changed and we are now breaking out of the browser sandbox in many ways. This is one of them. When we think about delivering experiences to our users we can think of out of the window. What would our users like to be able to do when not on our web site? How can we package our value adds in a way that they can do their thing at any point? How do we interact with the runtime? What can we do if we have more permissions to do interesting things?

We have only just seen the beginning with Jetpack and Chrome Extensions. They are many more APIs to write and for us to then consume. I personally think that Chrome is too restrictive on what you can do in the browser chrome for example. I would love to play around and have my browser morph in interesting ways. If I am on a particular site, new features and functionality could appear if I want them too.

It feels like we are touching the surface on what the Web platform and runtime is versus what a “browser” is as we have envisioned it until now.

2010 will be an exciting year for Web developers as they add extensions to their toolbox in a nice clean way.

I spent a lot of time advocating Gears. I loved the engineers (folks like Aaron Boodman who is doing great stuff with Chrome Extensions, and Chris Prince who now works on the fantastic Google Voice, and many many more…. many of whom are working on Chrome in some fashion).

Today the press is picking up the fact that Gears is dead, even though Google moved its efforts awhile ago (keeping life support turned on) and Linus talks about the focus on HTML5 and Chrome:

“We’re very focused on moving HTML 5 forward, and that’s where we’re putting all of our energy,” Upson said. “When we started the Gears project, three years ago, maybe three and a half years ago now, we did it because we couldn’t get the browser vendors interested in building offline applications. And so, so we said, okay, we’ll build a plugin that could do it. And lo and behold, once we shipped Gears, suddenly the browser vendors got very interested in adding capabilities to build offline applications.

“And so, I think Gears has accomplished its mission very well, in getting these capabilities into HTML 5,” Upson added. “In fact, the team that designed Gears was also instrumental in designing the HTML 5 versions of those APIs. You can almost think of what’s in HTML 5, with app cache, and database, and those things, as essentially Gears 2, and that’s how we view it.”

Many people are happy to wave good bye to Gears and look to the future of HTML5. I feel that too, but I do have a pang of “what coulda been”. The Gears team was incredibly pragmatic. How can we get Gmail Offline? What about other Google properties? This practical experience delivered Gears and the push for support of real APIs that developers need to deliver compelling experiences through the Web platform.

Although it is true that Google can push the cause through their own browser, their properties still need to deal with other browsers. ChromeFrame is one answer there, the new “Google Plugin”. The browser vendors are kicking into gear nicely now. Mozilla, Google, Apple, Opera, and even IE teams are working hard on new features and HTML5 support. When Gears started we (the Web developers) were in the dark ages of browser development. The IE team had moved on to WPF and Silverlight. The other browsers were fighting the fight against a huge IE6 dominant entry with lots of ActiveX keeping it in style.

Does this mean there isn’t a place for a Gears like solution? Yahoo! has BrowserPlus which has the additional benefit of allowing developers to write services. This was one of the issues with Gears. You got APIs that Google gave you. You had no way to extend the experience. Browser Plus allows that and I hope that Lloyd and team have a good 2010.

There is also JetPack (and Chrome Extensions) that allow you to extend the experience in a different way. If I had my way, Gears and Y!BP and JetPack would all have joined forces. That world would then look like:

• Gears/Y!BP allow functionality to work cross browser and offer a services framework to allow you to write new components that also work cross browser. This is fairly low level work, with some nice sugar for certain APIs.
• JetPack would give you access to low level APIs in a nice high level JavaScript API. Since it would run in Gears/Y!BP it would run cross browser too.

My wish for Santa? Have JetPack and Y!BP pickup and work together. Give developers a platform to create new services on the Web and have them work cross browser. We shouldn’t have to wait for browser vendors to implement APIs. We should be allowed to experiment more. Gears started its job with the zipper running higher, but there is always more room to run. If we worked out a way to get more people playing with the platform we could get so much more done. We saw what came out of “how could we do Gmail Offline” what about your application needs?

I will raise a glass to Gears and the new HTML5 overlord, but I will miss the vehicle for cross browser experimentation and what coulda been.