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.

Erase and Sync

eraseandsync

I don’t even want to try to explain what’s going on here. I mean, I understand it, but I don’t understand it. I don’t see how it’s in anyones interest for it to be flaming-hoops difficult to sync a device to a new Mac. Seriously, Apple, how did this pass your “it just works” razor?

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.

Sync

For years my lunatic Apple friends have asked me: “when are you going to get a Mac?”. When I finally did, they started asking me: “when are you going to get an iPhone?”. As iOS is growing increasingly more useful with good notifications and over-the-air updates, my answer has been trimmed down to when it has a Gmail app that’s as good as the Android one. “Gmail with IMAP works great” is the usual knee-jerk reaction and “what’s so special about the Gmail app?” the followup question. I’m thinking perhaps it’s time I change my stock answer. I think my new response will be: sync.

This morning on my way to work I was listening to Macbreak Weekly. A bunch of my heroes, including John Gruber, were talking about iCloud sync and the problems some of them were experiencing. Tonya had factory reset her iPhone several times trying to get contacts to sync properly. Andy jokingly suggested the merging of contacts was painful and would sometimes merge 17 different versions of the same contact into a lean 12. Chris suggested it was a good idea to make sure you had a backup of the contacts, calendar and email setup you considered “canonical”, before embarking on your iCloud adventure. When the team started talking about the supposed iOS 5 battery drain, iCloud was almost universally assumed responsible for this.

Grubers level-headed approach was that, while he apparently had no problems himself, he did believe Apples iCloud transition was going to be monumentally difficult and compared it to stepping from solid ground on to a boat while carrying valuable trinkets. Transitioning MobileMe customers to a new free setup, making sure not only calendars, email and contacts sync, but also documents, was bound to generate some headaches, but they’ll pass in time, he suggested. I agree, I’m sure things’ll improve once Apple is on the boat.

Perhaps there is something to be said about Apples approach to sync. As much as they tout that “the truth is in the cloud” — as Yogi Berra would say: that’s only true when it’s true. It’s no secret Apple loves native apps. Native apps run faster, smoother, nicer than web-apps. You’ll hear many chant this, they might even use allegories such as “being closer to the metal” when describing why a web-app can never be as good as a native app. Let me tell you this: Yogi Berra doesn’t care. If it works, it works. If the app is good, it’s good. If things sync, things sync. And if they don’t sync properly, they don’t sync properly.

Googles overarching approach to sync is to not sync. Push the changes immediately. When you add a bookmark to your Chrome browser, a teensy signal is immediately sent to Googles bookmark sync server pushing the change. When you finish typing a word in Google Docs, changes are saved. There is no sync, because there are not copies of files anywhere. There is only one file. There is only one email. There is only one contact. You’ll never have to worry about whether your Android phone, tablet, or Macbook has the most recently edited version of your document, or which one has the most complete contact, or which calendar you added an event to. Because everything is always in sync. It just works.

You’d think it would get muddy if you scratched the surface and peeked underneath. If you do, you’ll find that Android sync is actually asynchronous, and that if you use Google Docs’ offline editing capabilities, you’ll actually end up with some of the same sync challenges that Apple is facing: which version is the right version? Somehow I’ve never once had a problem with this, though. I don’t know if it’s because Google started with the web-apps and built native apps and offline sync at a later time, but I have no trust issues with Google getting my sync right. I know that if I visit google.com/contacts and edit a contact, my changes will propogate to all my devices seamlessly. I never have to worry about losing contacts, losing appointments, losing emails, getting corrupt data, or even backing up. While these words may smell like famous last words, I wouldn’t even think of backing things up. I expect it to work, I trust that it will work, and has done so far.

Compared to the flaming hoops I had to jump through to get just calendars, contacts and Gmail to sync on my wifes iPhone, using an Android device is just a relief.

The Assassination of Google Reader by the Coward Google+

reader

I’m pretty excited about the visual shakeup that’s going on at Google these days. Gmail and Calendar are prettier than ever, and it looks like there’s even some cues that align with Android now. Google Reader was one of the last properties to get the overhaul, and I was rather nervous about the announced Google+ integration.

I was totally unprepared for the scorched earth tactic Google employed, though. It appears that Google, after applying the new look, systematically uprooted every pretty little flower that made Reader what it was. Google then ground up all the flowers into mulch, burned the mulch, and salted the ground.

What made Reader so great? The social stuff. For every feed item you could click “Share”, and other Reader users who followed you would then get a customized RSS feed with your shares. You could even add a small comment to the top of the shared feed item. This spurned quite a lot of discussion, some of which I’ve archived here. From a “simplify your product line, focus on fewer products”, I completely understand why Google did this. Google+ already supports sharing and commenting, so why not share directly to Google+ instead of to a dedicated RSS feed? Unfortunately, that’s whiteboard philosophy at its best, and it betrays a fundamental lack of understanding of why Readers social ecosystem worked so well. Ironic, because Google+ is Googles social initiative. It’s really quite embarrasing.

I started writing a long blog post about how Google could fix reader and keep the Google+ integration. I thought long and hard about solutions to every problem introduced by the massacre. In the end, the frankenbuild that would have resulted from my advice would have been terrible. I even  went in to detail as to what exactly was massacred, but most of what I had to say has already been said elsewhere.

There’s a saying: if it ain’t broke, don’t fix it. Let me be clear, I loathe that saying. It’s shortsigthed, backwards and reactionary. It stands in the way of progress, and indicates the previous iteration of whatever is being referred to, “ain’t broke”. Let me tell you a secret it took me half a lifetime to learn: nothing is ever perfect, and everything can be improved upon. The notion of “perfect” is silly and highly philosophical. Reader wasn’t  perfect by any stretch of the imagination. Finding people to follow was a ridiculous hassle, and advertising the fact that you were sharing on Reader was nigh impossible. But once you did follow someone in Reader, once you did start sharing and commenting on shared feed items, the experience was easy to follow, highly intimate and very enjoyable.

What remains is a good feed-reader, but everything social about it has been scrubbed. Good feed-readers are a dime a dozen, and the sharing features while really well-implemented, are not that hard to copy. It is not unlikely that someone will eat the lunch Google left on the table here. Perhaps Google is fine with that. Or perhaps they’ll listen to sense:

Dear Google,

Reader is about reading RSS feeds, so please make shared items show up in an RSS feed again. +1 buttons are fine, but “Share” and “Note” should append to your shared feed and nothing else. Google+ is also a fine way to advertise that you’re curating an RSS feed. A theoretical integration with the circles might even make sense. But keep discussions, feed items and shares in Reader — where it belongs.

Google Chrome, Metro-Style

Windows 8 is a pretty bold new move for Microsoft. It’s bright, vivid, touch friendly and puts apps and contents way up top. It appears to have ditched the traditional desktop metaphor and filesystem. Apps look very different. Here’s what Internet Explorer 10 looks like:

IE10

That new look and feel for apps is being referred to as “Metro-style”. Metro-style apps run fullscreen and navigation happens through edge-activated interfaces. While I’m concerned about discoverability for edge-activated interface controls (essentially this is classic mystery meat navigation), I do like that apps are full-screen and that Metro-style apps ditch all archaic notions of UI chrome.

Which brings me to Google Chrome, capital C. Really great browser, my such of choice. From a high-level perspective, Google built this browser to accelerate the pace of web technology development, so that Googles own web-apps — Gmail, Calendar, Docs — could adopt newer features sooner. To that end, Google has gone to great lengths to make sure Chrome is not only cross-platform (Windows, Mac, Linux, soon Android), but that Chrome looks native to each platform. This tenet has been taken to the extreme, actually, with Chrome on Windows XP featuring the horrible “Luna” skin, and Chrome on Linux more or less establishing GTK as the de-facto UI toolkit on the platform, just to be able to use said toolkit. It’s really quite impressive, the amount of work put into making Chrome not only look native, but be native.

Of course we’re only on the cusp of the future. The next round of operating systems are likely to be much more mobile inspired. Windows is blazing a trail with adopting the Windows Phone Metro UI, OSX is likely to become even more iOS-like, and Ubuntu is already exploring more touch-friendly UIs. If Google is going to keep following the path of full-on nativity, Chrome engineers are going to be having some nasty headaches in the not too distant future. Is it even technically possible to replace Internet Explorer 10 as your browser of choice? With Windows 8 treating HTML5 web-apps as first-class citizens among native apps, it’s likely that IE is baked in to the operating system more deeply than it ever was before.

It’s also an interesting mind-game, imagining what Google Chrome would look like, if it were to theoretically be re-written as a Metro-style Windows 8 app. The Metro-style UI is already so minimalist in layout, icon style and even interaction patterns that it’s difficult to think of Metro-style Chrome looking very much different from IE10. The racing-car diagonal tabs for instance, which are important to Chrome’s branding, are hard to translate to Metro-style. Though I suppose if Google were to go this way, they could make their tabs look similar to those of the Android Honeycomb browser (which is likely to spell the direction of how Chrome will look like on Android, once that happens).

Will it happen? I think so, but I think Google will want to play the wait-and-see game for a while. Just like Android Ice Cream Sandwich may be a make-or-break proposition for Google, so do I think that Windows 8 is for Microsoft. Could be that Windows 8 adoption is too slow to worry about. Could be Google’s already working on Metro-style Chrome.