A Failure of Forward Compatibility

You know, everyone gives a lot of thought to backward compatibility when designing for the Web.  By “everyone,” I mean, “too few people,” and by “gives a lot of thought,” I mean “occasionally has the presence of mind to clearly state at the outset that the Web site won’t support AOL on Macintosh or WebTV.”  Hey, that’s a great thing.  Were I able to get my way and actually quite arbitrary, I’d say make everything work on the most recent version of Firefox only.  However, that’s not going to work for a majority of actual, you know, users or environments unless you’re designing for a captive, corporate-lockdown environment (where the only installed, supported browser is IE 5.5 on Windows NT because it was good enough for my father, dammit!)

However, if your organization is building Web sites or applications, particularly consumer-facing sorts of things, that you expect to have in production for a year or more, you’d better give some thought to forward compatibility.

For a quick example, let’s take this application designed to show current road conditions in Oklahoma.  Here’s what it looked like in Firefox 2.0 (and, I’m told, IE and Safari):

This OK app looks OK.
Click for full size

Well and good.  However, here’s how it looks in Firefox 3.0-3.0.4ish:

Not OK, OK.
Click for full size

It looks a little better in Firefox 3.0.5, so maybe it’s a bug in the browser.  Maybe not.  The end result remains the same: the site looks like crap, and the customer is seething about the quality.  Maybe not seething, but probably not eager to re-engage your organization for further work.

Ergo, as I was saying, your organization, especially if it wants to build long-term client relationships and make lots of easy money maintaining your own code, you ought to think about how you’re going to present this problem (sorry, I meant either challenge or money-from-fool-parting opportunity) before a new browser version comes out.

You could build enough time into your maintenance contract for a complete run through of your site/application and attendant bug fix time, expecting one or two major browser releases a year (for example, Firefox 3.0 and Internet Explorer 8.0; if you count Chrome, and I don’t know why you should, it would be three).  Expecting it to be in a standard 20% maintenance charge might not cover it.

You could mention them at the onset as small projects or bundles to package with it, keeping it apart from the traditional maintenance.

You could handle it internally, hoping that you’re just going to need someone to run through it without problems.

But you ought to have a plan in place, and you ought to be ahead of it.  Your customer or its users should not be the first person to encounter a compatibility problem.  Especially if you think of the customer as a current and future customer and not just someone who added cash flow two years ago and now they’re on their own.

(Link courtesy Charles Hill.)

No Responses to “A Failure of Forward Compatibility”

  1. blrincker Says:

    First of all, what exactly does “Ergo” mean?

    Secondly, I must have misunderstood the sarcasm, because the comment:

    “Were I able to get my way and actually quite arbitrary, I’d say make everything work on the most recent version of Firefox only.”

    Just isn’t something I’d expect to hear out of your keyboard. In fact, I’d expect you to prefer that sites work all the way back to IE 1.0 and Firefox 1.0. You do have those installed on a test machine somewhere, right?

  2. The Director Says:

    You mistake the impulses in me. I would probably not allow the Web at all in my perfect applications, using a risky, stateless, interface-is-open-to- interpretation-by-any-number-of- third-party-software.

    Client-server was risky enough.

wordpress visitors