An anonymous commenter left the following message on our feedback form the other day:

Just bought an iPhone and have been very disappointed with the slow speed of the Internet on Edge.
Your site compressed a 50 second navigation down to 10 seconds on a favorite web site.
Unbelievable ! ! !
Thanks for an outstanding tool ! ! !

The user agent and IP address indicates this person left the comment via the iPhone itself. This is incredibly gratifying for us to read. Skweezer makes ordinary websites much faster on the iPhone on EDGE or any phone on any network, no lie. It’s like a free speed upgrade to the EDGE network. I can’t wait to unleash our new upgrades to Skweezing technology which will compress web pages to an astounding degree, up from just unbelievable.

I just posted a list of my favorite mobile alternative sites (sites which are the mobile version of a regular website), and it struck me how few of these sites actually use the .mobi top level domain. It is kind of sad how little .mobi has caught on, just like mobile-specific style sheets in the wild are few and far between. How are mobile users supposed to discover where they can get their mobile content? Some sites automatically sense the mobile browser’s user agent and adjust themselves accordingly, which I think is ideal. For every other site, are we supposed to try to load the “real” site in our mobile browsers, hope it doesn’t crash, then try to find the “mobile verison” link buried in the footer? It would be really nice if there was standard markup or HTTP header standard to redirect mobile clients to a mobile-friendly version. For example, I would love to see something like this embedded in the HEAD of the LA Times homepage:

<link href="http://mobile.latimes.com/" rel="alternate" media="mobile" type="text/xhtml" />

Update (1/18/08): According to Russell Beattie, it’s possible right now. The media type is “handheld”, not “mobile” but it works. Now use it!

Until that day comes, site owners are doomed to make up their own standard. Lately M-dot subdomains have become popular, and mobile-dot or wap-dot sites have been around even longer. Other sites put the mobile version in a separate sub-directory. Based on my current site list, here’s a chart breaking down the methods that various websites use to distinguish their mobile content. Legend: SLD = second-level domain (like m.flickr.com); I realized too late that the correct term is third-level, but that collides with TLD which is top-level domain (as in .mobi) so I hope this chart still makes sense. The point is that the majority of sites that I could find for my list indicate mobile content with subdomains. Yes, not a very scientific study, I admit. Yes, I know there are 500,000 .mobi registrations, but squatters and ChadsAwesomeWebsite.mobi don’t count; I’m talking about discoverability. Where the heck is slashdot.mobi? How come this site doesn’t work as wordpress.mobi?

When it comes to the subdomains themselves, which is currently the most popular? I couldn’t stop making charts, so here’s another one (to the left). M-dot is the cool newcomer, but still in the minority. Mobile-dot is the current leader, followed by trusty ol’ wap-dot. It seems like a lot of companies consider “.com” as part of their name, or at least think their customers do.

Here’s a marketing idea for the dot mobi people, who are trying to buck this trend: make free .mobi redirects for the top 10,000 websites that don’t already have a .mobi domain, but may have a mobile version somewhere. For those without a decent mobile site, redirect their “trial” .mobi domain to their main site through a mobile transcoder. Heck, just do it for Typepad.com, WordPress.com, and Blogger.com and you’ll have millions of sites right there. At the end of a month or two, turn it off and have your sales people call them up to explain the drop in traffic. If that doesn’t sell cnet.mobi, I don’t know what will. It will have the added benefit of making customers expect the .mobi TLD. When their customer service lines light up with “how come your mobile site stopped working” calls, they’ll realize their customers have mobile browsers and they’re using them.

I just saw Jeff Atwood’s entry from last week on why you don’t want an iPhone, and his well-reasoned advice boils down to this: EDGE is painfully slow compared to 3G, and you should wait until they iron out the bugs in v2.0. For these reasons, even the Apple faithful are sitting v1.0 out. Sprint is obviously thrilled right now.

As far as I can figure, the difference between EDGE and 3G networks like EVDO is presently 4-5x, accounting for the recent boost. There is a free and easy way to get 4-5x faster downloads on any network, even EDGE: Skweezer. Because content is pre-compressed on our servers before it even starts down the thin invisible tube to your phone, there’s less overall data transmitted, which translates into a faster browsing experience. It is the equivalent of turning your 200 kbit connection into a 1 mbit connection. Basic web surfing will be loads faster with Skweezer than without.

You still don’t believe me? It’s been a while since we did a site comparison, so I ran a few sites through Firebug this evening (July 3, 2007) to compare their total original page weight with the Skweezed versions, with images on and off. Unfortunately the figures aren’t as dramatic as they once were because server-side content compression (gzip and deflate) is more commonplace now, and that used to be an easy win for us. Nevertheless, Skweezer still always brought the page weight down, as follows:

The worst value in each column is in red, and the best value is green. The fastest way to browse is without images, but that’s only useful if you’re just information hunting. Even with images on, the median speedup for browsing sites through Skweezer was 4.7 x, if we assume that the network is the main bottleneck. If you want to run your own tests, be aware that IE reports uncompressed page size in the page properties dialog, while Firefox reports the number of bytes received for the main HTML document, reflecting compression. The best way to compare total page weight accurately is to use a tool like Firebug or a proxy like Fiddler2.

Not to harp, but I’ve enjoyed reading one particular aspect of the conversation surrounding the most anticipated phone of the year, as follows:

A Trade-Off on iPhone Data Speed (John Markoff, NYT): “On the eve of the Apple iPhone’s debut, the top executives of Apple and AT&T today defended their decision to rely upon AT&T’s slow Edge wireless data network, rather than a faster network that is less widely available. Early reviews of the iPhone, while positive, have faulted the slower network because it will limit the palm-sized wireless computer’s utility in making the Internet easily accessible on the go.”

iPhone Blindness (Scott Karp, Publishing 2.0): “Buying an iPhone is like buying a MacBook that only supports dial-up access. [...] How can iPhone reviewers tout the web browser as the “real dazzler” and the “closest thing to the real Internet” when it crawls along like a 1400 baud modem?”

iPhone ‘Surfing’ On AT&T Network Isn’t Fast, Jobs Concedes (WSJ): “Mr. Jobs acknowledged that the company’s new iPhone won’t surf the Internet as fast as he would like on the network, called ‘Edge,’ but added that the device’s ability to connect to Wi-Fi hotspots would give consumers a speedier alternative for Web browsing.”

I think it’s clear that the reviewers equate the utility of mobile browsing with speed. If only there were some free mobile proxy web service that would compensate for the EDGE network’s lower speed without requiring a download and installation. I guess we’ll just have to wait until some enterprising company builds such a thing, or we could wait until all of our favorite websites make cunning little mobile versions. Until then, nobody should buy an iPhone, or any other AT&T phones that surf the so-called mobile Internet! That will teach them.

In developing a mobile vision, the Greenlight Wireless team has been tempted down several paths over the years. Should we get into video? Unified mobile IM/SMS? Should Skweezer be a mobile Pageflakes? We have thus added/dropped features as they compliment/detract from our main goals because we have to pick our battles. There are some things we do well (like mobile browsing) and some things we don’t (like e-mail). There are some things that we are too small to attempt, such as developing our own web search engine from scratch, and so we partner with companies that offer these things as a service or API we can use. For example, we use WorldLingo’s excellent translation API.

I mention this because I was looking at Clusty’s new mobile search and web proxy, which was announced earlier this week. There is no doubt that Clusty has some advanced search engine technology, and it has an obvious mobile application. However, their mobile web proxy leaves a lot to be desired. I know it’s still in its infancy and they probably intend to improve it, so it’s not fair for me to criticize it yet. However, if I were an executive at Vivisimo, I would take a hard look at build vs. buy or partner in this case. Mobile transcoding is one of those easily underestimated technologies. Skweezer powers the search results of other large search engines, and we’ve been doing it for years. Clusty search with Skweezer-powered results would be pretty nice and might free up a Clusty engineer.

(The title of this post could also be: Opera Stole Our Version Number! But we don’t have the number 4 trademarked, so we’ll let it slide.)

Today Opera announced the beta of v4 of their mobile browser, which I am downloading and trying out. There are all sorts of cool things you can do when you have both client software and server optimizing, and Opera is pushing the state-of-the-art here. Our mobile web optimizing software, Skweezer, is a server-only solution, so we are limited to the things your built-in browser can do. Anyway, I was interested to see some bloggers/journalists (and even Opera themselves) pitting Opera Mini vs. the iPhone (thanks to TechMeme for this list):

• The Tech Report: Opera takes a jab at the iPhone
• The Mobile Gadgeteer: Opera Mini 4: who needs an iPhone for mobile web browsing?
• MobileCrunch: Turn Any Phone into an iPhone
• Andy Beal’s Marketing Pilgrim: Opera Mini 4 Steals iPhone Thunder

As has been pointed out elsewhere: where’s the sense in comparing software to hardware? I call sour grapes on Opera’s part. You won’t be able to install Opera Mini on the iPhone, at least not right away, even though you could even install Opera on your desktop, phone, Wii, toaster, and slow-moving household pets. Your goal to install Opera on everything you love will be thwarted by Apple. So I believe Opera’s message here is: you don’t need an iPhone when you can have the mobile web on your crummy old phone right now! To which I reply: you don’t need client software, you can have a server-side web optimizer that works with iPhone’s Safari browser and your crummy old phone’s built in browser right now, no download! It’s called Skweezer, and we just updated it to version 4, which seems to be the right number for mobile web browsing products released in the summer of 2007.

There has been some complaining about the iPhone’s reliance on AT&T’s EDGE network. Here’s an example from Forbes.com, in sidebar to the article “Why You May Not Want an iPhone“:

The iPhone isn’t equipped for AT&T’s fastest “third-generation” (or 3G) wireless data network. Instead, iPhone users are stuck on an older, slower network, which means Web pages will take longer to load.

Also, since the non-announcement at the WWDC that Apple’s idea of 3rd-party applications is “sites that run on Safari”, there has been additional kvetching. I sympathize with everyone whose software does not translate to the web service model.

However, as a developer who makes a web service that speeds up browsing for mobile devices and doesn’t require a client installation of any kind, I couldn’t be happier about the iPhone design “restrictions”: it validates our approach completely. For the record: Skweezer addresses iPhone slowness without requiring any client installation. So while you’re waiting for Opera for the iPhone, give us a try first. And by the way, we just released Skweezer v4.0 which compresses images too, just in time. Welcome to Skweezer, iPhone people. Enjoy the entire internet.

AT&T or Apple folks: could I have one for testing, please? I’m already a Cingular/AT&T customer. You may already know the Kendall family from my wife’s addiction to the iTunes music store.

At long last, we released Skweezer 4.0 to the public last night at 8 PM Pacific time. Press release here. This is a moment of great pride for us since the team has been working on this since February and the launch went about as smoothly as possible. After 26 hours and only two minor patches today, I can confidently say it’s good and there’s no going back. This release reaffirms our commitment to providing the best mobile browsing experience anywhere, and I think we have decisively retaken our lead on mobile transcoding. This was a re-write from the ground up, and while we’ve changed a few things you can see, the most exciting thing to me is how this new version positions us for future enhancements, not to mention a performance boost across the board.

While I intend to write more in depth about my favorite features and the technical background, here are a few things that are different:

• Action-oriented home page. There used to be a “Skweeze box” front and center on the home page, followed by directory links and favorites if you were logged in. While it took some guts to remove that box from the home page (it’s been a constant feature since v1.0), I think the result is a better phone experience.
• Dynamic Images. By determining the client device’s screen size, we are able to resize images on our server and send the smaller, optimized version. I’ve seen some images come out 5% of the original size. I really want to talk more about the technical details of this, but I’ll save that for a later post.
• New search engine. Before, we detected search queries (as opposed to direct navigating to a website) and would skweeze a search engine’s results page. Granted the user could choose the default search engine, but it was less than ideal. Now that we’re using third-party APIs we can exert more control of the output, which means search results are more mobile-friendly.
• Find in page and phone numbers. On the first page of your search result destination, you can skip to the first occurrence of any search term, which will be highlighted. If you’re browsing through a phone that we support, we will try to link 10-digit phone numbers. These are new and sort of rough features, but rather than wait until they’re perfect, we thought we’d incorporate them now and see what you think.
• New directory. More sites and languages and a better back-end system will allow faster turnaround to incorporate suggestions, although currently “suggest a site” is behaving oddly, and we’ll get that ironed out this week for sure.
• Japanese UI. One of the newest members to our team recently translated the UI into Japanese, and this is just in time since our Japanese usage has been growing quite a bit lately. To all our new Japanese guests, ようこそ!
• Mail is gone. This isn’t in the press release because it’s a dropped feature, but we decided to discontinue the mobile e-mail feature from Skweezer. We simply weren’t able to devote the attention to it that it deserved, and it never caught on with more than a very small percentage of users. If ever Greenlight Wireless gets back into mobile e-mail, I think it will be a separate product or site from Skweezer. If you were one of them, I’m sorry.
• Mobile site bypass. For sites that are already mobilized, Skweezer should leave them mostly intact. We now send through the original user agent, so for sites that present a mobile alternative, this will let them do so.
• Self-explanatory desktop interface. It is difficult to describe the function of Skweezer in five words or less. If you visit Skweezer on your desktop browser, however, you’ll see the new narrow interface, and it should be more obvious what’s going on.

Wow, I meant to keep that list shorter. There are still some rough edges that only live traffic will expose (please use the feedback form in Skweezer if you see problems), but I’m confident in the overall quality. I want to thank our customers, partners, testers, end-users and investors for their continued support. We sincerely hope that Skweezer 4.0 will help bring the desktop web to even more mobile devices.

This has been sitting in my drafts folder for too long, but belated congratulations to Ask.com Mobile, winner in the Mobile category as well as the People’s choice awards! They are deservedly proud. If you haven’t already tried out Ask’s mobile site on your phone, you really should.

I was just reading an article by Dave McClure entitled “Yahoo just needs to fix one thing: Monetization“. He outlines three ideas for helping Yahoo skweeze squeeze more profit out of each search: finish a new advertising platform, do Cost-Per-Action (CPA) advertising, and acquire more startups.

Skweezer could really help out Yahoo on points 2 and 3. We’ve been experimenting for the past few years with how to best monetize browsing traffic: contextual ads, teeny-tiny CPM banners, even charging for pro service outright. As a mobilizing web proxy, Skweezer is uniquely situated to complete CPA transactions because while users are shopping and bidding and searching, they never actually leave skweezer.net. Verifying completed mobile CPA transactions through Skweezer would not be difficult at all, were we to somehow start showing CPA ads. Significantly, we would not require any change to the advertiser’s existing site and there would be no tracking “leakage” (blocking or failing to download a tracking beacon). The only other type of company that has this visibility would be the user’s carrier/ISP themselves, and how many advertisers are going to do separate deals with every carrier in the world?

I wonder how general web CPA solutions such as newly announced Turn.com handle this uncertainty. Interestingly (to me anyway), it seems like they have some former AltaVista alums at the helm, but I doubt they remember or ever crossed paths with me or Kevin from back in the day when we worked at Shopping.com. Small world, and I wish them well.