The Not-So-Rapid Blog

The Web 2.0 crowd are always waffling on about how brilliant web applications are. And in some cases, they're right.

However, in some cases, they're absolutely wrong. Case in point - the idea that the support is easier and cheaper because there's no fat client binary to deploy, just an application on the server side.

Yeah, there's no fat client to deploy. Just testing against large numbers of browsers.

Now, in a corporate environment, you can limit the number of browsers people use and the versions of browser that they use. But for something like my organisation's webmail system, it's trickier. Very much trickier.

People use it from anywhere in the world. On any machine. We get to say which browsers we support, but believe me - and my webserver's logs - that doesn't stop them from trying all kinds of browsers with it. I mean, we tell people that we'll support access from a Windows PC with Internet Explorer 5.5 or higher. What part of that does Opera 9.02 on Mac OS X fulfill, exactly?

But here's what made me think about it seriously - Internet Explorer 7 is out. Yes, that's hardly up-to-the-minute news - but this IS the Not-So-Rapid blog, y'know...

The impact of IE7 for me is simple - not much. We're not deploying it internally on any desktops/laptops, so we don't need to test anything against it. Oh, except anything that's externally accessible.

Like our webmail system. Whoops.

And is DWA compatible with IE7? Um... Maybe.

Now, to be fair, IE7 has been out of beta for less than a week. It's grossly unfair to ask IBM to be able to say for certain that it'll work.

So, to be safe, I've just had to send our support team leaders an email saying that we can't and won't support it until testing has been done.

 

It was in drawing up the timescales for that testing that the folly of Web 2.0's "cheap 'n' easy!" claims became evident.

 

IBM currently say that R6.5.6, or R7.0.3 will support IE7. R6.5.6 will not ship until March 2007, and R7.0.3 currently has no advertised shipping date (they're working on R7.0.2 FP1, which will ship in January - that should give you an idea of the timescales.)

So, if Microsoft push IE7 out as a recommended security update in November or December - as they're expected to - then my application (DWA) will likely be running on an unsupported browser for most of our staff using Webmail. After all, they're not going to turn down a Microsoft recommendation, are they?

Therefore, we have to test it ourselves and get any necessary FAQs/Known Issues out to our support staff, preferably before everyone gets IE pushed to them by Microsoft. "We don't support IE7" is not likely to be an viable option within a couple of months, it seems.

In fact, we already have four people using it, as far as I can see from our webserver logs.

 

So am I just griping, or is this a serious issue?

 

I have no idea. And I won't until I complete testing of IE7 for myself, and have IBM's own testing results via their knowledgebase. At that point, I'll be able to correctly assess the problem. But not until that point.

And that is the point for web applications - any update to the browsers yur application is designed for must be tested, yet ironically you don't actually get to test it until AFTER the update arrives.

 

And this is an improvement over fat clients?

I seem to recall that my fat clients were usually tested on a test network, piloted on a group of test PCs, and then finally deployed widescale once we were s atisfied that there were no problems and the benefits of the new version were cost-effective. Yes, that was expensive. But if something broke, it most likely broke during testing or piloting, and didn't affect the organisation.

I also seem to recall that I had control over it. My testing and piloting was done alongside an already deployed fat client, which was already working.

 

This new Web 2.0 method can't do that. New browsers appear and disappear with each update from the browser manufacturers. They break your apps, unbreak your apps, and it's just chaos.

 

But of course, we can control that in an organisation by using the same QA procedures for the installed browser that we use for any other fat client binary software package. So in most organisations, this won't be a problem.

So let's just treat my webmail application as an abberation, right?

 

STOP RIGHT THERE!

(Dunh-dunh-dunh, I wanna know right know... *ahem*. Sorry. Meatloaf earworm...)

 

We can't just stop right there, unfortunately. Because one of the advantages to those nifty Web 2.0 applications is supposed to be their rapid deployment and open nature. The idea that they're sold on is that if you start working with another company, you can just throw an extranet up for that company and it'll all be fine.

Except we've just been talking about how that won't be fine, because now you're dealing with browsers that are outside of your control.

And what if it's not a problem in your code? What if it's a problem in your platform? What if your current version of whatever framework you have is causing your problems?

Well, just like me, you're now dependent on your own testing, advisories and workarounds until you manage to get an update for that framework/platform from your vendor.

 

Wow. It turns out that the lean, mean, agile Web 2.0 still has the sorts of dependencies that we're used to. With the same sorts of impacts. They just don't like to mention it, because it gets in the way of the AJAX-filled client-end demos.

So your choices, when this happens in Web 2.0, are simple - spend time and money working around it by hacking the framework/platform (if possible) to be compatible, or leave it and do nothing until the promised update. Oh, how familiar.

 

It seems to me that the Web 2.0 people don't have the answers to the same questions that we were asking of the Web 1.0 people over five years ago.

They have shiny interfaces and rapid deployment, certainly. But I don't want to rapidly deploy a fix for something outside of my control that broke. I want it to not break in the first place, by being under my control. That's the point of an available, reliable service. Which, by design, Web 2.0 can't definitely deliver due to its platform dependencies.

 

Of course, none of this means that Web 2.0 isn't viable. It's got some excellent aspects. It's a nice set of goals and ideas that we can re-use even outisde of the traditional Web 2.0 technologies. We should just be aware that it's no panacea.

 

And we should have seen the warning signs anyway. Like all high-noise, low-signal fads, Web 2.0 is promulgated primarily by developers. And I mean no offense to developers, but I can't help notice that you guys almost never have to MAINTAIN what you leave behind. Someone else is always left with the shovel, trying to grow the promised roses.

 

So, the web browser thin-client turns out to need a whole set of shovels that traditional fat clients didn't. Personally, I think they're at least even - browser clients have their own unique set of problems, as do fat clients. The work's still there, just in a different place. There is no panacea of very-low-maintenance clients that never require updates, never break and never need support.

 

And if that surprises you, I own a bridge over the Thames I'd like to sell you.

Assuming, of course, that I have time to sell it to you, what with all the browser testing I now need to do with my webmail application...

 

Comments (6)
philipstorry October 24th, 2006 12:51:00

 Comments
Discussion for this entry is now closed.