Monthly Archives: June 2007

iPhone Slowness: Obviously No Workaround is Possible

Posted by on June 28, 2007 Comments Off

iphone_jobs.jpgNot 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.

New Skweezer feature: Find In Page

Posted by on June 28, 2007 Comments Off

There’s a new feature in Skweezer 4.0, which was just released last week, that we call “find in page”, and if I recall correctly the specific behavior was the result of a Kevin Perkins brainwave. The idea is that Skweezer helps skip you right to the content you are looking for in search results. We are not the first to do this, but I think our approach is an improvement. Here’s how it works:

Step 1: after performing a search on “breach” (a spy movie I just saw) I see that the first result I want is the fourth result. If this were on my phone, I could just hold down the “4″ key until my phone navigates to it. As it is, I’m using Firefox to take these screen shots, but with my user agent set to a phone so that the keys show up. FIP demo step 1
Step 2: unfortunately, boxofficemojo.com has a lot of navigation at the top of the page. However, the term I searched on is a link at the top of the first page after the search result, and I can click on it to skip to the first occurrence of the word “breach” in the page. If I searched on several words, each one would be a separate link. If I searched for “breach chris cooper” then each word would be linked separately. Chris Cooper is an awesome actor, by the way. FIP demo step 2
Step 3: after clicking the link for “breach”, the page reloads but skipped past all the navigation to main part of the page I wanted, specifically the first paragraph that contains the word “breach”. I have my answer in three clicks (not counting tapping out the word): Breach made $33 million domestic earlier this year. FIP demo step 3

If I wanted to, I could keep clicking on the term at the top of the page and Skweezer would reload the page skipped to the next paragraph or heading with the word “breach”. This is the functionality that I think Skweezer does uniquely. It’s not as perfect as I’d like but we hope to improve it even further in the future, besides adding in “content folding” as other transcoders do, but without the confusing paging.

Doing What You Do Well

Posted by on June 20, 2007 Comments Off

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.

Clusty mobile searchI 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.

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.

Skweezer 4.0 – Finally!

Posted by on June 18, 2007 3 comments

Skweezer v4.0 home

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. Read more »

ASP.NET Localization Catch-22

Posted by on June 13, 2007 Comments Off

nihongoAgain, sorry for the tech-heavy post, but I like to keep things that I learn here as sort of a permanent notebook. I’ve found many answers to my problems thanks to people who’ve written down their solutions, so it’s payback time for me.

If you’re using ASP.NET localization to allow your site visitors to set their UI language, then there’s an interesting catch-22. When a visitor changes their language settings, they would expect the confirmation message to be in the language they picked. For example, if they’re changing their settings from the default English to Spanish, you would expect the next page they see to say “Gracias”, not “Thank you”. If you do what I did, you might set Thread.CurrentThread.CurrentUICulture to a new CultureInfo object in the event handler of a Save button, then scratch your head and wonder why the language didn’t change.

It turns out that the CurrentUICulture did change, but it was too late: the correct page event to set the new culture is Pre-Init, way before the control event handlers fire. Unfortunately, at Pre-Init, the controls haven’t been loaded either, unlike Init or Load. In order to determine what the new language is supposed to be, you’ll have to extract that value from the request form classic ASP style, which I’ll leave as an exercise to the reader.

Congratulations Ask.com Mobile!

Posted by on June 8, 2007 Comments Off

2007 Webby Awards WinnerThis 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.

The Login Barrier is a Barrier to Growth

Posted by on June 8, 2007 Comments Off

Jeff Atwood wrote about the login barrier a few days ago, and I found it to be an interesting read, confirming our real-world experience with opening up Skweezer to the anonymous masses a few years ago. His basic point is that by hiding functionality behind a login/sign-up screen, sites turn users away. His conclusion:

If your application requires users to log in, don’t underestimate the impact of the login barrier you’re presenting to users. Consider utilizing anonymous, cookie-based accounts to give users a complete experience that more closely resembles the experience that named users get. By removing the login barrier and blurring the line between anonymous users and named users, you’re likely to gain a lot more of the latter.

As onerous as that barrier is to normal users, it is much worse for mobile users who have to triple-tap out passwords through multiple screens to fill in a form, God help them if they misspell their password and have to do it twice. Once we had the courage to open Skweezer to anonymous users, however, usage skyrocketed. In an attempt to quantify “skyrocket”, if memory serves me correctly, we received more unique anonymous users in the month following the switch than we had seen visit Skweezer in the prior two years combined. Oddly enough this eventually caused a spike in registered users also, as Jeff predicted above. Increased usage forced us to grow server capacity, which enabled even higher traffic, which in turn made us serious contenders for larger partnerships, and the cycle continues. Today Skweezer handles hundreds of thousands of users each week on the public site as opposed to just a few thousand subscribers per month. We just celebrated our 150 millionth page. Our revenue today is much higher than the “lost” subscription revenue, not to mention the priceless partnership opportunities that have been opened by our enterprise-grade capacity. You can’t get big unless you’re able to grow. I can’t wait to celebrate the next Skweezer milestones that are coming soon: the first million-user week, the first million-page day, and so on.

Looking back, it is clear that our perceived need for mandatory registration was a relic of our old business model to directly charge users a subscription for access. As for the future of Skweezer account registration, we will continue to allow anonymous site usage and will endeavor to leave sign up for only the actions that absolutely require it, such as saving favorites. My personal wish is to enable OpenID sign up someday in order to reduce the steps of the mobile user’s registration even more.