We just updated Skweezer again this afternoon with a few minor stability fixes and improvements. Among them:

• Once you log in, you now remain logged in for two weeks.
• For more modern phones Skweezer now allows limited CSS information which should make many pages look nicer and less bare. If you have a nice big color display, you should be able to use it. Of course, this means the page is not as small as before, but we want to push the limits of your phone’s browser.
• We’ve corrected HTML entity decoding errors that prevented some pages with foreign characters to display correctly.
• Device recognition has had an overhaul so that we can match unknown devices much better and we’re more likely to underestimate your device capabilities than overestimate them, if we can’t determine the device make and model.
• For desktop browsers, the images are not as overly compressed as they were. We’ll see how this works with our CPU and bandwidth.

We have done away with ASP.NET forms authentication once again due to its unreliability with mobile devices. ASP.NET second-guesses cookie setting somewhere, and sadly some cookies were being changed from absolute expiration to session cookies. This would require people to log in every time they closed their browser. Since user login is only protecting bookmarks now, we transitioned to a more mobile friendly home-grown solution.

For those devices that support it, CSS is limited to formatting elements only. Rules that influence properties such as margin, top, left, and padding are removed. CSS works for inline formatting, style blocks, and external style sheets. We do not yet handle @import declarations or composite rules such as “border: 1px solid black”. Here is the list of CSS properties that Skweezer currently supports: background-color, border-color, border-style, color, clear, float, display, font-family (generic names only), font-size (non-numeric only), font-style, font-weight, text-align, text-decoration, text-transform, vertical-align, and visibility. We are debating removing “float” because it does tend to make the document flow strange on small screens. Update: float is out; testers confirmed it is not good for small screens.

One major improvement with device recognition was the removal of strings such as “UP.Link/6.3.0.0.0″ from the end of the user agent. OpenWave has gateway software deployed at various carriers which rewrites the user agent with the software’s version. Although we thought that our fuzzy match algorithm took this into account, the removal of the version string makes the recognition engine much more reliable. We are also now trying to capture unknown user agents in an effort to do more research on their limitations.

In his article The Analyst, The iPhone, And The Future Of The Mobile Web, Dan Frommer recaps a discussion regarding the pros/cons of iPhone-style powerful mobile browsers that access anything which “signals the beginning of the end for the mobile Web as we know it today” vs. the utility of mobile-specific websites. After conceding that mobile browsers suck, he goes on (emphasis added):

But even if someday everyone has a browser as powerful as the iPhone’s Safari, that doesn’t fix the screen-size problem [...] even if developers use proper Web coding standards, “normal” Web sites will always be crippled on iPhones and similar mobile devices.

Anyone who has used the iPhone on AT&T’s pokey EDGE data connection also knows that the bandwidth just isn’t there yet to browse hi-fi Web sites and actually enjoy it. And for the foreseeable future, there are things you can do with a computer that you simply can’t do with phones, such as hovering a mouse cursor over part of a Web site, browsing with Java-based navigation, right-clicking on links and elegantly using multiple browser windows.

The near future of the Internet is going to look a lot like it did in the last decade, when content creators made separate sites for broadband and dialup users. The “real” Web will continue to get more and more multimedia-heavy, with Java, Flash, and video offerings designed for broadband connections. And the mobile Web should continue as a separate entity, accounting for smaller displays, and focusing on faster-loading, lo-fi content and simple navigation with fat fingers in mind.

I sadly agree that is what will probably happen for large corporate sites or web-only businesses (like Facebook), but I would like to add that Skweezer will bridge the gap for the rest of the web which I believe will remain in the majority. Anyone who thinks there will be both desktop and mobile versions of every site is deluding themselves. Remember the early days of Firefox when IE-specific sites would warn you to download IE in order to log in? Few sites responded with separate versions (or even separate stylesheets) for each browser, but the standard accepted practice is to make your site work on all major browsers. By using good web standards, XHTML and CSS and graceful fallbacks (like specifying onclick AND href for your A tags), web authors can be sure their sites will live long and prosper.

Skweezer has just been updated this evening. For one thing, the home page is quite different. After quite a bit of customer feedback, we’ve backed down from the one-size-fits-all mentality and have left one interface for phones and another for everyone else. The major change is to put the “Skweeze” box back on the home page, which can be used to start browsing or searching.

Another change we’ve made is to de-emphasize the mobile versions of websites, again due to feedback. Mobile purists have argued that if there’s a mobile version of a desktop website, that should be front and center on the mobile device. Mobile versions often have severely reduced functionality, however. That’s why as of today, the mobile version (if we know about it) becomes a link at the top of the page, on par with RSS links. Furthermore, for those sites that force users to view the mobile version based on browser detection (USAToday.com is one example), we’ve given our users the option to appear as a desktop browser if they so choose, by selecting the new “Identify as desktop computer” checkbox in their preferences.

Skweezers appears better on the iPhone in this release, now that we’re constraining the page “viewport” width to 320 pixels using a meta tag.

Finally, it seems that some sites simply don’t support JavaScript-less browsers, most notably PayPal’s desktop version. We are experimenting with a subset of our users to allow JavaScript back in Skweezer, and we plan to detect and expand JavaScript and CSS rendering in the future.

(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.

How many sites actually use frames nowadays? It turns out that there are people who track this very thing, such as the company Security Space who recently published their annual Technology Penetration Report. Since it is difficult to see the years side by side, I compiled their reports since 2004 into one matrix to see how things are changing, similar to how Alan Graham did last year. Yes, frames haven’t gone away yet. Sad.

Recently while working on a new ASP.NET 2.0 project, I encountered a JavaScript error which ended with the text “WebForm_PostBackOptions is undefined”. This was confusing because I had simply added a login control to an otherwise empty page. After some searching, I found a blog post where a SharePoint MVP solved this problem by excluding the file “WebResource.axd” from SharePoint processing.

I’m not using SharePoint. However, in the Global.asax file, I add a System.IO.Compression.GZipStream or DeflateStream to the response filter in the PreSendRequestHeaders event if the user agent supports it. A post in the microsoft.public.dotnet.framework.aspnet.webcontrols newsgroup seemed to confirm that the file WebResource.axd doesn’t like to be compressed. While it seems clunky, adding an exception to the filter to disallow dynamically compressing this file seemed to fix this error. I am posting this as search engine bait in case anyone else is having difficulties with ASP.NET validator controls throwing JavaScript errors and doesn’t realize that dynamic GZip/Deflate compression of WebResource.axd is causing the problem.

(Oops, forgot to post this. Moving from “draft” to “published”. Sigh…) One of my high school teachers once told me that he didn’t plan on teaching his son how to type because it would only be a year or two before we’d be interacting with computers by speech and they’d stop including keyboards. In his opinion, typing would shortly become a quaint anachronistic skill. Oh well for that.

The pull of the future is too great, and so for the jillionth time I read today in Slashdot how the cellphone keypad will be reinvented or replaced altogether.

Mobience, which is based in South Korea, has redesigned the ABC and Qwerty key layout, and come up with MobileQwerty. It’s essentially the same three-letters-per-key system as the standard mobile keypad layout, but the letters have been rearranged in a Qwertyesque way to increase efficiency. The other system developed by Nuance is a mobile speech platform that turns speech into text and replaces the keypad altogether.

The first is an incremental layout change, and the second seems as unlikely as my teacher’s Star-Trekian fantasy. I have an idea: what if you could speak directly into your cell phone and then your speech was converted into signals and then those signals were converted to speech on the other end and the listener could just listen to the words without reading them? That would be exactly what we have right now.

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.

Mozilla’s Firefox browser is my browser of choice for testing and developing web applications. The browser itself is not the thing, it’s the extensions that make it so choice for what I do. Just today I had to spoof a referrer header to test whether or not it would be validated by some code, and I found an extension called TamperData to do just that; so far, so good. Not including TamperData (which I assume will become essential over time), here are the extensions I use that I consider essential to my Firefox experience while testing and developing sites:

• User Agent Switcher: fantastic for pretending to be a phone
• Web Developer: lots of very useful page debugging stuff
• del.icio.us: sorry Furl, I’m just used to it
• Adblock Plus: killer
• TimeTracker: OMG, I just browsed for the past four hours! Thanks Lifehacker, now I can fully quantify my guilt.
• Google Browser Sync: helps me stay logged in between WinXP and Ubuntu. Google has all my secret-ist data now but: whatever.
• Extended Statusbar: coolio
• BugMeNot: like Adblock, for annoying sites that require “free” registration.