Supporting IE6 – a poison chalice or the holy grail?

One of the big benefits of Caplin’s browser-based SDP platform, Caplin Trader, is that it can run in virtually any browser without the need for plugins or special configuration.

This is no mean feat for a complex, high performance, low latency trading portal framework written in JavaScript and running to >250KLOC. Although IE8, Firefox, Safari and Chrome are similar enough to make it relatively straightforward to support each of them, IE7 and, particularly, IE6 are a different story. They are riddled with quirks and bugs in their layout, rendering and memory management engines. In addition, developer tool support is starting to lag. Worst of all, their performance is diabolical compared with the recent crop of competitors.

However, IE6 is often one of our customers’ main target browsers by default. Sadly the big financial institutions, and to a lesser degree their clients, run with locked-down and often out-of-date desktop components. This limits their capacity to upgrade or install new browsers, though it’s true that some of the smaller firms are able to do so more easily.

So, should we continue to support IE6? How should we encourage our customers and users to move to newer browsers? What are the benefits of doing so?

Why support IE6?

A large amount of engineering effort has to go into making Caplin Trader components behave and perform well in IE6. To say our developers would rather see it burn in hell is an understatement. A number of them use RobotJohnny’s amusing cartoon for their desktop background, and  I even recently discovered on of our teams had sneaked a joke story card onto their board entitled “Drop Support for IE6” signed by all the developers!

On the other hand our customers need us to support IE6, at least for the time being.  There may be some light at the end of the tunnel as I have heard that a couple of large international investment banks are planning to mass roll-out IE8 by the end of the year.

So in answer to the first question, yes, we will continue to support IE6 for the foreseeable future. Given this, what are the considerations we need to make to do this and how can we encourage users to upgrade?

IE6 performance

Here’s a graph, compiled last September by John Resig, of comparative JavaScript performance across different browsers. You can clearly see that IE7 (he didn’t even bother with IE6!) is an order of magnitude worse than most of the current browsers.

One clear benefit of our continued support for IE6 is that it forces us to produce components and libraries that perform well in that browser. All of our automated functional and performance tests are run across a range of browsers, but IE6 is considered the baseline – if it doesn’t work or perform in IE6 it’s not good enough!

This means that in the newer browsers Caplin Trader literally flies. Using it in FF3.5 or Chrome is really something – faster and more responsive than a lot of desktop apps I use every day!

Getting the most out of Caplin Trader

It’s one thing for our developers to enjoy Caplin Trader at its best, but really we want the end users to have this enhanced experience too! We’ve been experimenting with the best way to encourage them to move onto a newer browser if they can. One approach is to detect their browser and give them an information message that encourages them to upgrade if they can.

This seems like a good, and obvious idea – tell the users to upgrade their browser! However, all is not necessarily what it seems. Mark Trammel, over at Digg, recently did some very interesting user research to try and understand why on earth there was still a steady 10% of users visiting their site using IE6. (Note – this is a retail site, our experience of financial institutions suggests that their IE6 user base is at least 40%, perhaps higher!)

The interesting result (as shown below) is that 3 out of 4 users would upgrade browser if they could:

Why do people use IE6?
Why do people use IE6?

This means that constantly popping up a warning that tells users to upgrade is at best annoying, and at worst may infuriate them so much they stop using the application! For this reason our dialog tries to give both an encouraging friendly message (rather than a command or a warning) and also a way to prevent future popups (a checkbox). Hopefully this provides a good balance and will encourage users that can to upgrade, and those that can’t to put pressure on their IT departments to do so for them…

Poison chalice or holy grail?

In summary, there is a clear cost in engineering effort (not to mention developers’ hairlines!) to continuing supporting IE6. But this is currently outweighed by the benefits of ubiquitous reach and the fact that targeting a browser that’s an order of magnitude slower than most of the others means we consistently produce high performing code, without allowing performance complacency to set in.

5 thoughts on “Supporting IE6 – a poison chalice or the holy grail?”

  1. Interesting arguments raised here, we also do work with financial institutions who expect our framework to support IE6. We definitely do see a benefit in the speed of the applications if we use IE6 as our testing benchmark and this can only help the product.
    However, I would argue that the extra cost and man hours spent tailoring the solution to IE6 is not worth the speed increases. For well under the cost of tailoring the solution to IE6 you could put aside man hours for someone to check the performance of the applications in the latest browsers (all which come with or have available, performance testing suites) and remove any bottlenecks. Thus obtaining the same benefits at much less cost to the company, and dare I say it…frustration ;).

  2. IE6 misrepresentates corrrect and standardized sourcecode.
    So you have to create non-standard layouts and must abstain from using innovative technologies.
    That is definitely not the holy grail.
    Your effort for producing high performance code is creditable but performance consideration does not hit the bull’s-eye.
    “I have heard that a couple of large international investment banks are planning to mass roll-out IE8 by the end of the year.”
    That’s good news. I hope you got the information from a trustworthy source.
    Thanks for your thoughts.

  3. As you suggest in your post, you have no option but to continue supporting a crap out of date web browser, as that’s the browser of ‘choice’ of your clients. I’ve recently moved to a large company and the joy’s of Windows 2000 and IE6! More frighteningly they have just kicked off a two year roll out of Vista as Windows 7 makes it way to the self – enterprise IT policy is obviously ‘skip the good release’.
    There is a problem here for enterprise IT, as the pace of software development continues to get ever quicker, the release cycle getting ever shorter and shorter, how long will command and control from the ivory tower really work? Large organisations are getting more and more uncompetitive by the day.

  4. Timothy/Cymex: Thanks for both of your responses – I think you have valid points regarding the cost of IE6 support.
    It’s absolutely true that supporting IE6 is frustrating. The problem in our space is that it’s absolutely essential to do so, at the current time. If we dropped IE6 support right now our offering would no longer be as compelling for the banks…
    Even when (not if) we drop support for IE6 because our user-base is no longer using it in sufficient numbers, there will still be a requirement to support IE7. And in fact, the performance problem still remains in that browser too. Our experience is that so long as the user with IE6 has either the 5.7 script engine or the GC frequency patch for the 5.6 engine (which in fact we mandate), then the performance of the app is comparable in IE6 and IE7. This means that a focus on performance will still exist, even when IE6 gets finally slain!
    However, IE7 has the huge benefit of not being totally broken with respect to layout, CSS and respect for even the loosest of web standards. This is where a large part of the engineering cost for IE6 support lies. And I think this is where both of your comments are focussing. Right now we have to have separate IE6 stylesheets, and a large amount of time is spent getting layout to work the same in IE6 vs. the rest of the world. For IE7 and above we specify standards mode in our HTML, which actually makes the issue pretty much go away.
    @Cymex: I’m pretty confident that the IE8 migration will happen. And in a roundabout way, I hope that a combination of public sites like Digg and Youtube dropping IE6 support and apps like ours encouraging a more modern browser will cause a critical mass of user lobbying that means this time next year we’ll all be complaining about IE7! 🙂

  5. Rob,
    I totally agree that large organisations are often behind the curve with IT deployments. I think this will always be the case with the operating system (due to a combination of risk-aversity and rollout cost).
    Interestingly though, I think that the browser issue may start to change as more and more “proper” applications move to a web model. I think that some of the more forward-looking organisations are starting to realise that a browser is not just for reading news sites or the corporate intranet, but a true low-cost application deployment environment. Hopefully this, and the fact that a browser rollout is intrinsically simpler and lower-cost than a whole OS, means that maybe things are about to change?
    Paul Caplin, our CEO, has posted an interesting commentary on this exact issue over at Finextra:

Leave a Reply

Your e-mail address will not be published. Required fields are marked *