Chromecast: progress that misses the mark

Google's newly announced Chromecast is among a rare breed of particularly frustrating technologies. It makes progress toward an ideal but leaves me wanting.

Notably, Chromecast is a very narrowly-purposed implementation of view sharing the likes of which would be the underpinning of PAO (personal application omnipresence). Chromecast's chief use-case seems to be shoving video from a control device to a large monitor ("television").

PAO on the other hand is about attaching multiple context-sensitive and concurrent views to any number of applications at will. In PAO, I could view my Thunderbird instance, favorite Youtube videos, IM client, Twitter client, media player, or anything else running at my application server on my cell phone, on my television, or at my office workstation. Each view would be responsive to the device's characteristics.

To be clear, PAO doesn't exist. I'm hoping that it will some day. Announcements like Chromecast are proprietary and restricted steps toward the ideal, but steps nonetheless. Hence my frustration. A company the size of Google could realize PAO (although I just this week suggested that Microsoft should do so).

“Thickness” of the view

When consuming content hosted by a third-party, a PAO-enabled application would very likely flatten stream consumption, decoding, and rendering into the view. Doing so blurs the traditional model-view-controller (MVC) lines a bit, but adherence to MVC has never been a very strict matter, and certainly isn't today.

Apparently, Chromecast works the same way: by default it pushes just the location of the data stream to the receiver. The stream is not relayed through the control device.

However, Chromecast may also support a full view-pushing mode (where a composed view is transmitted from the control device, in a manner similar to VNC or Miracast). In both cases, the view is being pushed and while that is certainly interesting, the PAO model would provide both push and pull, with most use-cases being initiated from the view device—in other words, a pull.

As far as I know, in both of the Chromecast modes (stream-descriptor push and view push) the view remains read-only because, again, the use case for Chromecast is not providing a second input/output terminal but merely another output view.

Because PAO would provide both input and output across a spectrum of device contexts, a PAO application would use thicker views. The view would be responsive to the device's capabilities in the same way a responsive web application is today. A device with no input capability would display no input user interface elements.

Sit back and be Google consumers together

PAO is for any application. So what irks me most about Chromecast is its narrow purpose. Chromecast is a Google device, so it's designed to promote the consumption of Google content and the use of Google services.

As much as I want it to be, Chromecast is not about connecting my phone, my office workstation, my home computer, my tablet, and my television monitor, each in their own way to singular running instances of my applications—my singular Thunderbird, Trillian, and MetroTwit instances. It's not about consistent application state with multiple views across all of my devices.

I am left vaguely interested but ultimately disappointed.
About this blog