Most other scientific disciplines require you to learn from others before building upon what they have done. Sir Issac Newton’s oft quoted “if I have seen further it is only by standing on the shoulders of giants” is testament to this.

The inevitable conclusion of this is that the current generation of software developers is likely to repeat the mistakes of their predecessors.

IE 6 Must Die

IE 6 is terrible. Fact. Surely I can’t disagree with that. It breaks all the standards, and requires elaborate workarounds to get anything decent to work. At Caplin we are proud that Caplin Trader performs well in IE6 since many of our customers still use this as their internal browser, but the undeniable truth is that it performs a lot better in modern browsers.

Well, for those of us who remember its arrival 10 years ago, IE 6 was heralded the pinnacle of evolution. Its main competitor Netscape never really recovered from version 4 which supported a document object model (DOM) that few developers would identify with today based around a layer tag. Of course out of the ashes of Netscape literally rose Phoenix, which was later renamed as Firefox, although that’s a different story.

At its height in 2004 IE 6 had around an 83% of the share of the browser market (with another 8% held by IE 5). Such dominance that it is unsurprising that a large number of web developers only focussed on making their pages work in IE, including making use of non-standards behaviours and proprietary APIs that would later come back to haunt us.

Mobile Safari – History Repeating Itself?

Does Mobile Safari equal IE6?

Fast forwarding to the era of the mobile web, the question arises as to whether we are repeating the mistakes of the past by targeting our mobile web efforts purely at Mobile Safari?

There is little doubt that the popularity of the iPhone and iPad has ignited the rapid acceleration in interest in the mobile web. However only focusing on making web pages optimised for these “iDevices” has the potential to exclude a large number of your users from getting the best possible user experience.

The latest figures for Mobile Safari (excluding the iPad) show that it only has a 22% share of the mobile browser market (data from March 2011). This percentage has been slowly decreasing over the past couple of years and is likely to continue as the number of smartphone owners increase, with the greatest growth at the cheaper end of the market, thereby diluting the “iDevice” share.

To be fair to Mobile Safari, it is certainly more standards based than IE 6 ever was, therefore sites designed to work on the iPhone/iPad are more likely to work on other mobile devices.

However failure to test on other devices is likely to produce, at best, sub optimal experiences for users. As my colleague Dominic Chambers’ recently blogged, there are still many differences between the various mobile browsers. Progressive enhancement remains the web developer’s best weapon to cope with this.

Learning From Past Mistakes

The hypocrisy of condemning websites that only work on IE 6 compared to those being written now only for Mobile Safari is stark.

At the moment there may be good justification for only focussing on Mobile Safari (despite its 22% market share). However back in 2004 a number of web developers used similar justifications for an IE 6 focussed site (because of its 83% market share), and look where that got us.

It looks like there would be some administration overhead to set this up so the old sites/applications specify that they need to run in IE6 mode, but at least this gives people an option of running a newer browser. This put the responsibility in the hands of the users (or administrators) of old in house applications that require IE6 rather than in the hands of the software vendors writing new exciting applications that at the moment have to spend a lot of effort being compatible with IE6.

Will IE9 help us at Caplin, or other people that have struggled with supporting IE6 users for so long? Unfortunately it won’t help much.

We have mentioned problems with IE6 before, Browser wars: the ceasefire is over and Supporting IE6 – a poison chalice or the holy grail?. The problem is IE6 users in large corporations that are unable to upgrade, sometimes due to there being applications that need IE6, or they don’t want to pay to upgrade to the latest version of those applications that support newer browsers.

Could IE9 entice them though? Microsoft seem to be quite keen on HTML5 now, maybe people will be encouraged to upgrade? Well, yes, some people will – but the problem users on IE6 are almost certainly running Windows XP. What’s the one thing harder to get upgraded in a big corporation than IE6? The operating system, and guess what, IE9 is not supported on Windows XP.

So people stuck on IE6 are probably stuck on it for even longer now if they are on Windows XP – apart from those corporations that will upgrade to IE7 or IE8, which is their only option if they are on XP and not able to move to Firefox or Chrome.

There has been lots of buzz and some really interesting bits coming out so far including Silverlight 4 RC, Internet Explorer 9 preview (with HTML5 and CSS3 etc.), Windows phone information, etc.

Scott Hanselman has posted a great roundup of the announcements and keynotes.

Rumour on the street has it that, finally, the investment banks are going to start abandoning IE6. Barclays are allegedly going to do an enterprise-wide rollout of IE8 in Q2 of this year (put back from Q3 last year). Even more surprising (and impressive) is a rumour that Standard Bank of South Africa are going to ditch Microsoft browsers completely and move to Chrome for their corporate standard!

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:

JS Perfomance comparison

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. Here’s the message that’s coming in the next version of Caplin Trader:

New browser upgrade hint popup

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?

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 ubiqutous 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.