Google has two versions of Google Maps. Visit maps.google.com from a desktop browser and you'll get the desktop version, designed for large screens and mice. Along the top of the screen, you get Google's global navigation to let you pick between Maps, Images, Search, YouTube, and so on. On the left of the page, there's white space where search results and directions go. On the right, a large map.
But visit on a smartphone and you'll get the mobile version of Google Maps. This is slimmed down and designed for fat fingers on small screens; no global navigation, just a map occupying 90 percent of the screen and four finger-sized buttons at the top.
At least, that's what you see if you're using Safari on iOS, or Chrome, Android Browser, or Firefox on Android. Fire up Internet Explorer on Windows Phone, however, and you'll just get redirected to Google's mobile search page. This happens regardless of whether you have the browser configured to prefer desktop versions or mobile versions of sites.
Windows Phone users have noticed this, and they're not very happy. Widespread complaining around the Web reached a climax at the tail end of last week.
When quizzed about the block on Friday, January 4, Google's first response was:
The mobile Web version of Google Maps is optimized for WebKit browsers such as Chrome and Safari. However, since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile Web.
Google's response didn't, however, pass the sniff test.
First, it falls down on practical grounds. Windows Phone 7.5's browser is in most ways identical to the desktop version of Internet Explorer 9. Windows Phone 8's browser is virtually identical to Internet Explorer 10. The desktop version of Google Maps works just fine in these browsers. It's one thing for Google to say the mobile site isn't tested or supported in the mobile browsers, but the desktop version, at least, shouldn't be off-limits. The desktop version may not be ideal in a mobile browser, but it does work.
Microsoft's own statement on the matter makes this very point:
Internet Explorer in Windows Phone 8 and Windows 8 use the same rendering engine.
Blocking the phone browser but not its desktop sibling makes no sense from any technical perspective.
Making this point even more forcefully is the fact the blocking only occurs when you visit maps.google.com directly. If your browser is configured to request desktop sites, maps.google.co.uk serves up the desktop site to Windows Phone without complaint. If you have a direct link to a particular address then the link will work, too, with Google showing you either a mobile-oriented map page or a full desktop map page, depending on which kind of page your browser is configured to request. iFrames used to embed maps in other pages also work.
This means the sites for restaurants, museums, and other real-world attractions that link to or embed Google Maps to tell customers where they're located do work correctly, even on Windows Phone.
Further undermining Google's "WebKit" argument is the fact that Firefox on Android—which uses Mozilla's Gecko rendering engine, and not WebKit—isn't blocked. Google's statement makes a claim ("since Internet Explorer is not a WebKit browser, Windows Phone devices are not able to access Google Maps for the mobile Web") that doesn't hold true. Not using WebKit does not, in fact, prevent access to mobile Google Maps.
On top of all this are experiments done by two developers who write apps for Windows Phone. The block on Google Maps is a very simplistic one. Every time a browser requests a webpage, it tells the server its name and version, a piece of text called the User-Agent. Google Maps is using this User-Agent to choose whether to deny or permit access to Google Maps.
This was demonstrated in two ways. Tom Verhoeff used the Fiddler proxy server to rewrite the User-Agent of every request made by his phone. He replaced the Windows Phone User-Agent with a Chrome User-Agent—at which point mobile Google Maps became available to his Windows Phone, and it basically worked just fine.
Microsoft employee Matthias Shapiro similarly showed the User-Agent was the only thing standing in the way of successful use of Google Maps. He wrote a basic Windows Phone app that embedded the browser. Apps that embed the browser have the ability to override the User-Agent the browser sends; in Shapiro's case, rather than using a Chrome User-Agent, he simply misspelled the words "Windows Phone" but left the User-Agent otherwise unaltered. Once again the site basically worked.
As such, it's clear that there's no sound technical argument for Google's behavior. It's possible—perhaps even probable—that the mobile version of the site has some nuances and features that only work in WebKit, so Google might have some basis for denying access to the mobile Google Maps to Windows Phone. This is still dubious—those WebKit-only features wouldn't work in Firefox either, but Google's not blocking access to that browser. But without thorough testing it's hard to know what will work and what won't, and Google may be unwilling to commit the resources to testing a minority platform.
The desktop site is another matter entirely. Google already supports the Internet Explorer rendering engine on the desktop site. Mobile browsers that request the desktop site should be given access.
Google pulls a similar stunt with Gmail access. Windows Phone 8 can access the mobile and "basic HTML" versions of the site, but any attempt to access the full standard HTML desktop version reverts to the mobile site. This is in spite of the fact that the full version works fine in Internet Explorer 10.
Doing the wrong thing
Second, the claim that mobile Google Maps is WebKit-only falls down on philosophical grounds. In May 2011, Google claimed mobile Google Maps was "platform independent" and that "you will always get a consistent experience and the latest features [...] no matter what phone you use." The current behavior clearly contradicts that claim.
Broadly, the Web is built on vendor-neutral open standards. Requiring specific rendering engines is truly a return to the bad old days of "This site is best viewed in Netscape 4," and undermines the open intent of the Web. Parts of Google certainly understand this; Google developers working on Chrome and Web standards have supported Microsoft's efforts to produce interoperable spec and add interoperability features to WebKit. Microsoft, for its part, has implored Web developers to avoid treating WebKit as if it were the sole rendering engine on the Web.
Google's own guidelines for Web developers also warn that User-Agent detection is error-prone and liable to give users bad experiences. Instead of User-Agent detection, the company recommends the use of responsive design, a technique that uses CSS to alter page layouts to make them suitable for both mobile and desktop devices.
A plan to do the right thing
On Saturday, January 5, Google offered a second, longer statement:
We periodically test Google Maps compatibility with mobile browsers to make sure we deliver the best experience for those users.
In our last test, IE mobile still did not offer a good maps experience with no ability to pan or zoom and perform basic map functionality. As a result, we chose to continue to redirect IE mobile users to Google.com where they could at least make local searches. The Firefox mobile browser did offer a somewhat better user experience and that’s why there is no redirect for those users.
Recent improvements to IE mobile and Google Maps now deliver a better experience and we are currently working to remove the redirect. We will continue to test Google Maps compatibility with other mobile browsers to ensure the best possible experience for users.
This new statement implicitly contradicts the first, WebKit-only, claim. It acknowledges Google does, in fact, perform some amount of testing in non-WebKit browsers, and that mobile Maps isn't just for WebKit. It's also true that in Windows Phone 7.5, which uses Internet Explorer 9, panning and zooming the map content didn't work correctly. There is a legitimate issue there. This issue doesn't exist in Windows Phone 8.
The block is still in place at the time of writing, but assuming Google stands by its current statement, it should be lifted at some point and everyone will be happy.
Google making itself look bad
Nonetheless, the entire incident leaves Google looking tone-deaf, at the very least. If you're going to have "Don't Be Evil" as your corporate slogan, you'd better act holier than the holiest white knight if you don't want to look grossly disingenuous. The actions here were not whiter than white. The Windows Phone block is badly implemented, overly broad, and contrary to fundamental Web concepts, Google's claims about the mobile Google Maps, and Google's own published best practices.
Google's initial statement was untrue. It was perhaps approximately true, as it's certainly the case that WebKit browsers are the ones with the best support, but it wasn't actually true. If Google had truly been blocking every non-WebKit browser then its actions would still be disappointing, in the light of its recommendations to Web developers, but perhaps no worse than all the other companies that assume that all mobile browsers are WebKit.
But it wasn't; it was letting other browsers through the blockade, which in turn gave the impression that it was singling out Windows Phone for bad treatment. Which in fact it was, but probably for sound historic reasons (the mobile Google Maps site does work poorly with Internet Explorer 9) rather than any malice. Google's statement made its actions look worse than they really were.
Ultimately, Google could have avoided all the bad press and ill feeling if it had stuck to its principles. If responsive design and progressive enhancement—development strategies that make Web content available as broadly as possible—truly aren't viable for Google Maps then User-Agent-based redirections might be a necessary evil, but they should be narrow, accurate, and consistently implemented. Google's failure to do this, followed by its cack-handed PR response, has made the company the bad guy when it really didn't have to be.
reader comments
141