Web-based applications with WiFi

The convenience of wireless broadband wipes out one of the constraints that have been holding back web-based applications. Broadband alone wasn't going to do it, because if you had to stay in one place to be able to use your broadband connection, then what was the point of using web-based applications? Desktop or LAN-based alternatives were always going to be faster.

WiFi's combination of broadband and wireless fundamentally changes the equation. Once you can take your broadband connection with you, then the balance tilts decisively in favor of web-based applications that you can access wherever you are, irrespective of their or your location.

I've been experiencing this myself this week while on a business trip in California. For the first time, I haven't had to worry about finding my next chance to dial up and download my email, check out the latest news, upload content to my site and view the latest traffic stats. All I have to do is find a Starbucks, order a coffee, find a seat, and power up. Within seconds, I'm connected to the Internet at broadband speeds. It is difficult to describe how liberating this is if you haven't experienced all the frustrations of doing it the old way.

Broadband is a prerequisite for successful deployment of web-based applications because it allows vendors to provide rich client-side functionality without incurring a performance penalty. Users don't like waiting more than a second or so for the next screen when they're in the middle of using an application, but they also expect an intuitive, supportive user environment. With a sophisticated web-based application — for example HitBox or Xara Modules, both of which I use quite a lot to manage this site — that means downloading a lot of information and code to provide all of the necessary client-side functionality. All the heavyweight processing still executes on the server, but client-specific code needs to execute on the client. Broadband enables that richer client experience without a performance penalty.

There are some caveats to bear in mind when using WiFi. Connections are notoriously insecure, and therefore it's important to think carefully about what you might be unwittingly exposing to an electronic eavesdropper when you're online. You may not be able to encrypt the WiFi connection itself, but you can take steps to make sure you only use secure links (ie SSL connections) to submit user ID and password pairs, for example. The only trouble with this is that most application design (including the Web's default architecture) assumes you're logging on within a protected, firewalled environment, and therefore you submit your ID and password from a non-secure page. Application designers need to think about this a lot harder.

Ample proof that they don't comes when you sign up to open a T-Mobile account to use Starbuck's WiFi service. Much to my surprise, the sign-up process returns a web page that displays both your user ID and password in plain text. So anyone looking over my shoulder as I went through the process in Starbucks (fortunately no one was) could easily have seen both of them — thus compromising one of my secure passwords. This is nothing to do with WiFi, it's simply a T-Mobile web designer having a serious lapse of concentration. People say the Starbucks service is expensive. I think it's not bad, compared to hotel access rates, and considering you get a comfortable chair, nice background music and a pleasant view of the street. But a premium service should do a better job of protecting its clients' sign-on information.