Tag Archives: browsers

Friday Afternoon Skweezer Update

Posted by on August 3, 2007 Comments Off

Skweezer LogoWe 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.

Read more »

The Future of The Mobile Web

Posted by on August 1, 2007 2 comments

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.

Live long and prosperI 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.

Minor Skweezer update today

Posted by on July 18, 2007 Comments Off

Skweezer LogoSkweezer 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.

Opera Mini vs. iPhone – huh?

Posted by on June 19, 2007 1 comment

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

Opera logoToday 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):

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.

The iPhone Might Be Slow and Closed – Awesome

Posted by on June 19, 2007 2 comments

Steve Jobs iPhoneThere 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.

Website Technology Penetration

Posted by on April 9, 2007 Comments Off

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.

Technology 2004 2005 2006 2007
JavaScript 55.87% 59.37% 58.08% 59.77%
Frames 23.49% 18.17% 15.91% 13.90%
StyleSheets 35.06% 39.93% 49.51% 54.00%
Java 2.58% 1.67% 1.64% 1.22%
IFrames 7.72% 12.12% 9.88% 10.76%
GIF Images 61.22% 58.54% 63.26% 62.65%
JPG Images 46.42% 47.25% 54.11% 55.06%
PNG Images 4.11% 6.42% 7.78% 9.68%
Flash/Shockwave 9.55% 8.77% 12.75% 12.77%

Web Tech Trends 2004-2007

Fix for “WebForm_PostBackOptions is undefined” error

Posted by on February 23, 2007 2 comments

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.

The death of the cellphone keypad, once again

Posted by on November 14, 2006 Comments Off

Angry man on phone(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.

Bloglines + Skweezer = Crazy Delicious

Posted by on September 25, 2006 2 comments

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

Read more »

Firefox is my development platform

Posted by on July 26, 2006 Comments Off

Firefox logoMozilla’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: