With the introduction of Chrome OS, it’s tempting to criticize Google for what seems like a half-baked product. Compared to OS X, Windows 7, or even Google’s own Android, there is a lot lacking. But there are interesting ideas, even if they are not the first to propose them.

Where they’re not pushing the envelope enough is the interface. It’s a little disappointing that when they thought of making a web-based PC, they turned it into a web browser-based PC. There must be a better way to enable what they’re doing besides putting browser tabs at the top of the screen and an address bar underneath. It would be like Apple being unable to think outside their desktop OS and releasing the first iPhone with an interface that used a scaled down menubar.

Where Google is pushing the envelope too much is the entire rest of the OS. It’s interesting in theory, but not yet practical. It’s a good thing they are starting down this road so that hopefully in 5 years it will have developed into something that will be useful. Currently, there’s simply not enough infrastructure in place to make it a successful experience.

Where is your private file space in the cloud? When you buy a computer, included by default with any and all computers is space to store your stuff. You can share things if you want, but that’s something you opt-in to. If you buy a ChromeOS device, you had better be prepared to spend a lot of time getting up to speed on the privacy controls of each service you use, because private spaces in the cloud are hard to come by. Or you better know about dropbox/sugarsync/whatever and be prepared to pay an annual subscription to rent some online space. Simply put, the vast majority of people are not yet at this point.

Internet access isn’t where it needs to be either. HTML5 is a great starting point for offline connectivity, but so far it’s only a starting point. Will ChromeOS store your entire Gmail archive in its offline database by default, so if you’re working at a cafe without internet, you can reference an email you sent 3 months ago? Not yet.

Thinking about how ChromeOS is being developed and presented, one of the striking differences between Google and Apple is that Apple almost never* releases something before all the pieces are in place that are required to make it completely useful. Apple didn’t make the iPod when MP3 technology first appeared, they waited until they had music management software with an interface that made it easy to fill up an MP3 player AND enough storage could be packed into a small enough space that people could put it in their pockets. Whether Apple will successfully compete in the cloud is to be seen, but you can bet that they won’t release something along the lines of ChromeOS until they can craft an experience that fits seamlessly with the way people live their lives.

And so this is the key to evaluating ChromeOS. It’s unfair to look at it as a finished product to be stacked up against whatever Apple and Microsoft have currently released. For all its flaws, it’s obvious that it isn’t a product built for now. It’s a starting point for the future. Google’s description of using it as a “companion PC” is another way of saying “this isn’t ready for prime-time”. It’s a prediction of where computing will be 5-10 years from now.

Does ChromeOS have more potential than the many other thin client projects that have come and gone every several years? Google’s deep pockets and long gaze are cause enough to pay attention. Watching its evolution will no doubt be informative.

* Apple TV = the reason for the “almost” in “almost never”

HTML (”hypertext markup language”) is the core language that powers the World Wide Web. Any server side technology must in the end, display HTML in order for web browsers to be able to render web pages. HTML 5 is the latest revision of the HTML spec that is slowly being adopted by the different major browsers. There are some pretty exciting additions to the HTML spec and I wanted to go over a few and what they potentially mean for the future of the web.

New Tags
Structure Tags
New additions to the HTML markup family include tags like header, nav, article, section, and footer. From the visual perspective these probably won’t have a huge impact as users are unlikely to see the difference between pages built on the old DIV based layout and the new structure tags. However from the search engine perspective, these tags will make it easier for crawlers to distinguish between what’s the meat of the content and what is just fluff. Current DIV based layouts structure the content semantically through unique IDs and classes. We give these DIVs IDs and classnames like header, footer, post, etc in an attempt to classify and organize the markup. However these are abstract concepts from the browser’s perspective. If they wanted, there’s nothing stopping the web developer from naming the header something arcane like foobar or even call the footer something like nav_sub2. As you can imagine then, search engines and web crawlers must develop sophisticated algorithms to detect patterns in order to infer what’s a header or footer. However with these additions, the developer must clearly demarcate what section each HTML piece is, thus taking the guesswork out of the search engine. This has the benefit of potentially improving search engine results.

Canvas Tag
The new Canvas tag is exactly what is says it is - a blank canvas with infinite possibilities. Flash developers used to drawing pixels on the MovieClip object will immediately be able to relate. Essentially one would use the canvas tag to render any number of things from manipulated images, animation, or even 3D imagery. With the canvas tag, you could build applications such as a paint program, or a 3D slideshow without having to rely on Flash. As usage of the Canvas tag increases, you’ll see more animation and renderings that were typically done in Flash re-envisioned completely in HTML5 and Javascript. The drawback however is that whereas Flash is build once run everywhere that supports Flash, an HTML 5 solution would leave you vulnerable to browser compatibility issues.

Here’s a video of a Coverflow implementaion done purely in JS + the new Canvas tag

AV Tags
The Audio and Video tags promise to simplify the mess that is currently the state of the art when embedding video. Whereas before you had either the <embed> or the <object> tag depending on what browser you are using or maybe you just turned to a javascript based wrapper to handle your media needs, you can have a very simple video or audio tag. With the ubiquity of the Flash platform as a video player, I’m not sure this is going to make much difference. Sure this is a lot easier, but we really could have used this 10 years ago.

<video width="640" height="360" src="/demo/google_main.mp4?2"
autobuffer></video>

Web Worker
Think of Web Workers as threads - any jobs that can be computationally expensive and intensive. In the current model, a complex task on a webpage might bring the interactivity of the page to a crawl while it’s busy number crunching. A worker thread could be spawned off to do some intense client side crunching without bogging down the page. This is even more relevant in today’s time when so much is being offloaded to the front end UI with javascript libraries. A good candidate for web workers would be a browser based excel spreadsheet like Google Docs where number crunching on the client site is potentially very slow.

<script>
   var worker = new Worker('worker.js');
   worker.onmessage = function (event) {
     document.getElementById('result').textContent = event.data;
   };
</script>

Application cache
The Application cache allows web applications to function offline when it’s not connected to the Internet. Google Gears is an implementation of this. All the developer has to do is provide a manifest of files that the web application needs in order to function offline. I see this as a really great feature to make web apps more robust. With most webapps, if you lose connection, you most certainly lose whatever you were working on. I can see more and more applications handling loss of network connectivity more gracefully by taking advantage of the application cache.

All you need is this code snippet and a manifest file which lists all the files the application needs.

<html manifest="foobar.manifest">

Geolocation
The Geolocation API provides a scripting interface that lets the developer determine the user’s location (based on GPS or inferred from IP, Wifi, etc). The user must however allow the application to access that information. Although geolocation has been inferred by IP for a while now on the backend, we’re seeing an increase of functionality performed on the front end with AJAX and this is no different.

navigator.geolocation.getCurrentPosition(function(position));

Should I be using HTML5 tags?
Here’s a table outlining features I played around with in the latest browsers from Google, Apple and Mozilla.

* only certain formats
** sort of worked

As you can see, coverage on some of the new HTML 5 features is pretty good on Firefox and Safari. However with the audio and video tags, I did find that Firefox supports the open source codex Ogg Vorbis while Safari’s supports all the formats that Quicktime supports, naturally. So if you are looking to use some of the new HTML 5 features now, coverage on all the browsers is sketchy at best except for the Canvas tag. If you are trying to do video or audio, you’d best stick to Flash. I think where HTML5 is useful for the here and now is in the mobile sector. Many new mobile OSes including iPhone OS 3.0 and webOS have started supporting some of the HTML 5 features and since you would be developing platform specific apps, compatiblity issues are non issues.