Save the Developers from the Users

TechCrunch posted a plea to Save the Developers last week imploring users to upgrade their Internet Explorer 6 browsers to Internet Explorer 7.

According to W3 Schools, more than 30% of people browsing the Interwebs use IE6, even though it is more than 6 years old. The gist of the plea is that IE6 is old and has non-standard features that require additional work for web developers.

Although it’s not said it in so many words, the point comes down to cost, i.e. the additional cost of developing for an out-dated browser outweighs the low cost to the user of upgrading one’s browser. Theoretically, at a certain point, the cost of retaining an IE6 user outweighs the incremental value that user adds to your web app.

This makes sense for TechCrunch, since they cover lots of startups. To a small company, the cost of spending development time on IE6-specific issues means time not spent on building new features.

With Mix, we spend a fair amount of time working on IE6 issues, but since it accounts for 35% of our traffic, we feel it’s necessary. Mix has a higher percentage of Firefox users than average, 42%, and IE7 only brings in 15%.

The numbers for Connect, our internal social network, are more skewed toward IE6, where it comprises 45% to 38% for Firefox and 14% for IE7.

The difference between these numbers points to a larger trend. Corporate users managed by IT departments tend to use only officially supported software. Many IT departments have stayed away from Vista, which only runs IE7 and does not allow a back-rev to IE6.

Outside the corporate world, Vista uptake has also been slow. Microsoft pushes an IE7 update to XP users in through its Windows Update, but IE7 doesn’t run on earlier Windows versions that are still common in households like 98 and ME. I suspect that IE6 trumps IE7 in households too, although it might not be as big a difference as within large corporations.

For these segments, i.e. corporate users and casual consumers, the upgrade isn’t so cut-and-dried either because IT won’t support it or because upgrading software isn’t that simple. If you’re building a web app, you can expect to have users on IE6 and old variants of Windows for a long time.

Assuming you want more users, you’ll need to bow to their browser wishes, even if it’s annoying. I’ve used Firefox since version 0.7, and I still hit sites that tell me I must be running IE. That bugs me.

The problem is inertia. When it comes to computers, most people take the “if it ain’t broke, don’t fix it” approach to upgrades. I’m actually wondering why we didn’t take that approach with WordPress 2.5 right now. This is why you can’t tell your users to upgrade or switch browsers and expect them to do it.

If you needed more proof that the Internet is a platform, this should help. Now, when you build a web app, you need to install a host of browsers probably IE6, IE7, Firefox 2, Opera and Safari. You’ll soon need Firefox 3, as it’s scheduled for release in June, and you might still have users on Firefox 1.5 and some versions of Netscape.

In addition, you’ll probably want to have the main flavors of operating systems, too (Linux, Mac OS X and Windows XP, maybe Vista), each with several browsers installed.

Sounds like a lot of work, but if you want to support your users, you’ll need the right environments for testing and development.

You might see where this is going. It started as a post about virtual machines, but I meandered too much around browsers. Stay tuned for that one.

What do you think? This blog gets 59% of its visits from Firefox browsers, 20% from IE6 and 13% from IE7. Are you on IE6, and if so, why haven’t you upgraded or switched browsers?

Do you build web apps? How do you account for your IE6 users? Sound off in comments.

AboutJake

a.k.a.:jkuramot

19 comments

  1. @Tim: This is cool.

    Our problem is that we need to reproduce specific error conditions, usually caused by Javascript differences in IE6. A screenshot won’t cut it, so we have bunches of browsers crossed with the big three O/S.

  2. @Tim: This is cool.

    Our problem is that we need to reproduce specific error conditions, usually caused by Javascript differences in IE6. A screenshot won’t cut it, so we have bunches of browsers crossed with the big three O/S.

  3. When you’ve got essential web apps that don’t support IE7, you stick with IE6. Google “TestDirector IE7” for an example of the problem.
    Maybe we need a separation of rendering engine and browser UI, like the IETab extension for Firefox.

  4. When you’ve got essential web apps that don’t support IE7, you stick with IE6. Google “TestDirector IE7” for an example of the problem.
    Maybe we need a separation of rendering engine and browser UI, like the IETab extension for Firefox.

  5. @Gary: I second that. IETab is a great way to do what I need, and I’d completely forgotten about it after upgrading to FF3. Good stuff.

  6. @Gary: I second that. IETab is a great way to do what I need, and I’d completely forgotten about it after upgrading to FF3. Good stuff.

  7. @Chris: Thanks, it’s a bit tongue-in-cheek. On the one hand, it would be nice to drop IE6-specific development and testing, but on the other, you can’t bully your users.

    Thanks for the pointer to Dean’s work.

  8. @Chris: Thanks, it’s a bit tongue-in-cheek. On the one hand, it would be nice to drop IE6-specific development and testing, but on the other, you can’t bully your users.

    Thanks for the pointer to Dean’s work.

  9. several of our customers, especially the bigger cooperations, haven’t upgraded to IE7 bacause
    – not all intranet apps are working well with IE7
    – the upgrade is not hasslefree
    clear profiles, reinstall certificates, ….

    If IE6 and IE7 could coexist then the switch would have been made

  10. several of our customers, especially the bigger cooperations, haven’t upgraded to IE7 bacause
    – not all intranet apps are working well with IE7
    – the upgrade is not hasslefree
    clear profiles, reinstall certificates, ….

    If IE6 and IE7 could coexist then the switch would have been made

  11. @Oliver: IE6 to IE7 shows the shift caused by Firefox; in the 5 years between the two, MSFT had to shift development to support standards and modern browser features that weren’t in the original product plan for IE7.

    One bummer side effect is that apps built for IE6 never considered other browsers, and they won’t port to more open browsers, including IE7. Ironic.

  12. @Oliver: IE6 to IE7 shows the shift caused by Firefox; in the 5 years between the two, MSFT had to shift development to support standards and modern browser features that weren’t in the original product plan for IE7.

    One bummer side effect is that apps built for IE6 never considered other browsers, and they won’t port to more open browsers, including IE7. Ironic.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.