A Chromecast with a Remote

The internet is a series of tubes.

Last week Android TV leaked on The Verge. The leak was conveniently timed right after the Amazon Fire TV release, and featured unusually clear screenshots that were perfectly front facing but appeared lightly filtered, almost as if to make them appear as though they were unintentionally leaked. Regardless of intent, it gave us an insight into the set-top box that Google is supposedly building.

Just a couple of months ago I bought into the Google Chromecast, a headless HDMI dongle that streams the internet to your TV. The Chromecast is as simple as can be: it requires you to use your handset or tablet to control it, so there are no “apps” per se. In fact, in order for Netflix to support the Chromecast, it has to offer its content — movies, TV shows, poster art, box art — as URLs. Because the Chromecast can read nothing else.

That’s where it gets interesting. The article in The Verge suggests an obvious question, why is Google making a set-top box that requires apps when its first successful TV device required none? Thankfully, GigaOM filled in the blanks in their article on the technology behind. If I’m reading the tea-leaves correctly, Google have indeed cracked it, and the Android TV doesn’t really require apps — not in the way we’re used to:

I’ve been told that Google’s new approach wants to do away with those differences by replacing these custom interfaces with standardized templates. Publishers wouldn’t need to come up with their own user interface, but instead would develop apps that provide data feeds to the Android TV platform.

Read it this way: you don’t have to make an app for the Android TV, your content just has to be URL accessible. In fact, if a service is already Chromecast ready, putting it on Android TV will probably require very little work. It’s quite clever; just expose the content-tube endpoint and  you have the best of the internet in a native experience, like an RSS feed for television.

Android TV is just a bigger Chromecast, with a remote-control and an interface, should you prefer that. Ted Stevens was right all along.

Chromecast

Ordered the Google Chromecast the other day. It’s a little HDMI dongle you put into your TV to make it smarter. Amazing gadget, I must say, it’s been a while since I was this excited about a piece of electronics. It’s not that it’s that full-featured — right now it’s only actually useful if all you need is YouTube and Netflix (which happens to be the case for me) — rather, it’s the implications of the device that excites me.

It doesn’t have a remote control, and the device does nothing on its own. The remote is your phone or your tablet or your desktop. All the device does is receive streams from the internet, and you “suggest” those streams from your handheld. In essence it downgrades your “smart-TV” (or in my case, upgrades my dumb-TV) into being simply a display capable of receiving input. It removes every single bit of UI and interaction from the television itself, and propels it onto that thing you have in your pocket regardless.

The concept alone blew my mind when the implications sank in. I doubt it’s controversial to say that television UIs have sucked for decades. Just pick up your remote control and look at it, chances are you’ll find more than twenty buttons, 90% of which you’ve used only once. Alright maybe you picked up an Apple TV remote — vast improvement over most other remotes, but why is that? Right: fewer buttons. Which is why requiring all interaction happen on your smartphone is such a novel idea: by virtue of being a sheet of capacitative glass, your television remote now has only the buttons necessary, and only when you need them. 

It’s just great.

What’s even better is not having to switch on your television and change to the “HDMI” channel. The Chromecast is always listening for input, so if you tell it to play Netflix, it’ll turn on your TV for you, on the right channel no less. When you turn off the television again (alright, I suppose you do need your remote for that — and for volume), your Netflix app will pause the show you were watching. 

This is how television is supposed to work. They’ve cracked it.

Yeah sure, it’s early. Most people will need set-top boxes for a while still. For a 1.0, however, the Chromecast is remarkable. If only Netflix would auto-play the next episode in a TV show, if only Pocket Casts was Chromecast enabled… But hey, this dongle auto-updates transparently in the background. Who knows, maybe next time I turn on the televison, there it is. It is Chrome-based, after all.

Android, several years later

Google I/O is wednesday, which traditionally means a peek at the next version of Android. Having used Android since version 2, I thought now would be a great time to reflect on how far Android has come.

design

Droid

The Android open source project has been around since 2005, but it wasn’t until Android 2.0 (no unique dessert name, Android 1.6 was “Donut”) was released alongside the Droid phone that Android started its rise to some sort of smartphone dominance. Looking back, version 2 of Android was a pretty uninspired affair with very few good apps to brag about. Some apps were crashy and copy and paste wasn’t everywhere and not particularly good. The experience as a whole felt sluggish and laggy.

What made it worth getting instead of the iPhone, however, was the fact that everything synced as soon as you were logged in with your Google account. There was not a trace of iTunes, and did I mention the superior turn by turn navigation? Douchy hipsters would ask why anyone in their right minds would get an Android phone when they could buy an iPhone instead. Even back then, the answer was: sync and maps.

The Nexus Phones

HTC_Desire_cyanogenmod

While Android 2.0 started the rivalry between Apple and Google, Android 2.1 (“Eclair”) which coincided with the Nexus One, set the war ablaze. Pinch to zoom was omitted due to threats of themonuclear war, but the phone itself was still the best Android to date.

Only, there was a problem: way too little internal storage. 256M if I remember correctly. This little space had to hold the entire operating system, including apps, including application data. Which meant, of course, that you’d run out of space within days if you used the phone like you were presumably supposed to. Android 2.2 (“Froyo”) tried to mitigate this embarrassing hardware decision by allowing you to store apps on the SD card, but since application data was still stored on the system partition this change did little to fix the situation. Visually, Eclair received relatively minor tweaks, Froyo likewise.

home-plain

The Nexus S was released alongside Android 2.3 (“Gingerbread”) and it solved most of the problems that plagued the Nexus One. There was plenty of internal storage. Copy and paste was now unified across the operating system. There was a new, darker and flatter skin that made the experience a bit more elegant but the design felt weirdly half-baked. As a whole, the phone felt snappier, more coherent, and generally more pleasant.

Only, once again there was a problem. The stock Android browser bundled with the Nexus S was optimized for Snapdragon processors, not Hummingbird processors. The Nexus S had the latter, so browsing anything not mobile optimized was slower than it was on the Nexus One. You had to go out of your way to find an alternate (inferior) browser such as “Dolphin”. Not cool.

The Honeycomb Detour

honeycomb

We eventually found out what ailed the Nexus S. Google was busy making a tablet-friendly version of Android, and either didn’t have time to completely optimize the Nexus S, or simply chose to focus on the tablet instead. Matias Duarte, the original designer for WebOS, had been brought in to spearhead a strong visual direction for Android 3.0, “Honeycomb”. At the time, Gingerbread was just about ready to ship, and Honeycomb development was already underway. So the half-baked feeling that came with Gingerbread was due to the furious race toward the tablet.

For the very same reason, Andy Rubin had made the call that Honeycomb would be tablet only. There simply wouldn’t be time to scale the experience down to the phone form factor, that would have to happen in a later release. There was a lot to like about the end result, but arguably more to dislike. Regardless, a strong direction had been laid, and difficult structural decisions were in place.

Goodbye, Menu Button

Cue Android 4.0, “Ice Cream Sandwich”.

home-lg

Like sandwiches are combinations of things, Android 4 was for both phones and tablets. It drastically iterated on the Honeycomb UI. The spacey clock was now minimalist, and the pretty terrible Tron font had been replaced with a custom Helvetica-esque “Roboto” font. Applications, icons, even menu items were given a strong design direction, and the result for apps that used this new “Holo” theme was pretty gorgeous. Ice Cream Sandwich was released with the Samsung Galaxy Nexus, and later rolled out for the Nexus S (complete with a stock browser that was finally optimized for the Hummingbird processor).

Impressively, Ice Cream Sandwich managed to shed some of the legacy shackles that had held back earlier Androids. The Menu button, once a requirement on Android phones, was now frowned upon, and developers were asked not to rely on it. Every menu item would come with an icon and shown directly in the action-bar if there was room (and land in the Action Overflow menu if there wasn’t). The death of the menu button was welcome since the button itself was the epitome of mystery meat navigation. Ironic then, that toolbar items would be icon-only. Still, Ice Cream Sandwich was a huge release with fundamental and difficult changes to Android, necessary for the platform to stay competitive.

Waltz

For every problem Android releases would solve, however, new problems would become apparent. Like a waltz — two steps forward, one step back — Ice Cream Sandwich was no different. While the menu button had been killed, the problems with the back button had become increasingly apparent. I’m not even going to try and explain how the back button works, but here’s a chart:

navigation_between_siblings_market2

It’s not optimal. But it’s certainly fixable. Especially on the Galaxy Nexus, where buttons are software. If killing the back button is on the … menu… then it’s possible. If not, there has to be a way to make its behavior more predictable.

In a similar vein, now that Android is beautiful, it’s becoming increasingly clear how most developers don’t care about optimizing their apps for Android. Most apps aren’t using the new Holo theme (which is legitimately beautiful). There are notable exceptions — Tasks, Foursquare, Pocket — but even first-party apps like Google Listen haven’t been updated to the new 4.0 SDK level. If Google can’t eat their own dog-food, how can they expect developers to?

Jelly Bean

Wednesday is Android 4.1 day and it’ll be interesting to see how Google intends to tackle the problems facing their platform. Perhaps it’s time to mimic Apple and create the “Android Design Awards”, showcasing well-designed Android 4 apps in the market. Might as well give a reason for developers to update the SDK level.

There’s also the problem with timely updates. As it turns out, an operating system running on an ARM processor is fundamentally different from one that runs on, say, an Intel Processor. Where on the latter, you can simply make one OS distribution you can install on every Intel processor out there, ARM operating systems have to be written directly for the specific version of the processor. Which incidentally explains why you won’t be able to install Windows RT (Windows 8 for ARM) yourself. So how can Apple do it? Well they build everything themselves, so they don’t have to target more than one processor.

Still, all of that is just software. Software is written by humans. We tell software what to do. If updates for Android are hard to do because there’s no generic interface for the ARM CPU, then make one. Whatever you do, Google, the big next challenge on your table is making Android easy to update.

Hey Google? One more thing. It would be nice if the Nexus phones you make aren’t so big they don’t fit in my pockets.

Next for Chrome OS

Remember Chrome OS? No? That’s okay. It’s Googles Chrome-browser with a stub of Linux underneath it, making the browser the operating system. I believe in this thing, not for myself, but for my mom; the ability to hold a couple of buttons while it’s booting to format the entire system and reinstall it from the cloud, keeping all personal files intact, is pretty much the perfect mom computer. Still, Chrome OS and “Chromebooks” never really took off. Now Google’s trying to take it to the next step, which apparently means a window manager:

While there’s some interesting UI going on, particularly with the semi-fullscreen-split-view and the ultra-minimal taskbar, I can’t help but feel like they could’ve done something really interesting with this. I don’t think the desktop has a future.

Icons vs. Text

Aside from petty discussions on whether Google is evil or not, design-wise it’s an exciting time to watch the evolution of their products. Services across the board are being redesigned, some from the ground-up. There are even traces of an emerging consistency between the web-services and the Android operating system.

One trend in particular I’m following with great interest, and that is the move from text-labels to icons. Here’s Gmail:

gmailbuttons

It’s interesting because Google used to be a bastion of usability, and having only icons goes against what I’ve learned on the matter (which is that icon + text label reads best, only text label reads okay, icon only reads the least). So why did Google do this?

Google’s a big company. They’re known for being data-driven. So much, in fact, that they were once criticized for A/B testing shades of blue. Which means unless Larry Page has uprooted every previous principle the company was founded on (which I doubt), I’m pretty sure they’re watching the numbers on this one, and I’d be lying if I said I wasn’t interested in the results on their icon vs. text-label A/B tests. The fact that the icons are still there in Gmail tells me that either the negative impact of icon-only navigation was negligible, or that the decision to go with icons only was forced through despite.

Icon-only navigation can be gorgeous, sure, and well-designed icons or icons based on established metaphors can be really easy to read. The trash-can, for example, is hard to get wrong. But surely some actions can’t easily be translated to icons only? Here’s the Android 4 camera app:

android-camera

In the above screen capture, I’ve opened up the photo configuration pane. From left — the ellipsis means “more settings”, “SCN” is short for “scene”, the plus/minus is “exposure”, the “AW” is “white balance” set to “auto”, and the lightning is “flash mode” set to off. The icons are gorgeous, but some of them don’t read very well. Particulary SCN means they threw in the towel on an icon.

So where did the whole “icons first” trend start? Android, maybe. From the brand new design guide:

Action bar icons are graphic buttons that represent the most important actions people can take within your app. Each one should employ a simple metaphor representing a single concept that most people can grasp at a glance.

You should really head over to the design guide, the icons really are beautiful, and they are a core aspect of Android 4 apps. To put it briefly: Android 4 apps rely heavily on the action-bar. The action-bar is a bar across the top of the operating system. On phones it features an app icon and app name on the left, and as many icon-buttons as there’s room for on the right. If there are more buttons than there’s room for, these buttons go in to the “action overflow” button, which is the small ellipsis. Click the ellipsis and the icons are shown in a dropdown menu by their text-label counterparts. It’s discussed at length on the Android Developers blog.

As beautiful as icons can be, is the lack of text-labels sacrificing usability? Here’s Photoshop Touch for Android:

pstouch-1-600x375

Compare and contrast with desktop Photoshop and the UI is a far cry. Obviously the two apps are no-where near feature parity, but UI-wise the difference is stark. The Android app relies on the clean, uncluttered iconography whereas the desktop app fills the top of system-bar with text-labelled dropdown menus.

I really don’t know what’s best. On the one hand, icons certainly make for a prettier UI. If screen real-estate is at a premium, icons can be smaller than text-labels, and the uniform size can make them easier to fit in a clean grid. Icons need no translation either, which is nice. On the other hand, a text label can say what the button does. Right there. On the button.

Quick thoughts on the new Google-Bar

When Larry Page took over the reins from Eric Schmidt, apparently one of his first decrees was that all of Googles properties were to look prettier. A team of designers came up with the new design, featuring greys, curry reds, whites and a black top-bar which featured sharing options and notifications. Now the black bar is being rid of, in favor of a more minimal Google Bar:

This is what it looks like in my Gmail (by the way, if you haven’t received this bar yet, here’s how you can get it now):

googlebar

Collapsing the black bar certainly gives some much welcome extra room (especially welcome in Maps and Reader). Also, I personally never used the plethora of links that sat right at the top of the page starting from left, so the collapsing of those into a dropdown menu makes some sort of sense.

The new bar is now without weirdness, though. First of all, in the implementation I’ve tried (by using the cookie hack linked earlier), the Google logo dropdown menu invokes on both hover and click. I’m personally a fan of click, since hover always feels slow to me, but it gets weird if you’re used to the Google logo taking you to the homepage. Take Gmail, for example, clicking the Gmail logo (which by the way is gone now), you’d be taken to your inbox. To get to your inbox now, you have to click the left-arrow that sits on top of your email.

It’s also a bit wierd that the Google.com homepage features a different Google-bar:

newgoogle

… it’s obvious when you think about it, of course: you can’t have two colorful logos and two searchboxes competing on the same page. Oh by the way, that black dropdown shown in the screenshot above is not invoked by yours truly, it’s now shown by default when you visit the Google homepage. But at least they killed off the horrific white fade they had a while back.

It’s clear Google is in a state of flux at the moment. Some products are killed off, others are mutilated. At the same time, Google is prettier and more consistent than ever. Here’s hoping the dust settles at some point, and what made Google cool gets reintroduced.