When it comes to Google and Microsoft's dispute over Microsoft's Windows Phone YouTube app, it's clear there's very little common ground between the two companies. Google is insisting that Microsoft build its app in HTML5, while Microsoft is saying that it prefers to deliver native code. But despite their differences, there's one common theme in their narratives: both are saying that their way delivers the best user experience.
At the heart of Google's complaint is one interesting statement: that Microsoft hasn't added features to the mobile version of IE that Google wants it to use as the heart of an HTML5 YouTube application . That may be true, as while IE10 on Windows Phone is a substantial improvement over Microsoft's earlier mobile browsers it still lags both Apple's Mobile Safari and Google's Android version of Chrome in its HTML5 support. But if there are essential features that Google uses on the web that limit what can be done on Internet Explorer, what are they?
Well, the first thing to do is find out just what works where. I have Windows Phone, iOS and Android devices (a Lumia 920, an iPhone 4, and a Galaxy Note) on my desk, all running recent versions of their respective operating systems. That meant I could compare all three, seeing how they support HTML5, and seeing how various Google properties rendered on each device.
The starting point of my investigation was running the three mobile browsers through the HTML5 Test site. There IE 10 (both mobile and desktop) score 320 points, iOS's Mobile Safari comes in with 386, and the Android version of Chrome gets a massive 410 points. That means there's quite a range of capabilities between the browsers â€" though when you drill down into just what’s supported, they all support the core features of the standard; with differences only arising in some of the more specialised HTML5 features that are unlikely to be present in consumer-facing web services.
So if core HTML5 performance is unlikely to be a significant issue, we’re going to need to drill into things further.
One thing Google also says is that it wants to preserve the user experience in its properties. That's an admirable aim, and one that's easy to agree with. Unfortunately that requires consistency, and it's clear that Google is treating different platforms in different ways â€" even when they have similar capabilities. Let's start by looking at how the mobile sites for Google News, Mail and YouTube render on the three different platforms.
It turns out that YouTube is surprisingly consistent across the three operating systems, while Mail and News differ considerably.
Why's this? Well, there's one answer in that old adage that engineers scratch their own itches first. Walk around the Googleplex and you'll see lots of Android devices and the odd iPhone. So it's not surprising that Google’s own properties look best on those devices â€" they're where the itch is that Google's developers want to scratch. Open Gmail on an iPhone and its design is already starting to trend in the direction of iOS 7's minimalism. Open it on Windows Phone, and you’re getting flashbacks to the early days of Web 2.0.
But IE10 is a capable browser, with support for much of the HTML5 standard. So why doesn't Google deliver its full Android and iOS mobile web user experiences to Windows Phone users? That's not the case with some Google properties. We've already seen that YouTube looks much the same across devices, and it turns out that Maps has a very similar look and feel on iOS and Windows Phone.
But if you look closely at the header bar on the iOS rendering of Maps and compare it with the Windows Phone rendering you'll see some style differences between the two views, differences that give us a clue to what Google is â€" or rather, isn't â€" delivering to Windows Phone. Perhaps if we disguised a Windows Phone as another device we'd be able to find out just what’s happening in Google's page designs.
It turns out that there's a useful free app for Windows Phone that lets you switch the user agent of your browser, giving you the option of appearing as an iPhone or an iPad, or even a desktop PC running Firefox. That means you're able to see the iPhone and Android views of a site on a Windows Phone (or at least the HTML and CSS that’s supported by the IE10 Trident rendering engine and its Chakra JavaScript compiler).
Trying it on Google properties shows an interesting effect: the headers that it uses on its iOS and Android sites just fail to render in IE, even when it's masquerading as Android. Could it be that Google is relying on WebKit vendor prefixes to deliver its UIs?
So how do we find out what code is being delivered to a browser? While mobile browsers don't have the debugging tools of their desktop relatives, desktop browsers can be disguised as mobile browsers with a quick change of user agent. I installed a user agent switching extension in Chrome (as I wanted to see if the pages had WebKit specific code that wouldn’t render in IE or in Firefox), and began to investigate the code delivered to iOS devices using Chrome's built-in debugging tools.
Drilling down into the code of the header that didn't render on Windows Phone, it's clear just why it didn't work. Much of the header layout requires WebKit-specific CSS; and that's CSS that won't display in other browsers. In fact if you drill down into any Google mobile app, there's plenty of WebKit specific code all the way through the application.
Are the features that Google wants Microsoft to put into its browser those WebKit vendor prefixes? It's certainly relying on them in many of its web properties â€" and that would explain why it wants changes to Internet Explorer, allowing it to simplify the code in its JavaScript libraries and developer kits.
It's tempting to build apps that rely on the latest features, and if they'll run on most of the devices out there, well, the rest will catch up someday. But that's a rationale that assumes that the W3C will standardise on those experimental features, and that the resulting CSS and HTML markup will end up in new editions of current browsers quickly.
It's not just mobile where there's a problem; there are also compatibility issues on desktop PCs. One example of this comes from the toolbar Google recently deployed across many of its properties, in the wake of the launch of Google+. A drop down shows details of your Google+ account, at least on most of Google’s sites in most browsers. If you're using IE 10 it works just fine across most pages â€" until you get to one of Google's most popular sites, News. Roll over the Google+ notification icon here and the drop down tells you to upgrade to a more modern browser.
Not everyone is going to be familiar with the options in Internet Explorer's F12 debugging tools, so they're not going to know that Google is forcing IE10 to run in IE9 standards mode on the News page. They're also not going to know how to switch the page to render in IE10 standards mode to make the error go away. It’s not that these are particularly complex bugs to fix â€" but IE10 has been out for a year now, and the bug is still there.
Google appears to be using user agent sniffing to deliver different experiences to different browsers â€" a poor approach to modern web design, especially with the current generation of responsive design frameworks and with modern browser’s support for CSS media queries. Whatever it is, when Google’s mission statement reads that it’s there "to organize the world’s information and make it universally accessible and useful", it makes you think that Google may need to take another look at what users consider universal.
There's another question that needs to be asked. Why is Google using native code for its own YouTube app while insisting third parties work in HTML5? The rationale for an iOS native app is clear, as Apple doesn't let HTML apps use the Nitro JavaScript engine â€" giving native a clear speed advantage.
Android's fragmentation problem means that there are many different versions of Google's original Android browser still in use, alongside its current generation Chrome. With no chance of delivering a single user experience across all those devices, a native experience again makes sense as lets Google deliver a common experience to every Android device.
But why block a native experience on Windows Phone, where the heart of the OS is the UI, and where the browser doesn't support the WebKit prefixes that Google uses on Android and iOS?
What we're seeing are the results of many, many tiny engineering decisions, all made in isolation, but in the bubble of a WebKit world. What makes sense in that Chrome-powered world won't work everywhere. It might work on iOS for the moment, but as Google’s Blink WebKit fork diverges from Apple's WebKit, things are slowly going to stop working.
Living in a bubble doesn't work, even if your bubble is the dominant browser. It's time for the experimental prefixes to go away, and for sites and services to standardise on standards â€" not on what's cool today. And then we might even get a decent YouTube experience on Windows Phone...
No comments:
Post a Comment