RIM's Playbook, Google's CR-48
So the Techworld is abuzz with news of Research in Motion's Blackberry Playbook. (Pictureful review here.) The 7-inch device is the newest entrant into the quickly crowding market of Tablet PCs. Unfortunately, the Playbook's intial impressions all come back the same way:
"It's half-baked".
Let me expand upon that. While the hardware is very nice and considered a solid contender, the software experience leaves a lot to be desired. This is to be expected as the operating system is not Blackberry OS -- contrary to branding -- but a new os based on QNX. QNX is an embedded OS with a long history of running mobile and critical computation platforms for the better part of a decade. All of that QNX goodness, however, is backend. The user-land of the device runs (if memory serves) Adobe AIR, a repackaging of the Flash platform.
The UI is very clean and attractive. It takes cues from Blackberry OS 6 as can be seen in the home screen. Many bloggers have accused the Playbook of "stealing" ideas from Apple's iOS and HP's webOS. In the former's case, the blogger was referring to how one can rearrainge icons on the screen by holding down an application icon. The latter case refers to a swiping gesture from the bottom to the top of the screen to close an application. Really?
Are we really arguing about this? While I may be critical of Apple these days, a good UI idea is a good UI idea -- theft is the highest form a praise in this industry. Just because someone else implemented the idea first, does not mean that everyone else must implement something completely different. In fact, I find the opposite to be the case. Users become accustomed to certain gestures when interacting with a device of a certain form factor. Holding down an icon on a home screen to reorganize or swiping upward to close an app seem intuitive gestures to me. They are simple and elegant. Creating another gesture to do the same thing (where no patent prevents, or is worth the court battle) is a good thing for the users.
All of this gets into the notion of User Interface Patterns. Users expect a device to behave a certain way based not on it's OS, but on it's form-factor. Arguing that a good, intuitive, and elegant UI pattern is "unoriginal" is stubborn and short-sighted. With this sort of thinking, if one OS invented the mouse today, the blogosphere would erupt in ire at the first copy-cat. Please, get over it.
I ran across another sort-sighted argument the other day.
While checking my twitter feeds, I noticed a retweeted articule from the Huffington Post about why ChromeOS is a "stupid idea". Those of you that have listened to me on the OSNews Podcast know that I myself was sketptical when ChromeOS was first revealed. I couldn't possibly see how an operating system that consists entirely of a web browser would be of any use.
Then my job changed.
I work as an IT education developer. I write classes and training material for multi-million dollar enterprise software. For most of my career, each class I have written revolved around a particular product. I would write modules for each major feature of the product, breaking it down and educating students how to use and configure each feature.
About a year ago -- some months after my company was acquired by my current employer -- my boss informed me that I was to be given the new Cloud Computing cirriculum. At first, I assumed that it would be yet another product class. Cloud is so new, however, that a great deal of conceptal understanding is required in order to get started.
To educate myself, I decided to throw myself into it. I switched to in-browser applications where I possibly could. I subscribed to twitter feeds, blogs, and podcasts. I buried myself in the industry in order to understand what in the hell this Cloud thing was all about.
My opinions on ChromeOS were formed before any of this happened. Instead of being released at a breakneck pace -- as many bloggers assumed -- ChromeOS's release plans have been a snails saunter at best. I had initially taken this as a sign of eventual failure given the metoric rise of the Android platform.
Then Chrome 10 hit.
Chrome 10 introduced the Chrome Web Store -- an online repository of downloadable "apps". HTML 5 actually specifies this facility. Web sites can specify which files may be "cached" so that when the bowser is offline, the site can still be used. Perhaps not particularly useful for Facebook or Twitter, but think about Google Docs, Zoho, Producteev, and other SaaS (Software as a Service) applications. It is conceivable that you may still want to use these to get some work done while your Internet connection is down. These are perfect cadidates for HTML5's offline caching.
Except there's a problem.
Not a technical problem, a human problem. Users aren't aware of this facility at all. Granted, they may have been told, but how the spec lays this out leaves a lot to be desired. According to HTML 5, offline cached pages are available by entering in the web site's URL. I don't know about you, but the idea of trying to enter a URL in when I'm offline feels....weird. I expect the site not to be available because I know the computer is offline. If users aren't in the dark enough, developers may overlook this feature as sparsly used, or too complex to implement.
When the Chrome Web Store was introduced, many people thought the "apps" were just fancy bookmarks. Why even have them and introduce all the code cruft that comes with them? If you read Chrome's own developer documentation, you'll discover there are many motivations that suggest that a bookmark is simply not enough for a SaaS application. SaaS applications require special access permissions to browser features (configuration, storage, history) in a way that a mere bookmark cannot provide. When looking at an app on the Chrome Web Store, you'll notice the permissions in a sidebar on the right.
But it goes further than that.
Chrome apps are really *.crx files -- basically a ZIP file with another extension. This is a common practice given the ZIP algorithm's speed, features, and cross-platform ease of implementation. The *.crx files contain at minimum, an XML manifest file. This manifest specifies the name of the app, the icon, the permissions, and where to load it from. It's this last field that makes Chrome apps different.
Chrome apps come in two flavors, one in which all the files that make up the meat of the application are available elsewhere on the internet, the other in which the code is in the *.crx file itself. This latter mode enables dabblers and developers to create and publish HTML 5 applications without the need to drum up the web hosting themselves. Many Clock and Stopwatch application on the Chrome Web Store refer to no external site at all.
Chrome apps are not meant to replace the offline caching mechanism of HTML 5. In fact, they are their to make it obvious and intuitive. A good example of this is the application 3DTin. This application was originally packaged entirely in the *.crx file. As the app gained in popularity, the developers wanted to make it available for other browsers such as Mozilla Firefox. But, *gasp!*, *.crx files aren't understood by Firefox at all! 3DTin came up with a brilliant solution -- the application was rewritten to take full advantage of offline caching and uploaded to a public web server. Then, the *.crx version was stipped of all of its code, replaced with a reference to http://www.3dtin.com. Now the Chrome app for 3DTin instucts the browser to go to www.3dtin.com, and the web site instructs the browser which files to cache for offline use. This allows the developer to maintain only one "packaged" version of the app, whereas the *.crx is just a reference.
What about that HuffPo guy?
I've learned a lot about Cloud, HTML5, and Chrome in the last year. My understanding is a lot more nuanced. ChromeOS hasn't seen a wide release yet because the world in which ChromeOS would work best in, does not yet exist! Google is creating this world through the use Chrome of traditional desktop platforms, and the Chrome Web Store. The Web Store is an astonishingly clever way of making this happen. Google is waiting until the application space provided by the Chrome Web Store has matured enough to make ChromeOS viable.
Drat, lunch is over. Back to work.
