Google’s App Aesthetic

Monday, 3 November 2014

New today: updated Android apps for Google Calendar and Gmail. Both look interesting — as Benedict Evans succinctly put it, “Google is reworking Mail and Calendar from database displays to task-led interfaces. I wonder how far they’ll take that.”

And intriguingly, as Google’s new “material” design language evolves, it’s very clearly heading in a different direction than iOS. Talking about flatness is simply too superficial to be a useful discussion. Superficially, iOS and Android seemingly converged toward flatness (and Windows Phone, of course, was there already), but once you get past those surface similarities, all three mobile platforms are evolving in noticeably different ways.

But Google’s “Material Design” isn’t merely the design language for Android, it’s the design language for all the company’s software. One result of this is that Google’s iOS apps feel less and less like iOS apps with each major release. To me, they look and feel like Android apps running on iOS. Android users might disagree with that assessment, as much of what makes a good Android app Android-y is not how the software looks but the way it interacts with the system. But these Google apps certainly don’t look or feel quite like iOS apps. Their brand-new you-need-a-beta-invitation Inbox app is also interesting (I got an invitation last week), but even though it’s a brand-new app, if anything, it feels less like an iOS app than Google’s other iOS apps. For one thing, Inbox uses a blue background for the status bar, which is the system-standard cue to indicate that cellular tethering is engaged. Another example: None of the Google iOS apps I have on my iPhone (Maps, Gmail, Inbox) support the iOS standard swipe-from-left-edge shortcut to go back in the view hierarchy. That’s a two-year-old standard design pattern for iOS, and I find it downright essential with the bigger displays on the new iPhones. (In hindsight, it seems fairly obvious that Apple added this gesture in iOS 7 because they knew then that bigger-screen iPhones were in the pipeline.)

One last thought. Lost in the competition between platforms (iOS vs. Android) is the more philosophical competition between native and in-browser web apps. In the early days of iOS, say, circa 2008-2011, it was easy to conflate these two battles in public debate, because Apple was seen as the primary proponent of native app development, and Google was seen as a proponent of cross-platform web apps. No more. Google today (like Facebook) seems all-in on native apps, at least (again, like Facebook) for post-PC devices. Just a few years ago, I used to see a lot more arguments from web-app proponents that native apps’ dominance on mobile devices would be short-lived. I don’t see so much of that any more.

One reason some people argue in favor of in-browser HTML/CSS/JavaScript web apps is that it’s the last bastion for write-once-run-everywhere. The lament I hear most frequently about mobile development is that if you want to reach the widest possible audience, you have to write at least two apps, iOS and Android. If you include Windows Phone, now you’re up to three. My take has always been: Tough luck. The point of making apps shouldn’t be about making life easier for developers, it’s about making the best possible apps for users. If you value user experience above developer convenience, it’s easy to see why native apps are winning the war. But even on the desktop, with PC browsers, write-once-run-everywhere is often just a pipe dream. Here’s the screen I see when I try to log into the desktop web app version of Google Inbox using Safari on OS X Yosemite.

I don’t think the web version of Inbox is Chrome-only because Google wants to lock people into Chrome. I don’t think it’s about spite. I think it was just a practical decision that fell out of a desire to push the limits of the in-browser web app experience, rather than limit themselves to a common baseline of functionality available across the X top browsers. Cynics surely look at this as the second coming of Microsoft’s IE-only web technologies from the late ’90s, but my guess is that support for additional browsers is coming, that Safari is probably high on that list, and they shipped Chrome-first only because it was the fastest way they could ship. One reason Google created Chrome in the first place was to have a browser they controlled to better enable the sort of web apps they wanted to build.

In short, though, a Chrome-only app from Google — even if only temporary — is not how the world of standards-supporting web apps was supposed to work, in the aftermath of the breakup of Microsoft’s IE hegemony. But I’m not surprised. Practicality trumps idealism in the long-run, and the idea that the post-IE world of web browsers would lead to a world of universal cross-platform software is pretty much the definition of an idealistic crusade.

I see a certain irony in all this. Google is cultivating a single look-and-feel for their apps. But for mobile they’re creating them as separate native Android and iOS apps. But their latest web app for desktop PCs, Inbox, only runs in one browser, Chrome.