Conceptualizing Chromebooks, Chrome OS, and HTML5-based apps

According to Donovan Colbert, Chromebooks and Chrome OS aren't that revolutionary or different from other platforms - they just add an abstraction layer between the user and the application run-time environment. Do you agree?

I know that I've personally struggled with understanding and conceptualizing just how Chrome changes the model of the user/application interface compared to traditional OS platforms, and I think a lot of other people are struggling with this too. I've come up with an analogy that may be imperfect, but it will help many users understand how Chrome is similar to and different from traditional models of computing interface.

Let's start with iOS, which is a surprisingly good example to begin conceptualizing what's going on with Chrome OS. iOS is an incredibly closed platform that restricts users from much more than adding or removing apps, moving them around on a GUI desktop, and launching them. It's like an automobile with a hood that's sealed shut so tightly that only the factory can open it up.

When you download an app, there's a file structure on your iPhone, iPod Touch, or iPad, and the executable binary and library files necessary to load that app get copied into the file structure, just like on a traditional OS (Linux, OS X, or Windows). The only difference is that this is hidden from you on iOS.

The Apple approach is to deliver you a computing appliance. You just push buttons and it should work. If there's a problem, there are "no user serviceable parts" inside.

Android works the same way, to a certain extent. Your experience is through a shell, a front-end, that hides all the mechanics going on beneath the user interface. This is a contrast to the older model of OS platforms, which allowed you to get into the nuts and bolts of the file system, registries, libraries, and other deep system details.

Chrome can exist in several different models. Basically, no matter how you get into Chrome, there is a host OS that is a traditional model of OS as described above. On Chromebook devices, it will be the most minimal installation of a Linux OS possible - enough of a kernel and a GUI shell to launch a single locally installed application, the Chrome browser. There will be a file-system and structure underneath, but you'll be locked out of it, and it won't be something easily accessed by anyone without a lot of *nix experience, if at all.

An iPad or Droid is an actual physical hardware device interface. On the other hand, the Chrome browser is an abstraction layer that simulates a hardware device interface. It becomes a virtual machine.

When you open up Chrome, the Chrome "desktop/launcher" is functionally the same as your iOS or Android desktop. You'll see a collection of apps there - many of which are stored in Chrome on your local machine. The binary executable for the app Angry Birds, Dropbox, or most other apps is downloaded, installed, and accessible in the future from within the virtual file system of the Chrome OS visualized through your browser window.

I know that is a mouthful, but basically, it means that the app you download and install in Chrome OS appears in your Chrome browser desktop in the same way it would appear on the desktop of your iOS or Android device - and when you click on it, it loads and runs just like any other app in many cases, even if you're not connected to the internet.

You could conceivably take this concept pretty far. There would be nothing technically preventing Google from allowing developers to create virtual file-system hierarchies and file explorers that would give you a graphic representation of that virtual "file system," including where documents and other files were stored locally within the Chrome OS, or other system utilities and applications.

I don't think this is Google's intended direction with Chrome OS, though. They've stated numerous times that they want to encourage users to travel to the web more often, to spend most of their computing time connected (not offline), so Google's goal would seem to discourage this kind of approach to local computing and file storage with Chromebook devices.

Currently, on a test system running JoliOS with Chromium on a netbook, I have several apps, including Angry Birds and Super Mario Bros. Crossover. Once I downloaded, installed, and ran these apps, I could load them later on without an active Internet connection. This isn't anything new. Browsers have been able to download Java .jar files, scripts, and other code, and store them in the browser cache to be executed later, even when not connected, for a very long time.

My guess is that when running Chrome on a system with access to the physical file system, one could browse to the Browser Cache directory, find the executable, and manipulate it manually - copying it to another system and double-clicking it from the file system to load it there without a download, for example. Chrome simply keeps these files and displays them on the Chrome OS browser desktop, making them easier to access and load in the future.

There's a lot of misunderstanding about Chrome OS and "web-based, HTML5 apps." After all, Chrome is really just a browser - no different than Firefox, Internet Explorer (IE), or Opera, for all practical intents. As a matter of fact, you can point your IE browser at, and the site will ask you if you want to download Chrome or if you want to install Chrome extensions, which will allow you to play Angry Birds right from IE.

At the same time, the way the concept will be executed on Chrome OS hardware - it's basically an abstracted virtual machine displaying downloaded applications on a GUI desktop. The practical effect doesn't necessarily have to be that much different than the experience you get when you pick up an Android or iOS device. You'll see apps, click on them, and most of them will load and run whether you're online or not.

Many tech journalists have claimed that "Applications can't be installed on a Chromebook," but it isn't clear to me that this is true. It will be interesting to see if Chromebooks will allow any sort of local file storage or apps that are designed to run locally with local media. For example, there should be nothing preventing a user from installing a Chrome OS-based media player that would play locally stored digital music libraries and content.

Google is already testing an offline-enabled version of Google Docs. I presume it will allow you to access the Google Docs Office Suite without a connection to create your documents, spreadsheets, or presentations, and it will automatically sync those items with Google Docs Online the next time you connect to the internet.

Chrome is fully capable of hosting locally installed "native" Chrome OS applications that run offline. The only apps that require an internet connection are useless without a connection anyhow, such as Facebook, Twitter, Dropbox, and other applications designed to leverage web and cloud based resources.

Chromebooks and Chrome OS aren't that revolutionary or different from other platforms - they just add an abstraction layer between the user and the application run-time environment. There are lots of platforms and environments that already do this. Google is simply presenting this to us in a new way, which makes the browser the window and interface into our digital world. We'll have to wait and see if Google is successful with this approach.

Please feel free to leave your observations, comments, criticisms, or corrections in the comments. I think there is a lot of elaboration that can be done on this topic.