Visiting Bloglines mobile through Skweezer has been awesome for quite a while, but at long last the reverse is now true: visiting Skweezer through Bloglines mobile is also awesome. As of last week, Bloglines Mobile uses a custom version of Skweezer to optimize off-site links. This is highly exciting to us. The response on the net has been almost unanimously positive. Kevin has been covering the action, and of course we’re going to PR this properly I’m sure.
However, there was this reaction from Arne Hess of the::unwired, on the other hand:
Ouch, bad news! In my previous posting about Bloglines cooperation with Skweezer, I just wrote: “I hope, Skweezer isn’t trying to skweeze the::unwired since we are serving a mobile device optimized version already which doesn’t needs to be skweezed again.” and indeed, links from Bloglines to the::unwired articles are skweezed. Even worse, not the mobile optimized page is skweezed but the desktop version which results in a completely broken experience.
I tried it out, and sure enough, the::unwired serves up two different versions of each page depending on the user agent. As an experiment, I visited that post with the standard Firefox 1.5.0.7 user agent string, and then again with an old phone user agent, specifically the Motorola 551 (MOT-V551/01.02.03 MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1). The former returned 54.94 KB of HTML, and the later returned the same page that was only 15.92 KB. It is clear that the::unwired adapts page content for mobile devices. As it is today, Skweezer appears as IE 6, and so sites like the::unwired can not perform their magic. I think calling it “a completely broken experience” is a bit over the top, however.
Here’s why. 
There’s a problem with the Motorola 551 specifically, but shared by many phones that are currently the majority of the current US market. The Motorola 551 simply responds with an error if it receives more than 10 KB of information: “413 Requested Entity Too Large”. Skweezer tries to respect memory limitations and split the content up into pages. Furthermore, if the device supports it, we apply gzip compression to the HTML stream. The end result is that yes, the Skweezer user gets the desktop version, but viewing that post through Skweezer with the Moto 551 UA, the resulting page is only 6.59 KB, well within that phone’s memory limit. Without Skweezer the 551 throws a 413, which is a broken experience, IMHO. Clearly there’s a place for Skweezer to improve even the::unwired’s mobilized pages, even if it does nothing more than gzip. If the::unwired chooses to cater only to devices which can handle more than 20 KB, that is fine. Skweezer will still exist for the rest of the market.
The art of mobilizing pages is always evolving. If you describe what Skweezer does to a programmer (just say “dynamic mobilizing web proxy”), it seems like a 2nd year CS student’s homework assignment. We’ve seen services and companies come and go in this space because, gosh, it just seems so easy. Yes, you can whip together a Skweezer-like service in PHP in 30 minutes if you know your stuff. That service will be 80% decent, and if you limit your testing to your own Treo and your friends’ $600 Smartphones, you may even believe that you’ve got a Skweezer killer on your hands. Believe me when I say that that other 20% is non-trivial. Personally I believe that Skweezer itself is between 90 and 95% complete. To clarify, Skweezer at 100% would be universal and unambiguous improved experience to raw mobile browsing on all mobile devices that have at least 1% market penetration worldwide, when viewing the top 10,000 web URLs. That is just the technical challenge of Skweezing; there’s also infrastructure and the business side of it as well. To sum up this paragraph: mobilizing is much harder to do well than it first appears.
Returning to Mr. Hess’ constructive criticism, however… We are open to adjusting the behavior of Skweezer to account for properly mobilized content as it becomes more commonplace and has better implementations. Last year a survey of sites that self-mobilize (like the::unwired) led us to conclude that masquerading as IE 6 led to the most consistent and user-friendly experience. It is our mission to bridge the gap between mobile users and the web content they’re trying to access in the meantime. I promise to regularly re-evaluate our stance on passing the original UA header, and we may very well do this in a future release. Another possibility is that we could present the user with a choice to leave Skweezer and view the page directly if we detect self-mobilizing, as Mr. Hess suggested. In the meantime, perhaps the::unwired could expand their mobile device definition to detect Skweezer. For the record, we set the “Via” header to “Skweezer”, and our server IP addresses currently start with 65.38.160.x.
2 Comments.