If you design or develop web sites for a living (and if you’re reading this, you probably do), for the past couple of weeks your Twitter stream, RSS feed or [insert news firehose of choice] has likely been filled with everything from detailed rebuttals to complete bewilderment regarding Jakob Nielsen’s latest alertbox column, Mobile Site vs. Full Site.
Probably my favorite quote on the topic is this, from Josh Clark:
When you see a “full desktop site” link on your phone, you’re looking at an admission of failure.
As much as I agree with that sentiment, admitting failure is still preferable to ignoring the problem altogether. What if the site you’re browsing on a phone doesn’t even have that link, and you know that the content you need does in fact exist on that company’s “desktop” web site?
A Mobile Browser in Disguise
Well, if you use an Android phone running Ice Cream Sandwich (4.0), there is an easy option for circumventing the dumbed-down mobile experience on such sites: toggle on the option to view the “desktop” version of any given site in the latest version of Chrome browser for Android, released just this past week.
Advanced users have long been able to tweak desktop browser settings or use plug-ins to change the browser version or type advertised to web sites. The mobile version of Chrome just puts this option within easier reach of its users, perhaps anticipating (correctly) that they are more likely to need it due many of the poor choices sites have made in how to serve up mobile content. And it works the same way, by changing the user agent string of the browser — in this case, to a desktop version of Chrome. Below are examples of the UA string, both before and after:
Mozilla/5.0 (Linux; Android 4.0.2; Galaxy Nexus Build/ICL53F) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19
Spoofed “desktop” user agent for Galaxy Nexus, running Chrome for Android:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.45 Safari/535.19
Switching up the user agent string foils most web sites’ attempts to redirect such requests to their “mobile site,” since all clues as to its mobile-ness — the device name, the true OS and true browser — are stripped away or obfuscated. Result? The mobile-dressed-as-desktop browser is served up the default (desktop) content.
A Carrier Collision
Unfortunately, there’s another player in the web browsing experience that can get in the way of a user, his browser, and a web site. And it’s someone with a pointed financial interest in your browsing habits: the mobile carrier.
Such was the rude realization had by by my boyfriend Josh when attempting to visit a web site a few nights ago on his Android phone, a Samsung Galaxy Nexus. Encountering a redirect to that company’s feeble mobile site, he turned on the “Request desktop site” option in Chrome and attempted to reload the page… only to receive content of a very different kind, and not from the requested site:
(“Mobile HotSpot” is just T-Mobile’s way of saying “tethering.”)
Why the upsell/road block?
Josh quickly deduced that not only was T-Mobile “listening in” on his web activity/requests, it had determined that he was using a desktop computer paired with T-Mobile phone (not broadband) data service. And that type of network activity is a definite no-no on T-Mobile unless you are paying an additional monthly charge for the ability to tether other devices, such as a laptop, to your mobile data connection.
The way T-Mobile likely decided that Josh was tethering? The same way his destination web site decided to serve him that lame mobile experience: via the browser’s user agent string. And perhaps they combined this with knowledge about the number of gigabytes of data he’d already consumed that month. (He habitually uses around 2-3 GB per month, preferring to use his phone as his primary device for accessing the Internet, even at home.) And given that the display resolution of the Galaxy Nexus is a whopping 1280 x 720 pixels, even that would not have helped determine mobile vs. desktop.
So a disguise engineered by Google to let him successfully pass as a desktop user was convincing enough to trip T-Mobile’s “unauthorized tethering” alarms and end up blocking him from the content he requested in the end.
Even worse, more tests the next day revealed that Josh was now getting blocked by the “tethering upsell” screen when using Chrome for Android regardless of whether the “Request desktop site” option was checked. Apparently, T-Mobile had decided that all of his web activity while using any variant of Chrome was suspect, even when it was accurately reporting itself as a mobile browser.
What This Means
This little episode was, of course, frustrating (and triggered a testy, 20-minute call to a front-line technical support rep including lots of explaining to said rep about how web browsers and servers work). And someone at T-Mobile has logged the issue in some database somewhere where it may or may not be addressed in some manner (someday).
But the real lesson, I think, is in how users’ mobile browsing behavior is increasingly failing to map to outdated assumptions from both web site owners and mobile carriers about how their content and networks are being used. While iPhone users are known for chugging down data at a rate that far exceeds that of their other-OS’ed brethren, more Android users are trading their straws for steins as powerful new devices like the Galaxy Nexus or Galaxy Note are introduced, with their huge screens and fast, 4G network connectivity.
And, Jakob’s recommendations aside, a growing cadre of in-the-trenches designers and developers of experiences tailored for mobile and beyond understand how mobile is a user state, not a device. That context is increasingly difficult to pinpoint as users try to do anything and everything on their mobile device they would on a desktop computer. And companies who fail to shift with their users will be far likelier to, as Josh told the T-Mobile rep, “be tempted to take my business elsewhere.”